41 ms·

Rust Is Hard, Or: The Misery of Mainstream Programming

• draw_down 4y ago
• mc4ndr3 4y ago
  Rust isn't hard. Programming is hard. Rust just points out failure states before you encounter them in production.
  • threatofrain 4y ago
    All type systems will have meaningful and true propositions which are apparent to the programmer but not yet to the language team. Choosing a typed language is choosing to have a relationship with a living & evolving team/ecosystem, one which can improve over time in their ability to express and prove propositions or provide ergonomic abstractions. Some of what the author is complaining about matches my conversations with people who aspire to be Rust library authors — that you're often trying to hijack the type system because you <do> actually know better.
  • Gigachad 4y ago
    Other languages make this massively simpler by just disabling possible sources of failure like multithreading.
  • PragmaticPulp 4y ago
    I enjoy Rust, but it's not that simple. It really is more work to accomplish certain tasks in Rust than many other languages even when what you're doing is safe. The narrative that "Rust isn't hard" is getting tiresome, and I say this as someone who writes a lot of Rust. Let's be honest that Rust can be harder than many other programming languages in many ways, but those of us who use it believe the upsides and tradeoffs are worth the minor to moderate increase in difficulty. Pretending Rust is easy just sets beginners up for disappointment when they get into Rust and realize it wasn't what they were sold. Or worse, they start doubting themselves when they encounter the hard parts because Rust fans were busy insisting it's all easy.
    • Diggsey 4y ago
      Writing widely useful, performant, reusable, correct and stable libraries is very hard. Rust is the easiest language to do that in. If someone says programming in another language is easier, it's because they are not attempting (or are failing) to do one or more of those things. Those things are not always important so that's fine, but a lot of programmers (myself included) have this dream of being able to solve a problem once rather than over and over again, and that's why Rust appeals to us, and why we argue against Rust being hard - because it's actually easier for our particular usecase, but clearly not everyone has that same usecase.
      • ncmncm 4y ago
        > Writing widely useful, performant, reusable, correct and stable libraries is very hard. Correct. > Rust is the easiest language to do that in. Wrong. Rust provides very substantially less support to library designers than C++ does. Anyone creating ambitious libraries finds Rust a big step down. Rust might get more of what C++ offers library designers as it matures, but only at the cost of whatever simplicity it can still claim.
        • Diggsey 4y ago
          > Rust provides very substantially less support to library designers than C++ does. Anyone creating ambitious libraries finds Rust a big step down. Before I used Rust my main language was C++ where I specialized in writing libraries, and this is a ridiculous statement. It's only recently that the C++ standard library has gained enough functionality to do even some basic things in a portable way, so you're relying on other libraries to provide that, yet there is no standardized way to declare dependencies on those other libraries. There is no module system to ease structuring library code. There is no hygiene - a ton of stuff you include will just pollute the global namespace. There is no standard way to version your code. There is no standard way to update a library. Everyone uses incompatible string types - seriously, if you think Rust has too many string types, wait until you find out that every freaking C++ library represents strings differently, sometimes using the same types though! There is no standard place to publish libraries. Even basic language types like `int` differ massively from platform to platform, or even between different compilers on the same platform. Each compiler's preprocessor behaves slightly differently. The programmer must manually forward declare their functions, types, etc, and the rules are different for inline/templated code. All code is unsafe, and yet the rules for what constitutes UB are informal at best. (Whereas in Rust, the rules for UB are also not fully defined yet, but this is only relevant for the minority of your code which is not safe). All experienced C++ programmers think in terms of lifetimes, and yet cannot express this through the type system, so this must be documented informally. There is no standardized coding style or format. I'm going to stop now just because I'm bored but this list could go on for a very long time...
  • nhumrich 4y ago
    Im not so sure. There are a lot of error states that won't happen in production ever with other languages because the language/libaries handle those conditions gracefully without you needing to care. Rust pushes this to the edge, _which is good if you want that contol_, but is a cost you have to pay.
  • DeathArrow 4y ago
    >Rust isn't hard. Programming is hard. Programming should be hard only if the problem you are trying to solve is hard. Creating an boring CRUD app shouldn't be hard. Predicting with a good degree of success the market trends for stocks and options should be hard.
  • imaginaryNumb3r 4y ago
    This right here. Rust is a low-level language hat makes a whole dimension of implicit knowledge explicit. This is a very good thing, but if you are a programmer that is used to "copy paste, and then it works". You will have a very, very, very bad time with it. Rust forces you to think about memory. In an age where dynamic typing is so prevalent this seems like a fading art.
  • WuxiFingerHold 4y ago
    Why do you think the vast majority of software is written in GC languages? How does Rust point out deadlocks?
• 0xedb 4y ago
  Rust is hard until it's not!
  • adastra22 4y ago
    Life is hard until you're dead!
• brundolf 4y ago
  I expected this to be more one-sided - and it was a little ranty - but it also made a lot of good and substantial points
• nullcipher 4y ago
  Unpopular opinion: I find rust code unreadable. And I consider myself a polyglot. I am sure all those symbols have a special meaning but it's like perl to me. Just throw some random special characters and they all mean something.
  • 0des 4y ago
    Perl did nothing wrong, but I echo the sentiment you have about Rust. Last year I ported a mid size internal project to it as part of a resolution to learn a new language and the experience left me feeling like it was just me who "didnt get it". Building things took a lot longer, not just in the amount of code, but also the compile time. Ultimately compile time was the dealbreaker. On more than one ocassion I'd have to go back to the git history to remember what it was I had planned to do next.
    • bobbylarrybobby 4y ago
      Rust pro tip: don't compile til you're really done. Use something like cargo check or rust-analyzer to quickly spot errors without wasting time on the rest of compilation.
      • 0des 4y ago
        Thanks for the tip
  • wasifbaig 4y ago
    You are not the only one. I find rust code unreadable too even though I can understand it. I wish the type signatures and function definitions were on separate lines a la Haskell. That would have drastically improved the legibility.
    • ModernMech 4y ago
      You can do that in Rust by using a "where" clause. Put in a letter for each type, then define them on different lines.
• VWWHFSfQ 4y ago
  I've been programming in Rust for the last few years. My daily work is mostly just fumbling through compiler errors until the code works. Some observations: - The compiler is always right. - Do what clippy and rust-analyzer says. Don't ask questions. - If you're fighting the compiler, clippy, AND rust-analyzer, then you're almost definitely wrong. Virgins try to use &str everywhere. Chads just use String.
  • andrewchambers 4y ago
    This sounds like a terrible way to exist.
    • VWWHFSfQ 4y ago
      Happy way to exist!
      • andrewchambers 4y ago
        I suppose ignorance is bliss after all - I mainly hope you are exaggerating when you say 'fumbling through'.
      • phendrenad2 4y ago
        Getting paid to mechanically crank through compiler errors? Sounds okay actually!
  • orangetuba 4y ago
    I wonder what approach acts as the best mentor for someone who wants to eventually develop a good mental model for how systems work. The C approach where you suffer at runtime and then have to debug ferociously, or the Rust approach where your mentor hits you with a stick all day?
    • Hirrolot 4y ago
      I had C programming experience before touching Rust. I may be biased, but I think this is the right way to understand how computer systems work. Otherwise, Rust's design choices will make little sense to you.
