5 ms·

Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow

by bsaul 7y ago

Rust can't settle down right now, because it still has to make necessary changes to critical parts of the language, such as async. Go always had a very narrow and precise ambition and scope (a better C, aimed at server-side data plumbing). Which is the reason why it was able to nail a set of features from the start and keep it that way. Rust has a much wider ambition : all the modern languages facilities (generics, metaprogramming, etc) with the speed of C, AND breakthrough memory-safety features. Go doesn't try to innovate, and i suppose the author see innovation as something you should stay away until it's nothing new anymore.

littlestymaar 7y ago
> a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.
- root_axis 7y ago
  I think in practice it has become something closer to a better python than a better java.
  - earenndil 7y ago
    Personally, I don't think it's better than any of those languages.
  - meowface 7y ago
    More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency. Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.
- meddlepal 7y ago
  > it's a better Java. Ah ha ha ha ha ha ha. No. Just no. I say this as someone who writes Go day in and day out and wrote Java for a decade. Maybe it is if the last time you touched Java was 2001.
  - alexbanks 7y ago
    Can you explain why they're wrong?
    - erik_seaberg 7y ago
      Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.
      - alexbanks 7y ago
        It sounds like the point the person was trying to make was in use-case, rather than language semantics. As in, where one might've used Java before, they would now use Go. Not that Java and Go are semantically similar.
      - geodel 7y ago
        When did Java get versioned modules, value types, installable binaries, dynamic heap size?
        pjmlp 7y ago
        Installable binaries, around 2000, when the first commercial JDKs started having AOT compilation to native code. Currently available on PTC, Aicas, IBM, OpenJDK AppCDS (originally from BEA J/Rockit), GradleVM native images, Android ART AOT compilation. Dynamic heap size, since ever. Every JDK vendor had their own specific switches to configure it. Versioned modules, since Java 9 alongside Maven/Gradle. Value types, yeah point taken. There were Azul and IBM specific extensions, ObjectLayout and PackedObjects respectively, and the 2nd experimental release for value types was just made recently available.
- pjmlp 7y ago
  One day, when it has proper generics, interface validation without compiler error tricks, and an usefull portable UI library, it might be a better Java.
- LanceH 7y ago
  I went to a Go meetup where I use Go as a complement to Ruby. The speaker and most of the others there were using it as a more expressive/easier C. The middle ground it has carved out seems to let everyone say that their language does something better, but there seems to be a good chance that Go does a reasonable job at what their language doesn't do well (and isn't too far off to learn).
  - tapirl 7y ago
    it is a better-java language with c blood.
- Cthulhu_ 7y ago
  Nah, Kotlin is a better Java, Go has a mostly different use case.
Touche 7y ago
I don't know if "all the modern languages facilities" was a goal of Rust from the start. It seemed like the initial goal was to be able to develop a web browser with memory safety. "all the modern languages facilities" seems to be something that's come along more recently (last couple of years) as a result of a lot of non web browser developers taking an interest in the language.

by bsaul 7y ago

littlestymaar 7y ago

> a better C, aimed at server-side data plumbing I agree with all what you said but this. Go isn't a better C, it's a better Java.

root_axis 7y ago
I think in practice it has become something closer to a better python than a better java.
- earenndil 7y ago
  Personally, I don't think it's better than any of those languages.
- meowface 7y ago
  More like a "different Python" than a better one. Way more performant, way more verbose, and (IMO) way better concurrency. Not to go off on too much of a tangent, but I think asyncio is a huge mess and was a mistake. I still use gevent for everything in Python. https://glyph.twistedmatrix.com/2014/02/unyielding.html https://glyph.twistedmatrix.com/2014/02/unyielding.html is frequently cited as an argument for why goroutines and gevent and green threads suck and why explicit asyncio-style concurrency is better, but I have a lot of issues with this article and find the former two way easier, simpler, and faster to work with.
meddlepal 7y ago
> it's a better Java. Ah ha ha ha ha ha ha. No. Just no. I say this as someone who writes Go day in and day out and wrote Java for a decade. Maybe it is if the last time you touched Java was 2001.
- alexbanks 7y ago
  Can you explain why they're wrong?
  - erik_seaberg 7y ago
    Java got async I/O in 2002, generics and "for (x : iterable)" in 2004, and lambdas in 2014. Vintage 2001 Java was drastically harder to read and slower, though error handling was always less cumbersome than Go.
    - alexbanks 7y ago
      It sounds like the point the person was trying to make was in use-case, rather than language semantics. As in, where one might've used Java before, they would now use Go. Not that Java and Go are semantically similar.
    - geodel 7y ago
      When did Java get versioned modules, value types, installable binaries, dynamic heap size?
      - pjmlp 7y ago
        Installable binaries, around 2000, when the first commercial JDKs started having AOT compilation to native code. Currently available on PTC, Aicas, IBM, OpenJDK AppCDS (originally from BEA J/Rockit), GradleVM native images, Android ART AOT compilation. Dynamic heap size, since ever. Every JDK vendor had their own specific switches to configure it. Versioned modules, since Java 9 alongside Maven/Gradle. Value types, yeah point taken. There were Azul and IBM specific extensions, ObjectLayout and PackedObjects respectively, and the 2nd experimental release for value types was just made recently available.
pjmlp 7y ago
One day, when it has proper generics, interface validation without compiler error tricks, and an usefull portable UI library, it might be a better Java.
LanceH 7y ago
I went to a Go meetup where I use Go as a complement to Ruby. The speaker and most of the others there were using it as a more expressive/easier C. The middle ground it has carved out seems to let everyone say that their language does something better, but there seems to be a good chance that Go does a reasonable job at what their language doesn't do well (and isn't too far off to learn).
- tapirl 7y ago
  it is a better-java language with c blood.
Cthulhu_ 7y ago
Nah, Kotlin is a better Java, Go has a mostly different use case.

Touche 7y ago

I don't know if "all the modern languages facilities" was a goal of Rust from the start. It seemed like the initial goal was to be able to develop a web browser with memory safety. "all the modern languages facilities" seems to be something that's come along more recently (last couple of years) as a result of a lot of non web browser developers taking an interest in the language.