13 ms·

I spent an afternoon messing about with Rust and found it infuriating. The compiler kept (quite rightly) telling me how crap my code was and wouldn't compile it

• tatterdemalion 10y ago
  I am a volunteer who works on Rust & I do almost all of my open source work in Rust. I am paid as a Ruby web developer. I personally have little interest in systems programming & want Rust to be a productive language for application development. I frequently witness this rush to judge Rust as too complex to be used for business applications based on a few hours of hacking. For this to be a valid judgment, I would think one of two things would need to be true: a) Rust remains this difficult to use once you have experience with it, or b) most business applications are worked on for only a few hours. In my experience, neither of those premises hold. I believe that the rules of Rust not only give you exceptional performance without memory issues (as this article tries to demonstrate), but also that its rules engender a higher degree of correctness and 'well-factoredness' than most languages. I believe Rust is an excellent language for writing applications at every level of the stack when 'craftmanship' matters.
  • di4na 10y ago
    Or ... Business applications do not care about safety.
    • shadowmint 10y ago
      It's probably more a case that safety is critically important, but most LOB apps do not have particularly strict performance requirements. ie. java is good enough.
      • kod 10y ago
        Not only is java good enough, it's currently better than rust for networking applications. Hopefully tokio changes that, but it's not 100% there yet.
    • tatterdemalion 10y ago
      Please read my comment more carefully. My argument has nothing to do with safety, and flippant replies are quite rude. > I believe that the rules of Rust not only give you exceptional performance without memory issues (as this article tries to demonstrate), but also that its rules engender a higher degree of correctness and 'well-factoredness' than most languages. I believe Rust is an excellent language for writing applications at every level of the stack when 'craftmanship' matters.
      • di4na 10y ago
        And once again, i stay my case in the fact that "higher degree of correctness and well-factoredness" is probably not rewarded at all. Which means that the system do not push people to move to something that make these factors better. Performance is not one either. And i am not saying it is good. I strongly support your case. But the thing is, these factors do not matters for most business out there.
        • tatterdemalion 10y ago
          Fortunately the number of businesses that have to value correctness, craftmanship, safety, or performance over 'moving fast and breaking things' is not that high in order for Rust to succeed. I would agree that it will always be a language in the minority, but I think the industry is moving in an increasingly pluralistic direction as regards programming languages & that (nearly) all languages will be minority languages.
  • kazagistar 10y ago
    I'm compiler error feel like a matter of course, just another part of writing code. Errors the compiler didn't catch (and potentially could have), those annoy me.
  • bryanrasmussen 10y ago
    Well it might be that businesses don't want to invest in anything with a high learning curve if there are tools with a low learning curve that can solve the same problem.
    • tatterdemalion 10y ago
      Indeed! I don't believe that there are tools with a lower learning curve that solve the same problem Rust does - in particular my belief is the way that Rust is able to perform deep type analysis on imperative code (which is really what the dreaded borrow checker is all about) enables proficient users to write well-factored systems with a high degree of confidence in their correctness. If you want to onboard people to your code base with no familiarity with the language or your system and have them be 'productive' (for some definition of productive) within the week, Rust is probably not the right choice for you. In my experience projects for which that is a high priority (and the languages which enable them) also deal with a great amount of technical debt.
      • problems 10y ago
        You can definitely use languages that are just as safe, but higher level. You could make that argument with many functional languages like Scala or Clojure, you could even make an argument that even many imperative languages are also that solid - like C# or Java. Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. If you want something more precise - you can use Scala in a way that it's almost an imperative language with additional safety guarantees. The only gain you get going to Rust is really in the performance department. Rust is what you use if you want C-level performance combined with that safety, it might replace C and C++ as the OS, browser, high performance server and game development language. For anything else I find it hard to suggest Rust as a serious option when there are many high level languages that seem like better answers.
        • jmcomets 10y ago
          > Perhaps not quite as safe, but at least that they deliver the important parts of that safety without the cost of the learning curve. Sorry to say this but a lot of unsafe code has been written in Java or C#, putting aside the NPEs and such. In Rust safety isn't only about eliminating SEGFAULTs and buffer overflows, but also preventing data races and most concurrency issues. It's common to add threading to cpu-bound code, without worrying about deadlocks or race conditions. Rust also allows some very high-level code. Some of my favorite options out there: - option (std): https://doc.rust-lang.org/std/option/index.html https://doc.rust-lang.org/std/option/index.html - serde: https://github.com/serde-rs/serde https://github.com/serde-rs/serde - docopt: https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs Some more features: generics (traits!), immutability by default, type inference, first-class functions, operator overloading, conversion between related types.
  • jonathanstrange 10y ago
    For me personally Rust is not very interesting because it doesn't have a garbage collector. Manual memory management is just a pain in the ass and really not worth it for the vast majority of applications - games and realtime audio processing are an exception. Besides, if I don't want automatic memory management, I could also use Ada or Freepascal, who are both reasonably safe, though not generally as safe as Rust, and are mature and have a well-established toolchain.
    • foepys 10y ago
      I have never done anything with Rust but I was under the impression that Rust's borrowing and ownership system made manually freeing memory more or less obsolete except for a few edge cases where the compiler isn't intelligent enough. Is this impression false?
      • tatterdemalion 10y ago
        You are correct, you essentially never need to manually free memory.
      • adrianN 10y ago
        Manual resource management in Rust is about as convenient as manual resource management in modern C++. That is, you don't really do any "manual" memory management at all in >90% of your code, it's all taken care of by RAII.
        • pjmlp 10y ago
          Yes, but with the added benefit not requiring external tooling to validate those RAII pattern are used correctly and forcing not so security savvy developers to actually use them.
          • kazagistar 10y ago
            So it's better, safer, but still manual memory management.
  • AsyncAwait 10y ago
    I second this. Rust gets miles easier after you internalise the borrow checker, which takes anywhere from a week to several, but it's definitely worth it. I believe part of the reason is that people have limited time to play with this stuff and so they want instant gratification. Rust is not like that, but offers a much higher dose of delayed gratification instead. Once you familiarise yourself with the rules and get things working on the first or second compile, it means not only that you program appears to be working, but that it also passes a complex set of tests verified at compile time. When you become confident enough with Rust, you're basically as productive as with any other compiled language, with the added benefit that the code you wrote might actually be (re)usable afterwards. With Rust, you put in some work up front and reap the benefits since then, with other languages you can feel 'productive' right away, but not be able to write production grade software for weeks/months to come. Once you realise this, spending more than a few hours with Rust becomes an easier calculation.
    • k__ 10y ago
      I don't understand what problems the people have with the borrow checker. I can't imagine internalizing the borrow checker is harder than internalizing all the idiosyncratic quirks languages like JavaScript have.
      • dbrgn 10y ago
        The borrow checker prevents code from running at all, sometimes even if the code would be perfectly safe (e.g. two slices to non-overlapping areas of a vector). JavaScript on the other hand is full of quirks, but you get something to work quickly, even if it's buggy. The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated.
        • pimeys 10y ago
          > The huge advantage that Rust has over languages like JavaScript is that if it compiles, it's almost guaranteed to run (unless you have logic errors somewhere). I think that fact is greatly under-appreciated. This. In my company, our Rust apps have a very small amount of tests, mostly integration tests written with Python. You need to test certain business logic, but mostly if it compiles, deploy all the things :)
  • chias 10y ago
    I strongly agree with this. Rust has been a pleasure to learn, and I've been using it for everything from small scripts to even some minor web-dev. That said I do think there are areas in which using Rust is legitimately not a great idea. For example, I needed to convert a URL path into a filesystem path, and my code looks like this: let mut basepath = PathBuf::from(path_arg); for component in req.url.path() { basepath.push(percent_decode(component.as_bytes()).decode_utf8_lossy().into_owned()); } Granted -- each part of that makes a lot of sense, and I think it would be to Rust's detriment for things not to be that way. But when my focus has to be on rapid development rather than exacting precision, this sort of verbosity can get in the way. Personally, I have been using Rust anyway because I am trying to shift my development habits away from rapid development and towards exacting precision, and to this end Rust has been a godsend. But I can easily understand why this verbosity may push someone away. I do note, however, that verbosity is not the GP's complaint here.
    • tatterdemalion 10y ago
      It seems like you're using the url crate but a different version from what I have docs for (the path() method I see doesn't return an iterator). But I believe that some of those conversions are not optimally necessary. Definitely the into_owned is unnecessary and could be replaced by an & before `percent_decode`. This ownership wrangling is something we'd like to address in the coming year. Then I'm not sure about percent_decode. I think there could be a better convenience for that back and forth casting between utf8 and bytes that's going on. The only real decision you're making here is decode_utf8_lossy vs decode_utf8. I'd like to think this could be encapsulated as two methods on the Url type.
      • chias 10y ago
        Thanks for the critique! This is actually super helpful to me as I try to grow as a Rust developer. The point I'm trying to make though, is that if the developer's focus is on rapid development (which I imagine most people in webdev are), then at the end of the day I just want to urldecode something, and not necessarily worry about the character encodings etc.
