7 ms·

Rust Absolutely Positively Sucks [video]

30 points by mikece 3y ago

bena 3y ago
Here's the post that the video is about https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_programming_language_absolutely/ https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_prog...
- msh 3y ago
  I dont know rust but the following comment from the reddit thread resonates with me: So you started learning rust by trying to make something multithreaded that also interops with C instead of starting with something simpler so you can learn to understand the borrow checker? That's a recipe for disaster.
  - mikece 3y ago
    The choice of language was forced on the dev. He did a Java version of the app -- ON HIS OWN TIME -- and management nixed it.
    - imtringued 3y ago
      That doesn't excuse his choice of words. >am truly convinced that all the people who claim Rust is great are either lying to themselves or others A Rust novice telling every Rust developer in the world being wrong? There must be some irrefutable wisdom in there somewhere!
    - rob74 3y ago
      Yeah - there's a huge psychological difference between adopting a language out of your own free will and it being forced upon you. I suspect that's where a lot of the current hyperbole about Rust comes from...
  - gizmo 3y ago
    The issue here is that Rust presents itself as a systems language, i.e. a language where the programmer has control over how the system's resources get used. However, Rust has safety mechanisms that will stop you from doing what you want, even when what you want to do is safe and sensible. There is a contradiction here that Rust enthusiasts endlessly make excuses for. Rust is more like Go than C. Both Rust and Go can be used to write high performance services. Both Rust and Go have many modern convenience features. And both languages expect you to write code in a specific idiomatic way, wrt borrow checking and go channels respectively. If you need shared memory and fine-grained locking for performance you're not going to have a good time. And that makes Go and Rust unsuitable for a large chunk of applications.
    - cmrdporcupine 3y ago
      This is simply false. Having written code like what you're talking about... There is always an escape-hatch. Rust just wants to make sure you really know what you're doing before letting you go there. The idea being to provide safety-minded well crafted but performant libraries where the hard thinking about atomics & locking and unsafe-bounded memory shenanigans are confined in well-tested locales. Also don't see why you're comparing with Go. Entirely different bowl of soup. Go is not a systems programming language.
    - goku12 3y ago
      Rust is used for writing entire OS (e.g Redox) or parts of the OS that needs precise management of resources (e.g Linux kernel, Windows). It is used to write parts of web browsers (servo and quantum parts of firefox), game engines and in embedded systems. It's used everywhere that traditionally used C, C++ or Ada. There really isn't a justification to dismiss Rust as a systems programming language. The limitations that you claim are not there. The reasons are there in the other reply to you.
    - mike_hearn 3y ago
      There is unsafe{} if you want to do something not normally allowed. But, well, it's unsafe. I was surprised to learn of a memory management vulnerability in a Rust serialization library the other day (for capn'proto). It was using unsafe. You'd think that serialization is the sort of library where Rust's guarantees are most valuable.
- titzer 3y ago
  Thanks for posting the link. The video is useless, it's just rage-baiting. Stepping back from the emotional overreaction in the OP, this seems to be the relevant bit: > Right off the bat, as a total Rust newbie, I'm hitting all kinds of rough edges in Rust. For example, I'm trying to use rusqlite. It would be natural to stash DB prepared statements in a thread local for reuse in my multi-threaded code. I can't pass the connections around, because I need them in a C call-back (too much detail here I know) so I have to be able to look them up. Alas, after banging my head against the wall for a full day, I'm just giving up on the thread-local approach, because I simply can't get it to work. Part of the problem is that I can't stash a prepared statement in the same (thread local) struct as the connection from which they are created, due to lifetime limitations. It also seems that you can't really use two thread locals (one for the connection and one for the prepared statements) either. If there's a way to do it, I can't figure it out. What I take from this is that the library was designed to work with lifetimes a specific way, and the OP is trying to use them in a way not intended. Rust lifetimes being baked into the language means there is really no way around the design the library authors had in mind. If the library authors made bad choices, you are basically stuck. This is the crux of the matter. A poorly designed library in Rust comes with a straightjacket that you must wear. I've had students hit this kind of things several times. This kind of experience absolutely kills the flow and sucks all the joy out of programming. Poorly-designed lifetimes are non-composable and lead programmers down completely unnecessary, totally unproductive rabbit holes. Making memory management orthogonal APIs is the only way to make them composable.
  - cmrdporcupine 3y ago
    I actually ran into these precise problems with rusqlite and found them equally frustrating, and ended up ripping that code out in the end. The lifetimes model in that library are, IMHO, "wrong".
  - mike_hearn 3y ago
    It seems almost worse - the author of rusqlite replies and says, essentially, that you just cannot do what he wants to do at all, and the "fix" is to either constantly re-prepare statements, or rely on some sort of library built-in cache! The first will lower performance perhaps by a lot, but performance is probably why you're writing Rust in the first place. The second is a nasty hack that will require you to remember this cache exists and keep its size carefully tuned. As all he wants to do is stash prepared statements in TLS, a pretty normal task, it seems like a valid complaint that this is so hard and rustql doesn't seem to allow it. One aspect of Rust I wonder about it is that when reading it I see way more cloning than you'd intuitively expect. Seems like people hit the borrow checker, can't see a way out and just copy the memory to escape. Presumably that will lead to diffuse performance losses all over the app of the sort that can't easily be spotted in a profiler, sort of like pointer chasing in languages without value types. I wonder if C++ will actually end up having an edge in performance due to this. I know there are very heavily tuned benchmarks that show Rust being the fastest but I mean for "real" code of the sort this person is needing to write (done under time pressure).
