5 ms·

Just some random guy's anecdote. I learned both of these simultaneously in two quirky ways. I learned Go using the "Learn Go with Tests" book https://quii.gi

Just some random guy's anecdote. I learned both of these simultaneously in two quirky ways. I learned Go using the "Learn Go with Tests" book https://quii.gitbook.io/learn-go-with-tests/ https://quii.gitbook.io/learn-go-with-tests/ I learned Rust through a book called "From JavaScript to Rust" https://github.com/vinodotdev/node-to-rust/releases/download/v1/from-javascript-to-rust.pdf https://github.com/vinodotdev/node-to-rust/releases/download... The thing that stood out the most to me while learning these was their focus on composition over inheritance. Even though I really like C-based languages, I have never liked the inheritance push from the 90s-2000s. I really like some of the things in Go, but overall I felt I just didn't need it. .NET, Java, etc are more mature with comparable or better capabilities across the board. It's just hard for me to justify Go outside of stylistic preference. I really, really like Rust but ever since learning it almost 2 years ago, I still have not found a single use case for it. It's partially the maturity of the competition, but it's also that even in HPC, ML/DL, etc I've done just fine with the "legacy" stack. I would love to hear from people what their thoughts are on this. What are some scenarios where you see these languages thriving? What makes you want to use them? What's the best use case? Would love to evolve my thinking.

mongol 3y ago
I don't think Java has better capabilities across the board compared to Go. Go's ability to be compiled to a single executable is a strength that Java does not have. I learned Go after reading a post on HN about someone that used Go as a strong tool language, instead of shell script. I partly agree with that, and Java is not that either.
- barelysapient 3y ago
  100% this. Not worrying about the runtime environment is a huge improvement. And with go embed[1], that single binary can be literally _everything_ needed by the application. Even non-go stuff can be embedded, like for example, a compiled React application. [1] https://pkg.go.dev/embed https://pkg.go.dev/embed
  - closeparen 3y ago
    That's important for CLIs. As the server-side deployment ecosystem has moved towards bundling and isolating dependencies at the OS level (ironically driven by Go projects Docker and Kubernetes) it's mattered less for backend applications. You can just SCP a Go binary around, just like you could always SCP JARs around, but a shop trendy enough to be using Go is unlikely to be doing that.
    - barelysapient 3y ago
      True, but SCPing a JAR around still requires a JRE of some sort of another and all that entails. Sure, containerization helps that but, in turn, it too is another dependency in the eventual execution. Long term, I think static binaries win, probably due to advances in WASI/WASM; where the whole execution stack (as we think of it today) is thrown away and replaced.
    - vb-8448 3y ago
      > That's important for CLIs Not just CLIs, think about prometheus node_exporter or any kind of agent you need to install on a server or deploy to people's workstations or to external customers where you don't have any kind of control. Single binary, it's definitively one of the killer feature of go.
- riku_iki 3y ago
  > to be compiled to a single executable is a strength that Java does not have I think this is very outdated claim: https://www.graalvm.org/ https://www.graalvm.org/
  - Thaxll 3y ago
    GraalVM is not what you think it is, especially because it's neither easy to use or a drop in replacement. Major stuff does not work with it.
riku_iki 3y ago
> but it's also that even in HPC, ML/DL, etc I've done just fine with the "legacy" stack. I think JVM specifically has many design issues which allows rust to squeeze good extra mile compared to JVM hpc solution.

mongol 3y ago

I don't think Java has better capabilities across the board compared to Go. Go's ability to be compiled to a single executable is a strength that Java does not have. I learned Go after reading a post on HN about someone that used Go as a strong tool language, instead of shell script. I partly agree with that, and Java is not that either.

barelysapient 3y ago
100% this. Not worrying about the runtime environment is a huge improvement. And with go embed[1], that single binary can be literally _everything_ needed by the application. Even non-go stuff can be embedded, like for example, a compiled React application. [1] https://pkg.go.dev/embed https://pkg.go.dev/embed
- closeparen 3y ago
  That's important for CLIs. As the server-side deployment ecosystem has moved towards bundling and isolating dependencies at the OS level (ironically driven by Go projects Docker and Kubernetes) it's mattered less for backend applications. You can just SCP a Go binary around, just like you could always SCP JARs around, but a shop trendy enough to be using Go is unlikely to be doing that.
  - barelysapient 3y ago
    True, but SCPing a JAR around still requires a JRE of some sort of another and all that entails. Sure, containerization helps that but, in turn, it too is another dependency in the eventual execution. Long term, I think static binaries win, probably due to advances in WASI/WASM; where the whole execution stack (as we think of it today) is thrown away and replaced.
  - vb-8448 3y ago
    > That's important for CLIs Not just CLIs, think about prometheus node_exporter or any kind of agent you need to install on a server or deploy to people's workstations or to external customers where you don't have any kind of control. Single binary, it's definitively one of the killer feature of go.
riku_iki 3y ago
> to be compiled to a single executable is a strength that Java does not have I think this is very outdated claim: https://www.graalvm.org/ https://www.graalvm.org/
- Thaxll 3y ago
  GraalVM is not what you think it is, especially because it's neither easy to use or a drop in replacement. Major stuff does not work with it.

riku_iki 3y ago

> but it's also that even in HPC, ML/DL, etc I've done just fine with the "legacy" stack. I think JVM specifically has many design issues which allows rust to squeeze good extra mile compared to JVM hpc solution.