• adeon 4y ago
  I wish there was a Rust-like programming language that was just a little bit higher level than Rust. I like Rust's wide ecosystem with high quality packages, the nice type system, traits, the idea that my code generally runs pretty fast even if I'm being lazy about writing good code, and my code usually working correctly if it compiles. I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I've written Rust for years now and this still occasionally can really slow me down. Rust is still a very nice language so I just deal with it :) no pain no gain. I would love a Rust-with-GC or something in that spirit that is similar to Rust but automatically figures out lifetimes as much as possible and GCs whatever it cannot figure out automatically. I've looked at languages like Nim and read about research languages like Koka so I'm optimistic something will emerge from this space I really like.
  • yeputons 4y ago
    > I care about speed and correctness but Rust makes me also care about ownership and lifetimes even when I don't really want to care about that stuff. I don't think one can care about speed and correctness without caring about lifetimes and ownership. Even if you do not care about memory ownership and use garbage collection, there are plethora of other things that you take care of. For example, if you've juts sent an RPC/HTTP request, and a user closed a particular window, should you abort the request or not? What if the user have closed all windows except one? Can they actually close window X without doing something in window Y first? What should happen if you forgot to abort the request and now the callback is called, but the original caller is gone?
    • taneq 4y ago
      I feel this fact is grossly underappreciated. Caring about speed and correctness but not ownership and lifetimes (and thread safety and race conditions and...) is like caring about road safety but not caring about headlights. You're not avoiding ownership and lifetime problems, you're just avoiding looking at them.
      • 4y ago
• the_duke 4y ago
  Rust does not have to be this hard. Most of the pain here come from the unholy trifactor: combining async, lifetimes and dynamic dispatch with trait object closures; which is indeed very awkward in practice. Async support is incredibly half-baked. It was released as an MVP, but that MVP has not improved notably in almost three years. There are lots of ideas, some progress on the fundamental language features required (GAT, existential types, ...) and the random RFC here and there, but progress is painfully slow. This isn't because no one cares, but because Rusts async implementation (which is very cool due to the low overhead) and its interactions with the other language features require complicated extensions to the type system. It does seem to me like there might be a lack of resources/coordination/vision ever since the Mozilla layoffs, but that's a different topic. If you can avoid async I would recommend doing so. The problem is that the entire ecosystem has completely shifted to async. There are almost no active / popular libraries related to network IO that haven't switched over. To be clear: using async is fine if you know what you are doing, and it can provide incredible performance. But if you do, keep it simple: avoid lifetimes and most importantly: don't attempt advanced trait shenanigans - if you do need traits, just returned BoxFutures without lifetimes, throw in lots of clone(), share as little data as possible, use Arc<tokio::sync::Mutex<_>>, and call it a day.
  • Animats 4y ago
    > If you can avoid async I would recommend doing so. The problem is that the entire ecosystem has completely shifted to async. There are almost no active / popular libraries related to network IO that haven't switched over. Yes. I've been complaining about async contamination for some time. I'm writing heavily threaded code, with threads running at different priorities, and libraries which want async get in the way. If you look at the poster's example, the "Arc" version is very close to the Go version. And if it didn't use "async", it would be even closer. Go's green threads simplify things. It's real concurrency; you can block. But there are times when you have to lock. As I've said before, if you're writing webcrap, use Go. The libraries for web-related stuff are stable and well-exercised, since Google uses them internally.
    • cmrdporcupine 4y ago
• adultSwim 4y ago
  For applications programming, I'm excited about Flix, https://flix.dev https://flix.dev
  • melony 4y ago
    Looks like Scala with Rust syntax sprinkled on top.
• _hcuq 4y ago
  Shoulda written it in C maybe.
  • deleted 4y ago
    [deleted]
• Patrol8394 4y ago
  I am fluent in C/C++, Java, Scala. I really wanted to like Rust, but it is hard. The borrow checker is hard and the language api is not intuitive and/or ergonomic.
  • crabbygrabby 4y ago
    In my opinion, easy rust is easy, hard rust is hard. A lot of people take for granted how hard some things are to do correctly until they are asked to do them correctly. Not saying this to put you down, we all struggle with this until we get over the hump. My best advice for loving errr learning rust is put it aside for a few weeks after being annoyed with it. Survey some other language like idk Haskell, then try it again.
    • estebank 4y ago
      If I am allowed to quote myself[1]: > I have the unsubstantiated theory that experienced developers have a harder time than less experienced developers when learning Rust. You need to forget a lot of constructs that work well enough in the languages you already know because they introduce things that go against the single owner enforcement that Rust has, whereas somebody with less experience will simultaneously accept restrictions as "just the way it is" and not seek out more performant constructs that can be much harder to understand or implement. > Rust has a curse (it has many, but this one is critical): inefficient code is generally visible. Experienced developers hate to notice that their code is inefficient. They will recoil at seeing Arc<RefCell<T>>, but won't bat an eye at using Python. I know because I have the same instinct! This makes it much harder to learn Rust for experienced developers because they start with the "simple Rust code that will work but is slightly inefficient" and in an effort to improve it they land squarely in parts of the language they haven't yet developed a mental model for. TL;DR: Keep Calm and Call .clone() [1]: https://youtu.be/Z6X7Ada0ugE?t=705 https://youtu.be/Z6X7Ada0ugE?t=705
