[ndreas]

This is the core of the problem. Of course you can learn the language in a weekend, but you're bound to make the same mistakes developers have been doing for decades.

This may be ok, as you say, if you allow errors here and there because you are fine dealing with those problems. But at the other end, it may be a user that is affected by the error. Which may be ok as well, but why should it be? We lament the quality of software all the time.

Compare this to other engineering fields: unless you study the knowledge of those who came before you may not even be allowed to practice in the field. I would not want to use a bridge built by someone who learned bridge building in a weekend.

Software is different though, it's rarely a matter of life or death. Given that, maybe it's ok to not have the highest quality in mind, because the benefit of productivity far outweighs the alternative.

I'm torn.

[danenania]

Go is just making a certain set of tradeoffs. If you try to fix all the "mistakes developers have been doing for decades", you get Rust. And considering that Rust is already Rust, there is not much point in trying to make Go another Rust.

The line has to be drawn somewhere. I think everyone has certain things they'd put on the other side of that line, and strict nils are probably at the top of the list for many, but overall it's good that the Go team is stubborn about not adding new stuff. If they weren't, maybe there would be better nil handling, better error handling, etc. but compiles would also get slower and the potential for over-engineering, which Go now discourages quite effectively, would increase. At a high level, keeping Go a simple, pragmatic language with a fast compiler is more important than any particular language feature.

[tw061023]

The argument is that Go is making a _wrong_ set of trade-offs.

It was designed, specifically, as per Rob Pike, for _bad_ developers. Developers who couldn't be productive at Google because they weren't properly taught at unis [0].

Then it caught momentum and then here we are, discussing a bad language designed for bad developers as if there is nothing better we can do with our lives.

[0] https://news.ycombinator.com/item?id=16143918

[xyzzy_plugh]

If you think developers at Google are bad and weren't taught fundamentals then we live in different universes.

Pike's point is that peak PLT is too lofty to be productive or even useful for folks who are actually technically competent and literate relative to the rest of the industry. No one will get anything done if they're spending all their time teasing an advanced type system into inferring the required program.

[eviks]

How does it apply to this specific issue? What is so lofty and unproductive in proper null handling?

[xyzzy_plugh]

I did not suggest it applies to this specific issue, I replied to a comment containing inflammatory remarks, but I'll bite: To answer that you need to first produce the minimum change to the language that provides this functionality.

A solution might be optionals, which might require sum types, which might require generics (which Go just learned), which most definitely requires a more complex type system, which almost certainly involves longer compiler times.

Is that all worth it? I don't know. The Go team certainly didn't think so.

Languages that I'm aware of that do solve this are Scala, Rust, Kotlin to some extent, Haskell... languages which do not have a reputation of being stable, easy to learn, easy to read and understand, compile quickly, etc.

[eviks]

Thanks, I understand it was more a general inflammatory conversation, that's why I didn't like it and was wondering whether it could be grounded to this specific topic. Although I had in mind what "teasing an advanced type system" would be needed in this case that would lead to a loss of productivity, slower compliation is also relevant.

Though the reputation for those other languages mainly stem from their embrace of way more advanced concepts rather than null handling via optionals, I think that this specific concept makes it easier to learn/read/understand (though not compile quicker)

[richbell]

> ...languages which do not have a reputation of being stable, easy to learn, easy to read and understand, compile quickly, etc.

Kotlin is definitely the odd man out in that list.

[usrbinbash]

Nothing, the question is whether it is important enough to be included in the language.

Just because person A thinks this is hugely important, doesn't mean person B has to agree, or that B is a bad developer.

[usrbinbash]

> It was designed, specifically, as per Rob Pike, for _bad_ developers.

Mind showing us the source for that?

Go wasn't made for incompetent developers. I'm fairly certain that people who land a job as devs at Google are pretty competent.

Go was made to facilitate rapid onboarding, easy digestion of large codebases, and working efficiently in large teams where people are guaranteed to have widely different educational backgrounds, experiences and ideas about programming.

That's why the language has to be simple, obvious, and be focused on readability. That's also why Go is strongly opinionated.

[thwora23__]

Here you go: https://www.youtube.com/watch?v=uwajp0g-bY4

I think Go could still work without completely neutering the type system.

Algebraic Data Types and pattern matching are not difficult... python already has them.

[munchler]

I don't think anyone is suggesting that Go should be like Rust. It's too late for that. We're suggesting that people should just use Rust (or Haskell, or F#, or any other robust functional programming language) instead.

[usrbinbash]

> We're suggesting that people should just use Rust (or Haskell, or F#, or any other robust functional programming language) instead.

And how well did that work out for Haskell?

https://gist.github.com/graninas/22ab535d2913311e47a742c70f1...

Just because one person thinks Functional Programming is the right way to do it, doesn't mean another person has to agree. The same goes for every paradigm, and language feature under the sun. Different people want different things, different projects have different needs.

No single language gets everything right, no single paradigm solves every problem, no feature is a "must have" in every language. A functional approach might be great or a productivity killer depending on the use case. A GC may be the best thing in the world or a performance nightmare. OOP may be a really good idea or a path to unmaintainable crap depending on the implementation.

There are no silver bullets.

The only thing that is ABSOLUTELY certain: When people get told "Our way is better, you should use our way", despite the fact that there are no silver bullets, people will resist. And that resistance can lead to languages vanishing into obscurity.

[tome]

> And how well did that work out for Haskell?

You know this post is speculative fiction, right? It's actually about what could kill Haskell, not what could kill Rust?

[usrbinbash]

> It's actually about what could kill Haskell, not what could kill Rust?

Here is the articles title: "What killed Haskell, could kill Rust, too"

So no, it's not about what could kill Haskell. In 2022, ~0.3% of all code pushed to github was Haskell. To put that number into perspective: vimscript was ~0.25%

[tome]

Yes, I can read the title thanks. The article is about Haskell. The first sentence makes it clear it's speculative fiction presented as if from the year 2030. The article draws a hypothetical analogy between what could happen to Rust in 2030 and what is contemporaneously happening to Haskell.