- Verdex 3y ago
  Thanks for the link. I saw the youtube video advertised to me by the algorithm, but wasn't about to waste my time watching it. After decades of trying to get C-style systems programming right, we're still finding unsafe memory related security issues (ignoring implicit integer casts and UB). Thesis: Maybe c-style systems programming is bad. Rust consumes what we learned from cyclone et al as well as leveraging llvm and while I think we had reason to be cautiously optimistic for a while there, now it honestly seems to be working. But it works because we abandoned what we thought were the bad parts of c-style systems programming. Meanwhile, someone tries to shove c-style programming back into rust and finds it's not actually possible. Then complains. Technically, this is fine. The part that isn't fine is to loudly proclaim that everyone who is able to learn how to use rust correctly must be lairs. [As an aside, there's D, P, jai, rust, odin, zig, carbon, vale, swift, c++11+, and more. A good rule of thumb is that a programming language takes about a decade to really get moving. There's a reason that an absurd amount of time has been dumped into replacing c-style systems programming.]
  - c_crank 3y ago
    Bug free code only exists when it can be formally verified.
    - Verdex 3y ago
      | Bug free code only exists when it can be formally verified. ... okay. Although, on the other hand: | Beware of bugs in the above code; I have only proved it correct, not tried it - Knuth Perhaps bug free code does not exist?
      - c_crank 3y ago
        The replacement languages for C in systems programming aren't memory safe. They can cause segfaults. They have additional tools and syntax rules to make it less likely, but they can and will have memory bugs.
        Verdex 3y ago
linusg789 3y ago
The situation described in the video can and probably does happen to C++ codebases as well, if not even more than Rust. It's easier to be good at Rust than it is to be at C++, even if C++ seems easier at first.
- mikece 3y ago
  From the video it sounds like the largest problem is that the company/manager prescribed Rust as the solution to a problem where Rust might not have been the best fit. The dude wrote a Java version on his own time and despite being on a Java team at that job management insisted it be done in Rust. There might be issues with Rust and the scenario in question but it sounds like conditions at that work place are a bigger problem than the choice of a language.
- pclmulqdq 3y ago
  The specific situation the poster is in is very Rusty. If you are used to doing things a certain way that the borrow checker doesn't like (no, that doesn't automatically mean that what you want to do is unsafe or incorrect) then you will have big problems writing Rust. In this case, Rust was forced on the original author by management and there was a pre-existing codebase that did things in a very non-Rusty way. On top of that, it appears to be a performance-sensitive application with the need for async. That's just a recipe for a uniquely Rusty form of pain. This kind of gripe seems valid about the language. Rust is fantastic if you can be very Rusty, but it's also a language with a lot of opinions about how you ought to write code.
  - fnordpiglet 3y ago
    Writing language code idiomatically is a bit of the deal with any language. Trying to break a languages fu to be more like a language you’re more familiar with is common when learning a new language, but blaming the language is a rookie mistake.
    - Brian_K_White 3y ago
      What kind of mistake is thinking all legitimate tasks are equally doable in all legitimate languages? Or that there is any language that has no warts at all, and so any problems are automatically "holding it wrong"?
