4 ms·

> Remember when Rust and Go were comparable? They were never intended for the same niches. Go is a Java/Python replacement. Rust is more of a C/subset of C++ r

• pjmlp 1y ago
  Go is hardly a replacement with its weaker type system.
  • kitd 1y ago
    A weaker type system than Python?
    • pjmlp 1y ago
      Yes, as you can see for what is possible to express with Pyright. Just because Python is dynamic, doesn't mean it lacks the notion of a type system, or the whole set of concepts that Go has no way to express, like meta-classes, multiple inheritance, comprehensions (eager or lazy),.... Many folks going from Python to Go, would never done it if Python had a modern JIT on CPython, or the package management wasn't the way it is, hardly anything to do with the language itself.
      • GoblinSlayer 1y ago
        I don't quite understand what's the point of a type system when it's going to be defenestrated by dynamic typing. In javascript the typeof operator can be used to check the type.
        • brokencode 1y ago
          The type system still allows organizing and abstracting code in standardized ways. Static type checking is nice and is certainly my preference, but dynamic type checking doesn’t mean no types. It means the types are checked at runtime.
        • pjmlp 1y ago
          Because the runtime still takes advantage of those concepts, an array doesn't stop being an array, and magically turns into a list, with different hardware requirements only because a language is dynamic. Same applies to all other remaining types. That is how even though people see Lisp as a dynamic language using only lists, in reality most Lisps (and Schemes) since the 1980's have all necessary types to write machine friendly code (aka mechanical sympathy), including having existed graphical workstations that only failed the market because UNIX and C were as cheap as free beer for all pratical purposes.
• steveklabnik 1y ago
  Way back when Rust was first made known outside of Mozilla; it was pretty close to Go. While the intent was to be super low level, it didn’t really achieve those goals until years later, and kind of at the expense of parts of the original vision.
• hardwaresofton 1y ago
  Other WAY more qualified people already responded and elucidated on the initial origins of Rust (it used to have a garbage collector!), but I can at least add this: The definition of "same niche" is doing a lot of heavy lifting. There's a marked difference between what these tools became and the impression of them along the way and the axes along which they were compared in actuality. In the simple "I need to build a backend" conversation, Rust and Go were comparable long after Rust changed to a "real" systems language -- I'd go as far as to say people still compare them to this day (and Go probably wins that larger niche for many contextual reasons). I think the point is partially reflected in your own statement -- there are many axes along which Go is not a Java replacement, and is not a Python replacement either. The definition of the "niche" vastly changes the answer. For example, if you pick the right niche (e.g. HFT) Java meaningfully outperforms Go because high performance Java is... actually high performance -- those millions of man years into the compiler, runtime, etc produced progress. That said both of those languages get trounced by the FPGAs and custom hardware in the end. I'm not convinced it was always wrong to compare Rust and Go, but the modern understanding of how different they are today is definitely better/I am glad they're more separated/more people know not to directly compare them.