4 ms·
I'm coming from having written mostly Python, Ruby, and Scheme for my past three jobs. I am not looking at Rust merely for replacing C for native extension lib
by lambda 11y ago
I'm coming from having written mostly Python, Ruby, and Scheme for my past three jobs.
I am not looking at Rust merely for replacing C for native extension libraries.
I'm looking at Rust for having a good static type system; I'm getting very sick of dealing with "hashly-typed" data in Python, or all those places where I forget a yield and so never actually block on a deferred, causing errors at runtime rather than just not compiling (sometimes type errors, if I try and access that value, but sometimes just things executing out of order, which are much harder to debug).
I'm looking into Rust for having a good multi-threading story. I've been doing plenty of event-driven programming in Python (using Twisted), which is great for non-blocking network I/O, but there are other ways to block on long computations, disk I/O, blocking in native libraries, and so on. At some point, you really do need good multi-threading, and Python falls fairly short in that department. You can hobble by, but it's not pretty.
Go doesn't solve either of these problems. It has slightly more static typing than Python, but without generics, it's pretty limited. It doesn't really do anything to prevent nasty race conditions with shared data structures in multithreaded code. Sure, if you are disciplined and use only message passing of immutable data structures, you can avoid some problems, but part of the point is that when programming in the large, with multiple people working on something over multiple years, it's easy for some mistakes or bad assumptions to creep in an wind up causing problems.
I've taken a look at Go, and it never really appealed to me as a direction to move in. If I want message passing concurrency in a GC'd language with a runtime, I can use Erlang/Elixir. If I want just simple, pretty code without much multithreading, I can use Python. If I want raw performance and low level access, I can use C or C++.
Rust actually does offer advantages over all of these. It does have it's complexity, so for quick and dirty scripting tasks I'm likely to stick with Python. But especially once Rust gets an easier to use non-blocking I/O story (since event based non-blocking is great for networking), I'm going to be seriously considering it simply as a replacement for Python for any large project that will be worked on by several people over several years, just due to the additional safety and static guarantees it offers.
- lmm 11y agoHave you looked at the other four languages I mentioned, e.g. OCaml?
- lambda 11y agoYes, I discussed those in another comment: https://news.ycombinator.com/item?id=10290874 https://news.ycombinator.com/item?id=10290874 In this comment I just discussed Go, since that's what the parent comment mentioned. Haskell and OCaml are both great languages, but to a lot of people, they come off as much more "academic" or "ivory tower," and require a lot more effort to learn to use effectively for people who are not used to functional programming. Couple that with the fact that they still use GC, so are a lot harder to get consistent low-latency performance as well as being a lot more difficult to use for any applications where you need to embed them in other applications, and they just don't offer enough of a reason to move to them over the current combination of "Python for high-level stuff, C or C++ for low-level, performance sensitive stuff". Rust, on the other hand, promises to be effective for the low-level, performance sensitive stuff, is good for embedding in other languages, offers the additional benefit of giving statically checked memory safe multithreading with shared mutable data structures, and provides a powerful static type system for effective programming in the large.
- runeks 11y ago> Haskell and OCaml are both great languages, but to a lot of people, they come off as much more "academic" or "ivory tower," and require a lot more effort to learn to use effectively for people who are not used to functional programming. I think the problem is that people who are used to C++ and Python approach Haskell as if it were just another language, in that category of languages. You need you learn some new stuff in order to really understand Haskell, but that's hardly a fault. I actually think non-programmers would have an easier time learning Haskell than experienced programmers. There really isn't anything inherently difficult in Haskell. It just requires a different approach. It can be annoying to write Haskell programs sometimes, because it's so hard to get it to just compile. But that's the entire point: the fact that the compiler can do so much when we restrict ourselves to pure functions. It also forces us to figure out exactly what our program needs to do, before we can implement it, rather than build on top of proof-of-concepts, as is typical with Python.
- kazinator 11y ago