Slide with text: “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.”

In small print it says the data is collected over 2022 and 2023.

  • 1984@lemmy.today
    link
    fedilink
    arrow-up
    34
    arrow-down
    4
    ·
    edit-2
    7 months ago

    I don’t know. After writing rust for a while, and slowly putting programs together, I tried Go and I feel so relived I can just write what I want in 10 seconds instead of messing with lifetimes, borrow checker and other stuff I actually don’t care about at all.

    A more experienced colleague said that yes that is true, but Go can’t guarantee your code is correct, so you will spend time fixing your code also in Go. Probably true.

    • orclev@lemmy.world
      link
      fedilink
      English
      arrow-up
      41
      ·
      7 months ago

      Right, it’s essentially the same argument as strong vs. weak typing. The weak typing proponents say JavaScript is best, because you can just write anything and you don’t need to worry about all those pesky types getting in your way. The strong typing proponents (which if it’s not obvious I am one of) point out that you can write incorrect code quickly in just about any language, but writing correct code is much harder, and the cost of correcting code increases the later the mistake is found. Errors that can’t even be written are better than errors that are found at compile time which are better than errors that are reliably caught at runtime, which are all infinitely better than errors that only randomly appear under very specific circumstances.

      That is why many people switched to using TypeScript for their websites instead of JavaScript, because even though you have to spend more time putting type annotations on everything, and at the end of the day at runtime TypeScript is literally just JavaScript, the errors it lets you find at compile time instead of runtime make the effort necessary to include those types worth it. Same thing applies with Rust vs. Go. Yes it requires more thinking up front when you’re writing Rust code, and yes it might take you longer to write that code, but it’s also going to be correct code you can be confident in and not have a bunch of ticking timebombs waiting in it that you don’t even know about.

      An extra 30 minutes spent having to think about a dozen lines of code, is infinitely preferable to spending 3 hours pouring over stack traces and single stepping debuggers to find that one subtle mistake you made.

      • FizzyOrange@programming.dev
        link
        fedilink
        arrow-up
        11
        ·
        7 months ago

        I totally agree, though I think it’s worth adding:

        • The advantages of static types is not just finding bugs (though it does do that quite well). It also massively helps with productivity because a) types are now documented, b) you can use code intelligence tools like renaming variables, go-to-definition, find-references, etc. (assuming you use a good editor/IDE).

        • In general stronger types are better but I do think there is a point at which the effort of getting the types right is too high to be worth the benefit. I would say Rust hasn’t reached that point, but if you look at formal verification languages like Dafny, it’s pretty clear that you wouldn’t want to use that except in extreme circumstances. Similarly I think the ability to use an any or dynamic escape hatch is quite useful, even if it should be used very sparingly.

        • arendjr@programming.devOP
          link
          fedilink
          arrow-up
          4
          ·
          7 months ago

          You are right. But I think similar secondary benefits also come from using the borrow checker. Rust developers, by necessity, try to avoid using circular references and prefer immutability where they can. Both of these are advantages because they tend to make for systems that are easier to understand and are easier to maintain.

        • orclev@lemmy.world
          link
          fedilink
          English
          arrow-up
          3
          ·
          7 months ago

          It also massively helps with productivity

          Absolutely! Types are as much about providing the programmer with information as they are the compiler. A well typed and designed API conveys so much useful information. It’s why it’s mildly infuriating when I see functions that look like something from C where you’ll see like:

          pub fn draw_circle(x: i8, y: i8, red: u8, green, u8, blue: u8, r: u8) -> bool {
          

          rather than a better strongly typed version like:

          type Point = Vec2<i8>;
          type Color = Vec3<u8>;
          type Radius = NonZero<u8>;
          pub fn draw_circle(point: Point, color: Color, r: Radius) -> Result<()> {
          

          Similarly I think the ability to use an any or dynamic escape hatch is quite useful, even if it should be used very sparingly.

          I disagree with this, I don’t think those are ever necessary assuming a powerful enough type system. Function arguments should always have a defined type, even if it’s using dynamic dispatch. If you just want to not have to specify the type on a local, let bindings where you don’t explicitly define the type are fine, but even in that case it still has a type, you’re just letting the compiler derive it for you (and if it can’t it will error).

          • FizzyOrange@programming.dev
            link
            fedilink
            arrow-up
            8
            arrow-down
            2
            ·
            7 months ago

            Without static type annotations you can only make best effort guesses that are sometimes right. Better than nothing but not remotely the same as actual static types. The LSP you linked works best when you use static type annotations.

            Also I would really recommend Pylance over that if you can - it’s much better but is also closed source unfortunately.

            • asdfasdfasdf@lemmy.world
              link
              fedilink
              arrow-up
              4
              arrow-down
              2
              ·
              7 months ago

              Why would it just be best effort? To find references for a specific thing, it still would parse an AST, find the current scope, see it’s imported from some module, find other imports of the module, etc.

              • Buttons@programming.dev
                link
                fedilink
                English
                arrow-up
                5
                ·
                edit-2
                7 months ago
                if random() > 0.5:
                    x = 2
                else:
                    x = "hello"
                

                Where is the definition of x? What is the type of x? If you can’t identify it, neither can the LSP.

                This kind of thing actually happens when implementing interfaces, inheritance, etc. Thus, LSPs in dynamic languages are best effort both theoretically and in practice.

                • asdfasdfasdf@lemmy.world
                  link
                  fedilink
                  arrow-up
                  2
                  arrow-down
                  1
                  ·
                  edit-2
                  7 months ago
                  1. Look at entire file instead of snippet.
                  2. If there is anything that could create a variable x before this area, then that’s where x originates. If not, and if it’s a language where you can create x without using a keyword like let or var, then x is created in the scope in your snippet.

                  Types are not necessary at all.

                  • Buttons@programming.dev
                    link
                    fedilink
                    English
                    arrow-up
                    3
                    arrow-down
                    1
                    ·
                    7 months ago

                    then x is created in the scope in your snippet

                    Saying “x is defined somewhere in the entire program” isn’t satisfactory to many users. Also, you didn’t tell me what type x has. Can I do x + 5?

              • FizzyOrange@programming.dev
                link
                fedilink
                arrow-up
                2
                arrow-down
                1
                ·
                7 months ago
                def get_price(x):
                   return x.prize
                

                Ok imagine you are a LSP. What type is x? Is prize a typo? What auto-complete options would you return for x.?

                  • FizzyOrange@programming.dev
                    link
                    fedilink
                    arrow-up
                    2
                    ·
                    7 months ago

                    How are you going to find references to prize, go to its definition or rename it without knowing what type x is? It’s impossible without static types.

    • 2xsaiko@discuss.tchncs.de
      link
      fedilink
      arrow-up
      14
      arrow-down
      1
      ·
      edit-2
      7 months ago

      instead of messing with lifetimes, borrow checker and other stuff I actually don’t care about at all

      There’s nothing wrong with putting Rc<_> or Rc<RefCell<_>> around data if you don’t want to fight the borrow checker or think about lifetimes even if you know it can be written without.

      • lightnegative@lemmy.world
        link
        fedilink
        arrow-up
        5
        arrow-down
        1
        ·
        7 months ago

        There’s nothing wrong with putting Rc<> or Rc<RefCell<>> around data

        It’s mainly the visual pollution that bothers me. Wrapping everything in the reference counting smart pointers just because you can’t be bothered dealing with the borrow checker seems like an antipattern

        • nous@programming.dev
          link
          fedilink
          English
          arrow-up
          3
          ·
          7 months ago

          I don’t know why so many recommend Rc or Arc as a catchall. 90% of the time if you want to avoid the borrow checker then a clone or copy is good enough.

    • FizzyOrange@programming.dev
      link
      fedilink
      arrow-up
      12
      ·
      7 months ago

      Really? I might have agreed for some other languages, but Go is so bare bones it feels like it takes way longer to write simple stuff than with Rust - you have to tediously write out loops all the time for example.

      Tbf I haven’t used it since it got generics. Maybe it is better now.

      • nous@programming.dev
        link
        fedilink
        English
        arrow-up
        3
        ·
        7 months ago

        Rust gives you high level abstractions but also allows lower level control over the hardware. These are not mutually exclusive.

        You can easily argue almost any language is high level though, it is such a nebulous term that it is almost meaningless.

    • jack
      link
      fedilink
      arrow-up
      2
      arrow-down
      13
      ·
      7 months ago

      But Go has garbage collection so that code is as correct as that of Rust. Go is just a little less performant

      • orclev@lemmy.world
        link
        fedilink
        English
        arrow-up
        23
        ·
        7 months ago

        Rusts ownership model is not just an alternative to garbage collection, it provides much more than that. It’s as much about preventing race conditions as it is in making sure that memory (and other resources) get freed up in a timely fashion. Just because Go has GC doesn’t mean it provides the same safety guarantees as Rust does. Go’s type system is also weaker than Rusts even setting aside the matter of memory management.