Should I Rust or should I go?
kerkour.com
"Is Rust a great fit for this project?" I get this question quite frequently so I think it's time to write down my thoughts if it can avoid you some painful and costly mistakes. Short answer: no. Coming from someone who wrote a successful book about Rust (Black Hat Rust)

I think some raised points are relevant…

  • SavvyWolf@pawb.socialEnglish
    4·
    1 year ago

    I know it's clickbait and all, but I can't really let their comments about "decay" go without saying anything.

    I spent a weekend updating a Python project after updating the OS. Fuck Python's release methodology.

    Yeah, Rust has a lot of releases, but they're all backwards compatible. I'm pretty sure a modern Rust compiler can compile any historic Rust program. Meanwhile every "minor" Python release has backwards incompatible changes and there's no guarantee of backwards compatibility at all. And that's without even bringing up the big major bump from 2 to 3 which… Was not handled well.

    Honestly, if there's any language that people should be angry at for "decaying", it should be Python. Hell, even C and C++ have got this right.

    • kornel@lemmyrs.orgEnglish
      1·
      1 year ago

      I maintain a long-term Rust + Node.js project, and the Node side is the painful one.

      Node makes backwards-incompatible changes, and doesn’t have anything like the editions to keep old packages working. I can end up with some dependencies working only up to Node vX, and some other deps needing at least Node v(X+1).

      • AggressivelyPassive@feddit.de
        1·
        1 year ago

        That's an issue with almost the entire js ecosystem. I'm part of a project that has rather high security standards, so we have to keep everything updated. The Java side is almost trivial, update some version number, let the tests run and you're fine. The js side is a constant battle against incompatibilities, weird changes for no reason and simply tons of vulnerabilities.

  • SorteKanin@feddit.dk
    4·
    1 year ago

    It's not uncommon in the professional world™ to have a project that is left untouched for 3 years and then suddenly needs an update. Now imagine being the one tasked with updating the dependencies of a service that is 31 versions behind…

    Yea you do rustup update and you're done because obviously it still compiles because it compiled before and there are no breaking changes. Funny how easy that was?

    • snaggen@programming.devEnglish
      0·
      1 year ago

      And don't get me wrong, I think Go is ok and I use it from time to time. When Go and Rust started to get traction, I actually laughed at Rust thinking it was a stupid language. Why would anyone use Rust when you had Go, it sounded so great with its go routines and all. I then started to use it, and it wasn't bad, but it wasn't something that got me all excited either. And it was the horrible error handling and all these simplifications that sacrifices correctness that made me feel it was only an ok language. It is the correctness of Rust and that you have to handle all errors aso, that makes it a bit annoying, but it is also these things that makes it great.

      • sugar_in_your_tea@sh.itjust.works
        0·
        1 year ago

        I don't mind the error handling in Go, what bothers me is a bunch of safety issues. For example:

        println(interface{}(nil) == nil)
println(interface{}((*int)(nil)) == nil)

        Depending on how your logical flow works, this can end up causing bugs in a very surprising and hard to detect way.

        Also, you can call methods on nil values, like this:

        type A int
func (a *A) doStuff() {
    *a = 3
}
var a *A = nil
a.doStuff()

        This panics inside doStuff, not at the call site, which can mean functions could run fine and fail later, making it harder to track down the nil value.

        There's a lot of other footguns, especially as you get into multithreading. I started building code with Go back at 1.0, and they didn't turn on multithreading by default until 1.4 or 1.5 (I forget which), at which point our assumption that the built-in map type was multithreading-safe didn't hold (at least for assignments and reads). That was in the documentation, but the fact that it worked fine for multiple releases made it that much worse.

        I still think Go is a fine language, but it should be limited to smaller scale projects like microservices because there are enough gotchas that the simplicity of the language hides for me to not recommend it.