43 ms·

Why Not Rust?

• amelius 6y ago
  > All this complexity is there for a reason — we don’t know how to create a simpler memory safe low-level language. But not every task requires a low-level language to solve it. And what most people forget is that complexity works against safety: the less the programmer is distracted by other issues (e.g. memory management), the more they can focus on security.
  • elteto 6y ago
    I think you need to develop this point a bit more: at face value it looks (to me) like you are saying: "The borrow checker is more complex than simple malloc/free calls therefore it is less safe." Which is clearly wrong.
    • amelius 6y ago
      But you can also compare it to a GC'd language, which from this viewpoint is safer. A GC'd language, however, is usually not preferred for systems work. However, most applications don't fall in that category.
      • muldvarp 6y ago
        I don't think GC'ed languages are actually safer from a memory safety viewpoint, they're just easier to use.
        • dnautics 6y ago
          it depends on the GC'd language. You absolutely cannot do use-after-free, double-free, or stack overflow in erlang (unless you FFI into C). You can OOM erlang (but you can OOM Rust, too).
      • pjmlp 6y ago
        Mostly due to cargo cult and politics than anything else.
  • gameswithgo 6y ago
    Can you elaborate more on what you mean, and how you know it to be true? Taking the argument in reverse we might expect programming with just nand gates to be the most safe approach. Do you mean, all else equal, that it works against safety?
    • amelius 6y ago
      What I mean is that the less the programmer is distracted by other issues (e.g. memory management), the more they can focus on security. (I added it to my comment).
  • MaxBarraclough 6y ago
    > complexity works against safety. Not always. Java programs have fewer memory-management issues than C programs, and they tend to be less severe.
    • ncmncm 6y ago
      The evidence does not support this assertion. Certainly C programs have a poor record of memory usage errors, but the habit of Java programs routinely needing orders of magnitude more memory to do similar work is well known. Memory leaks are as easy under GC as in C.
      • whateveracct 6y ago
        > Memory leaks are as easy under GC as in C. This is just untrue. And no, allocating a bunch of short-lived objects isn't leaked memory. Neither is the overhead of the GC.
        • ncmncm 6y ago
          It is very easy to leak Java objects, simply by failing to remove them from containers when their usefulness has ended. And all the memory not yet collected has effectively leaked until the next reclaim cycle, which might never happen. So, memory leaks are as easy under GC as in C.
          • whateveracct 6y ago
            Neither of those is really a memory leak imo. The first one is a "retainer" leak in a way, but in your average Java use-case (e.g. an HTTP request handler) you have to make a pretty uncommon mistake for any allocation to outlive its usefulness and grow unbounded without being collected. Whereas in C you literally have to call free manually. That is way more error-prone than the ways you leak memory in Java. Once again, using too much memory or the GC running "eventually" are not leaks they are just not optimized memory management (a heavily fetishized thing in our profession.)
  • atoav 6y ago
    Not checking things will always be less complex than carrying out a metric ton of checks. But if checks means "pass or halt" then I don't see how it would impact safety negatively..? Wouldn't no checks equal less recognized bugs and therefore in turn lead to less secure code?
• fortran77 6y ago
  Thanks! This convinced me. I'll stick to C for low-level, C++ for CUDA stuff, and C# for everything else.
  • gameswithgo 6y ago
    What if you were working on something where a cve or data leak from a buffer overrun could kill the company, or end a life?
    • joerichey 6y ago
      If you're working on safety-citical software, I think using formally verified C code (as discussed in the article) would be the best approch. If a bug could kill someone, you should (to the greatest extent possible) have a proof that such bugs are impossible.
    • pjmlp 6y ago
      How do you ensure an unsafe block on an dependency downloaded from cargo out of some pad-left like implementation doesn't do exactly that? Also should be noted that Rust lacks the necessary certifications.
      • dodobirdlord 6y ago
        In a situation where memory unsafety could put people (or the future of the company) at risk downloading random unaudited dependencies off of crates.io is obviously a no-go. Ideally downloading off of crates.io is a no-go during building anyway, since cargo can work with all of your external dependencies mirrored to a local filesystem or your own custom crate registry.
        • pjmlp 6y ago
          So basically the same approach as required by ISO security standards for C, C++, Ada and Java.
      • scns 6y ago
• jhoechtl 6y ago
  Too complicated which means when your lead rust dev leaves good luck finding another one.
  • dodobirdlord 6y ago
    If you run a Rust shop you need to invest in training and mentoring. It's probably not the right choice for a butts-in-seats feature factory.
    • Polylactic_acid 6y ago
      Seems like its mostly getting used by places doing fairly cutting edge infrastructure or other works where its going to take a fair bit of training to begin with.
  • pizza234 6y ago
    If one chooses manual memory managment, the "complicatedness" (as you put it) is not a matter of the language, it's a matter of programming type. As other computer engineering concepts (e.g. referential integrity in database systems), the lack [of implementation] of a feature (e.g. foreign keys) doesn't make a system that needs that concept simple - it just shifts it to the application level.
  • est31 6y ago
    As the article says, it's a chicken and egg problem. Small number of jobs, means small number of people who have had those jobs in the past and now have those 6 years of experience with Rust plus minimum 4 years of leadership experience. Means more deciders having the attitude you have instead of "let's go with Rust!".
  • mhh__ 6y ago
    It definitely wouldn't be easy as finding your next web developer (or similar) but relatively niche languages (in my experience) tend to have some very clever people on their forums (or similar) so - especially for Rust which is a established language in my mind these days - you shouldn't have that much of a problem finding someone technically capable (HR notwithstanding)
