7 ms·
> That's unrelated to whether it has systematic problems. As is much of your post to be honest. Like, yeah, javascript is successful. Bash is successful. No one
by throwaway894345 3y ago
> That's unrelated to whether it has systematic problems. As is much of your post to be honest. Like, yeah, javascript is successful. Bash is successful. No one will argue that those languages don't have systematic problems.
Right, bash and js have pretty significant problems, but they remain popular because they were developed as exclusive languages for platforms which became wildly popular; essentially they benefit from monopolies and network effects in a way that Go never has. The fact that Go is a popular language and still rapidly growing indicates that its issues are relatively minor compared with its advantages over other candidates (e.g., Haskell).
> On the other hand, haskell is "complex and difficult" in terms of having a powerful type system. In my personal experience, I've found that haskell code has far fewer bugs than go code, and a large fraction of the bugs I encounter in go would not have been written in haskell or rust, in a language with a more powerful type system.
Granted, but in my experience those languages trade off a lot of productivity in order to reduce bugs, and that leaves me a whole lot of time to debug Go programs and achieve a similar degree of correctness. Moreover, I often spend so much of my energy thinking about the type system in Rust/Haskell that I make silly mistakes that the type system doesn't catch (I've written a static site generator in Go and then in Rust, and I wrote a bunch of URL/filepath handling bugs in the Rust version that weren't present in the Go version--despite the benefit of hindsight--because I was focusing so much on the type system). Rust also makes it a lot more painful to create and use new integer types compared to Go (e.g., you have to define a ton of traits and even then you still have to wrap integer literals in MyIntegerType::new(0) and so on), so I see a lot of code that just passes around u64s as identifiers for different resource types and it's super easy to use the wrong u64 to index into the wrong resource collection.
I'm not saying that Rust results in more bugs on balance (I don't think it does) but that Go wins overall for most ordinary application code (but not for systems code, or high performance code, or real time / mission critical code).