The struggle with Rust

https://ayende.com/blog/176801/the-struggle-with-rust?Key=ed64b64e-91c9-41be-ba0f-348641976e20

by mpalme • 9 years ago

200 295 9 years ago

grabcocque• 9 years ago

These kinds of articles are always hostages to fortune. Because I guarantee somebody, any second now, will demonstrate that what the author wanted to do was trivial, and if he'd spent a bit less time trying to start flamewars on Hacker News he'd have discovered it.

Not me, by the way, I don't know rust. But I reckon it'll be about three comments down.

BozeWolf• 9 years ago

It is already in the comments at the site of the article.

To quote "Will": "On the bright side it is possible to implement a pretty elegant solution to this particular problem"

mpalme• 9 years ago

But in any case, it will be helpful for other newcomers to Rust because they are likely to run into the same challenges.

Amezarak• 9 years ago

I think part of the problem is this: if you're say, a C++ programmer, you can write C++ in most other languages and have a working program, even if it's not idiomatic.

You can't in, say, SQL, Rust, or Lisp. That doesn't make them a priori harder than other languages, it just requires a shift in thinking, whereas if you're jumping to say, Java after C++, you can get started right away and hopefully pick up idiomatic Java as you go along.

Instead of thinking "here's how I would implement this in C++, now how do I translate that to Rust?" you have to cut that part out and think "how do I write this in Rust?" I mentioned SQL because that's where that really, really, clicked for me: if you ever write SQL and think imperatively, you are doing it wrong, you have to think in sets, and once you do that, SQL is the easiest and most natural thing in the world. The Rust Book is pretty good, but I think it would really benefit from an in-depth section early on explaining how writing in Rust requires a paradigm shift in your thinking, and exactly how to think Rust-ically. I'd write something here, but I'm still learning how. :)

kazagistar3• 9 years ago

(SQL is still kinda a crap language for dealing with sets, because the synatx does not represent the order in which set operation are applied or anything else; instead, they went with the "cobol" strategy of trying to make things like english.)

But I agree with your premise, certainly.

steveklabnik4• 9 years ago

We're re-writing the Rust book at the moment: http://rust-lang.github.io/book/

It doesn't explicitly have a section like this, exactly, but there are several "thinking in Rust" style chapters towards the end.

gcp11• 9 years ago

If this were a C++ problem the author wouldn't have blogged because the answer would've been on StackOverflow.

sambe2• 9 years ago

Not sure if your comment was intended dismissively/jokingly, but I think also somewhat insightful. I find myself much less often really thinking about how to do something these days; if it seems remotely standard or potentially troublesome I google it. As a result, I spend less time thinking "algorithmically" about low-level stuff and probably lose something. But I also spend more time thinking (perhaps algorithmically) about the business domain, and am ultimately more productive.

killercup• 9 years ago

That's why I'm really looking forward to the point in time where "non-lexical borrows in Rust stable" and "clippy installable via rustup" converge.

adwhit• 9 years ago

These sorts of articles are starting to pop up a bit more frequently, presumably because Rust is starting to get a bit of traction. The theme is "I know $LOW_LEVEL_LANGUAGE therefore I should be able to program Rust. I spent a few days and couldn't. I don't like Rust."

Unfortunately, things aren't that simple and Rust really is different from other languages. It takes months of steady investment (and yes, frustration), but the payoffs are spectacular. I would urge the author to persevere. In the meantime, the community is very helpful and I'm sure you'll get lots of useful advice on the back of this post.

sametmax4• 9 years ago

Exactly. The fact that rust is easier than most low level languages made the high level language crowd forget than bare metal programming IS HARD. Try to do a big project in C++ or C and you'll see that making something that is production worthy takes months.

Besides, as a Python trainer I can make you productive in it in a few days. But it will still take a lot of time for you to be good at it. The only difference with rust is that the first "reward stimuli" comes later down the road because you need to be better at it than at Python to make use of it.

trishume• 9 years ago

Agreed. Rust is different from other languages in that it is HARD to learn. It took me 3 projects and thousands of lines of code before I finally felt like I'm okay at Rust. Each project involved tons of compiler fighting that I now know how to avoid or solve.

The problem is that instead of a general technique for solving borrow checker issues, every issue has a different specific technique. Hash map matches (like the article) require the entry API. Multiple mutable pointers into a buffer require either using a typed Vec or Vec#split_off. Cyclic data structures require an Arena or Rc<Refcell<>>. String casting issues sometimes require .map(|x| &x). Global state requires lazy_static. Nice error handling requires error_chain. When you run into problems with "Send" you need a Mutex. The list goes on...

It's like pure lazy functional programming in Haskell in that unlike other languages you can't just pick it up based on previous knowledge and patterns. You need an entirely new toolbox of pure algorithms and data structures, or in this case borrow-safe algorithms and data structures.

alkonaut• 9 years ago

Agreed. Rust is different from other languages in that it is HARD to learn

But do you learn to code in a different paradigm where you don't struggle by iterating on a compilable and runnable piece of code, but rather struggle on iterating on a non-compilable piece of code and "once it compiles, it works"?

ajmurmann• 9 years ago

The issues and solutions you list sound super valuable. Do you know if there is a write up about those issues somewhere or did you just learn through blood and sweat?

jononor• 9 years ago

Are these strategies for solving borrow checker issues documented anywhere? Sounds like a case for which a best-practice reference would be golden.

lhnz• 9 years ago

  > Cyclic data structures require an Arena or Rc<Refcell<>>.

Is there a way of creating a cyclic data structure that doesn't involve these types?