• Anderkent 10y ago
  You're describing a learning curve. It's true that writing rust is a pain if your internal model of the ownership checker is inaccurate; but once you learn it and stop 'fighting the compiler' it doesn't actually constrain your expressiveness much. I think there's much more to Rust than just a systems language. For anything that you need to have c binding for (say, a crypto library), it seems a very good choice. I was also thinking of combining some high level, abstract language (Clojure/Haskell etc.) with perf-critical sections written in Rust.
• wtallis 10y ago
  > For line of business apps, it is inaccessible and the safety dial is turned up too far. The dial is certainly turned up further than most businesses are accustomed to. But if that business is doing something involving my credit card number, I think the threshold of "too far" ought to be somewhere beyond Rust. I hope that Rust does get some substantial adoption for line of business apps, if only to give us some data on how much it really costs to deal with your buffer overflows in advance, instead of suffering the embarrassing outages and hacks that make the national news.
  • sillysaurus3 10y ago
    The dial is certainly turned up further than most businesses are accustomed to. But if that business is doing something involving my credit card number, I think the threshold of "too far" ought to be somewhere beyond Rust. Most security flaws aren't things that can be directly checked by a compiler. There are some, certainly, and it's worth preventing those. But the vast majority is in application logic, which no compiler can protect. Competent programmers working in an expressive language is probably the best defense.
    • tatterdemalion 10y ago
      While obviously no type system can prevent all logic errors, an expressive type system is very valuable to avoiding these kinds of errors (in my opinion more valuable than the loss of overall expressiveness types imply, but that debate is a can of worms and YMMV).
    • marcosdumay 10y ago
      I'll disagree here. Most security flaws can be completely avoided by the use of auto-managed resources and a comprehensive type checking. On that order. Basically the bugs normally claimed to be in application logic, that are mostly uncovered or extraneous corner cases are prime time for compiler verification.
  • ben-schaaf 10y ago
    No matter how high you turn up that dial, it won't prevent businesses from using md5 for password hashing and a misconfigured mongodb.
