Hacker News Reader

Comment by MichaelGG | Hacker News Reader

It is confusing to me, too, why a Ruby or Python user would look at Rust (for the same use cases). Unless they want it to replace C for native extension libraries: then it makes a lot of sense. But I'd expect a Python user to pick up Go before Rust, simply because Go is more like Python (managed runtime).

Rust comes up a bit short, I think, when looking at some functional styles. Function composition doesn't look very easy in Rust, so a lot of the concise code you might expect in a functional language is much more work to express (no custom operators either). Not that I blame them: having no-overhead (no GC, but also no spurious code/allocations in general) yet fully safe as a core design goal is a huge constraint that no one else has had success under.

View on HN

No-one wants a runtime just for the sake of it. Go gives very little in return - it's less safe than Rust and, despite automatic memory management, not appreciably more expressive.

I think the advantages of Go lie in making it easy to reason about performance/operational behaviour (which Rust and OCaml have, but is perhaps missing from Haskell), and in having a well-supported syntactic metamodel (scala.meta may ultimately become such a thing). With some recent emphasis on code generation it almost resembles the lisp traditional.

But I can't see Go itself working out in the long term. The concurrency model is too ad-hoc, and the language too tightly coupled to it. And in a language that's already gone to the trouble of a static type system, the cost:benefit for generics is insanely good.

> It is confusing to me, too, why a Ruby or Python user would look at Rust (for the same use cases).

Perhaps it is because they are not looking at it for the same use cases, and more as something to augment their toolkit. Rust makes it possible to be a decent systems programmer without having to spend a decade of acquiring the war wounds to become a great C or C++ dev. In the past, the only real option for those devs if they wanted decent performance was Java, and it's really hard to get Java to talk to Ruby or Python, and it's also hard to understand what the JVM is doing under the hood. Rust is now a possible alternative.

Here's what Armin Ronacher, the creator of Flask, thinks of Rust and how it compares with Python: http://lucumr.pocoo.org/tags/rust/

Note the articles aren't listed in order. Rust for Python Programmers is the latest, written four months 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.

Have you looked at the other four languages I mentioned, e.g. OCaml?

Yes, I discussed those in another comment: 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.

> 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.

> It also forces us to figure out exactly what our program needs to do, before we can implement it.

Note that the pronoun "it" in your sentence could easily have antecedents such as "assembly language" or "Brainf*".

> But I'd expect a Python user to pick up Go before Rust, simply because Go is more like Python

Python + Go is hardly any better than just Python. Go is easy to learn but the reward is small.

Python + Rust, otoh, increases the types of problems you can solve and can dramatically improve your skills as a software developer.

As a Python developer interested in Rust, for me it's the logic is this: Rust allows me to learn a systems language to complement high level/scripting language without having to learn C/C++ which I find ugly and full of legacy cruft. This is important since Python encourages you to build native libraries for performance or low-level interfaces. The Rust programming style is also more familiar than "true" functional languages.

Languages like Go are tricky for Python extensions because they include their own runtimes, which means you have 2 runtimes with garbage collectors to deal with.

In a more "fuzzy" sense, I think there's also a philosophical appeal in the way Rust promotes human-friendliness over theoretical purity. Python promotes one correct and logical (to humans) way of doing things and I feel Rust is designed with the same ambition, even if the requirements of low-level memory management necessarily make it more complicated.

Reply on news.ycombinator.com