junon 3y ago
Great, more pointless language warring. Switching to rust made iteration times on my OS significantly smaller, the code much easier to maintain, and the tooling almost completely standard Rust tooling instead of a jury rigged amalgamation of Unix tools etc. To each their own.
- c_crank 3y ago
  Language warring isn't really pointless, because generating hype and buzz is what drives BIG-BUSINESS-CORPS into adopting new languages for their flavor of the decade.
  - UncleMeat 3y ago
    Having been directly involved in language support discussions at one of the very largest BIG-BUSINESS-CORPS, I am pretty confident that "hype and buzz" is not the key contributor to decision making.
    - cmrdporcupine 3y ago
      Yes, not sure what commenter is pointing at. It's not the large corps that drive this kind of froth, it's smaller shops or startups with smaller teams where decisions get more easily dominated by individuals with opinions. But, all that said. Rust Good. I work in Rust. I like Rust. I just don't believe in one size fits all, and I want to see companies apply balanced processes in technology or framework adoption.
      - c_crank 3y ago
        While Java is the 'safe' pick now, remember that it was once a language being fad pushed by Sun and Smalltalk fans.
        cmrdporcupine 3y ago
        "I Was There, Gandalf, 3000 Years Ago"
jackmott42 3y ago
At the end of their reddit post they say "Rust feels like a MAJOR step back from Java." which I think sums up the issue: 1. Rust is supposed to be harder than Java, you get runtime performance for your efforts. If you don't need that performance, by all means do not use Rust! 2. Rust is not as mature of an ecosystem as Java yet, and so there are going to be pain points compared to stuff that has been around forever. 3. Rust is also new to the poster, while using a new language is fun on toy projects, having to use a new language in production is always frustrating, even when you aren't moving to one that is fundamentally harder So, yeah I like Rust, but don't really disagree with their views here. Hopefully work is choosing to use Rust for a reason!
- goku12 3y ago
  > 1. Rust is supposed to be harder than Java, you get runtime performance for your efforts. If you don't need that performance, by all means do not use Rust! I have to disagree with this. It's easy to use Rust as a general purpose programming language once you are familiar with its type system. Getting there of course, is a different matter. There is a point beyond which the strict rules of the language stops feeling like a burden and starts feeling like a guide. > So even though I like Rust, I don't really disagree with their feelings. I can sympathize with the beginners. Navigating the Rust type system as a beginner takes a lot of patience and contemplation. Doing it under deadlines imposed by management is completely counterproductive. If I were a manager, I would either hire someone who knows it already, or invest in their training. That said, it's a very toxic behavior to take out that frustration on a community that created and loves the language. Express the frustration and seek help? That's fine. But calling them liars and cursing their project a swift death? I don't see how that's agreeable. This really isn't about Rust - it's about not being completely inconsiderate with strangers on the internet. People need a detox from the pressures of corporate life.
  - jackmott42 3y ago
    1. "easy to use once you figure out this hard thing" is another way of saying hard. 2. Some people look at those rants as toxic, and I understand that, but there is also value in expressing and seeing people's true feelings. Rust does this to people! Can we fix it?
cmrdporcupine 3y ago
Honestly, half of this is just ... use Rust for what it's for: systems programming. Where the handcuffs and compromises it puts on you make sense. Just ... stop writing web services in it. Not writing a compiler, a browser, an operating system, a database, an interpreter, building fundamental datastructures, or a working on an embedded system etc? Go back to enjoying the conveniences of garbage collection and looser ownership models. If you hit a wall with the GC and performance there, you can always rewrite portions native later.
- mikece 3y ago
  The choice of language was forced on the dev. He did a Java version of the app -- ON HIS OWN TIME -- and management nixed it.
  - cmrdporcupine 3y ago
    Yep, sounds like bad engineering management. My comment wasn't aimed at him but people like whoever his team lead is. FWIW Rust is my fulltime language. And actually I would probably use it for (some) web services, for personal things. But if I were managing and staffing a team, I would not do this simply because hiring and managing that would suck.
    - goku12 3y ago
      > I would not do this simply because hiring and managing that would suck. Could you elaborate on the disadvantages of Rust from the point of view of a manager or a project lead?
      - cmrdporcupine 3y ago
        Potential for staffing -- finding talent, and competent talent. Established best practices -- this is still being sorted out in Rust in various domains. Third party library support -- again, immature in some domains but not all. Managing and tutoring junior devs -- a bit trickier here. I think there is potential big win in using Rust. I want to see it propagate. I work in the language, and love it. But also a big fan of right tools in right places. For most web service ("full stack") type projects a GC managed language with a pile of existing code and a larger potential hiring pool just makes sense.