• the__alchemist 6y ago
  I hope this isn't too much of a tangent given the article's subject is details and specifics. I adore Rust for it's unique combination of features: - Can write fast, and systems-level code; something typically dominated by C/++ - Makes standalone executables - Modern, high-level language features - Best-in-class tooling and docs (As the article points out) I'm not familiar with another language that can do these together. It's easy to pidgeonhole Rust as a "safe" language, but I adore it on a holistic level. I've found Rust's consolidated, official tooling makes the experience approachable for new people.
  • nicoburns 6y ago
    It's the modern high-level language features that get me. Despite Rust technically being a lower-level language, they are so well implemented that I often find Rust more enjoyable to code something in than other supposedly friendlier languages. The killer is the compile times. If Rust had Go-like compile times it would be almost perfect.
    • est31 6y ago
      You get accustomed to the slow compile times of Rust over time. Then you do some Go stuff and get extremely surprised by how quick it is, almost as if Go's cheating. But it's just rustc being slow :).
      • ncmncm 6y ago
        You don't achieve success by getting (some) people accustomed to your failings. That is a route to failure. There are many, many routes to failure. Staying off them doesn't guarantee success; it's table stakes.
      • pjmlp 6y ago
        Sadly I am spoiled by Delphi, C++ Builder, VC++, D, Eiffel,...
    • drran 6y ago
      Rust is high-level language. You mean "a language which allows low level access to hardware". Right?
• angelbar 6y ago
  Because oil...
• forrestthewoods 6y ago
  > Rust also lacks an analog for the pimpl idiom, which means that changing a crate requires recompiling (and not just relinking) all of its reverse dependencies. Interesting. I did not know this. I would have thought Box<dyn Foo> would have achieved PIMPL. Is that not the case?
  • joerichey 6y ago
    I think you would actually need Box<dyn Foo>. But the bigger point is that the current build system can't figure out that a rebuild isn't necessary in these cases.
    • forrestthewoods 6y ago
      > I think you would actually need Box<dyn Foo> Oops. Good catch. Fixed. :) Sounds like this is a fixable problem though? That’s nice. I really appreciate the amount of attention Rust compile times is getting. (Especially because relative to C++ they aren’t actually that bad!)
  • ArchOversight 6y ago
    The downside to the PIMPL idiom in C++ at least, is that you have double indirection. The outer exposed API is called on `this` which then uses the internal `pimpl` pointer to actually call a function. While it may speed up building, I have found it incredibly clunky to use in C++ and prefer to write my code without it, choosing instead for longer compilation times.
    • forrestthewoods 6y ago
      > The downside to the PIMPL idiom in C++ at least, is that you have double indirection. PIMPL is just a tool. There’s no argument here that it should be used in all or even many cases. The fact that C++ has this tool and Rust does not is interesting. PIMPL indeed has overhead. Both when writing the code and when calling the code. If a program crosses the PIMPL boundary many times then the calling overhead can be meaningful. However if the API is small and the program spends more time “inside” the PIMPL than crossing the boundary the runtime overhead is trivial. A key benefit of PIMPL is that, in some cases, you can have a very lightweight header than clearly expresses an API without making users include a ton of dependencies they don’t actually need. I shall not express my opinion on C++ headers. Historically I have not liked PIMPL. My current project benefits from it a great deal. Most projects probably would not. Like I said, it’s just one of many tools.
• est31 6y ago
  A big thing missed here is compatibility. The systems programming market is huge but most of it is covered by C/C++ programs, many of which being giant codebases with millions of engineer hours inside them. You can't just rewrite them in Rust. And Rust will always be second in place when it comes to interacting with C/C++ codebases, C++ will always be better at it, and if it's only the explicit safety barrier. So languages like Rust are relegated to picking up the new greenfield codebases and some few codebases where engineers felt courageous enough to introduce it. Overall, the signs are good though. I think it's much easier to onboard new engineers to Rust rather than to the company specific dialect of C++.
  • omn1 6y ago
    You're right about the massive amounts of C/C++ code out there. I'd disagree that the integration is harder than with C++, though. Calling Rust from C and vice versa is fairly straightforward and there are automatic code generators for doing so. Things just get wrapped into an `unsafe` block and that gives you the same guarantees you'd have with C++ (none, basically). From there you can start to gradually rewrite critical parts in safe Rust and profit from the cargo ecosystem along the way. In that sense there's even an advantage for Rust over C++ in my book.
    • est31 6y ago
      Integrating with C is easier than with C++ but it still needs those safe wrappers. With C++ you can use stuff directly, and maybe sometimes have to convert between say C and C++ strings. Integrating with C++ is much harder, especially if some C++ features are used. What if you have to inherit a class to do something? What if there is a generic function that you need to invoke? Even tasks as simple as catching exceptions are difficult. Things have improved with dtolnay's cxx thankfully.
    • ncmncm 6y ago
      Calling C++ libraries from Rust is in general impossible. The more useful the library is, the less likely it is that Rust can call it. As the languages evolve, that will sharpen. There is no "C/C++" code. Using the expression mainly generates confusion, most usually in the person saying it.
• networkimprov 6y ago
  Will the compiler performance eventually match C++, or are there fundamental limits to it?
  • sanxiyn 6y ago
    Rust already compiles as fast as C++ if you write in roughly equivalent style.
    • pjmlp 6y ago
      I can easily beat Rust, thanks to incremental linking and binary libraries.
    • jhasse 6y ago
      In my experience C++ is a lot faster, especially with multiple cores.
  • moonchild 6y ago
    I'm not sure what your point is there; rust and c++ are both famous for having slow compile times. Languages with good compile times include: - C[1] (unless you go crazy with the preprocessor) - Go (unless you go crazy with code generation) - D (unless you go crazy with templates) 1. With TCC or similar. Gcc/clang compile times are just ok (though better than with c++; and interestingly, though gcc is slower for c++, it's faster for c).
  • higerordermap 6y ago
    It should in theory be better because of modules instead of header files. It is bad because rustc emits quite a lot of LLVM IR and lack of binary libraries / library caching.
