Comment by tinco | Hacker News Reader

Comment by tinco | Hacker News Reader

Being able to port a 20 line Python script to a 20 line Rust is the holy grail. Surely Rust has the ambition to one day achieve that, but it is by no means the main priority nor the original design goal of the language.

Justin criticizes the file_double function, it being complex with nested maps and conditionals. All of this complexity is also in the Python code, just hidden away in abstractions, the library and the virtual machine. Rust, right now, is still very explicit and revealing of inherent complexities. This code is exactly why you should use Python and not Rust for this kind of little script. One day the Rust developers hope Rust will be comfortable enough for you to consider using Rust in this situation, but it won't be soon.

The point gets softened a little by the remark that it probably would not be a picnic in C either, but I don't think even that is true. C still allows you to be very expressive, it would not encourage using those maps or even half of those conditionals. Rust is just that more explicit about complexity.

That said I honestly believe Rust is the best thing that has happened to programming languages in general in 20 years. Rust is rocking the socks off all the non-web, non-sysadmin fields, soon its community will make good implementations of almost every hard problem in software and Rust will be absolutely everywhere.

The file_double code was, IMO, quoted completely out of context. If you go read the error handling section, that code is used as a motivation to the next section, where you get gradually introduced to more economical error handling.

The error handling chapter is... Really big. Because it tries to explain everything from first principles. But it does include explanation and examples for using easy error handling as well, whose syntactic noise and level of boiler plate come quite close to Python.

Too much kool-aid. Most programmers are not writing system code and they'd be much better served with languages like Go, Nim, and D. In fact, the example the author is trying to port over would have been much easier in Nim.

The actual question is then about the author learning a new paradigm and way of expressing system code. If that is the case these are just pains he has to go through because Rust will never be like Python for quick and dirty scripts, nor should it be.

can nim handle gc across threads yet?

Yes. Use the Boehm-Weiser GC. Very simple.

".. soon its community will make good implementations of almost every hard problem in software and Rust will be absolutely everywhere"

This is very unlikely. I can't see when Rust would solve the problems Julia (for example) does. And vice versa of course.

Nothing wrong in a language tackling a few domains really really well and not trying to solve "every hard problem in software"

Rust hasn't made significant incursions into math modelling or industrial processing. It's advantages are slim there. Embedded will fracture into network interfacing and realtime where user input is less hostile, more predictable and doesn't require extensive constraint.

Isn't it this kind of thinking that leads to sql injections in number plate readers?

I'm hoping for matrix/tensor primitives, like Fortran. Rust might be a good replacement. The C interop would also be useful for Fortran interop.

What do you mean about industrial processing? PLCs?

Many R/Python libraries for statistical programming use C/C++/Fortran under the hood, for the stuff that needs to be fast.

I'd like to contribute to many of these packages, but have little interest in learning the languages. Rust could provide a good replacement (and one which is more productive for people used to higher-level languages). There hasn't been much uptake so far, but I'm hopeful.

Reply on news.ycombinator.com