FrustratedMonky 3y ago
Anecdotally, if you are coming from Java, then changing your brain to think like Rust (functional) is a paradigm shift. (in true sense of word paradigm, a shift in perspective). Until the grok happens, yeah, it probably seems stupid and pointless. (but yes, it seems to be 'object' v 'functional' language war critiques again)
- fnordpiglet 3y ago
  Rust is more imperative with a functional nature, and has no meaningful runtime reflection and fairly weak object nature making it a real shift for Java developers, but a more natural shift for C developers who are familiar with basic functional programming.
- Sharlin 3y ago
  Java is, in fact, roughly as functional as Rust is! * Lambdas/closures: Java has had them since day one, albeit with horrible syntax. Nice syntax since Java 8, almost ten years ago (indeed predating Rust 1.0!). Some functional patterns are even easier in Java thanks to GC of captured variables. * Lazy lists, combinator chaining: Rust has iterators (and with rayon, parallel iterators); Java has streams, parallelizable by design, since Java 8. * Closed sum types: Rust has enums, Java 17 has sealed interfaces (semantically equivalent albeit much more verbose to define). * Pattern matching: Rust has `match` (and `if let` et al.), Java has `switch` which although not nearly at Rust's level yet, has been gradually gaining extra matching powers (JEPs 440 and 441). The real stumbling blocks for a Java developer are a lack of GC, the sharing XOR mutation paradigm, and lack of support for some common OOP patterns. Also a lack of reflection is a pretty big thing.
raspyberr 3y ago
This is a 20 minute video about someone reading out a reddit thread whilst streaming? Why?
- UncleMeat 3y ago
  Content for the content gods.
- coding123 3y ago
  Some people feel like they are more important than others, so they make a video of their reactions to reddit since it is indeed more authentic than everyone else. /S
  - afiori 3y ago
    Actual truth is that reaction content is incredibly cheap to make.
- mikece 3y ago
  Because I can listen to that in the background while doing other things.
- horsawlarway 3y ago
  I had to turn it off just based on how badly the person was stumbling in reading the damn thing.
- 015a 3y ago
  Because it has 150,000 views. Why does content exist? Because people watch it. He adds context, as a professional dev. He is entertaining, even if the original content isn't. And even if it is: the average human being today doesn't read anymore.
- delaaxe 3y ago
  What's wrong with commentary?
jamil7 3y ago
Picking Rust up for work, I feel like I had the opposite experience due to how much the difficulty curve had been hyped by some members of the community. The compiler basically tells you what to do, if you don't understand the message, you google a little or find the relevant part of the Rust book online. I'll admit, I started a lot smaller than the author of that post.
nymalt 3y ago
There was a nice comment Prime made that it's not only about the ownership model, many people come to Rust for it's type system. I have a feeling that far too many people go do Rust while what they actually need is OCaml - it's fast, has a nice type system and you don't have to think about lifetimes.
- cmrdporcupine 3y ago
  I agree, and OCaml (and the less popular but delightful StandardML) are lovely. But the problem there is the ecosystem just isn't there. F# or Scala seem like reasonable choices.
- duped 3y ago
  Ownership is part of the type system.
mike_hearn 3y ago
Hypothesis: maybe this guy would have been better off learning SystemJava instead of Rust? Given that he already knows Java. SystemJava is a very odd animal. It's a Java superset that is sort of hidden away inside the Graal project and not really advertised. SystemJava is Java for systems programming, proven out by its use to write a full JVM (with garbage collector etc, all in Java). SystemJava is syntactically identical to Java, so all existing tools and IDEs can work with it. However the semantics are quite different: 1. It's always compiled ahead of time to a standard platform native binary (exe or lib). 2. You can do both GCd and manual memory allocation, pointer arithmetic, stack allocation, calling in and out of C without JNI and so on. 3. Some objects are "magic" and not compiled as objects at all like CWordPointer which lets you do raw ptr derefs. Tutorial example file: https://github.com/oracle/graal/blob/14d366284d137415f3defb23a7eb2b72d44953f3/substratevm/src/com.oracle.svm.tutorial/src/com/oracle/svm/tutorial/CInterfaceTutorial.java#L86 https://github.com/oracle/graal/blob/14d366284d137415f3defb2... With this you can do things like make what appears to be a C library on the outside, but write it with Java on the inside. The parts of the runtime needed will be compiled into the binary. You can rely on the GC for anything that isn't performance sensitive, and use manual memory management for the rest. Or you can use the GraalEE version which has the G1 GC that is these days very fast and powerful, without needing much tuning. SystemJava doesn't have anything like the Rust type system, so it won't catch data races or double frees (when working with manually managed memory). But it might have been a better tradeoff given the skills profile of this team.
- telotortium 3y ago
  I can't even find a single page describing System Java on https://graalvm.org https://graalvm.org, so they'd probably have even more difficulty with that than Rust.