• armchairhacker 4y ago
  I personally believe that Rust is an exceptional language and it’s ahead of its time. Seriously, can you think of any other language with as incredible type system, incredible tooling, incredible performance, incredible package management and general package quality, incredible compilation target support, and practically no few backwards-compatibility quirks? But Rust is a really bad general-purpose language. Because Rust isn’t a general-purpose language. It’s designed for high-performance, low-memory, safe computing. The only reason it’s even remotely considered “general-purpose” is because of how great it is. Unless you actually need to write something that’s high-performance, low-memory, or safe (or there’s a really important package in Rust that you can’t find anywhere else), stick to something like Swift or Kotlin or Java or TypeScript. Or even JavaScript or Python or Lua if you’re only writing small scripts. - Rust abstracts almost nothing about the OS. In order to understand Rust, you need to understand at a low-level how computers actually work and how languages compile. You need to understand the what, why, and how of threads, the stack / heap, I/O, endianness, etc.; and language features dynamic dispatch, references, async runtime, memory management etc.. These language features are all implemented in Rust, but they’re explicit, you have to think about them and choose your implementation. People say that Rust is hard because of the borrow checker but there’s much more than that: dyn Traits (you have to understand when a trait can and cannot be dyn), Unsized types (and why there are so many type parameters, because everything must be sized), closure traits, multi-threaded communication, what async actually does, etc. Heck, we almost got you to manually choose allocation schemes (they’re default type parameters, which is weird because Rust doesn’t have many implicit defaults). You often face decisions like - should this trait be a static / type parameter, or dynamic / Box<dyn Trait>? - Is this value borrowed or owned or Cow? - Should this be a unique reference / Box or a shared reference / Rc or a shared-across-threads Arc or not a reference at all? - How do we control this value and communicate across threads, do we make the whole thing thread-safe or message passing or provide a shared Mutex/AtomicBool? - How do we manage async, do we set up an async runtime ourselves (and if so how do we configure this runtime), or how do we add integration with existing async runtimes? - Should this be a Cell / RefCell because we don’t want to or can’t pass a single mutable reference around? And when / how do we dereference the RefCell as to ensure it doesn’t get accessed anywhere else until the dereference is dropped? - Can we do this safely, aka encode it in a way the compiler understands? And if not, how do we a) do it correctly unsafe and b) make the unsafe code as short as possible? - And this explicitness is part of what makes Rust so amazing, because other languages make these decisions for you. But every decision has costs, and either they a) incur higher overhead, or b) lose safety guarantees. e.g. in JavaScript everything is on one thread, so no data-races but no true parallelism; everything is garbage collected, so no use-after-free or double-free but you get GC spikes; everything is a dynamic boxed reference and types are checked at runtime, so no passing complex types and type parameters everywhere, but calls are much slower and there is no true type-safety. Or in C++, there are multiple threads with shared memory but you must explicitly avoid data-races; there is no GC overhead but you must explicitly manage allocs/frees; you can choose whether to pass/store things as references or values and there’s a type system, but values can be assigned / casted to the wrong types leading to memory corruption. Rust is the only mainstream language where you can do unsafe-but-efficient stuff, but it’s actually safe because it’s checked at compile-time. - But this explicitness also makes Rust a bad general-purpose language. e.g. If you want, you can pretty much make everything in Rust like this. #[tokio::main] for the implicit async runtime, everything Gc<RefCell<T>> for no borrowing concerns, dyn Any with upcasting / down casting, etc. This is mainly at the cost of a ton of extra syntax. And of course you get higher overhead and lose compile-time guarantees, which are now checked at runtime. Or better yet, what you should actually do, is write your code which doesn’t need high performance, low memory, or security guarantees in another language. And possibly interface it to Rust code with FFI. Because Rust isn’t a general purpose language. It tries to be general-purpose, and is to an extent, but it’s ultimately built for niche performance and reliability guarantees, and you just can’t have those without user overhead.
• mynameisash 4y ago
  I started picking up Rust a bit over two years ago, and it was HARD. I didn't have teammates who knew it to help me out, so I used community resources (/r/rust, exercism.io, etc.) I'm still not great with the language, but I'd say I'm about as proficient in it as anything else. The progress is slow enough that you find many more opportunities to quit, but once you do become productive, I think the hard work really pays off. I've written before about some of my woes in taking a service to prod with mostly Python code. It was easy to write and get running, but then it had all sorts of errors that were basically impossible to detect until runtime. Kind of a nightmare to maintain. Transitioning it to Rust was a lot of work, but I've literally only had one error that I had to fix, which was caused by my faulty assumption about incoming data that I simply `.unwrap()`ped. I initially was interested in Rust for the promises of higher-performance, lower memory footprint compute, and that is a great aspect of it. But the correctness guarantees that I've experienced make all the hard work I went through absolutely worth it. Sure, it would be great if the learning curve was less steep. But that doesn't mean the hard work isn't worth it.
  • eternalban 4y ago
    Rust and Python sit at almost extreme opposite ends of programming paradigms. The question on the table remains if the excessive complexity of the Rust language is factually worth the pain.
    • crabbygrabby 4y ago
      If you need performance, compiled binaries, etc then yea it sure can be worth it. In some cases you don't have a product if you can't get the performance to reach a certain level. In other cases you spend a lot more money tracking bugs in production that rust just doesn't allow to happen in the first place. Every project has different priorities, some projects don't need rust at all, some greatly benefit from it. The complexity is worth it for me, even for hobby projects, mostly because after a few weeks of toiling with it, I learned it wasn't that complicated, and what it gives me in price of mind way surpasses that.
      • 4y ago
• koyote 4y ago
  As someone that has only dabbled in Rust, the post reminds me of C++ and its mind-boggling templating system. Rust even seems to provide you with the multi-page compile errors. Is it really as bad, or does the post only highlight the misery you get when you're working on the fringes of what the language is capable of doing?
  • crabbygrabby 4y ago
    It's actually really fun once you get the hang of it and realize the compiler is there to help you ship code that runs! This person hit a rough spot and got very frustrated basically... It happens, it's part of learning. The hardest thing about rust is, it tells you straight up when you don't understand something you are trying to do. For people who are otherwise productive and think they know certain things, this can be an ego slap. In return it makes you a better programmer because you learned something, it's just a bitter pill sometimes. In my opinion this person should have gone to rust discord/discourse, and asked for help. A lot of this would have been explained. Some of what they dealt with are rough edges that require practice to overcome though. But yea, lots of people are happily shipping async code in rust, right now. It's very possible.
    • fulafel 4y ago
      Though most people don't get the hang of it. Some people also get into C++ templates and build complicated things with them for fun (eg the whole subfield of template metaprogramming came from inventing a clever abuse of the accidental power of templates as a poor man's macro system)
  • estebank 4y ago
    > Rust even seems to provide you with the multi-page compile errors. rustc strives to provide you as much relevant context as possible. When hitting very verbose output, it is a hint that what you're trying to do is difficult and will require considered design that the compiler can't help you with. The compiler is trying to help you clarify your code so that it can understand it. Looking at the diagnostics shown in the blogpost, I see only one that is indeed terrible[1], but those in particularly are getting less and less verbose as we tackle them one by one with more targeted diagnostics. I also see the lifetime errors (the closure one when you specify the argument type and the on "`Execute` impl is not general enough"), which I wish gave more context. As support for HRTBs lands, related errors will stop happening as much and the code will indeed work (or the compiler will be able to tell you what alternative syntax you should be using). And, in a general plea for people writing Rust, when you encounter a subpar diagnostic, file a ticket[2]. [1]: https://hirrolot.github.io/media/rust-is-hard-or-the-misery-of-mainstream-programming/teloxide-error.txt https://hirrolot.github.io/media/rust-is-hard-or-the-misery-... Be aware that this is not exactly what rustc outputs, as some text decoration have been stripped, but that is a lot of text. [2]: https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Aopen+label%3AA-diagnostics https://github.com/rust-lang/rust/issues?q=is%3Aissue+is%3Ao...