• Ygg2 10y ago
  What were the most common errors? Did compiler's errors helped guide you to solution? I came to Rust, from Java and I do remember Rust being hard, but not enough to quit. While I am no guru, the elision usually does job for me.
  • ed_blackburn 10y ago
    Me being completely inept at appreciating borrowing. The compiler was brilliant. It said 'no' a lot, but was certainly helpful. I gave myself four hours to play with it one afternoon. It wet my appetite enough to try it again in the future. I actually have an idea that needs a C++ wrapper. I'd like to try to use Rust instead of C++.
• slight 10y ago
  I mostly work with PHP in my day job and I've been following Rust so had an idea about its constraints but hadn't written any. I decided to port a personal web project I've been working on to Rust as my first attempt at the language and was able to port the core classes and get some other initial stuff up (web framework mainly) in about a day. It was a lot simpler than I expected. With the IDEA plugin and a bit more experience I think I can be about as productive in Rust as with PHP, and that's coming from about 17 years PHP experience. Edit: With the caveat that the number of available libraries and SDKs is still low, but in the case of PHP that was the case until the last couple of years anyway after Composer and Packagist came along.
• akiselev 10y ago
  That's the primary problem I had with the Rust learning curve: you learn all about this great safety stuff but the documentation fails to beat into your head that the safety switches are right in front of you. The chapters on variable bindings and mutability should both start by introducing RC<RefCell<>> and the first couple of introductory chapters should use only unsafe code (I'm only half joking on both points). For all the emphasis on how the extra safety prevents common bugs and makes life easier, little is put on how to actually tell the borrow checker that you (sorta) know what you're doing and the true power of unsafe is left for some deep dark corner. I mean, seriously, the book on unsafe Rust is called the Rustonomicon as if the memory model of the old default-unsafe-unless-you're-Dennis-Ritchie languages is some Lovecraftian horror brought on because of our thirst for the cursed FFI. Meanwhile, Rust's damn near magic (at least for me, a non-functional systems mortal) affine type system, which can eliminate many logic bugs and massively increase code reuse, is all but forgotten. The type system is at the core of Rust's entire memory safety but you need to read dozens of scattered blog posts and projects, and the standard library docs, to start to get a feel for how to move from OOP to trait based composition and lifetimes. In aiming for simplicity, most docs fail to show in practical settings how you can use Rust's type system to redesign your architectures in natural ways that completely reframe the process of writing code, making it easier to port ways of thinking and love the borrow checker. Sorry, that was a colorful rant. Teaching a new paradigm is tough and the Rust docs team have done a great job. As the language and community mature, better and better pedagogical practices will emerge and introductory material that approach the language from all angles will grow.
  • deleted 10y ago
    [deleted]
  • tatterdemalion 10y ago
    You're not wrong. I think the reality is that the design patterns for using Rust are still emerging from our shared experience; trying to write that sort of book would be putting the cart before the horse.
    • akiselev 10y ago
• vbezhenar 10y ago
  > For line of business apps, it is inaccessible and the safety dial is turned up too far. For most business apps GC is better option, than other memory-management options. I'm not seeing Rust in place of Python or Java, as well. But it could be used in some speed critical pieces, where C currently used, for example.