30 points by mikece 3y ago

bena 3y ago

Here's the post that the video is about https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_programming_language_absolutely/ https://www.reddit.com/r/rust/comments/12b7p2p/the_rust_prog...

msh 3y ago
I dont know rust but the following comment from the reddit thread resonates with me: So you started learning rust by trying to make something multithreaded that also interops with C instead of starting with something simpler so you can learn to understand the borrow checker? That's a recipe for disaster.
- mikece 3y ago
  The choice of language was forced on the dev. He did a Java version of the app -- ON HIS OWN TIME -- and management nixed it.
  - imtringued 3y ago
    That doesn't excuse his choice of words. >am truly convinced that all the people who claim Rust is great are either lying to themselves or others A Rust novice telling every Rust developer in the world being wrong? There must be some irrefutable wisdom in there somewhere!
  - rob74 3y ago
    Yeah - there's a huge psychological difference between adopting a language out of your own free will and it being forced upon you. I suspect that's where a lot of the current hyperbole about Rust comes from...
- gizmo 3y ago
  The issue here is that Rust presents itself as a systems language, i.e. a language where the programmer has control over how the system's resources get used. However, Rust has safety mechanisms that will stop you from doing what you want, even when what you want to do is safe and sensible. There is a contradiction here that Rust enthusiasts endlessly make excuses for. Rust is more like Go than C. Both Rust and Go can be used to write high performance services. Both Rust and Go have many modern convenience features. And both languages expect you to write code in a specific idiomatic way, wrt borrow checking and go channels respectively. If you need shared memory and fine-grained locking for performance you're not going to have a good time. And that makes Go and Rust unsuitable for a large chunk of applications.
  - cmrdporcupine 3y ago
    This is simply false. Having written code like what you're talking about... There is always an escape-hatch. Rust just wants to make sure you really know what you're doing before letting you go there. The idea being to provide safety-minded well crafted but performant libraries where the hard thinking about atomics & locking and unsafe-bounded memory shenanigans are confined in well-tested locales. Also don't see why you're comparing with Go. Entirely different bowl of soup. Go is not a systems programming language.
  - goku12 3y ago
    Rust is used for writing entire OS (e.g Redox) or parts of the OS that needs precise management of resources (e.g Linux kernel, Windows). It is used to write parts of web browsers (servo and quantum parts of firefox), game engines and in embedded systems. It's used everywhere that traditionally used C, C++ or Ada. There really isn't a justification to dismiss Rust as a systems programming language. The limitations that you claim are not there. The reasons are there in the other reply to you.
  - mike_hearn 3y ago
    There is unsafe{} if you want to do something not normally allowed. But, well, it's unsafe. I was surprised to learn of a memory management vulnerability in a Rust serialization library the other day (for capn'proto). It was using unsafe. You'd think that serialization is the sort of library where Rust's guarantees are most valuable.
titzer 3y ago
Thanks for posting the link. The video is useless, it's just rage-baiting. Stepping back from the emotional overreaction in the OP, this seems to be the relevant bit: > Right off the bat, as a total Rust newbie, I'm hitting all kinds of rough edges in Rust. For example, I'm trying to use rusqlite. It would be natural to stash DB prepared statements in a thread local for reuse in my multi-threaded code. I can't pass the connections around, because I need them in a C call-back (too much detail here I know) so I have to be able to look them up. Alas, after banging my head against the wall for a full day, I'm just giving up on the thread-local approach, because I simply can't get it to work. Part of the problem is that I can't stash a prepared statement in the same (thread local) struct as the connection from which they are created, due to lifetime limitations. It also seems that you can't really use two thread locals (one for the connection and one for the prepared statements) either. If there's a way to do it, I can't figure it out. What I take from this is that the library was designed to work with lifetimes a specific way, and the OP is trying to use them in a way not intended. Rust lifetimes being baked into the language means there is really no way around the design the library authors had in mind. If the library authors made bad choices, you are basically stuck. This is the crux of the matter. A poorly designed library in Rust comes with a straightjacket that you must wear. I've had students hit this kind of things several times. This kind of experience absolutely kills the flow and sucks all the joy out of programming. Poorly-designed lifetimes are non-composable and lead programmers down completely unnecessary, totally unproductive rabbit holes. Making memory management orthogonal APIs is the only way to make them composable.
- cmrdporcupine 3y ago
  I actually ran into these precise problems with rusqlite and found them equally frustrating, and ended up ripping that code out in the end. The lifetimes model in that library are, IMHO, "wrong".
