5 ms·

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 safet

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#.

Zababa 5y ago
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.
- throwaway894345 5y ago
  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.
  - Zababa 5y ago
    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!
    - throwaway894345 5y ago
      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. :)
  - hajile 5y ago
    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.
    - 5y ago
closeparen 5y ago
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.
- throwaway894345 5y ago
  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.
nerdponx 5y ago
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?

Zababa 5y ago

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.

throwaway894345 5y ago
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.
- Zababa 5y ago
  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!
  - throwaway894345 5y ago
    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. :)
- hajile 5y ago
  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.
  - 5y ago

closeparen 5y ago

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.

throwaway894345 5y ago
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.

nerdponx 5y ago

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?