Typescript has something resembling nil as inherited from Javascript, so presumably that's what you are referring to. C and Javascript are the most widely used languages in existence. Clearly they weren't kneecapped. It mightn't be to your preference, but "I don't like it" would be an atypical use for the word "kneecap".

There is a stronger case to be made for the other two. Calling GOPATH a design mistake is a stretch as it was perfectly suited to use within Google, but it didn't fit the typical solo developer's environment. Lack of generics made writing certain types of code difficult. You could be convincing in suggesting that Go did end up being used less than it otherwise would have because of those choices.

iota? It's just a construct that generates numbers (an enum). How does that kneecap anything? If it really bothers you, you can manually number the values by hand instead. Why would anyone reject a language because it allows you to optionally choose to have the compiler assign numbers automatically instead of forcing you to do it manually? The answer is nobody. In fact, most popular languages have something equivalent to iota.

▲

stouset 5 hours ago | parent [-]

Nil exists in C and is widely considered to be a massive mistake in the language. An understandable one at the time, but a mistake nonetheless.

Thus “go borrowed it from C, therefore it can’t have been a mistake” is a pretty lame take. The whole point of a new language is to make improvements on what’s out there already. Go missed an opportunity to fix one of C’s most notorious mistakes. So yes, they kneecapped themselves by forcing all of the users of Go to continue dealing with this well-known footgun.

Does it mean Go isn’t popular? Of course not. C was popular. PHP was popular. JavaScript is popular. Go is popular. This is always in spite of their faults. But Go could have been better.

▲

9rx 5 hours ago | parent [-]

> Nil exists in C and is widely considered to be a massive mistake in the language.

You're almost there, but it is wildly considered to be massive mistake in context of arrays. C has weird array semantics that are confusing and hard to get right, even for seasoned developers. That is where NULL comes to bite people time and time again. Go did not inherit C's arrays. Neither did Javascript. They go out of their way to avoid what C did. In Go, you can come close to the same semantics if you use the unsafe package, but take note the name.

Yes, they still have nil, but the scope is tightly constrained and while it is technically possible to misuse, you have to try pretty hard to do so. There are many other things that are more likely to end up being misused. Those would be the more massive mistakes.

> But Go could have been better.

Obviously. Every language ever created can be better.

▲

stouset 5 hours ago | parent [-]

> You're almost there, but it is wildly considered to be massive mistake in context of arrays.

From Tony Hoare: "I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object-oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years."

Odd that he wouldn't mention the word "array" anywhere in that quote.

> Yes, they still have nil, but the scope is tightly constrained and while it is technically possible to misuse, you have to try pretty hard to do so.

Like by not remembering to check if a pointer is nil? Or actually comparing one typed nil to a different typed nil?

> Obviously. Every language ever created can be better.

Only one of us is arguing that reimplementing C’s mistakes is actually a good thing.

▲

9rx 5 hours ago | parent [-]

> Like by not remembering to check if a pointer is nil?

Rule of thumb is to not introduce values that aren't valid. Equally, don't put in -1 for an age value, even if the language allows you to. You might later forget to validate that the age value is valid.

Yes, mistakes are possible, but these types of mistakes are pretty rare. There is some value in eliminating the possibility of those mistakes, sure, but we cannot pretend that it comes cost-free. There is good reason why almost nobody uses Rocq.

> Or actually comparing one typed nil to a different typed nil?

This is something that is likely to confuse, but not a facet of nil. It is related to interfaces. Let's not flail around like one of those wacky blow up things at the used auto lot.

▲

stouset 3 hours ago | parent [-]

Ah the good old “just be a perfect programmer and you won’t run into any issues” argument. Haven’t heard that one in awhile.

	▲	9rx 2 hours ago \| parent [-]
		If only you had made it to the second paragraph. Hey, at least we can now understand why you have such a hard time with nil, so that's something.