- mike_hearn 3y ago
  It seems almost worse - the author of rusqlite replies and says, essentially, that you just cannot do what he wants to do at all, and the "fix" is to either constantly re-prepare statements, or rely on some sort of library built-in cache! The first will lower performance perhaps by a lot, but performance is probably why you're writing Rust in the first place. The second is a nasty hack that will require you to remember this cache exists and keep its size carefully tuned. As all he wants to do is stash prepared statements in TLS, a pretty normal task, it seems like a valid complaint that this is so hard and rustql doesn't seem to allow it. One aspect of Rust I wonder about it is that when reading it I see way more cloning than you'd intuitively expect. Seems like people hit the borrow checker, can't see a way out and just copy the memory to escape. Presumably that will lead to diffuse performance losses all over the app of the sort that can't easily be spotted in a profiler, sort of like pointer chasing in languages without value types. I wonder if C++ will actually end up having an edge in performance due to this. I know there are very heavily tuned benchmarks that show Rust being the fastest but I mean for "real" code of the sort this person is needing to write (done under time pressure).
Verdex 3y ago
Thanks for the link. I saw the youtube video advertised to me by the algorithm, but wasn't about to waste my time watching it. After decades of trying to get C-style systems programming right, we're still finding unsafe memory related security issues (ignoring implicit integer casts and UB). Thesis: Maybe c-style systems programming is bad. Rust consumes what we learned from cyclone et al as well as leveraging llvm and while I think we had reason to be cautiously optimistic for a while there, now it honestly seems to be working. But it works because we abandoned what we thought were the bad parts of c-style systems programming. Meanwhile, someone tries to shove c-style programming back into rust and finds it's not actually possible. Then complains. Technically, this is fine. The part that isn't fine is to loudly proclaim that everyone who is able to learn how to use rust correctly must be lairs. [As an aside, there's D, P, jai, rust, odin, zig, carbon, vale, swift, c++11+, and more. A good rule of thumb is that a programming language takes about a decade to really get moving. There's a reason that an absurd amount of time has been dumped into replacing c-style systems programming.]
- c_crank 3y ago
  Bug free code only exists when it can be formally verified.
  - Verdex 3y ago
    | Bug free code only exists when it can be formally verified. ... okay. Although, on the other hand: | Beware of bugs in the above code; I have only proved it correct, not tried it - Knuth Perhaps bug free code does not exist?
    - c_crank 3y ago
      The replacement languages for C in systems programming aren't memory safe. They can cause segfaults. They have additional tools and syntax rules to make it less likely, but they can and will have memory bugs.
      - Verdex 3y ago

linusg789 3y ago

The situation described in the video can and probably does happen to C++ codebases as well, if not even more than Rust. It's easier to be good at Rust than it is to be at C++, even if C++ seems easier at first.

mikece 3y ago
From the video it sounds like the largest problem is that the company/manager prescribed Rust as the solution to a problem where Rust might not have been the best fit. The dude wrote a Java version on his own time and despite being on a Java team at that job management insisted it be done in Rust. There might be issues with Rust and the scenario in question but it sounds like conditions at that work place are a bigger problem than the choice of a language.
pclmulqdq 3y ago
The specific situation the poster is in is very Rusty. If you are used to doing things a certain way that the borrow checker doesn't like (no, that doesn't automatically mean that what you want to do is unsafe or incorrect) then you will have big problems writing Rust. In this case, Rust was forced on the original author by management and there was a pre-existing codebase that did things in a very non-Rusty way. On top of that, it appears to be a performance-sensitive application with the need for async. That's just a recipe for a uniquely Rusty form of pain. This kind of gripe seems valid about the language. Rust is fantastic if you can be very Rusty, but it's also a language with a lot of opinions about how you ought to write code.
- fnordpiglet 3y ago
  Writing language code idiomatically is a bit of the deal with any language. Trying to break a languages fu to be more like a language you’re more familiar with is common when learning a new language, but blaming the language is a rookie mistake.
  - Brian_K_White 3y ago
    What kind of mistake is thinking all legitimate tasks are equally doable in all legitimate languages? Or that there is any language that has no warts at all, and so any problems are automatically "holding it wrong"?

junon 3y ago

Great, more pointless language warring. Switching to rust made iteration times on my OS significantly smaller, the code much easier to maintain, and the tooling almost completely standard Rust tooling instead of a jury rigged amalgamation of Unix tools etc. To each their own.

