undefined

points

[-]

I'd say you already get like 70% of the benefit of a type system with just the basic "you can't pass an int where string is expected". Being able to define your own types based on the basic ones, like "type Email string", so it's no longer possible to pass a "string" where "Email" is expected gets you to 80%. Add Result and Optional types (or arguably just sum types if you prefer) and you're at 95%. Anything more and you're pushing into diminishing returns.

by hgomersall225 days ago|

parent|

[-]

Well it depends what you're doing. 95% is like, just your opinion man. The rust type system allows, in many cases, APIs that you cannot use wrongly, or are highly resistant to incorrect usage, but to do that requires careful thinking about. To be clear, such APIs are just as relevant internally to a project as externally if you want to design a system that is long term maintainable and robust and I would argue is the point when the type system starts to get really useful (rather than diminishing returns).

by rednafi224 days ago|

parent|

[-]

> The rust type system allows, in many cases, APIs that you cannot use wrongly, or are highly resistant to incorrect usage, but to do that requires careful thinking about

I need none of that guarantee and all of the compilation speed along with a language where juniors in my team can contribute quickly. Different problem space.

by bogeholm223 days ago|

parent|

prev|

[-]

While I agree with your analysis and points, my upvote was based entirely on the Lebowski reference

by ratorx225 days ago|

prev|

[-]

This might work for the types you create, but what about all the code written in the language that expects the “proper” structure?

> Types either represent the data or not

This definitely required, but is only really the first step. Where types get really useful is when you need to change them later on. The key aspects here are how easily you can change them, and how much the language tooling can help.

by IshKebab223 days ago|

prev|

[-]

That's not true. There's a spectrum of typing complexity all the way from TCL everything-is-a-string to formal languages like Lean where the types can prove all sorts of things.

As you go further towards formal verification you get:

* More accurate / tighter types. For example instead of `u8` you might have `range(0, 7)` or even a type representing all odd numbers.

* Better compile time detection of bugs. (Ultimately you are formally verifying the program.)

* Worse type errors. Eventually you're getting errors that are pretty much "couldn't prove the types are correct; try again".

* More difficulty satisfying the type checker. There's a reason formal verification of software isn't very popular.

So it's definitely true that "more obnoxious types" exist, but Go is very far from the obnoxious region. Even something like Rust is basically fine. I think you can even go a little into dependent types before they really start getting obnoxious.

TL;DR, he's just lazy and doesn't really care about bugs.

by throwawaymaths224 days ago|

prev|

[-]

> Types either represent the data correctly or not.

No. two types can represent the same payload, but one might be a simple structure, the other one could be three or twenty nested type template abstractions deep, and created by a proc macro so you can't chase down how it was made so easily.