If you’re a fan, why?
If you’re not fussed on it, how comes?
2 Likes
To put it very concisely, these are I believe the two most important advantages of static typing:
- It removes whole class of potential bugs. Essentially all the
undefined is not a function-style bugs are impossible in static type-systems. This means easier testing but also that less ‘defensive programming’ is required. - Knowing that something is guaranteed to e.g. always be an integer allows for extra optimizations to happen.
7 Likes
In addition to what @Qqwy said :
- The sum types – like
OptionandResultin Rust – allow for, and mandate, exhaustive pattern matching which is missing in e.g. Elixir, and that leads to a lot of code being written exclusively for the happy path.
6 Likes
I’m OK with static-typing in languages which have type inference, like Crystal, Go and Rust, etc.
2 Likes
I find this an interesting statement as in my mind Go is a language with a painful lack of inference, types are required everywhere.
Here’s a fully type safe program in Elm:
main =
let
double a = a + a
twice f a = f (f a)
in
{ name = ("Louis", "Pilfold")
, score = twice double 50
}
And here’s the same program written in Go:
type Name struct{
First string
Last string
}
type Person struct{
Name Name
Score int
}
func Main() Person {
double := func(a int) int {
return a + a
}
twice := func(f func(int) int, x int) int {
return f(f(x))
}
return Person{
Name: Name{
"Louis",
"Pilfold",
},
score: twice(double, 50),
}
}
The Go version requires many more type annotations, and I would argue that many of them (especially the annotations on anonymous functions) provide no technical benefit at all. If anything they’ll make the code very slightly slower to compile as they need to perform inference inside the compiler to assert that they are correct.
To make matters worse, the Go version isn’t type safe (it lacks null checking and many other features), and it is less flexible (the double function only works with ints).
I like many things about Go, but in my opinion its type system leaves an awful lot to be desired.
6 Likes
I’ve used Go on and off several times in the last 5 years. I like the authors’ dedication and opinionated approach even if I disagree with some of their choices. And I’ve found that, with a combination of resolve and discipline, you could actually produce pretty solid and performant software with it.
That being said, if you’re going to have to heavily utilize resolve and discipline then why use Go at all? You might as well code in C++ and will likely achieve more with it.
Stricter type systems (OCaml, Haskell, Rust) slap you until you get the program right – to a certain extent of course; they don’t guarantee lack of bugs.
Golang in my eyes is mostly shaping up to be a natively compiled Python or Java… You have to code super defensively and that’s a recipe for disaster, especially in big teams.
5 Likes
That’s always been OCaml in my eyes. Native compiled with C speed, fully strongly typed but with almost no type declarations (it’s type inference is extreme). And has similar performance characteristics as Python (GIL, though to be removed in the future, extremely fast C bindings, etc…)
1 Like
Even though type inference in go is very limited, I still like it, and I think they deliberately made it so, to keep the language simple.
2 Likes
Fair I suppose but then OCaml has much stricter type system compared to Go, so making an analogy with Python feels a bit weird?
2 Likes
I like the goal of being a simple language but I think Elm is a good example of how a more sound type system can be used to make the language even simpler! With Elm there are no exceptions to the rules of the type system, but Go’s rules have many exceptions and special cases.
For example, there are no generics, except for slices, maps, and channels.
4 Likes
When I was learning Elm, it took some time and effort even I already knew a bunch of imperative languages and one functional language (Elixir), but two or three years before that when I was learning Go, it didn’t take any effort, 'A tour of Go' and ‘Go by example’ was enough to get me started. For people who started with functional languages, that might be the other way around.
A very good point.
2 Likes
A very classic game of tradeoffs. Do we pick:
- A language that’s easy to start with but we’ll struggle being productive with it down the line, OR
- A language that’s hard to pick up and hard to even get the basics down which will make our long-term productivity much bigger compared to the language above.
At one point it becomes a “pick your poison” kind of a personal stroke thing. 
5 Likes
These kind of personal anecdotes have to always be taken with a pinch of salt, they represent a single person’s experience and that may not be representative of anything specific.
For example, my experience is different to yours. When I was learning Elm it didn’t take any effort. I read “The Elm Guide”, and that was all I needed to feel confident working in Elm and I immediately started using it in production.
Does that mean that Elm is better than Go for learning? Or does your story mean that Go is better than Elm for learning? No, it just means we have different experiences learning these languages, and I would wager this is because of our different backgrounds. You’re familiar with many imperative languages and 1 functional language, while I’m familiar with many functional languages and much fewer imperative languages. Generally I find imperative languages more difficult to learn!
I think overall both Go and Elm do an excellent job of being easy to learn, and I think other languages could learn a lot from them
6 Likes
OCaml is about as succinct as Python, which is far FAR more so than golang, and Python has recently gained static typing that is far superior to golang as well (though you need another tool to verify correctness as the compiler itself doesn’t). ^.^
Elm has lots of exceptions to its static typing system that has failed correctness on multiple cases. I used to keep a list but since I’ve finished purging elm from my work I haven’t kept up. But it basically has fake typeclasses that a user can’t expand and are so misimplemented that you can generate bad code with them; it’s TCO generation fails in multiple situations (not fails as in doesn’t TCO, but rather that it generates broken code); its equality isn’t commutative in some cases (that was a fun bug…); and so much more. Elm I really wanted to like, but it’s a very poorly designed language in my eyes, and that was after using it for over a year in production.
I still think OCaml is far better at those, it’s super easy to pick up but also very safe. If only the multi-core branch would finish and be merged in full, lol.
For note, the multi-core branch does have large swaths merged into core every version as each part is tested in depth. OCaml is such a language that everything is excessively tested and verified before it enters the mainstream.
I can find my Elm-broken list again if someone is actually curious. ^.^
But if you find Elm easy I still think you’d find OCaml even easier, ^.^
3 Likes
Ah yes! The horrible special type classes. I had successfully removed them from my memory!
2 Likes
Things go back and forth.
Coming from C and Java 25 years ago and swapping over to dynamic typing with python and later erlang. The speed of development with dynamic languages back then in comparison to the static alternatives it made sense to go dynamic.
Now the pendulum is swinging back to stronger and better type systems (MLs, rust) which have improved tooling and makes development faster and safer than with the traditional type systems. Now the speed of development is on par with dynamic alternatives (in most but a few domains) but you also have a compiler helping you avoid errors.
There are better and worse examples of static and dynamic typing.
I never feel safe writing C.
I never feel safe writing Php/javascript
I feel very safe writing Rust/Ocaml
I feel safe writing erlang
I don’t think go makes sense from a type-system point of view. It is like a mix of C and a dynamic languages and I don’t like the trade-offs it gives me. My point is that people who likes go are either coming from python/ruby or from c/java, which makes sense as go is somewhere in between.
3 Likes