c_crank 3y ago
Language warring isn't really pointless, because generating hype and buzz is what drives BIG-BUSINESS-CORPS into adopting new languages for their flavor of the decade.
- UncleMeat 3y ago
  Having been directly involved in language support discussions at one of the very largest BIG-BUSINESS-CORPS, I am pretty confident that "hype and buzz" is not the key contributor to decision making.
  - cmrdporcupine 3y ago
    Yes, not sure what commenter is pointing at. It's not the large corps that drive this kind of froth, it's smaller shops or startups with smaller teams where decisions get more easily dominated by individuals with opinions. But, all that said. Rust Good. I work in Rust. I like Rust. I just don't believe in one size fits all, and I want to see companies apply balanced processes in technology or framework adoption.
    - c_crank 3y ago
      While Java is the 'safe' pick now, remember that it was once a language being fad pushed by Sun and Smalltalk fans.
      - cmrdporcupine 3y ago
        "I Was There, Gandalf, 3000 Years Ago"

jackmott42 3y ago

At the end of their reddit post they say "Rust feels like a MAJOR step back from Java." which I think sums up the issue: 1. Rust is supposed to be harder than Java, you get runtime performance for your efforts. If you don't need that performance, by all means do not use Rust! 2. Rust is not as mature of an ecosystem as Java yet, and so there are going to be pain points compared to stuff that has been around forever. 3. Rust is also new to the poster, while using a new language is fun on toy projects, having to use a new language in production is always frustrating, even when you aren't moving to one that is fundamentally harder So, yeah I like Rust, but don't really disagree with their views here. Hopefully work is choosing to use Rust for a reason!

goku12 3y ago
> 1. Rust is supposed to be harder than Java, you get runtime performance for your efforts. If you don't need that performance, by all means do not use Rust! I have to disagree with this. It's easy to use Rust as a general purpose programming language once you are familiar with its type system. Getting there of course, is a different matter. There is a point beyond which the strict rules of the language stops feeling like a burden and starts feeling like a guide. > So even though I like Rust, I don't really disagree with their feelings. I can sympathize with the beginners. Navigating the Rust type system as a beginner takes a lot of patience and contemplation. Doing it under deadlines imposed by management is completely counterproductive. If I were a manager, I would either hire someone who knows it already, or invest in their training. That said, it's a very toxic behavior to take out that frustration on a community that created and loves the language. Express the frustration and seek help? That's fine. But calling them liars and cursing their project a swift death? I don't see how that's agreeable. This really isn't about Rust - it's about not being completely inconsiderate with strangers on the internet. People need a detox from the pressures of corporate life.
- jackmott42 3y ago
  1. "easy to use once you figure out this hard thing" is another way of saying hard. 2. Some people look at those rants as toxic, and I understand that, but there is also value in expressing and seeing people's true feelings. Rust does this to people! Can we fix it?

cmrdporcupine 3y ago

Honestly, half of this is just ... use Rust for what it's for: systems programming. Where the handcuffs and compromises it puts on you make sense. Just ... stop writing web services in it. Not writing a compiler, a browser, an operating system, a database, an interpreter, building fundamental datastructures, or a working on an embedded system etc? Go back to enjoying the conveniences of garbage collection and looser ownership models. If you hit a wall with the GC and performance there, you can always rewrite portions native later.

mikece 3y ago
The choice of language was forced on the dev. He did a Java version of the app -- ON HIS OWN TIME -- and management nixed it.
- cmrdporcupine 3y ago
  Yep, sounds like bad engineering management. My comment wasn't aimed at him but people like whoever his team lead is. FWIW Rust is my fulltime language. And actually I would probably use it for (some) web services, for personal things. But if I were managing and staffing a team, I would not do this simply because hiring and managing that would suck.
  - goku12 3y ago
    > I would not do this simply because hiring and managing that would suck. Could you elaborate on the disadvantages of Rust from the point of view of a manager or a project lead?
    - cmrdporcupine 3y ago
      Potential for staffing -- finding talent, and competent talent. Established best practices -- this is still being sorted out in Rust in various domains. Third party library support -- again, immature in some domains but not all. Managing and tutoring junior devs -- a bit trickier here. I think there is potential big win in using Rust. I want to see it propagate. I work in the language, and love it. But also a big fan of right tools in right places. For most web service ("full stack") type projects a GC managed language with a pile of existing code and a larger potential hiring pool just makes sense.

FrustratedMonky 3y ago

Anecdotally, if you are coming from Java, then changing your brain to think like Rust (functional) is a paradigm shift. (in true sense of word paradigm, a shift in perspective). Until the grok happens, yeah, it probably seems stupid and pointless. (but yes, it seems to be 'object' v 'functional' language war critiques again)

