upvote

points

by gethly1 days ago |
comments
upvoteby phplovesong1 days ago|
[-]
Complexity does not equal language features. Sometimes simple is good, but sometimes simple just simply means more bugs in your code.

As a prime example, Go unwillingness to add even the most simple enum kind of type. Having enums (ADTs) with exhaustive pattern matching is NOT complex in any sense or form. It just takes away so, so many bugs you would normally see in production code.

One other low hanging fruit is the fact that zero values are in 90% of all cases not what the dev intended. Sure, the mantra goes "make them useful" but thats hard. How to you know if a value (int) was zero initialised, or if the user did in fact input zero as value. No matter, you will need to validate every one of these "zero values" if you want some sort of robustness.

reply
upvoteby flossly1 days ago|
parent|
next
[-]
Adding `null` to C was very simple to add. It added a lot of complexity that the language designer did not see coming (hence the billion dollar mistake he made on that).
reply
upvoteby phplovesong23 hours ago|
parent|
[-]
`NULL` was originally added to ALGOL back in 1965. C was not even a thing back then. It was obviously a bad choice to port NULL to C, one that ADTs would have perfectly modeled, without the billion dollar cost.

In fact C was built sometime around the early 70s, and at the same time the first MLs where also being developed. One added null, while the other added a better mechanism for "nothingness".

Bottom line is you cant compare "adding null" and adding a feature that is over 50 years old, one that is battle-tested thru generations, and still holds up.

Solid maths does no suffer bitrot.

reply
upvoteby 9rx20 hours ago|
parent|
prev|
[-]
> Go unwillingness to add even the most simple enum kind of type.

Go has enums, under the iota keyword. But I imagine you are really thinking of sum types. Technically Go has those too, but must always have a nil case, which violates what one really wants out of sum types in practice.

Trouble is that nobody has figured out how to implement sum types without a nil/zero case. That is why you haven't seen a more well-rounded construct for the feature yet. This is not an unwillingness from the Go team, it is more of a lack of expertise. Granted, it is an unwillingness from those like yourself who do have the expertise. What stops you from contributing?

> It just takes away so, so many bugs you would normally see in production code.

What bugs do you imagine are making it to production? Each pattern matched case has a behaviour that needs to be tested anyway, so if you missed a case your tests are going to blow up. The construct is useful enough that you don't need to oversell it on imagined hypotheticals.

reply