• the_duke 6y ago
  > Not All Programming is Systems Programming Personally I often use Rust for "non systems-programming" tasks, even though I really wish a more suitable language existed. Rust has plenty of downsides, but hits a particular sweet spot for me that is hard to find elsewhere: * Expressive, pretty powerful, ML and Haskell inspired type system * Memory safe. In higher level code you have almost zero justification for `unsafe`, unless you really need a C library. * Immutable by default. Can feel almost functional, depending on code style. * Error handling (it's not perfect by any means, but much better than exceptions in my book) * Very coherent language design. The language has few warts, in part thanks to the young age. * Great package manager and build system. * Good tooling in general (compiler errors, formatter, linter, docs generation, ... ) * Library availability is great for certain domains, decent for many. * Statically compiled. Mostly statically linked. Though I often wish there was an additional interpreter/JIT with a REPL. * Good performance without much effort. * Good concurrency/parallelism primitives, especially since async * Increasingly better IDE support, thanks to the author of this blog post! (rust-analyzer) So I often accept the downsides of Rust, even for higher level code, because I don't know another language that fits. My closest alternatives would probably be Go, Haskell or F#. But each don't fit the above list one way or another.
  • yashap 6y ago
    You might like Scala and/or Kotlin. You listed Go, but Go’s type system is very weak, as is Go’s support for immutability, two problems that Scala and Kotlin don’t share.
    • jhardy54 6y ago
      Personally I'm not very excited about making Java a hard dependency, or the fact that Scala can't be bootstrapped like most other languages. [0] [0]: https://bootstrappable.org https://bootstrappable.org
      • yashap 6y ago
        Your 2nd point will stop being true very soon. Scala 3 will apparently be coming out sometime this fall (https://www.scala-lang.org/blog/2020/09/15/scala-3-the-community-powered-release.html https://www.scala-lang.org/blog/2020/09/15/scala-3-the-commu...), and the compiler will be the Dotty compiler. Dotty is bootstrapped (https://dotty.epfl.ch/blog/2019/05/23/15th-dotty-milestone-release.html https://dotty.epfl.ch/blog/2019/05/23/15th-dotty-milestone-r...). The first point is true, but IMO not a big deal for most applications. Scala native exists, but is very immature. Still, if you’re writing web services, data processing jobs, etc., I don’t see much of an issue with depending on the JVM. Definitely an issue with things like command line tools, or apps with super tight resource requirements, but that’s not the case for a tonne of software.
• AllasAskBar 6y ago
  Anyone can see that C/C++ is outdated. Peering into the mess of those languages is like seeing Java/C# when you are used to a modern language like kotlin.
• rvz 6y ago
  Another thing not mentioned is there's still no mature cross-platform production ready GUI libraries written in Rust yet. None of them come even close to Qt or countering Electron. Just mere unmaintained bindings to them. [0] I guess it is either Electron (HTML/CSS/JS) + 200MB Chromium engine or Qt5 (C++) for now. [0] https://www.areweguiyet.com/ https://www.areweguiyet.com/
  • est31 6y ago
    There are a bunch of tiny single person projects but they are young and have tons of missing features and bugs. Ideally, you'd have a team building and maintaining a solution but that requires either an insane amount of coordination (and there's tons of disagreement about which design pattern to use), or money.
  • neutronicus 6y ago
    "yet" Most languages never get one, and content themselves with piggybacking off of WxWidgets or JavaScript (or whatever).
    • raphlinus 6y ago
      Indeed. There is certainly no mature GUI framework in Rust yet, simply because it is an extremely ambitious undertaking, but I believe that Rust is by far one of the most promising languages for developing such a thing. I see great vitality both in explorations (for example, figuring out the best patterns for expressing reactivity) as well as infrastructure. I'll give an example of the latter which I find compelling. OpenType shaping (one of the subproblems of text layout) is a notoriously difficult problem, and almost nothing can compete with HarfBuzz, which is written in C++. Yet there is already one pure Rust alternative being used in production, Allsorts (used in Prince XML), and another promising one in development (rustybuzz, being developed by RazrFalcon, who has a track record of shipping ambitious 2D software).
      • pjmlp 6y ago
        I rather use the native engines from each platform.
• pron 6y ago
  > we don’t know how to create a simpler memory safe low-level language. This may well be true, but using a memory-safe language is never, ever the goal. The goal is creating correct and secure programs -- that have as few bugs and security flaws as possible/required -- as cheaply as possible. While a memory safe language in the style of Rust is one means toward that end, that eliminates an important class of bugs at the cost of language complexity, it is not the best way toward that goal, at least not that we know, and it is certainly not the only one [1]. I.e. the hypothesis that if I want to write a program that's as correct as possible/needed as cheaply as possible then I should necessarily use the language that gives me the most sound guarantees regardless of the cost this entails is just some people's guess. It's hard to say if it's a good guess or a bad one because it's clear that we're talking about specific sweet-spots on a wide spectrum of options that could be very context-dependent, but it's still a guess, with good arguments both in its favour as well as against. > In Rust, there are choices to be made, some important enough to have dedicated syntax. Not only that, but those choices are exposed in the type signature and are, therefore, viral. Changing some internal technical implementation detail can require changes in all consumers. This is not a problem with the type system -- on the contrary, Rust's type system ensures that all the changes that need to be made are made -- but it is a fundamental problem with all low level language. They all suffer from low abstraction, i.e. a certain interface can represent a smaller number of implementations than in high-level languages (even if the choice is not explicit in the type, like, say, in C, the usage pattern is part of the interface). But Rust's choice to expose such details in the types has its downsides as well. > If you use C, you can use formal methods to prove the absence of undefined behaviors C now also has sound static analysis tools [2] that guarantee no undefined behaviour with a nearly fully automatic proof that scales to virtually any code size and requires relatively little effort, certainly compared to a rewrite. [1]: Another low-level language with an emphasis on the same goal of correctness, Zig, takes an approach that is radically different from Rust's and is so simple it can be fully learned in a day or two. Which of the two approaches, if any, is better for correctness can only be answered empirically. [2]: Like https://trust-in-soft.com/ https://trust-in-soft.com/, from the makers of Frama-C
• stephc_int13 6y ago
  In the videogames world we - need very good performance - don't care about memory safety (not an issue) - also need fast compile time
  • est31 6y ago
    It has improved a little a while ago with the stable profile overrides feature, allowing you to compile dependencies in release mode and your own logic in debug mode. Made work on my Rust written game much easier. But there's still ways to go. Ideally you have an engine and lua/scripting layer anyways.
    • dmm 6y ago
      I don't know how I missed this but you really made my day! Serde is much slower in debug builds so I have been using release for everything. That works but the builds take a looong time.
    • mitchtbaum 6y ago
      > Ideally you have an engine and lua/scripting layer anyways. Honk
  • muldvarp 6y ago
    > In the videogames world we [...] don't care about memory safety (not an issue) Well, that's how you get remote code execution vulnerabilities in CS:GO [1]. If you're doing anything at all over the network you absolutely need to care about memory safety. This doesn't mean that you need to use Rust of course, but security is still an issue. [1] https://hackerone.com/reports/351014 https://hackerone.com/reports/351014
    • j-krieger 6y ago
      So what? As far as I know, those are user problems and have not costed valve a single dollar in damages.
      • 6y ago
• jeffrallen 6y ago
  In the section on "Rust is big and you have to learn it" the author was too nice to people like me: I'm just not smart enough to manage the demands Rust puts on me while also solving my own problem. I feel like this is a really serious problem for Rust: the number of people capable of making the right choices among the 10 ways to structure a class is too small. This is also why there's too much dangerously bad C and C++ in the world.
  • dodobirdlord 6y ago
    Yea, I think Rust may be hurting currently for conventions or "best practices". The benefit of most "best practices" isn't usually that the opinions actually have any merit, but rather that they are consistent and meld into the background. Has any large company that uses Rust published a well-regarded and well-adopted detailed style guide in the way that Google publishes style guides for the languages they use?
    • hobofan 6y ago
      You probably won't find much of written out style guides on Rust, since with rustfmt and clippy, a strongly community endorsed code formatter and linter have been available since (almost) day one. With that, you have most of the "best practices" in form of a tool already.
      • timidger 6y ago
        Clippy catches a lot and I can't imagine coding without rustfmt. But there's more to style guides than formatting and Clippy lints. Some designs will pass Clippy (or worse, lead to Clippy warnings far past the point where a redesign is economical) but be inefficient, inflexible, or have a poor effect on compile speeds. One major problem I experienced in my last job (where I worked on production rust) was the insane amount of macros and proc macros used. This was an originally C++ heavy shop so they leaned on it more than, say, a python shop moving to rust would. This led to terrible compilation times and confusing code only certain engineers could maintain (I'm guilty here - I've since left and I know of one proc macro I wrote that will cause headaches to anyone who uses it). We need an opinionated style guide. The language is so complex we probably need multiple, with different trade offs.
• Animats 6y ago
  As I've said before, Go has the advantage of mediocrity. It's boring as a language, but it does automatically most of the things you need for web back-end stuff. It's garbage-collected and does subscript checking, so you're covered on memory safety. There are stable libraries for most things you need in a web server, and those are mostly the same libraries Google is using internally, so they're well tested. The green thread/goroutine approach means you don't have the problems which come from "async" and threads in the same program; there's only one concurrent task construct. There's a lot to be said for that. You can put junior programmers on something and they'll probably get it more or less right. Rust is very clever. The borrow checker was a huge step forward. It changed programming. Now, everybody gets ownership semantics. Any new language that isn't garbage collected will probably have ownership semantics. Before Rust, only theorists discussed ownership semantics much. Ownership was implicit in programs, and not talked about much. Tying locking to ownership seems to have worked in Rust. A big problem with locking has been that languages didn't address which lock covers what data. Java approached that with "synchronized", but that seems to have been a flop. (Why?) Ada had the "rendezvous", a similar idea. Rust seems to have made forward progress in that area. I used to say that the big problems in C are "How big is it?", "Who owns it for deletion purposes?", and "Who locks it?" At last, with Rust we see strong solutions to those problems in wide use. Much work has gone into Rust, and it will have much influence on the design of later languages. We're finding out what happens with that model, what's useful, what's missing, and what's cruft. In the next round of languages, we'll probably have to deal directly with non-shared memory. Totally shared memory in multiprocessors is an illusion maintained by elaborate cache interlocking and huge inter-cache bandwidth. That has scaling limits. Future languages will probably have to track which CPUs can access which data. "Thread local" and "immutable" are a start.
  • pjmlp 6y ago
    I am looking forward that the generics 2020 edition actually make it, as Go is becoming anyway harder to avoid on my domain. I think ultimately the biggest Rust contribution will be for GC languages (tracing GC | RC) to also adopt some kind of early reclamation, similarly to Swift's ongoing approach, and we will reach a good enough situation and that will be it.
  • 6y ago
• mhh__ 6y ago
  I think Andrei Alexandrescu's comment that Rust "skipped leg day" is still mostly true (Rust does what it set out to do better than anyone else but the metaprogramming in particular isn't very attractive)
  • nindalf 6y ago
    Peronally I feel more comfortable writing metaprograms in Rust than any other language. Could you elaborate?
    • ncmncm 6y ago
      Rust macros have no access to types at all. Types are essential for any but the most trivial metaprogramming.
      • redrobein 6y ago
        Can you give a specific example of this?
      • raphlinus 6y ago
        If you consider the scope of metaprogramming to include both macros and traits (and I do), then this is seriously understating the case. Rust's type system has a Prolog-like core and is Turing complete, so is quite expressive in able hands. A great example of the two features working together is serde, which automatically derives serialization and deserialization code (with custom overridable behavior such as defaults) for a very wide range of types. It's also something like 20-50x faster than Swift's Codable based implementation of JSON.
        • ncmncm 6y ago
          I guess I do, too, now. It has got more powerful since I last looked.
