75
Done!
I like Python for quick and dirty stuff
There is one more little secret that not everyone knows:
You do not need lifetime annotations and full borrow checking if you do not care to press out the last drop of performance out of the CPU, or if you just draft experimental code.
In fact, you can very much program in a style that is similar to python:
- just pass function arguments as references, or make a copy (if you need to modify them)
- just return copies of values you want to return.
This makes your code less efficient, yes. But, it avoids to deal with the borrow checker before you really need it, because the copied values get an own life time. It will still be much faster than Python.
This approach would not work for heavily concurrent, multi-threaded code. But not everyone needs Rust for that. There are other quality-of-life factors which make Rust interesting to use.
... and of course it can't beat Python for ease of use. But it is in a good place between Python and C++. A bit more difficult than Java, yes. But when you need to call into such code from Python, it is far easier than Java.
For software developers, it is better to have frequent tiny changes that can break things, than a big mess of breakage.
Do you hate distractions? Do you love steady improvements? This will affect your preference and judgement about rolling release.
The same can be true for desktop users. It also depends on how stable your software is. If you use mainly vim, dwm, and LaTeX, very few changes will break your flow.
EDIT: also, there are very few languages less productive and beginner-friendly than C++ in my opinion.
I am a professional C++ developer with 20 years of experience and have worked in about eight other languages professionally, while learning and using a dozen more in hobby projects.
I agree with you here. The only areas where specifics are worse are package management in Python, and maintainability of large SIMULINK models.
The function composition style comes from functional programming and Rust's OCaml heritage. It can make it easier to reason about invriants and possible sets of values of the result of a computation step.
Rust transforms these to the same or a close equivalent of hand-written loops.
Similar methods are used in specialized, high-performance C++ libraries such as blitz++ and Eigen. But if you mess up bounds, you will get UB with them.
The one thing I really did not enjoy, subjectively, with Rust, is that writing "C-style loops" comes with a performance penalty because there are bound checks happening, so the idiomatic version of a loop in Rust usually involves iterators and function composition.
IIRC you can speed up such checks by putting an assertion in front that checks for the largest index - this will make repeated checks for smaller indices unnecessary. Also, bound checks are often not even visible on modern CPUs because speculative execution, branch prediction, and out-of-order execution. The CPU just assumes that the checks will succeed, and works on the next step.
Generally no. As soon as a class hierarchy becomes moderately complex, implementation inheritance makes code very hard to maintain, because you need to read the whole stack of classes to see what a single change will actually do.
Rust has another system, traits and trait implementations.
Enjoy! I don't know what you used to seriously program on but I am willing to bet that the ownership paradigm that it enforces is going to feel at least moderately new to you, unless you forced yourself to code that way anyways.
Thinking about ownership is the right way e.g. for C++ as well, so if one has coded professionally in larger systems, it should not be too alien.
One still needs to learn life time annotations. So, assuming that you know, for example, C++, it is an a bit larger hurdle than picking up Java or Go, but it is worth the time.
In many aspects, Rust is far more productive and also more beginner-friendly than C++:
- far better compiler error messages
- a superb and easy-to-use packaging system
- Unicode support
- support for unit testing right in the language
- strong support for a side-effect-free or "functional programming" style which is great for testing and tasks like data analysis or parsing
- better modularization
- avoids implementation inheritance, and the trait system is a bit different but superb
- no undefined behavior (in safe Rust) which means nothing less than that the code does what it says - and this is extremely useful in larger projects
- great support for safe concurrency
- the language and library frees one to think about interfaces and algorithms which is where the big wins for performance are hidden (and IMO one of the key factors for the astounding success of Python).
I could go on... but I need to do other stuff
A nice editor for both Markdown and reStructuredText with minimal dependencies, which allows to change seamlessly editing between rendered text and source text. Like one has a tab for source text, and one for rendered text, and can change and edit both tabs.
Gollum wiki has something similar but it could be better. Maybe even having two panes side-by-side, left source, right rendering, and one can edit both and / or flip them.
Also, I think one could find a ton of small useful improvements in Zim Wiki. I use it all the time to gather and structure information on poorly documented stuff, which is very often needed when working with legacy software, and it is great and extremely useful but not perfect.
I guess that still depends on the maintainer which is responsible. But since drivers often deal with untrusted data, which can lead to security exploits, this makes a lot of sense.
Great news! So, we can expect that European industrial companies will start to pick up Rust around 2035 and it will become kinda mainstream around 2045... shortly after the heat death of ~~the universe~~ Southern France. ;-)
3
855
Chat Control 2.0 has passed the first round of approval
(discuss.tchncs.de)
cross-posted from: https://discuss.tchncs.de/post/48813307
!!! IF YOU ARE AN EU CITIZEN, PLEASE DO THE FOLLOWING FORM !!!
https://fightchatcontrol.eu/#contact-tool
Be especially sure to select your home country's permanent representation in the Committee, but selecting everyone the website proposes is a very good idea (and done by default).
Raise your voices and flood their inbox, this might be the last chance we ever get
view more: next ›
HaraldvonBlauzahn
joined 8 months ago
Other strategies might be better suited. For example, say you work on automobile steering software and management is cutting so much corners that things become unsafe. In that case, it might be best to write a mail to the legal department and naively ask some questions about safety and technical concerns. Then print it and take it home.
In general, if you can't ethically agree to a commit in open source software, it should be possible to withdraw that contribution.
There might be other cases where autorship or contribution to some software might expose you to discrimination. In that case, I think it is perfectly ok to work anonymously.