I ask because I used the latter recently, after struggling to create lifetimes that were acceptable to the compiler. I only found it when I searched for 'cyclic data structures rust' on Google.

It would have been much nicer if the compiler could have noticed that I was trying to create a cyclic data structure and then have informed me on the different ways of doing so. Perhaps a misunderstanding on my behalf, but the error messages that I previously received felt like they were sending me on a wild goose chase.

I still don't think writing Rust code is hard, but there are definitely improvements which could be made to the compiler error messages.

wyldfire• 9 years ago

Agreed. Rust is different from other languages in that it is HARD to learn.

Don't you think C/C++ are hard to learn too? C++ has a vast surface area and I think it's unlikely that most people who use it understand much of it. When I code in C, I feel like I have to be paranoid because it's so easy to forget a path that doesn't recover allocated resources. But if I'm not paranoid, I just leak the resources and don't care about it (ever, or until many months or weeks later when the problem's discovered). So the easiness is illusory IMO. It seems to me that all of those other resource leaks are just leaking too slowly for us to discover yet.

Each project involved tons of compiler fighting that I now know how to avoid or solve.

As frustrating as it is, it's easier than struggling with heisenbugs. Those can easily eat up days trying to reproduce issues.

rubber_duck11• 9 years ago

It takes months of steady investment (and yes, frustration), but the payoffs are spectacular.

This was the exact same thing I kept reading back when functional programming was becoming in vogue - people were pushing for Haskell, saying that purity and laziness were amazing, type system could almost prove correctness at compile time, etc. etc. You just need to meditate deeply on category theory and draw direction graphs to become one with types and all would be revealed to you.

Hybrid functional languages got adopted in the meantime (F#/Scala/Clojure come to mind) and a lot of FP was adopted by OO languages - it wasn't pure or fancy but it solved problems in an accessible way. Most people still don't use Haskell.

I'm hoping Rust doesn't go down this path as I want a replacement for C++ badly. But saying "you need to spend a few months to get intimately acquainted with the language" is just not going to work in practice if you're hoping about breaking in to the mainstream.

gcp11• 9 years ago

I'm hoping Rust doesn't go down this path as I want a replacement for C++ badly.

So that's opposed to C++'s "It takes a few years to get acquainted to the language enough that people would want your stuff in production code"?

Nobody hires junior C++ programmers.

the_af5• 9 years ago

You just need to meditate deeply on category theory and draw direction graphs to become one with types and all would be revealed to you.

In order to just use Haskell you don't need to meditate about category theory at all.

Some things do require months -- or even years -- of studying. Like, for example, C++, Java or whatever was your first programming language. There is absolutely no getting around that.

ique• 9 years ago

So you're saying it's perfectly feasible to become an expert C++ programmer over a weekend, but it's completely impossible to learn Haskell?

bpicolo• 9 years ago

I'm a big fan of hybrid functionals. I think being able to fall back to somewhat imperative code makes sense on occasion. Some things are better expressed in either paradigm, and that's OK.

crdoconnor• 9 years ago

The clincher for me with respect to rust is that I see a steady stream of useful software being developed in it.

I never really saw that in Haskell and I've heard people talking about it for at least 15 years. That indicates that something is missing.

vertex-four2• 9 years ago

You just need to meditate deeply on category theory and draw direction graphs to become one with types and all would be revealed to you.

Luckily, Rust's community is much more pragmatic - but their goals are still to create something substantially different from existing languages because existing languages are not enough to guarantee what Rust guarantees.

the_duke2• 9 years ago

I think the problems with Haskell are quite different than the ones with Rust.

Haskell suffers more from being a research playground, bad documentation for both the language and it's libraries, confronting you with many unusual concepts (type theory, monads, laziness,...) and, as a pretty old language, a lot of legacy cruft that makes a lot of things awkward (string handling is the prime example).

Rust wants to be a widely used language and while it has some aspects that are not trivial and quite often make it verbose and awkward, in reality it's not really that different from, let's say C++, apart from the borrow checker and lack of classes.

I don't think much will change about Haskell, but I have hope for Rust that it will steadily improve.

lmm5• 9 years ago

F# and Scala are halfway to Haskell - maybe 3/4 of the way even - compared to the languages that were popular at the time (and the more experienced people get the more Haskelly their code tends to become). Hell, those popular languages are about 1/3 of the way to Haskell now. Any serious language these days has lambdas, map/reduce/filter, and type inference; most have list comprehensions and pattern-matching.

You're right that there needs to be a path up to there though. The reason Scala really worked for me is that it let me make my way up to a very Haskell-like style while remaining productive every step of the way.

omouse2• 9 years ago

To get any programming done, you have to learn certain things, you can't complain that it takes weeks to learn a new programming language and months to assimilate it's model of thinking.

But saying "you need to spend a few months to get intimately acquainted with the language" is just not going to work in practice if you're hoping about breaking in to the mainstream.

You mean it's okay for everyone to struggle to work with JavaScript for years and years trying to come up with an OO system and a module system and trying to just bundle the files for the browser, but it's not okay to spend months on getting intimately acquainted with the language?

Who cares if Rust becomes mainstream, we only need the best open source code to use it (like Firefox and the other C/C++ libs that are thinking of porting over). We don't need it to be mainstream, we just need it to be possible to learn it within a reasonable timeframe (less than a year).

sidlls2• 9 years ago

All the "hard" things a user learns in Rust have to be learned in C++, too. It's just some things are learned in a different way in Rust (e.g. fighting with the borrow checker) than they would be in C++ (e.g. proper use of const(expr), references, moves, etc.).

wiremine• 9 years ago

It takes months of steady investment (and yes, frustration), but the payoffs are spectacular.

In my experience, most developers can't or won't put in this sort of investment. Which leads me to wonder what fields/niches will Rust land in?

This might change if, as other commenters have stated, it is taught as a first or second language, but that doesn't seem likely anytime soon...

gcp11• 9 years ago

Rust's niche seems very clear: C++ programmers that need better tools. This is an audience that should be willing to make a time investment, and understands the trade-off, for the most part.

noxToken• 9 years ago

it is taught as a first or second language

This is interesting. Many universities teach Java, C, C++ or Python as a first language. The headache that many first year students suffer from these basic (relatively speaking) languages is readily apparent. Rust is very strict, and it requires an entirely different mindset to use. I wonder how this would fare with students who have a clean slate.

JepZ2• 9 years ago

I never wrote a single line of rust, but when a language is hard to learn, the compiler error messages are probably just bad in terms of comprehensibility and offer the user no direct solution.

valarauca1• 9 years ago

    when a language is hard to learn, the compiler error 
    messages are probably just bad in terms of 
    comprehensibility and offer the user no direct solution.

I don't want to sound snarky but Rust really does have amazing error messages, and they literally do offer direct solutions/suggestions using literal examples and raw samples of your source code.

It even offers the `rustc --explain EXXXX` (where XXXX is an error code) that give an in terminal deep dive + examples on why this is an error/how it is failing.

    I never wrote a single line of rust

sdenton4• 9 years ago

Yeah, I've seen a number of posts like this for go as well. I wonder if it may be useful to start programming in these languages with a more experienced buddy to ask questions if and do some coffee reviews, to reduce time spent banging one's head on the keyboard, and get better acquainted with the language's idioms.

nercury2• 9 years ago

Yes, it is hard to use mutable shared values Rust. This is exactly the point.

creshal• 9 years ago

So how do you avoid it?

nikbackm• 9 years ago

Use unsafe or wait for the improved borrow-checker?

nercury2• 9 years ago

Well, you either uniquely mutate, or keep the value immutable.

Usually you construct the pipeline to switch between these as you need. If you need to share the result from one mutation to the other, you can do it by passing a simple immutable value that communicates the state change to other mutation, but don't try to do both at the same time. This is simply a good practice enforced at compile time. Of course, sometimes these rules prevent some valid cases, but overall it is worth it.

If we are talking about HashMaps, the Rust std lib has useful Entry api to for get-or-insert use cases. In rare cases where you need to share the value between different parts of the system, there are primitives you can wrap your value in and enable reference counting, as well as internal mutation (even if wrapper is immutable, it provides safe api for mutation). In cases where the concurrency is needed, there are mutexes, channels, and multiple libraries to parallelize the code (like rayon or crossbeam).

burntsushi5• 9 years ago

There's no single solution to the problem, which is perhaps one reason why folks new to Rust might stumble over it. You can't just get two aliased mutable pointers to the same region of memory in safe code. Sometimes the borrow checker can't quite see through everything. Consider this trivial example, which will fail the borrow checker:

    let mut owned = vec![1, 2];
    let x = &mut owned[0];
    let y = &mut owned[1];

That this fails might come as a surprise to a lot of folks because it's easy for a human to see that it's perfectly safe. Namely, neither `x` nor `y` refer to the same point in memory, but the borrow checker still forbids it.

What's the solution to this problem? Well, it depends on what problem you're trying to solve. One popular approach is to change the representation of your reference from a pointer to an index:

    let mut owned = vec![1, 2];
    let ix = 0;
    let iy = 1;

Now, in order to dereference your reference, you need to do `&mut owned[ix]` instead of simply `{STAR}x`. There are various trade offs to this choice of course, including the fact that `&mut owned[ix]` will likely be bounds checked. (Bounds checking could be turned off by using `unsafe { owned.get_unchecked_mut(ix) }`.)

But there are more solutions to this problem! Here's another:

    use std::cell::Cell;
    
    let owned = vec![Cell::new(1), Cell::new(2)];
    let x = &owned[0];
    let y = &owned[1];
    
    x.set(10);
    y.set(20);
    
    println!("{:?}", owned);

This uses a concept known as "interior mutability" to permit mutating through a borrowed reference. `Cell` only works for `Copy` types ("plain old data"), whereas you'd need to use `RefCell` for non-copy types like `Vec<T>` or `String`.

Finally, we can come full circle and use the `split_at_mut` API on slices to get two mutable views into the same slice. This is a good example of something that is ultimately implemented using `unsafe`, but exposes a `safe` interface:

    let mut owned = vec![1, 2];
    {
        let (xs, ys) = owned.split_at_mut(1);
        let x = &mut xs[0];
        let y = &mut ys[0];
        *x = 10;
        *y = 20;
        // The added scope is used so that the mutable
        // borrow of `owned` is done before borrowing it
        // again to print its contents below.
    }
    println!("{:?}", owned);

There are various trade offs to each of these approaches and which one you use depends on the problem you're trying to solve. Of course, the criticism of "I just want to use mutable pointers dammit" is valid, because Rust will, for the most part, force you to think of another way of solving your problem (unless you're OK using `unsafe` and raw pointers). We occasionally pay a price for it when the borrow checker isn't quite smart enough. In the example I've shown in this comment, it's obvious what the borrow checker should do, but in a real program, it's rarely so simple.

CyberDildonics• 9 years ago

shared mutable values are also called globals

gnuvince• 9 years ago

When I first learned OCaml (knowing only Python), I swore a lot at the type checker for refusing to compile code that I knew would work at run-time (e.g., a variable having multiple types, but on strictly disjoint execution paths). It seemed insane to me that people would want to subject themselves to this kind of bondage and discipline. And yet, many years later now, I have learned and internalized how type systems work, I have learned not to try and simply replicate Python patterns in OCaml, and as a result I use OCaml to write code quickly and without any headaches; and not only is the type checker no longer an obstacle, it's now a valuable assistant.

I believe that we are seeing the same kind of phenomenon in Rust: we are trying to replicate C or C++ code directly in Rust, and we get frustrated when our efforts are foiled by the borrow checker. It's going to take some time and some efforts before we learn and internalize how borrowing works in Rust and how to change the way we write programs so that it is no longer an obstacle. The Rust team looks very receptive to comments about taking away some pain points (e.g., non-lexical lifetimes), but we also need to accept that, for a little while, we are going to feel like we did when we were new programmers and were trying to make sense of these new constraints.

tejinderss• 9 years ago

Not related to the topic but how do you find ocaml as compared to python or rust? Do you think its worth learning today as opposed to rust for high level general purpose programming?

njs12345• 9 years ago

It occupies a slightly different niche to Rust as it has a GC. If you can live with that, it's probably going to be more productive than Rust for you.

It's definitely worth playing around with a language from that family. OCaml is maybe slightly more practical than Haskell and it has some nice resources available - in particular Real World OCaml looks really good: https://realworldocaml.org/

lmm5• 9 years ago

It is well worth learning an ML-family language. In addition to Rust, OCaml or Haskell as njs12345 mentioned, F# or Scala might be options. OCaml is probably more mature than Rust, has more libraries available, and has automatic memory management which takes some of the load off you (especially if you're writing a GUI application, IME). But it's not got Rust's "hot right now" factor, it doesn't have Rust's ease of embedding in other languages, and it doesn't have quite the same focus on high-quality documentation.

If you already know Rust I wouldn't bother learning both - they're very similar languages.

krat0sprakhar• 9 years ago

Absolutely! If you're looking for fast, GC'd, native functional language I'd say OCaml is a great option. There's actually a very comprehensive set of blog posts migrating an open-source python based project to OCaml, that I'd recommend reading if you're looking for a more thorough comparison - http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret...

Personally, I used OCaml while at university to write a programming language (http://jsjs-lang.org) and totally loved it. Real world OCaml is a great resource and I'd definitely recommend giving OCaml a try. My only regret is that I don't get to write OCaml as much as I want to due to the kind of projects I work on, but given that Bucklescript[0] and Reason[1] are moving ahead in full steam, that might change shortly too :)

[0] https://bloomberg.github.io/bucklescript/

[1] https://facebook.github.io/reason/

jackmott3• 9 years ago

It is worth looking at F# as well, which is basically OCaml on the .NET platform. With the advantages of having the entire .NET ecosystem of libraries available for use, being able to use more than one core of your cpu, a solid IDE, and some other features like type providers. There are some disadvantages as well, such as not being able to compile to a native executable.

Anyway the syntax is so similar you can learn one and switch to the other with very little pain.

nickpsecurity2• 9 years ago

I'll also add to their recommendations that GC'd languages can be used for OS's or system code. You can do that with a number of strategies:

1. Go unsafe on lowest-level operations that simply can't be GC'd. Quite a few of these can be expressed as finite, state machines which can be model-checked for correctness. Static analyzers are also really good these days in whatever code you can avoid dynamic allocation in. The rest of the code is GC'd. That's what the Oberon operating systems do.

2. Use a real-time, low-latency, concurrent GC that basically knocks low single or two digit performance out of the system. Lots of products in embedded Java have special GC's for that. Buy a faster CPU. Trade dollars or performance for productivity and safety.

3. Use a mix of GC's in the system where each one is tuned for the job at hand. You might use a real-time, concurrent one in the kernel. Maybe just reference counting in one more about performance. Maybe a straight-forward one for stuff that's not performance-critical. Could even use one that's mathematically verified for correctness in that situation. JX Operating System is an example of OS that mixes up GC strategies.

That's for software. Your options open up a bit if you can also deploy custom hardware. At the least, a modified soft-core on an FPGA. The LISP machines & maybe a Java CPU of the past often included hardware acceleration for garbage collection. One built the GC right into memory subsystem/interface of the processor where neither the processor nor applications had to be aware of its existence. It just did its thing in parallel to execution of the app. A concurrent, low-latency one integrated with virtual, memory hardware shouldn't take much hardware resources to pull off.

jnbiche4• 9 years ago

I believe that we are seeing the same kind of phenomenon in Rust:

I don't know. I picked up OCaml fairly quickly, but I have consistently struggled with Rust, trying it for a while before abandoning it in frustration with lifetimes, 2 or 3 times. I can program in Rust, but it still seems like an ongoing struggle, as opposed to the smooth brain to text programming I've gotten used to in Python, JavaScript, OCaml, and Lua, and to a lesser extend C, Go and Elixir (just because I haven't used to latter 3 as much, at least recently).

I think Rust may be ideal for embedded software development, or low-level systems software, but for general application development, I think OCaml or perhaps Swift or Scala are more ideal, at least for me (or at least until I decide to try Rust again, perhaps it will stick this time).

Edit: Oh yeah, and I was even able to become productive enough in Scala to build a significant project (a programming language) in a relatively short period of time. Now, I'm not silly enough to think I've really mastered Scala in such a short period of time, but I was using it productively as a functional language as I would OCaml with little difficulty. On the other hand, I've started 3 (3!) programming languages in Rust but have yet to get beyond much beyond the parser/AST stage before I quit in frustration.

smt88• 9 years ago

smooth brain to text programming

This isn't a good thing, in my opinion. Brains make mistakes. I don't want smooth, uninterrupted coding. I want the compiler to tell me when I'm making the mistake, even if it makes things choppier. It's a lot less painful to write code in fits and starts than to write a million tests or spend hours debugging.

sametmax4• 9 years ago

Give it time. Rust is brand new and has changed considerably during the last year. The rust team listen closely to the community and will smooth things up. But they can't do it all at once.

Recurecur• 9 years ago

I think Rust may be ideal for embedded software development, or low-level systems software, but for general application development, I think OCaml or perhaps Swift or Scala are more ideal, at least for me (or at least until I decide to try Rust again, perhaps it will stick this time).

If you're not aware of it, scala-native looks very interesting... It looks to be active project.

https://github.com/scala-native/scala-native

FWIW, I've also enjoyed Swift development quite a bit. I think Swift will go deep into the C++ sweet spot.

rbehrends9• 9 years ago

This is a different issue. The problem that the author is observing is that Rust operates on the hypothesis that the ownership relation is mostly left-unique and acyclic and that you run into problems when this hypothesis doesn't hold. And this affects not only explicit data structures, but also the implicit structures that involve stack frames (local variables, closures, etc.).

While Rust has mechanisms to deal with this (copying, Rc<T>, etc.), all these mechanisms add pain points, and for problems that are not just theoretical. It affects a number of design patterns, closures that survive the scope they were created in, functional-style programming, functional data structures, any data structure that naturally involves a DAG or cycles.

The difference compared to a (good) static type system is that a good [1] static type system does not measurably reduce expressiveness; Rust's ownership model does.

This is not to say that there isn't a point to Rust's model. Rust directly competes with garbage collection as the main alternative model to achieve memory safety and is an obvious choice in cases where garbage collection is not a realistic option. But where garbage collection is an option, the tradeoffs that Rust makes become much less attractive.

[1] Obviously, primitive static type systems (example: Java up to version 1.4) do pose a problem.

humanrebar3• 9 years ago

First, the expressiveness is all there. You just need to explicitly say you are responsible by using unsafe blocks. So risky pointer and allocation logic becomes the programmer's job, not the borrow checker.

Second, this article only considers the costs of a stricter borrow checker, not the benefits. It will be more work for the coder to have to think about how allocation and ownership is communicates. But I've been through much bigger headaches in production code at inconvenient times (for the business plan) due to dangling pointers, multi-writer concurrency bugs, and ill-defined memory models in software designs.

Even if Rust is much harder than alternatives instead of just different, and even if that's inherent in borrow checking, it's not clear that it's still not worth it in the long run.

rntz3• 9 years ago

The difference compared to a (good) static type system is that a good [1] static type system does not measurably reduce expressiveness

This is pseudo-jargon. What counts as a "measurable" reduction? Do you have any substantive evidence that "good" typesystems don't reduce it? And why are only type systems which satisfy this property "good"? You talk cogently about tradeoffs later on, but this sentence taken literally suggests only a type system which doesn't make this particular tradeoff can be "good". Why?

My go-to languages for the past few years have been Haskell and Racket. There have definitely been times I picked Racket because I knew Haskell's type system would interfere with my expressiveness. Certainly Haskell is less restrictive than Rust with regards to ownership, but all type systems restrict you. I think GP is spot-on in pointing out that you just get used to it over time as you learn to think and code in ways that avoid pushing against the type-system's weak spots.

But where garbage collection is an option, the tradeoffs that Rust makes become much less attractive.

Yes, precisely. It's not a fundamentally different issue from getting used to other static type-systems; it's just a different tradeoff.

braveo14• 9 years ago

I agree, ayende is a C# person, he's well aware of statically typed languages.

I also agree about your other points, I think maybe one of these days the borrower will become more sophisticated, but these issues he's complaining about are the exact reason I put Rust down. It just felt too sophomoric, as if the language wasn't really ready.

Not all is bad, I really like the way errors are handled in Rust, but there are definitely some problems with the approach they take.

aomix• 9 years ago

To me it seems like Rust has an additional wrinkle with safe and unsafe code. A new Rust user needs to figure out both "How do I do this" and "Is this possible in safe code". The limits of safe code seems to be something people are figuring out at all levels. Rust projects seem to start out with a relatively high amount of unsafe code. Then as the project matures the unsafe sections are reduced or eliminated.

maffydub• 9 years ago

I think whether you feel you need unsafe when you first come to Rust depends on the angle from which you're coming.

Coming from C/C++, I know that there are structs in memory and can visualize what they look like - surely I can just go and tweak them? (No I can't because either it wasn't safe to do that anyway, or I need to explain to the Rust compiler why it is safe, and that can be quite difficult.)

Coming from something like Java, I (probably) don't think too much about what the underlying structure in memory is, so I'm less likely to try to do this.

Either way, it feels like part of the learning curve is learning the "Rustic" way to do something - in general, you probably shouldn't be reaching for "unsafe" until you know what you're doing! ;)

bluejekyll7• 9 years ago

This really isn't that big a deal. I have written 60k lines of code in my side project, it's required zero lines of unsafe Rust code. I have needed to extend some other OSS libraries I depend on and those have required unsafe code for bindings to C, but that makes sense. Even in Java it's unsafe to write JNI to C.

eternalban4• 9 years ago

You came from interpreted Python to compiled OCaml and I suspect that your initial encounter with a compiler is the underlying issue. (For example, being new to FP but very friendly with compilers -- C, C++, Java, C# -- I found the initial OCaml encounter surprisingly pleasant. Haskell was something else though :))

I looked at Rust specs 1.0 when they were released and immediately recognized that Rust is not a 'dating' language, but rather a very serious 'marriage' till death do us part sort of deal. (I would say the same for Haskell, & Scala.) And imho the initial promise of addressing the out of control complexity of C++ was not met.

I have no doubt that Rust is a thoughtful, and powerful, language. But you have to be prepared to exchange vows at the alter.

gcp11• 9 years ago

And imho the initial promise of addressing the out of control complexity of C++ was not met.

I'm not sure. Type traits seem to be much more manageable than how the same thing is handled in C++ template code, no?

Also, if we can bring in ecosystem effects such as cargo...

throwaway91111• 9 years ago

Of all the things I'd accuse rust of, complex is not one of them. Could you give an example of the complexity? I've not found a single pattern in rust I wouldn't already have to think about in c++, but I have to think about it less because the compiler thinks about it for me. I just can't postpone the confidence until later.

pmoriarty2• 9 years ago

I never got past the pain-in-the-ass stage of dealing with the OCaml compiler. I hated wrestling with it for something simple. It really slowed me down to no end.

I remember asking on freenode's #ocaml for help with a convoluted error message, and when I was told what it meant and how to fix it, I asked how the person who helped me knew what it meant. He told me he'd taken two semesters of type theory courses at uni. Having to spend a year taking university-level courses in order to effectively program in OCaml seemed like way too much pain for too little gain when there were so many other less painful languages to program in.

Later I discovered Lisp and then Scheme. Both were a sheer joy to use compared to OCaml. I didn't have to wrestle with the type checker, my programs were quick and easy to write and understand, and in their own way the languages were just as powerful as OCaml was. Sure, OCaml had them beat at safety (at least if you were comparing ordinary Lisps and Schemes, not statically typed versions or extensions with more safety features) but it way, way more painful and slow to program in, for me. I recognize that if you need the safety, then the pain might be worth it. But even then it might be worthwhile to program in a dynamic language like Lisp/Scheme and then once the program matures, rewrite it in a safe language like OCaml. But even then, I think I'd just rather dial up the safety features of Lisp/Scheme or use one of the static versions.

That's just me. I know some people love OCaml. And I'm sure I'm missing some of its wonders that are only apparent when you dive deep enough in to the language. But from what I did learn of it, it just wasn't for me.

sfilargi• 9 years ago

What helped me when starting with OCaml is always declaring the types in the function's arguments. The compiler errors started making a lot more sense.

Dowwie• 9 years ago

I spent the last week working with Rust and learning from the Rustaceans. It's been such a great experience. I am really glad that I dedicated some time to it. In a short amount of time, I've already dramatically improved some computationally expensive python code by more then 10x, largely with the help of the community. Further, Rust is already making me a better programmer. If you are skeptical, I challenge you to dedicate yourself completely to a solid week crash course of Rust and experience this for yourself. If you struggle, don't give up and blog about why you hate Rust. Join #rust-beginners on irc.mozilla.org and ask for help.

justinlaster• 9 years ago

So I spent a few evenings with Rust

I stopped reading. There is literally nothing you could possibly say that'd be worthwhile after "a few evenings" with Rust, especially when you lack the proper background in the first place.

This trend of "The problem with Rust: A naive and inexperienced perspective"-esque articles is already old.

sgift• 9 years ago

I read a bit further, it doesn't get better and my summary would be: Rust isn't C++, doing things the C++ way in Rust is not easy, therefore it requires too much ceremony to do what I want and is too hard.

bronson• 9 years ago

I made it to

I have a buffer, that I want to mutate using pointers

Turns out you were right.

gcp11• 9 years ago

Yeah, that entire paragraph is basically a list of all the things safe Rust will not allow you to do. It should be a sign that you're tackling the problem the wrong way around...

gravypod5• 9 years ago

Could the issues of rust be rectified with a better theorem proved that goes past "2 things are touching this"? I don't think I'd mind if the compiler said "your code will not work because eventually it will modify the same bytes at the same time and create an unpredictable state" but I will mind if it says "your not good because you have two mutable references.

Diggsey2• 9 years ago

Having a more powerful theorem prover is not always better: it makes it harder for the programmer to know whether a piece of code will work, and you can start getting non-local effects, where a change in one part of the code can break a (seemingly) unrelated part.

However, what you're asking for is very similar to what types like `RefCell` and `RwLock` do - they effectively delay borrow-checking until runtime. Now you can have references to a `RefCell` in multiple places in the code, and they can all get mutable access to the interior, just not at the same time.

Having said that, I find it interesting how rarely things like `RefCell` are needed in practice: there's almost always a better way to satisfy the borrow checker, and it usually results in much cleaner code.

gravypod5• 9 years ago

Having a more powerful theorem prover is not always better: it makes it harder for the programmer to know whether a piece of code will work, and you can start getting non-local effects, where a change in one part of the code can break a (seemingly) unrelated part.

I think there are two solutions to that problem. The first is to involve HCI people in the development in the language to see how they can improve the output and communication from the theorm prover to the programmer. I imagine that, some time in the future, a very powerful therom prover will make its way into a "general" language and will bring some cool effects. The theorum prover I'd like to see will attempt to prove all of the conjectures used in the program and, when not possible, will say "possibly invalid code. Please solve this conjecture" where then this would be given to a mathamatician and they have to complete the missing steps to see if it works, if not we tell the compiler this isn't going to work and it now generates errors for this.

The other solution is to limit the shared state of every program using very strict segregation of all moving parts and an attempt to limit use of side-effect-causing operations.

This second one is nothing new, I mean the original LISP crowd had these ideas down and theres nothing new.

I don't think I've ever worked with a compiler that has a built in theorum prover, possibly a shared library of proven work, and a way to in the language aid the prover. For instance this type of function definition

    int(int numerator, int denominator) where (denominator != 0) divide {
        return numerator / denominator
    }

And even more so I've not heard of unobtrusive theorum provers that keep out of the programmers way while still being useful. I think an unproven relation should be a warning. It's not good but the program can still run and you (you being not me but the math-people) can come up after me and prove all of my work or tell me I'm an idiot and to fix it.

lmm5• 9 years ago

Well Rust's way of ensuring you don't modify the same bytes at the same time is to ensure that any byte has precisely one "owner" in any region in which it is mutated. That's a model we know how to implement and also an easy model for humans to think about - we can see what's going on (we can see the regions in the code) and we know what to expect to work (e.g. if you have a mutable reference you expect to be able to use it to mutate what it refers to). If you can formalize a better model you can probably implement it in a language, but what model would that be?

gravypod5• 9 years ago

From an implementation standpoint that makes sense. From a usability standpoint it does not. The use case of systems programming usually involves many mutators on a single piece of, non-copiable, data. I can see why the person writing the Rust prover would say "yea this is the best" but I can't see why anyone else would because it's filter cuts out a large portion of completely valid code that is not incorrect but instead is "scary" or "spooky".

If you can formalize a better model you can probably implement it in a language, but what model would that be?

I'm just someone on the internet here to complain. I can't do that because I'm not a smart math person who can prove how to get there or even generalize it to work with other programming related things.

pron4• 9 years ago

Rust provides something that few if any other languages do: memory safety without GC. It is very obvious that this comes at a non-negligible cost in development effort. If you need what Rust provides -- and an important class of software certainly does -- you should be more than happy to pay that extra cost. If you don't, there are plenty of alternatives. But exchanging effort for rather unique guarantees is the very explicit tradeoff that Rust makes. That few other languages choose to make this tradeoff is what makes Rust so valuable.

burntsushi5• 9 years ago

To be clear, I think the data supports that Rust comes with a non-negligible learning cost. Whether that cost is continually paid isn't clear yet. (I personally think the answer is "no.")

pron4• 9 years ago

I agree that there's no data, but I would be very surprised if the answer is indeed no, as there are at least good theoretical reasons to assume extra cost. Proving anything (let alone to a compiler) comes at a computational complexity cost (think of the proof as a certificate). In principle, a large number of proofs may be "free" in the sense that no more information than the programmer normally supplies the compiler is necessary. But if this is true in every case, that is very surprising.

moomin• 9 years ago

The joke being, this is being written by a guy who has constantly insisted on his blog that if people don't think NHibernate and IoC are a good idea for their project, it's because of their personal failings.

Me, I muck around with Haskell. No I'm not productive in it. I don't think that's Haskell's problem, though.

leshow• 9 years ago

The first few of these types of posts were OK. But now it's a bit ridiculous. You spent 2 days trying a new language and you didn't like it, your opinion means nothing.

Etzos2• 9 years ago

I don't typically respond to comments like this anywhere, but I think this kind of view is dangerous to have. And it's one the Rust community at large seems to try to shy away from.

This kind of attitude towards people trying out a new language is damaging to the person trying the new language and to people who are part of that languages community. The former because it will give them the notion that the community is hostile towards them and newcomers in general and the latter because it can enforce a dogmatic view of the language ("you do it our way or no way!" kind of feel).

A language's ability to have people pick it up easily is important. In Rust's case there is definitely always going to be a bit of a hump for people to get over, but the concern put forth in this article seems like a legitimate one, but one the Rust community seems to be aware of. Acknowledging and helping people with these problems (while searching for a way to potentially avoid such a situation for the next newcomer) is important and it's critical that you not simply dismiss someone's opinion because they don't know or understand "the right way to do it" yet.

threatofrain• 9 years ago

For a language like Rust that puts all the pain up-front, I want to hear whether the pain is worth it. But someone who spends only a few days can't give you a weighing of whether the pain is worth it.

I'm reluctant to even listen to someone's Amazon product opinion if they've only used it 2 days.

flukus3• 9 years ago

This is particularly bad considering who it's from, his claims to fame include nHibernate and ravenDB, both of which take much longer than a few evenings to learn, with more questionable value as well.

vbezhenar• 9 years ago

I don't know Rust good enough, but do unsafe blocks help there? Data structures belong to library code and libraries surely can utilize unsafe blocks, because they are expected to be heavily tested.

omouse2• 9 years ago

I know about GDB, that ain’t a good debugging experience

I can't take this article seriously after reading that and after reading this:

So I spent a few evenings with Rust

How long did it take you to learn C, C++, Java, Python, Ruby, Perl or other languages? MONTHS. Many many many months. Sure you could get something up and running in a few evenings but after many months did you realize that earlier code could be better. Each language has its own obstacles and spending a few evenings isn't enough time to get around them.

I gave Haskell a pass but after checking out Elm I can see more of its power. I gave Rust a pass because the language was changing but now that it's stable I expect to sit down for a few months at least learning it.

draw_down• 9 years ago

I agree with him about GDB.

kernelbandwidth• 9 years ago

The very same trie code that I tried to write in Rust I wrote in one & half evenings in C++

Use unsafe. No, really, just use unsafe.

Clearly a big value of Rust is that it's a safe language, and the design patterns around safety and affine typing are emerging and good. We should want people to write and use safe code as much as possible. But the trie example seems, to me, to be very much the sort of thing unsafe is for. Writing in C++ is essentially doing everything in unsafe. Unsafe is not evil; it's an important part of the language and when it's called for, it's called for.

Manishearth10• 9 years ago

I'm not sure, tries are pretty easy with safe code. It's only things like data structures with parent pointers where things get hairy.

If your goal is to use malloc and stuff (which seems to be what the author wanted) then of course you should use unsafe. Unsafe is indeed for doing abstraction-writing like this. Still, you should avoid it if you can.

drbawb3• 9 years ago

We are talking about allocating memory, in a system level language, and unless you are jumping through hops[sic], there is just no way to do that.

To be fair, if you want to call malloc it is still just as accessible[1][2] as it is in C. If you search the Rust documentation for malloc `libc::malloc` is even the first result. If you were to use that on stable Rust the error message will even tell you to link your program to the libc published on crates.io (which is just adding a line in your Cargo.toml file.)

I'm not sure I'd call that jumping through hoops. I'd love if Rust provided easy access to its own allocator on the stable release channel; but I'm willing to wait for them to get it right, these things take time.[3]

[1] https://doc.rust-lang.org/libc/x86_64-pc-windows-msvc/libc/f...

[2] https://is.gd/cgkX2R

[3] https://github.com/pnkfelix/rfcs/blob/117e5fca0988a1b0c4b6e4...

Manishearth10• 9 years ago

Also, most folks would use `Box` with `Box::into_raw` (also `Vec::with_capacity` for dynamically sized stuff, which works fine.

RawVec is an implementation detail; Vec exposes most of what you need for dealing with raw memory.

tps5• 9 years ago

I'm not coming from C++, but my experience with Rust has been:

* Read the book, got some of the concepts but most of it went over my head.

* Did nothing, maybe thought about it a little bit.

* Two weeks later: read the book again. It made more sense but some of it is still lost on me.

* Actually wrote some Rust. Was hard, frequently consulted the book, the "by example" book, r/Rust, and google.

* Two weeks later, it's much easier. I'm still consulting outside resources frequently, but I generally know how to fix problems as they arise and my mental model of the how the language executes is becoming more and more accurate.

I've spent on average 30 minutes a day working on a pretty simple Rust program for about a month now. The advantages of Rust so far have been: if it compiles, it works. Extremely easy to refactor: for my main data structure, I've switched between vecs and arrays back and forth probably 4 times to get a feel for the differences. This is generally really easy to do because they both implement the the iterator trait. In the other languages I use (at work), switching between one type of collection and another would be a huge time sink and involve a lot of annoying (though trivial) refactoring.

The main advantage of Rust for me (and the reason why I decided to check it out vs go) is that I don't have a lot of experience thinking about memory at a low level. The dynamic languages I work with abstract that away from the programmer. I wanted something that would force me to think about how and where memory is being allocated, and whether I want to pass by reference or value. For someone who has spent a lot of time with C/C++ or just someone with a background in CS/programming languages, this may all seem obvious to you. But there's a lot of programmers out there who learned with dynamic languages and don't have a good mental model for memory. Rust is a good instructional tool for us.

I don't really have an opinion on whether Rust is "production ready." It's being developed rapidly though, so I think it'll get there.

eximius• 9 years ago

If you just want to allocate a chunk of memory for random use like you would in C, it can't be guaranteed to be safe. So I would hope you need to jump through hoops.

AstralStorm11• 9 years ago

It is a rust weakness that it does not have "partial unsafe" that guarantees some things. Makes many kinds of code unnecessarily hard to reason about.

w8rbt• 9 years ago

"multiple mutable references"... I would use C++ for this. I would not use rust if I had a design that required that ability.

jeffdavis• 9 years ago

Writing libraries, especially implementations of well-known algorithms and data structures, is a bad way to learn most languages. Technically, it's possible, but I think it skews the experience strongly toward languages that are similar to what you've worked with before and languages that are more permissive.

I suggest writing applications, or libraries closer to applications (e.g. a specific library that parses a special data format important to your domain), where you have a clear goal but not a clear path to the goal in mind. In other words, hacking.

Let's say the author had finished the Trie. What good experience could he possibly have? It's not going to magically run faster than the C++ version or use less memory. It's a well-known algorithm so there probably aren't subtle bugs in the C++ version that rust would have caught. The best you could possibly say is that it was faster to write -- which is exactly why it skews the experience toward familiar and permissive languages.

I am trying to learn rust (albeit very slowly) by doing some hacking to make it work better for postgres extensions. I know postgres, and I think it would be cool if it were easier to write postgres extensions in rust. Of course you can today, but you'd have to use a lot of unsafe FFI calls.

protomikron• 9 years ago

I do not know Rust, but I know C and some Haskell and AFAIK one should building a program in Rust differently than in C/C++ (which is probably the authors background).

Get out a quick correct (and this can not be emphasized enough) version (obviously one has to learn the language here) and then optimize (when you have numbers). The author did not seem to get a working version with Rust (sorry, if I am wrong on this), and tried an approach that he knows would work for C/C++. But maybe another approach would have been already performant enough?

nimmer• 9 years ago

Sounds like Nim is what you are looking for: http://nim-lang.org/

It's fast, has a Python-like syntas, a good degree of memory safety and optional GC.

The struggle with Rust

Related Stories