• aazaa 6y ago
  > Programmer’s time is valuable, and, if you pick Rust, expect to spend some of it on learning the ropes. Of all the arguments, time-to-productivity may be the most compelling. Rust will keep most new programmers from being productive far longer than any other language. I'd say 3x minimum. What's a little surprising, though, is how many of the difficulties beginners have stem from just one concept: ownership. Counterintuitively, ownership is quite simple. But what's mind-bending about it is that it doesn't exist in any other language a beginner is likely to have used. Yet ownership pervades Rust, sometimes in very hard to detect ways. And perversely, it's possible to write a lot of Rust without ever "seeing" ownership thanks to the complier. Eventually, though, the beginner comes face-to-face with ownership without recognizing the trap s/he's fallen into. Ownership isn't something you can "discover" by messing around in the same way that most language features can be teased apart. The term "fighting with the borrow checker" is actually a symptom not of a struggle with a feature but a struggle with a basic, non-negotiable concept that hasn't been learned. I can recommend this video for getting over the hump: https://www.youtube.com/watch?list=PLLqEtX6ql2EyPAZ1M2_C0GgVd4A-_L4_5&v=1QoT9fmPYr8 https://www.youtube.com/watch?list=PLLqEtX6ql2EyPAZ1M2_C0GgV... In my experience, Rust productivity shoots up by a lot given a basic understanding of ownership.
  • dlubarov 6y ago
    Besides the learning difficulty, I'd there are some real ergonomic issues related to ownership, such as the difficulty of cloning into a closure [1], or nested &mut receiver calls being rejected despite being sound [2]. [1] https://github.com/rust-lang/rfcs/issues/2407 https://github.com/rust-lang/rfcs/issues/2407 [2] https://github.com/rust-lang/rust/issues/6268 https://github.com/rust-lang/rust/issues/6268
  • lostcolony 6y ago
    "But what's mind-bending about it is that it doesn't exist in any other language a beginner is likely to have used." This is true about killer features in any language that is above the 'average' on the power spectrum ( http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html ). In fact, even beyond beginners, I see resumes for people all the time with 20+ years who have only used Java/Python/C/C++. If you are evaluating languages for power or expressiveness, not just tooling/libraries/domain integrations, you're going to have longer ramp up time on average, regardless of the seniority of the developer, because you're by definition looking for features that aren't average (and therefore not mainstream).
