Comment by throwaway894345 | Hacker News Reader

Comment by throwaway894345 | Hacker News Reader

Parent Full thread

throwaway894345

Obviously this is subjective, but for my money I use Go for everything where development velocity matters and Rust for everything where performance and/or safety are paramount. I steer clear of VM and interpreted languages because true first-class support for statically linked native code is really hard to beat (and all of the "but you can AOT/statically-link Java/C#/etc!" promises seem to come with significant hidden caveats that you only run into after considerable investment).

Yeah, I know everyone hates on Go for its type system and because Rob Pike called it a systems language once (although the idea that OCaml is a systems language while Go isn't boggles the mind), but it's honestly so much more productive than any other language I've used. I also tried hard to like OCaml but the tooling was crumby and integrating libraries which used different standard libraries or async libraries or etc was painful. The ecosystem was also quite a lot smaller and important libraries were missing or low quality. While the Go community has its own problems, the OCaml community was positively toxic (if you have a problem for which there isn't a pat solution, then what you're trying to do is stupid and if it wasn't stupid then Jane Street would have solved it already).

While an ML type system is certainly nice to have, it turns out there are a lot of factors that matter more for practical software development, and if you're missing out on these fundamentals, the best type system in the world won't save you (and I posit that Go excels in these fundamentals even if it lacks an ML type system). I understand that this will not be a popular sentiment in a thread about F#.

I find it's very productive to write the production code in Go, but very labor-intensive to achieve adequate test coverage over the error return branches.

Of course not every organization needs this, but many people will find B2B customers, regulators, due diligence people, etc. who are interested in the coverage metric as an indicator of quality. If you write the same tests as you would for another language, your line coverage will suck.

That’s a real bummer that anyone seriously cares about that metric, or that they think line coverage between different languages should be comparable. Insane.

I really like ML-likes, but I feel the same way about Go. I hoped for some time that a equivalent of F# would appear for Go and gain a bit of traction, as I really like algebraic data types, immutability by default and a few map/filter/reduce from time to time, but sadly that didn't happen. It's really frustrating because sum types and pattern matching would have been a good alternative to if err != nil that could be cheked by the compiler, and the language already has a more powerful switch. On the other hand, the language is nice to use, the tooling is good, and popular enough to usually have what you need.

Yep, fully agree. Unlike many MLs, Go nails syntax, tooling, runtime, ecosystem, standard library, etc but the type system could be better. In my opinion there's space for a "Rust with GC", but every time I say this the OCaml and F# people come out of the woodwork to evangelize their languages but those languages miss the mark in many important respects.

I don't fully agree about syntax. I think Go should have used the ML-style name: type. First this makes things easier to read, and second it makes things more coherant. When you declare a variable, you do either name: type = value, or name := value. This way, when you remove the type, you just fuse : and =. That's a small nitpick though. For the rest I agree.

> In my opinion there's space for a "Rust with GC", but every time I say this the OCaml and F# people come out of the woodwork to evangelize their languages but those languages miss the mark in many important respects.

I fully agree with this, Rust with a GC is what I've been looking for too. However as you said, F# and OCaml don't really fit the bill. Let's hope we can have something like that in the next 10 years!

Agreed that syntax isn't perfect (and I'd be fine with `name: type` although the current `name type` doesn't chafe me much), but it's a lot more approachable to a much wider audience (and IMO just easier to read for almost anyone regardless of background) than OCaml or Haskel or F#.

> Let's hope we can have something like that in the next 10 years!

Agreed. :)

If Google chose StandardML instead of Go, SML would win hands down in every way. Not many people or companies have tens to hundreds of millions sitting around to build a new language and ecosystem.

Not, that this matters much, probably a technicality

Dart is the language google is in a way selling, as the dev language for their new mobile platform flutter

Go, just happened, most available online material suggest that Go did really just happen

Rob pike have his taste, and build Go, in my opinion in the spirit of C, a pragmatic rather than theoretic effort

Go success, I think was not something that google really pushed for, it just happened because it seem many developer seem to prefer to use simpler languages, and deal with complexity "of using" a language, rather than learn a complex language and deal with the complexity "of learning" a language, developers are more engineers and craftsmen, rather than scientist

This is what people often regurgitates when talking about Go but I don't agree with most of it. "simple" is relative. Clojure people love to talk about simplicity too, but for some reason I imagine most of them wouldn't agree with Go programmers on what "simple" is. SML has plenty of "simple" parts too. Sum types checked by the compiler instead of having to think about "if err != nil"? That's what I call a pragmatic choice. Immutability in most cases? Again, a pragmatic choice. Option instead of checking for nil, and having the compiler do your work? Again, a pragmatic choice. If we were talking about Haskell, I would agree, Haskellers get easily excited by academic ideas. But things like algebraic data types, pattern matching and immutability are craftsmen tool. As a proof, you can see most of these ideas in Go, but they're half-formed. Returning a result and an error is a result type, but you have to do everything manually. The "switch on steroids" in Go is a half attempt at doing serious pattern matching, type switches are a proof of that. The name of the variable is here before the name of the type, but the ":" is not here.

I'm not saying we should throw everything from Go away and all start programming in SML. I'm saying that people that worked on Go were too dogmatic to include pragmatic features that would have made it a better language. You can see this easily, from Rob Pike claiming that taxonomy is the least interesting kind of science or something like that, and thus a more useful type system is unnecessary. This is dogma.

Go didn't "just happen", Go had the support of Google to write a high quality and extensive standard library, and all the tooling around it. That takes a tremendous amount of time and money. SML or OCaml doesn't have that, so it's harder for them to compete. I assure you that if Go looked like a garbage collected Rust, while still having all the great tooling, the easy concurrency, the standard library and all that good stuff, its success would have been the same if not better.

Serious question: how much better is statically-compiled native code compared to a well-tested runtime like the JVM? What would make you decide to universally eschew the latter? Ease of deployment?

Reply on news.ycombinator.com