11–20 of 178 posts
Why not both? I spend most of my time in Go, but learning other languages is always on my radar, most recently OCaml. It's just fun and helps keep me spry, if that makes sense.
- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you'll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don't have to face Rust async/thread combo hell. - Hard problems that have concurrency, performance issues, or have to be high…
> Rust is overhyped
People are excited about Rust! Not sure why this is a reason you _shouldn't_ use the language.
> Rust projects decay
The text doesn't match the headline here; Rust takes backwards compatibility very seriously, and rust code I wrote in 2016 against Rust 1.10 still compiles with Rust 1.72 in 2023.
> Rust is still in beta
Mentions missing async traits, which is legitimately annoying, but the workaround with the async_trait crate works in practice
> The standard library is anemic
This is a tradeoff; big standard libraries become graveyards over time (the classic article on this: https://leancrew.com/all-this/2012/04/where-modules-go-to-di...). How long was Python stuck with a terrible HTTP client because that was the one in the standard library? In Rust we have an incredible, state of the art regex library because it's a separate crate and is allowed to evolve.
> async is hard
Rust's async is hard to get started with; it's a barrier to get over like learning the borrow checker and lifetime system. But once you do I've found it productive and incredibly performant.
--
Overall, I don't think that Rust is the right solution to all problems. Rust makes you think about everything you're doing, the ways in which your programs use resources, and every possible class of errors. This is incredibly useful for writing fast and correct software, but will be overhead for people who just want to move fast.
I also think that static memory management is not the right tradeoff for most application software, although a GC language with Rust's ergonomics and crate ecosystem would be amazing for those use cases.
I'd personally always choose Java over Go especially given recent developments like ZGC, GraalVM, and Project Loom which essentially makes Java a better Go.
It’s missing a subheading for “anytime you do not want a garbage collector” which is true for almost anything real-time / graphical etc
It compiles faster but that is about it. Which is a good thing too because it's verbose AF and heavily reliant on code generation even after generics shipped so that compiler lines/s actually matters.
The only knock you can put on Java for reliability is null-safety but lets be real, nil pointers, bad slice initalisation, etc are 10x worse in Go especially these days with @NotNull and powerful editors like IDEA stopping you from doing dumb things. Or simply using Kotlin which is non-nullable by default.
That and all the things Go is good at Java is simply better at. (especially once Java 21 ships in the next few days).
- Low pause GC? ZGC has Go beat, not just on pause times but on throughput and heap size scalability up into the terabytes. - Non-blocking code with synchronous coding style? Virtual Threads are much much better than goroutines. - Channels? ArrayDeque and friends are faster and have a lower learning curve.
Maybe the only area I think I prefer Go to JVM-land is the good parts of the stdlib. Go has lots of shit stdlib cough collections cough but there are some real gems. Namely the x509 and ASN.1 libraries are absolutely top notch.
Learning curve is also lower ofcourse, it's a very very simple language which is good for beginners and those taking their first steps out of JS/Ruby/Python into static types, pointers, etc.
Anyways, my real point was Java is easily faster and more reliable than Go and it seems pretty insane to reach the opposite conclusion if you have been on top of developments in both languages.
- Webcrap - use Go. The arguments for Go for that use case is that 1) Google provides the libraries for most web back-end things you'll need, and since Google uses those libraries internally, even the obscure cases have been exercised, and 2) Goroutines are both low-cost and can block, so you don't have to face Rust async/thread combo hell. - Hard problems that have concurrency, performance issues, or have to be high…
Highly recommend sqlc.dev, goa.design, gokit.io, gql-gen, bind, and all the other code-generation libraries in Go.
Don't write all that code by hand. Figure out your domain objects, queries, revolvers, etc.., generate the code, then deploy it.