• andrewmcwatters 6y ago
  Not many people just come out and say it, but I think Rust is an ugly programming language. That's a good enough reason for me.
  • cuddlecake 6y ago
    Could you try to explain why you think rust is an ugly programming language?
    • pornel 6y ago
      • Rust is focused on being explicit rather than pretty/elegant. So there's sigilisitic code like `&/&mut`, `move||`, `Arc<T>` for details that are implied in higher-level languages. • Rust wants to have easy-to-parse unambiguous syntax. This makes turbofish required when you have a type in expression context. You need `->` for the return type. • Rust uses generics, and angle brackets are ugly. It also mandates `{}` in blocks, but allows skipping `()`, which gives you a high ratio of ugly brackets to the nice round ones :) • Rust wants to make up for the cost of explicitness by adding abbreviations. So you have `fn` that's both explicit and terse. Instead of verbose `switch/case/default`, Rust's `match` uses patterns and `_ =>`. Rust designers pay a lot of attention to the syntax, but it's designed from a very practical point of view (it is clear? unambiguous? easy to write? composes with other syntax?), and "does it look neat?" is very low on the priority list.
      • feoren 6y ago
        You sound like the kind of guy who prefers CoffeeScript over JavaScript; YAML over JSON. Every single programming language has punctuation -- the "punctuation-free" languages have all just decided that their punctuation should be invisible.
  • cxr 6y ago
    I took a lot of heat for that in a recent thread. There's really no convincing Rust's most vocal fans what a mistake it was to focus on fixing so few of C++'s problems when they had the opportunity to fix the its-grammar-is-dogshit problem (and slow compiles times) in the same stroke but completely failed to do so. (Votes were all over the place. At one point that comment was up 10–15 points IIRC even with some opposition, until the Aucklanders woke up and buried it in downvotes. And that was when I was being a lot more polite about it than I am now.) C++ programmers seem to have a permanently altered sense of what constitutes "tastefulness". Every time I think of the ugliness of Rust, I'm reminded of the comments from Stallman where he acknowledges the elegance of Java as an evolution of C's syntax, even though he never reached for Java for himself, having always stuck to C and Lisp instead. Then he goes on to trash C++.
• maitredusoi 6y ago
  Rust is certainly powerful but not accessible to all dev. After 12 years of ruby, nothing push me to learn rust. By most I would stick to crystal, which is way morea accessible
