-
// handle unexported go stdlib error, XXX fix after https://github.com/golang/go/issues/35234
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
-
Features such as type unions. The topic of this conversation.
> Why are we not using OCaml or standardML or even F# (which I tend to look favorably on) more widely then?
In my opinion there are a number of factors. I have most experience with OCaml, so on that:
1. Terrible Windows support.
2. Poor documentation.
3. An obsession with linked lists and recursion, which are great from a theoretical point of view, but abysmal from a performance point of view (and also simplicity IMO).
4. Poor syntax. The dearth of brackets and semicolons makes it very hard to visually parse. Something as simple as mismatched brackets can be very frustrating to resolve. The insistence on (a -> b -> c -> d) style function types is unnecessarily confusing. Generally when there has been a choice between academic cleverness and accessibility they've always chosen cleverness.
5. Global type inference is pretty clearly a mistake at this point.
IMO part of the reason Rust is so successful is that it has taken a lot of the very good ideas from ML and basically fixed all of the above issues.
Standard accessible C style syntax, but expression based and with proper ML style types. Fantastic documentation and Windows support. No linked lists to be seen.
It's such a compelling design someone copied it for Go: https://borgo-lang.github.io/