fnordpiglet 3y ago
Rust is more imperative with a functional nature, and has no meaningful runtime reflection and fairly weak object nature making it a real shift for Java developers, but a more natural shift for C developers who are familiar with basic functional programming.
Sharlin 3y ago
Java is, in fact, roughly as functional as Rust is! * Lambdas/closures: Java has had them since day one, albeit with horrible syntax. Nice syntax since Java 8, almost ten years ago (indeed predating Rust 1.0!). Some functional patterns are even easier in Java thanks to GC of captured variables. * Lazy lists, combinator chaining: Rust has iterators (and with rayon, parallel iterators); Java has streams, parallelizable by design, since Java 8. * Closed sum types: Rust has enums, Java 17 has sealed interfaces (semantically equivalent albeit much more verbose to define). * Pattern matching: Rust has `match` (and `if let` et al.), Java has `switch` which although not nearly at Rust's level yet, has been gradually gaining extra matching powers (JEPs 440 and 441). The real stumbling blocks for a Java developer are a lack of GC, the sharing XOR mutation paradigm, and lack of support for some common OOP patterns. Also a lack of reflection is a pretty big thing.

raspyberr 3y ago

This is a 20 minute video about someone reading out a reddit thread whilst streaming? Why?

UncleMeat 3y ago
Content for the content gods.
coding123 3y ago
Some people feel like they are more important than others, so they make a video of their reactions to reddit since it is indeed more authentic than everyone else. /S
- afiori 3y ago
  Actual truth is that reaction content is incredibly cheap to make.
mikece 3y ago
Because I can listen to that in the background while doing other things.
horsawlarway 3y ago
I had to turn it off just based on how badly the person was stumbling in reading the damn thing.
015a 3y ago
Because it has 150,000 views. Why does content exist? Because people watch it. He adds context, as a professional dev. He is entertaining, even if the original content isn't. And even if it is: the average human being today doesn't read anymore.
delaaxe 3y ago
What's wrong with commentary?

jamil7 3y ago

Picking Rust up for work, I feel like I had the opposite experience due to how much the difficulty curve had been hyped by some members of the community. The compiler basically tells you what to do, if you don't understand the message, you google a little or find the relevant part of the Rust book online. I'll admit, I started a lot smaller than the author of that post.

nymalt 3y ago

There was a nice comment Prime made that it's not only about the ownership model, many people come to Rust for it's type system. I have a feeling that far too many people go do Rust while what they actually need is OCaml - it's fast, has a nice type system and you don't have to think about lifetimes.

cmrdporcupine 3y ago
I agree, and OCaml (and the less popular but delightful StandardML) are lovely. But the problem there is the ecosystem just isn't there. F# or Scala seem like reasonable choices.
duped 3y ago
Ownership is part of the type system.

mike_hearn 3y ago

Hypothesis: maybe this guy would have been better off learning SystemJava instead of Rust? Given that he already knows Java. SystemJava is a very odd animal. It's a Java superset that is sort of hidden away inside the Graal project and not really advertised. SystemJava is Java for systems programming, proven out by its use to write a full JVM (with garbage collector etc, all in Java). SystemJava is syntactically identical to Java, so all existing tools and IDEs can work with it. However the semantics are quite different: 1. It's always compiled ahead of time to a standard platform native binary (exe or lib). 2. You can do both GCd and manual memory allocation, pointer arithmetic, stack allocation, calling in and out of C without JNI and so on. 3. Some objects are "magic" and not compiled as objects at all like CWordPointer which lets you do raw ptr derefs. Tutorial example file: https://github.com/oracle/graal/blob/14d366284d137415f3defb23a7eb2b72d44953f3/substratevm/src/com.oracle.svm.tutorial/src/com/oracle/svm/tutorial/CInterfaceTutorial.java#L86 https://github.com/oracle/graal/blob/14d366284d137415f3defb2... With this you can do things like make what appears to be a C library on the outside, but write it with Java on the inside. The parts of the runtime needed will be compiled into the binary. You can rely on the GC for anything that isn't performance sensitive, and use manual memory management for the rest. Or you can use the GraalEE version which has the G1 GC that is these days very fast and powerful, without needing much tuning. SystemJava doesn't have anything like the Rust type system, so it won't catch data races or double frees (when working with manually managed memory). But it might have been a better tradeoff given the skills profile of this team.

telotortium 3y ago
I can't even find a single page describing System Java on https://graalvm.org https://graalvm.org, so they'd probably have even more difficulty with that than Rust.