• csomar 6y ago
  > Rust is a systems programming language. While Rust is a systems programming language, it has a very advanced Traits system. This makes it, in my opinion, more powerful than your average scripting language (Python, JavaScript, etc...) I have recently used Rust for something that I should have, normally, used JavaScript or Python for. Based on my experience, I probably gained in development time because I didn't do much debugging. Rust code just works, it's simply amazing. > Complexity One way to approach this, is to actually enjoy this complexity because there is real theoretical computer science behind it. It's not complexity for its own sake. > Compile Times This one is really annoying even with a powerful processor. > Maturity I'd argue that since many high profile companies like Facebook, Google and Microsoft used Rust to start new projects (like Libra, Fuchsia); Rust is stable enough to be used in a production capacity. You'll probably benefit more if the project is new and thus have less time dealing with C compatibility.
  • millstone 6y ago
    Traits do not make Rust more powerful than your average scripting language. They are much less powerful. The biggest hole here is the complete absence of any dynamicism. Rust types do not have any real runtime presence. Concretely, there is no way to dynamically check whether this value implements some Trait. This is used in Golang (Copy -> WriterTo) but is impossible in Rust without manual implementation.
  • higerordermap 6y ago
    The cognitive overhead of rust is more than prototyping oriented langauges. It is not because of dynamism but the need to think about details. That's natural for the intended domain of rust. (Robust system programming). But rust might suffer due to scope creep because someone felt the need to teach rust to all ruby rail / javascript webshits.
  • LoveHateRust 6y ago
    Rust's typesystem really makes it a great fit for business applications. Totally agree. Kotlin comes close, though. Rust itself is production ready, but not the ecosystem.
  • 6y ago
• throwaway78123 6y ago
  Rust in prod has been bittersweet for us. Our main goal was to 1) do our job and 2) leverage some of the great promises of Rust. Deterministic memory management and bare metal performance are great and have been realized benefits. The great promises were realized. On the “do your job” front though, the lack of a good STABLE library ecosystem has been a real issue and big source of frustration. It seems that most library developers in the Rust community are hackers writing Rust for fun, and I do not say that in a negative way. But the consequence is that things are usually not super well maintained, but more critically are targeting Rust Nightly (which makes sense as Nightly has all the new cool compiler stuff). Add the scarce professional talent pool, the unavoidable steep learning curve, low bus factor risk... It’s just hard to justify pushing (professionally) more Rust beyond its niche. With Mozilla pulling out (to some extent), the big focus on Web-assembly... it just feels off if all you want to do is build boring backends. The contrast with Golang’s “boring as a feature” is quite interesting in that regard. Time will tell if Rust will make it to the major leagues, or will be another Haskell.
  • tmandry 6y ago
    Most libraries don’t target nightly anymore. It certainly used to be the case that nightly had all the cool features everyone wanted, but almost all features that popular crates depended on have now been stabilized. Even Rocket (the most high-profile holdout I know of) now works on stable as of earlier this year. As for maintenance, as with all library ecosystems it’s a mix. The most popular crates tend to be the most well-maintained in my experience. This is definitely something to consider when taking on new dependencies.
  • swsieber 6y ago
    Many things that used to nightly don't anymore. I think the only thing I'm using on nightly is Rocket, and that's set to change soon. May I ask what it was?
    • throwaway78123 6y ago
      parquet-rs: to read or write parquet files, cf the Arrow project: https://news.ycombinator.com/item?id=23966150 https://news.ycombinator.com/item?id=23966150 where one person asking about triggered a ticket in Arrow's JIRA. I am not holding my breath (a 2.5 years old issue on Github about the exact same thing appears to be dead: https://github.com/sunchao/parquet-rs/issues/119 https://github.com/sunchao/parquet-rs/issues/119) The web framework situation has also been a problem for quite some time. No clear stable equivalent to jetty, flask, go's net/http. Great that Diesel (which looks great) is making it to stable. I really wished it was stable 3 years ago. On that note it would be great if crates.io would have stable/nightly compatibility as a primary concept/badge/filter. I can't think of any other mechanism to nudge library developers into supporting stable as a first class citizen.
• mbo 6y ago
  > “Rust should have stable ABI” — I don’t think this is a strong argument. Monomorphization is pretty fundamentally incompatible with dynamic linking and there’s C ABI if you really need to. This is an interesting topic unto itself, described in one of my favourite pieces of technical writing of all time: How Swift Achieved Dynamic Linking Where Rust Couldn't - Alexis Beingessner - https://gankra.github.io/blah/swift-abi/ https://gankra.github.io/blah/swift-abi/
• Karupan 6y ago
  > Complexity - Programmer’s time is valuable, and, if you pick Rust, expect to spend some of it on learning the ropes This has been my experience as well. I've been trying out Rust for a week now and as an experienced programmer, the complexity of the language is overwhelming. That said, you don't need to know all language constructs to get started. In the last week, I've been able to build a simple but useful cross-platform GUI app after reading only the ownership/lifetime section of the Rust book. But yes, it is not for everyone and it certainly isn't a simple language to pick up.
  • leeman2016 6y ago
    > cross-platform GUI app May I ask using what?
    • Karupan 6y ago
      I evaluated a few libraries, but ended up using iced [0]. I'm writing a short blog post with my findings (will hopefully post it on HN) [0] https://github.com/hecrj/iced https://github.com/hecrj/iced
• k__ 6y ago
  Sure, not everything is system programming, but Rust has some higher level features that are even missing in languages like JavaScript and Python. Pattern matching is very powerful. I'm not entirely sure, but have the feeling that Rust's "cons" are mostly short term draw backs and the "pros" could be really valuable in the long run.
  • sunsetSamurai 6y ago
    I think there's a proposed pattern matching implementation for javascript in the works.
    • steveklabnik 6y ago
      There is, and the author of that proposal created it after learning Rust.
    • k__ 6y ago
      There is also Z https://github.com/z-pattern-matching/z https://github.com/z-pattern-matching/z
  • millstone 6y ago
    Consider a function like getElementById(). This is natural in JS, but a crisis in Rust - what does it return? How do you ensure that your caller doesn't have some unwrapped RefCell on the stack? etc. Broadly speaking, Rust is good at trees and bad at graphs. This implies real tradeoffs, real design decisions. There are many software components that Rust is just not good at, by design.
    • palmtree3000 6y ago
      Apparently [1] it returns Option<Element>. [1] https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.Document.html#method.get_element_by_id https://rustwasm.github.io/wasm-bindgen/api/web_sys/struct.D...
      • 6y ago