• andrewchambers 4y ago
  Do not use async rust when you are learning. It is ok once you are proficient in rust.
  • Hirrolot 4y ago
    Personally I avoided async and macros when I was learning Rust. Perhaps this is an advice I would give to new Rustaceans.
• 999900000999 4y ago
  The syntax is just hard. I tell new programmers to start with either Python or JavaScript. The pay is the same or better, and it's much easier. I've been programing for almost a decade, I still can't understand lower level languages like Rust and C++. Why, if you can design a new language, not make something with the simplicity of Python ? If your going to compile the binary anyway, have the complier figure out the types and optimize. This is why JavaScript is eating the world. We don't need legions of hardcore software engineers. We need people who use a bit of Python, JavaScript, etc, to make their jobs easier. The future of programing is easier higher level languages. Rust has some applications, but it's too hard for most
  • mikebenfield 4y ago
    Python can be simple, to the degree it is simple, because it makes so many of your decisions for you. In Rust the design space is very large. For instance, if your new type is going to refer to some data, should it own the data, should the data be on the heap (in a box), should it carry a safe reference (if so, mutable or not?), should the data be reference counted, or possibly atomic reference counted, or maybe for some reason you need to keep an unsafe raw pointer to the data? In Python this is simple because the decision is already made for you: your new type keeps (essentially) a reference counted ref to the data it needs. That’s it. That’s all you can do. That’s great if that decision is always adequate for your application. If you need extra flexibility you’ve got a problem.
  • HKH2 4y ago
    > If you're going to compile the binary anyway, have the compiler figure out the types and optimize. Rust does have type inference. I normally only use types explicitly when I'm collecting from an iterator, or when I want simpler error messages. > We need people who use a bit of Python, JavaScript, etc, to make their jobs easier. I am not a programmer, but I use a bit of Rust to make my job easier. > Rust has some applications, but it's too hard for most Debugging scripts is usually harder than debugging Rust, in my experience. Being explicit about things has a lot of benefits in the long run.