• simias 10y ago
  In my experience with Rust so far I find that I'm slower when I write Rust code than, say, C. However I find Rust code a lot simpler to maintain. I can offload some of the cognitive load of C to the borrow checker (who owns what? Should I free this pointer? How should I tell this method what's the length of this buffer? Can this function fail, and if so how?) For the same reason I also find it easier to dive into 3rd party Rust code and modify it. In general you don't have to worry about hidden side effects, global state, weird calling conventions and similar things with Rust.
• ekidd 10y ago
  > For line of business apps, it is inaccessible and the safety dial is turned up too far. My employer has a "line of business app" written in Rust. Here's what we're learned: 1. Rust does have a learning curve. It's easier to learn to use well than C++, in my opinion, but certainly harder than Ruby or Java. You really, really need to budget 2 weeks for turning an existing C++ developer into a productive and confident Rust developer. You can't take somebody who doesn't know the difference between "stack" and "heap", or who has never passed an anonymous function to "map", and expect them to bang out code rapidly in two days. 2. The library situation for business apps is just barely adequate. We need support for PostgreSQL, RabbitMQ, REST APIs, etc. In each case, high-quality libraries exist, but they're usually missing something. (For example: For PostgreSQL, we need to use both 'postgres' and 'diesel' to get the feature coverage we want. For RabbitMQ, we don't have heartbeat support. For REST APIs, we won't have good HTTP request mocking until the Hyper async stuff sorts itself out. And so on.) 3. The Rust code is just ridiculously fast. We're processing gigabytes of data, so we love this. 4. The Rust code is remarkably "trustworthy", and I'm not just talking about memory safety. If your program even compiles, it almost always works correctly (assuming you understood the spec). This has at least as much to do with Rust's 'enum' and 'match', which encourage people to enumerate and handle all cases, as it does with the borrow checker. 5. Rust code is very pleasant to maintain and refactor once written. Overall, we like Rust, but we're mostly only using it where (a) we really want performance, or (b) we really want to make sure we handle lots of tricky corner cases correctly. Oh, or (c) for long-running jobs that take hours to run on real data, where compiler correctness-checks are a huge win. We'll probably gradually use Rust in more places as we get experience and the tools mature.
  • plinkplonk 10y ago
    This is a great experience report. Thank You (spoken as someone on the verge of taking the plunge into Rust, but getting stuck on lack of documentation on unsafe etc)
    • ekidd 10y ago
      I don't think we have a single line of 'unsafe' code in any of our 6 Rust projects at work. If you're using Rust for business apps, you'll basically never touch 'unsafe'. For an extreme example from a weekend project, I wrote an MPEG 2 Program Stream / Packetized Elementary Stream / subtitle image decompressor, which obviously does a lot of bit-banging. (It's an ugly old format.) And I never touched 'unsafe' once. This is typical. The only big exceptions are (1) working with existing C libraries, which isn't too hard once you get the hang of it, but which obviously requires 'unsafe', and (2) writing your own graph-like data structures from scratch, which you should avoid in favor of using an existing library like petgraph (https://docs.rs/petgraph/0.4.3/petgraph/ https://docs.rs/petgraph/0.4.3/petgraph/). Basically, a doubly-linked list or cyclic graph is the worst possibly introduction to Rust for newbie Rust programmer. Start with something easier! I mean, unless you're the kind of person who tries to pole-vault learning curves, in which case, have fun.
• progman 10y ago
  > I spent an afternoon messing about with Rust and found it infuriating. The compiler kept (quite rightly) telling me how crap my code was and wouldn't compile it for me. I found it frustrating but thoroughly educational. The same is true for Ada and Haskell. You point to a typical problem of people who are interested in Rust. They like the syntax and features but the compiler gets in their way to be productive in a short amount of time. That is frustrating. The Rust community should not point so much emphasis on its beloved borrow checker like the Haskellers praise their monads. Both things are attractive only if their is real practical value in everyday coding. If devs need three to ten times more time than in C++ to develop something then they won't switch, even if C++ has no borrow checker. They could compensate this lack with verification tools, FramaC and the like. I agree with Andreas Bergmeier's comment in the author's blog. Experienced developers may barely have problems with lifetime issues, in particular if they use a language with garbage collection which really makes sense for most business applications. Rust would probably have much more convincing power if the community would go the way which Microsoft went to promote their C++ and C# compilers. They provided a very convenient Visual Studio IDE with excellent documentation.
  • hasenj 10y ago
    Why should Rust try to paint itself like yet another ruby/python/javascript? It's not, and should not try to market itself as if it was. People who need Rust know they need it.
  • steveklabnik 10y ago
    > They provided a very convenient Visual Studio IDE with excellent documentation. They've been paying me to write docs for years at this point, and IDE integration is a major focus of this year.