• ncmncm 6y ago
  This is a pretty good summary. Not to pile on, because Rust is still in a fragile condition, but the point that Rust cannot, and never will be able to call, typical C++ libraries deserves a boost (no pun intended). This matters because C++ has more facilities to encapsulate powerful semantics into libraries than any other language. People write libraries in C++ that cannot be written in other languages, routinely. This makes it usually impractical to integrate Rust code into an existing modern C++ codebase, unless it implements a wholly independent subsystem. That matters because effectively all of the most demanding systems-level work, today, is conducted in C++, not C (old OS kernels and databases excepted). The longevity problem also deserves attention. The normal, expected fate of any new language is to die. It practically takes a miracle to survive, and we have no way to predict miracles. So, we don't know if there will be anyone to maintain Rust code written today. What will it take to survive? It comes down to numbers. Rust has an excellent adoption rate for a language at this stage. To survive, it might be enough were the rate to increase by two orders of magnitude. You don't get that just by more and better publicity. It needs change. But the changes needed are, by experience, very, very unpopular among existing Rust users. Rust will never displace C++ or C. C++ does things Rust can't. C will dwindle only as its user base retires, because C users actually like it for its failings: it makes them feel tough (or something). Rust is an overwhelmingly better language than Java or Go, and the world would be a better place if Rust were to displace them. But neither of those has the specific problems that the borrow checker demands be solved. They have other, graver weaknesses. So, for Rust to displace them, its advocates will need to change their approach to appeal to users of those languages. That will require at least a different build model that admits an order of magnitude faster builds, and a looser use of the borrow checker that generates less frustration. It might need accommodations to integrate in Go and Java projects, maybe including support for a JVM target, virtual call mechanism, and import of foreign Go and Java modules. To get any of that, the project will need to excite people now in those environments with the prospect of easing their pain. Rust's advantage there is that their pain is great, and Rust could ease it.
  • farresito 6y ago
    > Rust will never displace C++ or C. C++ does things Rust can't. Could you expand a little bit on that?
• Ericson2314 6y ago
  Great blog post > Rust also lacks an analog for the pimpl idiom, which means that changing a crate requires recompiling (and not just relinking) all of its reverse dependencies. I really hope `extern type` could help with this. edit wrote https://github.com/rust-lang/rfcs/pull/2984#issuecomment-695844429 https://github.com/rust-lang/rfcs/pull/2984#issuecomment-695... on how I think it could.
• jart 6y ago
  TIL Rust is working on its own version of ASAN and UBSAN: https://github.com/rust-lang/miri https://github.com/rust-lang/miri How shocking.
  • tmp538394722 6y ago
    Shocking why?
    • chubot 6y ago
      I imagine because ASAN and UBSAN are dynamic analysis, while Rust's philosophy is to offer static guarantees. I guess the problem is "unsafe" blocks. Someone else can probably elaborate better, but if you have pure Rust code with no unsafe blocks, you shouldn't have any memory errors. But large systems written in Rust might still benefit from finding memory errors dynamically rather than statically with something like ASAN.
      • steveklabnik 6y ago
        You are correct, yes. This is used on unsafe code only.
• snarkypixel 6y ago
  Yeah, compiling in Rust was the bane of my existence. I tried to stay on old versions for as long as possible to avoid compiling. At some points, I'd basically have to wait 10-15min.. so I'd go for a walk or grab coffee. Then I'd switch to javascript and it felt like going at the speed of light. To each their own.
• SrslyJosh 6y ago
  Why not try Zoidberg?
• jahaja 6y ago
  My main issue with "complex" or "expressive" languages are how they scale. Certainly not with regards to performance or throughput, but rather with how they scale with people. How will the code base look after 5 years and when a company have 50, 100, 200 devs instead of 10? Expressive languages invites people to have their own dialects, their own little version of the language. It also invites people to be too smart for their own good and especially for the team's good, resulting in code that's very hard to debug and maintain for other people than themselves. I've seen in the game industry with C++ how bad it can get[1]. Because in practice there's pressure, deadlines, temporary stand-ins "helping" other teams to finish their sub-projects. There just isn't always time to be strict, so code rot will always sneak in. Of course this happens in all languages, but I find it much less extensive in so-called "boring languages". [1] Because of this I'm actually really surprised that a few big game industry companies have recently adpoted Rust, because the main problems afaik were code complexity over time and build times.
  • higerordermap 6y ago
    Would take an expressive language any day, with some restrictions on templating / macros enforced on junior developers, rather than writing tedious for loops in Go.
    • jahaja 6y ago
      Why? The writing part of this job is the easy part. Furthermore, if you think that this problem is solved by just hassling junior devs a bit you're painfully wrong. Some people with great experience are still prone to this, some times as a matter of style.
      • higerordermap 6y ago
        Go makes it easy to understand what is happening at a micro per-statement level and not a macro level. For me, readability is about expressing __intent__ and not about every machine detail. Writing all that boilerplate is also more error prone. My favourite example: see the following code in Go containsVal = false for _,i := range array { if (i == val) { containsVal = true } } This is one statement in any language with reasonable abstraction capabilities: python: `val in array` Javascript: `array.includes(val)` Java: `array.indexOf(val) != -1` C++: `std::find(array.begin(), array.end(), val) != array.end()` (Actually C++ one is already quite verbose and little distracting, but sure you can implement it better in C++) Go is only so-called modern language in which standard library cannot provide trivial abstractions to convey intent. Instead you have to use interface{} escape hatch or use codegen. The 'Go is readable' meme is misguided.