• throwaway23342 4y ago
  Async rust isn't pretty. If you are using async rust, and want to borrow data, use an Arc<T>. In fact, if you ever use tokio::spawn, you will have to use Arc<T> anyway because it requires 'static lifetime.
  • Hirrolot 4y ago
    True about 'static. Sometimes I think I need an IDE shortcut for `Send + Sync + 'static`. Like `if err != nil`, you know :))
    • estebank 4y ago
      The trait_alias[1] nightly feature might be what you want :) It was dormant for a long time, but it seems like it might be getting some love towards stabilization (or outright removal, I guess) at some point in the medium future. [1]: https://doc.rust-lang.org/beta/unstable-book/language-features/trait-alias.html https://doc.rust-lang.org/beta/unstable-book/language-featur...
  • pkolaczk 4y ago
    You can also use Box::leak to obtain 'static references to stuff that lives till the end of the program.
• cmrdporcupine 4y ago
  I've been doing a lot of Rust the last two weeks. Like others have said, if you stay away from async, it's not that bad. But I also have plenty of experience in OCaml and Standard ML and Scala, and also C++. Still, I'm finding my C++ experience is more hindrance than help most times. Async & Tokio is pure hell if you have any kind of shared mutable state. And also it's tough to fight 20-30 years of programming experience with modeling things in an object-oriented fashion; I find tying state & method into structs and using 'self' on methods in OO fashion just makes things far worse when async is involved. The thing that really bugs me about Rust and I think it's the core of what really confuses many people is that it upends our normal intuitions about scoping. In other languages we're used to thinking of the scope of things in terms of lexical scope at the block/function/module/class level, and inside that scope, anything is game. You can almost visually see it. Usually. Rust can work this way, but mostly doesn't by default. It's like you were programming in C++ but instead of normal copies and references, almost every single variable use was a std::move. Profoundly unintuitive. I just used this variable, why can't I use it again?! I think many of the things in the language -- lifetimes and borrows especially -- should have been modeled with a more explicit syntax instead of hiding inside existing standard language features (type parameterizations and assignment)
  • Hirrolot 4y ago
    > Rust can work this way, but mostly doesn't by default. It's like you were programming in C++ but instead of normal copies and references, almost every single variable use was a std::move. Profoundly unintuitive. I just used this variable, why can't I use it again?! You just need to get used to it, really. As you've noted, it's about our habits. The ownership model makes perfect sense after some experience in Rust, unlike that stuff with asynchronous programming.
  • voidhorse 4y ago
    couldn’t agree more. I’ve been thinking a bit about rust recently and why it’s hard to write when starting out, and I think needlessly verbose syntax is about 10% of the problem and not enough syntax around borrowing/the memory model is 90% of the problem. In other words, Rust syntax is minimalist in all the wrong places. A lot of borrow checking related stuff in rust forces you (until you internalize how it works) into a check/compile-fix loop that is horribly inefficient and tedious. if performing moves had special syntax it’d be palpably obvious to even new rust programmers that a move is happening and that assignment does not work as it does in about 99% of other programming languages (in most cases). also important things that then invert or alter this behavior should also have special syntax. for example, I’m still not sure how any client code is supposed to know that some library type implements Copy (which complicates things further by inverting rusts inversion of typical semantics). seems like the only way is “try it and see” or read the docs. I guess the idea is that you shouldn’t necessarily need to know this, but I do think rust would have benefited from making borrow and memory handling more transparent and obvious with special syntax around it (beyond lifetimes, at point of use, not just in signatures). As it stands it seems to want to give users the control that comes with manual memory management with the sort of “hiding away” of details that GCs traditionally afford
• nemothekid 4y ago
  I've been doing async Rust since the tokio 0.x combinator days, and I remember being like OP. For some reason `Arc` did not exist in my mind and it was a struggle appeasing the borrow checker. The Go version is similar to the final Rust version; except the Go version is forcing you to use Arc everyone[1]. Seriously, just use Arc (or Arc<Mutex<>>), in 70% of cases you are wrestling with the borrow checker trying to do something dangerous, in the other 30% the borrow checker is wrong and isn't smart enough to understand what you are trying to do. In both cases, 95% of the time, you aren't creating enough objects per second to justify getting rid of that atomic add. I'm not even sure this is limited to async code either. I've seen plenty of code by C++ "zero cost" gods which abuse lifetimes in order to avoid a single clone or Arc. At least the compiler made sure you won't segfault, but I'm not sure the complexity is worth it over just an Arc. [1] I know this this is a simplification.
  • Hirrolot 4y ago
    I do completely agree with your advice of using `Arc`s. But unfortunately, sometimes it gets very tedious to deal with all these `Arc`s: https://github.com/teloxide/teloxide/blob/ec1d41220c51872cf96e597072c63cdfe77c3521/src/dispatching/dispatcher.rs#L418 https://github.com/teloxide/teloxide/blob/ec1d41220c51872cf9.... It also blurs the advantage of Rust as a lifetime validation tool if you use reference counting anyways. But it seems that it's the only viable approach for async at the moment.
    • nemothekid 4y ago
      I have plenty of code like that: let id2 = id.clone(); let watch_id2 = watch_id.clone(); let id3 = id.clone(); let watch_id3 = watch_id.clone(); let ready2 = Arc::downgrade(&ready); let video_stream = async move { // use id2, watch_id2, id3, watch_id3, ready2 } My realization is that in most cases an Arc is the right tool for the job, especially in concurrent applications. I see it as the borrow checker doing it's job, if you have two threads that need to share data and one of them may go away at any moment, the only way you can ensure the memory stays around is with "runtime borrow checking", e.g. a garbage collector. In C++, the way this is solved is usually "just trust me, I won't use this memory here"
• mhh__ 4y ago
  If you want a better C++ that lets the compiler do work for you rather than you working for it try D.
• beltsazar 4y ago
  While I can see why zero-cost abstractions are important in Rust, I was wondering how much simpler Rust async could have been if zero-cost had not been a hard requirement. The way I see it, Rust async is most useful for IO-bound applications, which can afford some non-zero abstraction CPU cost.
  • estebank 4y ago
    If zero-cost wasn't an aim then it would indeed be much easier. For example, async fn in traits isn't (yet) in the language. The type system level changes to make them possible is being actively worked on (it is high priority!), but if we didn't care about "you can't write more efficient code by hand", then we would have provided that feature with the semantics of the async-trait crate[1], which provides a macro that turns `async fn foo() -> i32 { 42 }` into `fn foo() -> BoxFuture<Output = i32> { Box::new(async { 42 }) }`. Going down that route would have "silenced" that criticism, at the cost of locking us to subpar behavior at least until the next edition. The approach of waiting until things are baked well enough to land in stable is frustrating as a user today, but I believe has a better chance of standing up to scrutiny long term. In the meantime, the community is able to "plug" those failings, at the cost of worse dev UX due to not being builtin. [1]: https://crates.io/crates/async-trait https://crates.io/crates/async-trait
• LoveGracePeace 4y ago
  I'm very confused. Rust is mainstream? C, C++, Java, C#, Python, JavaScript are all what I would call mainstream. Rust is not a language that comes to mind at all.
  • broodbucket 4y ago
    Rust has hit the point where it's in the conversation for what language you'd write a new project in, even for big companies (typically the most lethargic). I'd say it's at the level of mainstream where there's Rust being written in a significant portion of the industry, but not at the level of mainstream where it's somewhere in the stack behind most of organised society
  • mikebenfield 4y ago
    Pretty damn mainstream nowadays, yes. Quite a few big tech companies are either actively doing much of their new systems programming in Rust, or else dipping their toes in. I honestly don't know of a big tech company that is happy with the idea of just continuing to use C++ indefinitely - they are _all_ looking for alternatives, and Rust is the most obvious option.
    • adastra22 4y ago
      > I honestly don't know of a big tech company that is happy with the idea of just continuing to use C++ indefinitely Every game company ever. And Google.
      • mikebenfield 4y ago
        This is not accurate.
      • Morgawr 4y ago
        The Google team I work on (ChromeOS, crosvm[0] specifically) has been transitioning to Rust for a lot of our new services (mostly crosvm and stuff that interacts with it) and I couldn't be happier :) [0] https://google.github.io/crosvm/ https://google.github.io/crosvm/
• ankurdhama 4y ago
  The article mentions: > It compiles fine now but the final API is defected: ideally, we do not want a user to wrap each handler with Box::pin. Why not, whats the problem (apart from some sort of philosophical idea of "beautiful api")?
• tmcw 4y ago
  The author is 17 and writing code (and posts) at this level? The kids are all right.
  • Gigachad 4y ago
    Some people are just so ahead of the average. I thought I was pretty good knowing the basics of Rails/Databases at that age, but I was no where near the level of writing coherent posts on languages.
  • lr1970 4y ago
    > The author is 17 and writing code (and posts) at this level? The kids are all right. He is a talented kid from Kazakhstan. So nice to see this here after all that Borat nonsense badmouthing Kazakhstan just for cheap gigs.
• encoderer 4y ago
  This is not a critique of rust but my experience is that I needed to build something that was distributed cross platform as a statically linked binary. So, I narrowed my choices to Golang and Rust. I wanted to learn rust and was only so/so on golang and really tried. I knew this project would go slower because I’d be picking up a new language but as I was still being brain hurt by rust I peeked at go and it can get a little convoluted but overall it’s a readable language where I felt like I could start writing decent code within days. Since it was mostly about building something for users and not just my own learning I had to go with go. Not sure if I will ever learn rust but it would have to be for a hobby project or solve a problem for me that is fundamental to the desired outcome that go, python etc could not.
• DeathArrow 4y ago
  >So why Rust is so hard? Rust is a systems language. To be a systems PL, it is very important not to hide underlying computer memory management from a programmer. For this reason, Rust pushes programmers to expose many details that would be otherwise hidden in more high-level languages. Examples: pointers, references and associated stuff, memory allocators, different string types, different Fn traits, std::pin, et cetera. Rust is a static language. This is better explained in my previous essay “Why Static Languages Suffer From Complexity”. To restate, languages with static type systems (or equivalent functionality) tend to duplicate their features on their static and dynamic levels, thereby introducing statics-dynamics biformity. Transforming a static abstraction into its dynamic counterpart is called upcasting; the inverse process is called downcasting. Inside push_handler, we have used upcasting to turn a static handler into the dynamic Handler type to be pushed to the final vector. C and C++ are both systems languages and static typed languages (I don't know of any systems language which is dynamic typed) and don't feel to me so hard. C# has "pointers, references and associated stuff, memory allocators, different string types" as features but it is at the same time a higher level language and you make use of those features only when you need to deal with low level stuff, no pain implied. So, to me, these reasons don't quite explain why "Rust is hard".
  • mikebenfield 4y ago
    To me C++ is much, _much_ harder than Rust. Maybe in C++ it's easier to get a program to compile, but it's dramatically harder to make sure you've checked all the boxes you're supposed to check to make sure your code is safe and complies with best practices. For instance, consider the rules of 5 [1]. There are so many rules like this in C++, so much complicated stuff you're supposed to know to write anything at all, and much of this is just _accidental_ complexity: it's just there for historical reasons or language design reasons that in retrospect don't make much sense. [1]: https://stackoverflow.com/questions/65455464/is-the-rule-of-5-for-constructors-and-destructors-outdated https://stackoverflow.com/questions/65455464/is-the-rule-of-...
    • ncmncm 4y ago
      Rule of 5 was a C++11 thing, maybe even mainly a C++03 thing. Your complaints about C++ have aged badly. C++20 is not the same language as C++11, which was not the same language as C++03. Rust's complexity is rapidly approaching C++'s. In 5 years, if Rust hasn't fizzled, it will get there. Only being used to it will make it seem any simpler.
• DeathArrow 4y ago
  Performance, safety, ease of use. You can only pick two. I like the strategy that Nim employs. Due to multiple ways of memory management strategy you can use (different types of garbage collectors, reference counting, manual memory management or no memory management), you can have different combinations of performance, safety and ease of use - so it can fit nicely what you are trying to accomplish.
• ThePhysicist 4y ago
  Just got started with Rust and yeah, my biggest pain point so far were lifetimes and async code. I finally replaced tokio with multithreaded blocking code, which seems to be much simpler and more familiar. The problem with async was that some of the libraries I needed (e.g. for QUIC) didn't support it, so you had an unholy mixture of blocking and non-blocking code. Coming from a C++ background I appreciate Rust's novel approach of borrow checking, though I'm not sure if it's more "elegant" than C++'s approach with unique pointers, move constructors etc.. What I love is the modern ecosystem and build tooling around the language (including documentation and package management), for me that's Rust's main advantage over C++.
  • mikojan 4y ago
    I've successfully replaced tokio with the lower-level mio in one such case. After all threads and async serve different purposes: Threads when you're computing a lot, async when you're waiting a lot, no?
    • deleted 4y ago
      [deleted]
    • lumost 4y ago
      Threads work OK for concurrency in many apps. The developer cost of async may not be worth it in many cases.
      • ibraheemdev 4y ago
        I would say that threads work _very well_ for concurrency in _most_ apps. Thread context switches have gotten much much cheaper over the years, and the idea that threads are heavyweight is very outdated.
        • lumost 4y ago
          True, java apps have comfortably run 10s of thousands of threads without issue historically. Coroutines are nice as they allow trivially writing an app which scales to millions of concurrent operations. Rust is nice as it lets us write code for every occasion, async is awful as it poisons the entire ecosystem. The same result could have been achieved with a few tactically inserted yield statements for I/O and locking which are pretty much the only times that async or coroutines help.
• cute_boi 4y ago
  I am too hardcore fan of Rust, but whenever I see incomplete features like GAT / HRTB/ No async function in trait / too much boilerplate code even if its unnecessary it make me annoyed. However, when I look on other side of the aisle, I think Rust is still good PL.
• viktorcode 4y ago
  I never got the point of having borrow checker in a single-threaded environment. Can someplace please explain its usefulness to me in that scenario?
  • nickez 4y ago
    You avoid use after free for example
  • TheDong 4y ago
    Let me show you a bug in Go which involves no threads/goroutines, but would be solved by the borrow checker: https://go.dev/play/p/sEptCgMM0Bh https://go.dev/play/p/sEptCgMM0Bh In rust, you could not write that code without using either unsafe, or getting borrow checker errors.
  • Twisol 4y ago
    The borrow checker statically prevents having mutation and aliasing at the same time. Aliasing is when two names refer to the same state; mutable aliases make it possible for "someone else" to act on that state while you're using it. Consider the humble for-each loop: for (let x : xs) { xs.remove(0); } If you're not careful, modifying a collection while you're traversing it can cause you to visit elements multiple times, or skip some elements entirely. There are effectively two tasks occurring at the same time -- interleaved, not parallel, but still concurrent: the ordered traversal and the action on each element. Both tasks can view the list, but one of them also modifies it behind the other's back. This problem simply can't happen in Rust (without going out of your way, at least), because you can't independently mutate a list you're already iterating over.
• ncmncm 4y ago
  A language is starting to approach maturity when articles complaining about it or explaining how to work around its fundamental flaws come to exceed articles bragging about having got something, anything, working in it. Rust might yet get there.
  • fnands 4y ago
    As the adage goes: "There are only two kinds of languages: the ones people complain about and the ones nobody uses".
• HacklesRaised 4y ago
  Is rusts most loved status simply Stockholm syndrome? I've really tried with rust, and we simply don't get on. I hear all the arguments about CVEs and wonder if rust will reduce the number of these problems simply by disabling the programmers that create them. I understand the draw, I want to love it, but i think I might not be smart enough.
  • baby 4y ago
    I’d say no. Been doing Rust for 3 years now and I have decided that I will never again accept a job offer that makes me write C++ or Java.
  • timClicks 4y ago
    No, it really is wonderful once you make it. Which resources have you used to learn?
    • marcusramberg 4y ago
      Sounds like survivor bias :)
    • HacklesRaised 4y ago
      I did ok with Rustlings and I read the 'The Book', I'd say I am largely struggling with async and lifetimes. I have spent most of my career in C, C++, Objective-C and have recently tried Zig, which I enjoyed, possibly because of it's brevity, and I read through the Jakt programming language docs, which was much more familiar to me but I think if you only used Rust with ARC it would be a simple language to adopt so that's not really a fair comparison. I think what I really need is a project rather than learning resources, with time being our greatest enemy, I need motivation to get over the hump so to speak. (Like I said, I might not be smart enough, or I might just be profoundly lazy). Thanks for your reply.
      • wiz21c 4y ago
        I've been leraning rust with a pet project of mine (an Apple2 emulator). That was a bit too complex for a start as I had threads and a bit of architecture to structure my code correctly. But in the end, I know understand how rust does threads and memory allocation and I'm now much less intimated by the type system. I still don't get the lifetimes. Moreover, a lot of the libraries in rust needs you to understand the type system thoroughly sometimes to use them, and some of them use the typesystem to enforce some specific behavior (without telling you :-)). For example, the logger mechanism in rust makes it very hard to dynamically change the logger implementation at run time but it doesn't explain why (in the end, I think it has to do with thread safety, but I'm not sure). It took me about the equivalent of 30 full days to get there. Although I'm an experienced programmer (C++,assembly,Java,python,R), the last 15 years have been python 99%. Had I continued with C++ all those years, I'm sure I'd understand rust much better. So, just keep going and really listen to the borrow checker. The thing is really smart and sometimes, after a lot of pain, you understand that your own mental model was wrong :-)
• lenkite 4y ago
  Compare the Rust Handler-Dispatcher program with the Go Handler-Dispatcher program and look at the truly extraordinary complexity that Rust adds to what is effectively a simple design problem that any of us have implemented several times, if your career has had a few years of original coding. Handler-Dispatcher is not some complicated design pattern. It is very basic. Its implementation in any language should be short and elegant. This is NOT something you should be losing sleep over. Rust, unfortunately, is even MORE complicated than C++ in language complexity today. Good tooling does not eliminate the burden of extraordinary complexity that Rust wants to enforce on its adopters.
  • hazz99 4y ago
    I don’t think it’s true that any given “basic” design pattern should should necessarily be simple in every language. Certain things are short and elegant in Rust. Certain things are short and elegant in Python. Each optimises for different things. I also don’t believe it places “extraordinary complexity” on the shoulders of the programmer; this complexity is often a sign you’re doing something wrong, or working against the grain of what Rust is optimised for.
    • lenkite 4y ago
      Ok, what is wrong about the Rust solution given by the author of this article ? What is he doing wrong ?
      • hazz99 4y ago
        They’re not doing anything wrong, but working with generics, traits and async code is very much against the grain of the 2018/2021 editions of Rust. The async story hasn’t finished, and is definitely the area that needs most improvement in terms of developer experience. There are a number of gated features and RFCs that propose solutions to these problems (e.g. GATs), but they haven’t been moved into the core language yet. That doesn’t mean Rust is inherently bad or difficult, only that we’re working with an early version. Rust is young! We didn’t have futures until 2019, iirc. Lots of core Rust concepts (lifetimes, ownership, references) need to be rethought for how they fit into asynchronous programming, and how to make everything compose well together.
• bricss 4y ago
  Thx Rust, but I'll go with Zig lang.
• roxaaaane 4y ago
  Author makes a claim that Rust is hard because it's a systems language, i'd like to claim that Rust is hard because it hides the systems part of systems programming. Systems Programming is just UNUX/POSIX/WIN32 Programming it's writing software that interacts with the OS, Rust hides much of this in language abstraction (for good reason) but the trade-off is that using the language becomes complicated.
  • Santosh83 4y ago
    Don't all languages hide OS API under their own libraries and abstractions? How is Rust special in this? IMO Rust is hard because it (the borrow checker) forces you to keep track of data and state manually. If you were aiming for practically bugless C/C++ I believe you'd have expend pretty much the same effort, but Rust forces you to do it, while C/C++ leave it up to you.
• iovrthoughtthis 4y ago
  feel the authors pain everytime i sit down to give rust a try i get catapulted down some esoteric rabbit hole about conceptual abstraction over computer memory that rust invented for my safety that isn't fully fleshed out conceptually or in implementation all my rust programs are provably safe though, because i never finish them and no one ever uses them
• wodenokoto 4y ago
  I've only written php, Python and R to any large-ish extend and way back in the day i was introduced to programming using Delphi. I have absolutely no idea about what is going on in that article. Is Rust just completely different from everything else, or have I been completely shielded from "actual programming"?
  • baq 4y ago
    1. garbage collection is amazing for developer productivity if you can afford it. 2. if you don't know if you can afford it, you can.
    • pkolaczk 4y ago
      > 1. garbage collection is amazing for developer productivity if you can afford it. Probably not for everybody. I haven't noticed any significant productivity boost when coming from C++ to Java years back, and then I also can't see any significant productivity decrease when switching from Java to Rust. I feel the unavailability of GC is widely offset by other features that make Rust more productive than Java. Surely, I got stuck once or twice while learning (Rust is harder than Java) but once it clicked, I know which things to avoid and generally it goes very smoothly. Now there are many things I love about Rust and I constantly miss in Java. (The number of times I wished I had RAII in Java) > (The number of times I wished I had tracing GC in Rust).
      • baq 4y ago
        > coming from C++ to Java if you were a competent C++ programmer, yeah, i can absolutely see that; nowadays, most people start with a GC-ed language and get tripped up all the time if things they take for granted aren't there. unsurprisingly.
• jollybean 4y ago
  I believe that the borrow checker is amazing, some other things are nice - but as though it's all kind of an experiment. I'm extremely wary of issues of productivity in Rust - most code does not need to be that perfect and the tradeoff is not rational in so many cases. Rust is the 'C++' of it's era of languages - bizarre, unwieldy. It's an experiment. We are waiting for the 'James Gosling of Rust' to come along, and blow a ton of unnecessary complexity away with the 'Java' iteration of Rust. Then it will be mainstream and uncool :)
• bkolobara 4y ago
  I see a lot of people here saying something like "Just use Arc<Mutex>, it will be plenty fast". As someone who does it all the time, I noticed that code becomes less readable and hard to comprehend that way. Important types stand much less out in function signatures once you have Arc<Mutex<InterestingType>>. Rust is already extremely verbose and adding additional layers to types doesn't help. Not even to mention that now every time you want to access the value you need to do dance with calling .lock().
  • pkolaczk 4y ago
    Rust pro tip: use type alias. As for using lock() - you'd have to do it in any language in some way. If you have sharing and mutability, you need some kind of synchronization.
    • nyanpasu64 4y ago
      Only in Rust you need synchronization when accessing an object from multiple places on the same thread.
      • steveklabnik 4y ago
        You don’t need full synchronization if you’re not going cross threads. RefCell and the like don’t use atomic operations or barriers or anything fancy like that.
• eashish93 4y ago
  Still, I think rust need another 3-4 years to be beginner friendly.
• gary17the 4y ago
  While the article is an absolutely excellent analysis of Rust from the low, PL-level ergonomics point of view, it seems to largely miss (or, intentionally, skip) the bird's eye point of view of complexity inherent to software development. I was recently tasked with developing a fragment of a mobile app written in Objective-C++ (an awesome PL powerhorse, BTW) that mixed multi-threaded (multiple dynamic UI layers, multiple levels of background processing) and async (multiple over-the-network downloads, multiple database updates, etc.) To make a long story short: even though I've been coding C++ for 20 years, I am still a bit depressed about how badly I got my own @$$ handed to me on my first try. It took a ton of bug hunting and code refactoring to get everything right. Being forced by Rust to throw together a couple of somewhat inelegant reference counted pointers is... trivial compared to the benefits Rust offers (safety). I was also recently tasked with investigating serverless. To make a long story short: due to the fact that serverless is billed by the amount of memory used and the CPU time required to execute a lambda, so far in my analysis Rust is coming out on top over interpreted and garbage-collected languages to such extent that it actually makes the difference not just between a "good" and "very good" solution, but between an "impossible" and "feasible" one, cost-wise. Being forced by Rust to read a couple of books on how the new concepts of ownership and lifetimes work is... trivial compared to the benefits Rust offers (efficiency). If you define "feasibility of a commercial success" as "finding a pain point and being the only solution for it on the market", then it becomes more and more likely that, with time, Rust will win over many other PLs.
  • pnt12 4y ago
    I liked your thoughts but disagree with the conclusion. It seems that serverless is cost prohibitive in many scenarios, and requires lots of optimization to be cost effective. So isn't it more of a fault of serverless than a strength of rust?
    • gary17the 4y ago
      I see your point, but it all depends on whether the choice of a particular organizational infrastructure architecture is a priority for you or not. If infrastructure is a priority, (e.g., "we don't really want to hire anyone just to setup/monitor/secure that Linux box with all those REST API server/database processes, thus we prefer serverless), serverless is important and Rust performance is its strength. If infrastructure is not a priority, (e.g., "I was gonna roll out my own VPS anyway, I love this stuff"), serverless is all about its faults and Rust is irrelevant (it is logical to choose an easier PL, e.g., the excellent Golang).
• iex_xei 4y ago
  Another data point: After writing / (re)writing 20K+ lines of code as a CLI side project in Rust (without touching async), I think I can say it's the best language for me after 20+ years of experience in other languages. I like the compiler, and I learn a lot from clippy. The "hard" part about Rust is you have to "unlearn" some of the basic mechanisms like scope and ownership that you bring from other languages. It doesn't allow you to build quick and easy solutions that allows you to lie to yourself (or your boss.) You have to spend more time upfront to compile and fix all warnings, but in my experience so far, fixing these at the right time (i.e. before compilation) is better than fixing them after someone writes a Github issue. I can't say it eliminates all bugs, but my trust level to my Rust code is around 10x more than my Python code for the same problem. (And I'm writing Python since 2002.)
  • m25n 4y ago
    I have found that as I gain experience with rust, I spend less and less time “upfront to compile and fix all warnings”. I think rust requires a different design philosophy. It just takes time to adopt it into your mind.
    • iex_xei 4y ago
      That's true for me as well, but I learned these after many failures. Now, I start by writing enums and structs for the problem, then iterate the design with functions and if it's really needed add these functions as impl of a certain struct/enum. This is the inverse of "Object-Oriented" design where one has to start from interfaces and manipulate data to satisfy the interfaces.
      • wvh 4y ago
        Sounds like Go. Just write code, then see if any obvious interfaces pop up and if you need them.
        • iex_xei 4y ago
          I wrote servers in Go as well, and I like the language. After Rust, I believe at some point, I enjoy to solve the "problems" Rust brings, not that it's rationally better than Go.
• esjeon 4y ago
  Out-of-topic, but it's funny how some pro-Rust comments actually read like pro-Haskell comments. Haskell has more extensive and thorough typing than Rust, so anything good about `trait` is even better in Haskell. You just have to "unlearn" more to get used to pure functional programming.
• xolve 4y ago
  I find rust and scala quite similar on learning curves. You have to reach a certain level before you can work with the language and library ecosystem. The benefits proposed by proponents of both languages are there but after the mean of the bell curve. Also a beginner is asked to work with external interfaces and libraries because the language and its standard library is defined to be minimal in certain ways. The answers to which are supposed to come later. So a lot to take it on the first step itself. Both languages are still working on some answers and kept options open. So "why" of that is also complicated.
• eternityforest 4y ago
  I really do not like the minimal stdlib idea, but as far as the language itself, I don't see the problem. Have people never experienced "Lots of pain" debugging? All those hoops modern languages make you do are just the same things you'd have to do yourself. Instead of having to use some language construct to do whatever it is, you do it the simple and obvious way... but all reasoning to prove safety is on you. Instead of "Learn these 50 features", which is hard but not impossible, you have to "Lol IDK git gud and don't do bugs", which is not only hard, but it's all on you to even figure out if you did it right.
• perryizgr8 4y ago
  I think a big factor that makes rust hard is the prevalence of special syntax everywhere. These are special character sequences that could have been expressed another (more verbose) way, that were introduced for dev convenience. It makes the code extremely hard to read for me.
• laerus 4y ago
  The software industry is maturing albeit slowly.
• gwbas1c 4y ago
  I've been toying with Rust on and off for a few years. I find it very difficult to be productive for many of the same reasons that TFA lists. > Finally, imagine that Rust’s issues dissapear, it is high-level, and has uniform feature set. That would presumably be close to the theoretical ideal of a high-level, general-purpose programming language for the masses. Funnily enough, designing such a language might turn out to be a less intimidating task than original Rust, since we can hide all low-level details under an impenetrable shell of a language runtime. Holy smokes yes. Rust introduces some extremely powerful features that other languages seriously need. Matching on an enum (although Rust's also needs a more traditional enum,) is awesome. Rust's error handling, IMO, is a step in the right direction away from exceptions. I even like the fact that I can enforce single ownership of an object; or have methods that take ownership of an object. And, differentiating between mutable versus immutable without needing different types is infinitely valuable. Furthermore: My favorite feature of Rust is that it's 100% compiled with no need for a framework or runtime.
  • capableweb 4y ago
    Minor correction: Rust does need a runtime (normally), it's just very small and embedded in the binary, so it mostly seems nonexistent, but it's there :) More info: https://prev.rust-lang.org/en-US/faq.html#does-rust-have-a-runtime https://prev.rust-lang.org/en-US/faq.html#does-rust-have-a-r... Not to take away from your overall point, which I agree with.
    • gwbas1c 4y ago
      Oh, don't argue semantics. It's not like I have to tell someone to install .Net, Java, Python, ect, in order to run a Rust program. (Or figure out how to bundle it in an installer.) By your logic every language, except for assembly, has a runtime.
      • capableweb 4y ago
        I'm not arguing, just adding some detail to a slightly incorrect fact. It's true that you usually don't have to ask anyone to install anything else to run a Rust program, because the default experience of using Rust + Cargo bundles the runtime for you. But the same can be done with the languages you used as examples as well. Many programs do in-fact include .net, a JVM or a Python runtime so the users don't have to care about it. Biggest example is probably Blender, which ships with Python (and doesn't require a installer). Many IDEs made with Java also ship their own JVM runtimes.
• MrBuddyCasino 4y ago
  2012: we cannot trust programmers to write correct C 2022: we cannot trust programmers to write compilable async Rust
• lumost 4y ago
  One area that I think we'll see some progress on soon is "Ease of use" in Rust. A major change in the last few months for the github trending repositories has been the appearance of full applications built in rust. As more full software products are written we should start to see what works and what doesn't work. IDE support in rust is getting better, but still has a long way to go. What Rust will likely need is a set of libs similar to Guava, and Guice to make coding actually productive. We already see that starting to emerge with the Tokio ecosystem, however it would be helpful to have stronger support outside of the Async community.
• TheDesolate0 4y ago
  Rust isn't hard, it's just more verbose than devs are used to because it forces you to think about lifetimes and types.
• tarator 4y ago
  Excuse my ignorance but my small experience in Rust convinced me that the language actually promotes functional programming (you get bizarre errors when trying golang or c++ style of programming). Registering handlers doesn’t sound functional at all. Quick search about reactive functional streams leads me to interesting solutions. For example tokio::sync::broadcast. I would love to hear your opinion on this.
• muxneo 4y ago
  Rust really has steep learning curve. I have 20 years of C and C++ experience. It did not take me so much time to learn languages like Javascript (especially async javascript) as it is taking for me to understand borrowing and other features of Rust. I initially decided to use Rust for developing a microservice for my video conferencing startup HeyHello.video . I think I am going to stick to Javascript or use Go.
• llllllllllll9 4y ago
  i haven't met one dev whose interested in rust for solving a problem. they just want to rust for its sake. which is ok. whatever. but that tells you something.
  • pdimitar 4y ago
    That only tells me you came to post a troll comment and leave.
    • llllllllllll9 4y ago
      :)
  • steveklabnik 4y ago
    Hi. Rust uniquely solves problems for us, and that’s why we use it.
    • llllllllllll9 4y ago
      awesome.