• georgehm 6y ago
  big plus one for Kotlin as a general purpose language
• ajxs 6y ago
  The article fails to mention Ada's capabilities in the area of formal verification. The 'SPARK' subset of the language is designed explicitly for this purpose. Modern Ada/SPARK also support Rust style 'safe-pointers': https://blog.adacore.com/using-pointers-in-spark https://blog.adacore.com/using-pointers-in-spark
• slmjkdbtl 6y ago
  I (hobby gamedev) moved from Rust to C a few weeks ago, here's something that made me switch: 1. Compilation time (no more words needed) 2. Forced to use Cargo for managing dependencies. The downside of a good dependency toolchain is that people will use it and there will be tons of indirect dependencies. For cross-platform development it's very common to see one of your indirect dependencies doesn't support the platform you wanted, and there's no way around it (even you know how to fix it you'll have to submit a pr and wait till the merge and crates.io release (takes years), or download the whole dependency chain and use everything locally which is a total mess) 3. Too strict. As a hobby gamedev the thing I value the most is the joy of programming, I don't want to spend all my time trying to figure out how to solve a borrow checker issue (you'll always face them no matter how good you're at Rust, and I don't want to use Rc<RefCell<T>> everywhere), and I just want to be able to use global variables without ugly unsafe wrappers in my naive single threaded application. As a language I love every aspect of Rust, just ergonomically I don't want to deal with it now.
  • gpm 6y ago
    > (even you know how to fix it you'll have to submit a pr and wait till the merge and crates.io release (takes years), or download the whole dependency chain and use everything locally which is a total mess) For what it's worth, cargo supports patching dependencies without maintaining the whole dependency chain locally. See here: https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html https://doc.rust-lang.org/cargo/reference/overriding-depende...
    • slmjkdbtl 6y ago
      That's very good to know! Thank you. Yes such feature is very needed for a package manager
  • Snelius 6y ago
    Yea. The Rust is a language pleasant to read about but not to wish to write on.
• zelly 6y ago
  Memory errors are not as big of an issue in the real world as the designers of Rust seem to assume. Andrei Alexandrescu has this quote about how Rust skipped leg day. You should all look it up. Here's what actually matters, in the real world, for the type of programs I'd choose Rust or a Rust-adjacent language: - Fast compile times - Easy build system. Must be parallel, saturate all cores, and handle distributed builds as a built-in first-class feature. Should be able to produce static binaries or dynamically linked binaries. Should be able to consume binary dependencies (that means a stable ABI). - Optimized, fuzzed, highly-tested, standards compliant web stack built-in - Ability to compile CUDA kernels, built-in - Automatic memory management with an escape hatch for where manual is necessary - Rich metaprogramming and compile-time reflection - Created by or funded by a large U.S. corporation so that PMs are likely to choose it. - IDE/LSP language server/editor plugins maintained by the language designers Failing this, you are an academic language, not a real world industry programming language in 2020.
  • Analemma_ 6y ago
    > Memory errors are not as big of an issue in the real world as the designers of Rust seem to assume. Microsoft and Google have both reported that memory safety errors make up about 70% of their security vulnerabilities.
    • esjeon 6y ago
      Still, security issues are secondary. The primary issue is always to make things work. You have no security to worry about if you don't have a working software.
    • zelly 6y ago
      That is solved by using garbage collection. There are times you need manual memory management. Then there are other times you don't (the vast majority of use cases). Rust forces you to constantly pretend that memory management matters, which gets quickly tiresome. Not everyone is working on Chromium or Windows. The reality of the matter is that for most real-world software development security doesn't matter at all.
    • 6y ago
• baby 6y ago
  From a security point of view, the major issue with Rust is still the shallow standard library, a shame the article doesn't emphasizes this and instead lists this as a negligible point. How many will end up using rust wrongly due to the lack of a rand library, or anything cryptography, etc. And that's nothing compared to the lack of a hex encoder/decoder, of a tcp library, of a json library, etc. Compare that to Golang and Rust has a lot to improve on.
  • higerordermap 6y ago
    Yeah, with all those focus on security, it is kind of astonishing that rust ecosystem has grown such a hard-to-audit web of dependencies. The only thing that explains it is an influx of web programmers who are used to this.
• chubs 6y ago
  I've been pondering similar issues re Rust a lot lately too. Mainly that it's very safe and fast, but that is offset by how difficult it is to use. I recently had an idea: What if i made a subset of Swift and a transpiler that outputs simple C? The C output would make it a great contender for integrations with existing code in the 'systems programming' genre. Swift is such a lovely language, far simpler than Rust, but being tied to apple's ecosystem and LLVM makes it difficult to use for many of these areas. This would also be great for embedded, which is something i'm also passionate about. End result would be: productive + simple + safe language, great for systems/embedded IoT stuff. Anyway i've submitted the idea for an R&D grant, we'll see if it goes anywhere. Would love to hear people's thoughts.
• trevorBelmont 6y ago
  Seething tranny
• baby 6y ago
  OK this annoyed me enough that I wrote my rebuttal :) https://www.cryptologie.net/article/505/why-not-rust-for-security/ https://www.cryptologie.net/article/505/why-not-rust-for-sec...
• doonesbury 6y ago
  This is one of better critiques I've read. I still think as a matter of market and solutions for same rust will continue to be a player. But I'm not game for rust to learn at the same time while I make, say, a distributed system. Frama-C with c++ I still think is the better combo