That would get rid of the "panic: runtime error: invalid memory address or nil pointer dereference" errors.
https://wakatime.com/blog/48-go-desperately-needs-nil-safe-t...
… and pattern matching. Maybe just some extensions for `switch`.
… and one of the `try` proposals.
That having been said… I do appreciate that Go has gotten where it is today by being radically simple, and that a lot of extreme care needs to be done to add new features to the language. It’s hard to draw a firm line in the sand. I feel like all of these features would work great together, though; it’d enable Go to do something like `Result` in Rust with few language-level changes.
I even remain somewhat skeptical about generics, but I am hopeful.
Go's proponents think it's okay to be a bit less powerful so that there is only 1 maybe 2 ways to do something. This makes code at different companies more similar.
It also mean that a new grad can join the team, read the code, copy it, modify it some, and it's pretty much right. A staff SWE and a new grad will right very similar code in Go. In C++ it's anyone's guess how similar their code will be.
I don't buy that a staff SWE and a new grad will write very similar code in Go.
As far as simple language. It is possible to design simple languages that are very expressive, Lisp and Erlang come to mind.
> … and pattern matching. Maybe just some extensions for `switch`.
Go has type switches which are… ok. If it were possible to “close up” interfaces and type switches took that in account (match completeness) you’d be done about done, you would not have the structural / patterned unpacking but that’s probably less of a concern.
That is complete nonsense.
The ability to create an open set of types is powerful, so is the ability to create a closed set of types, and they are not exclusive.
But go currently has only one of the two, which significantly limits its expressivity and type safety.
there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language.
If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive
here, have fun. You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess. You know everything! I am but a simple blubbite, too dim, too dim to get it.
Yes, the hilarious arrogance of… taking in account useful things that work?
> there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language.
Literally the exact same statement could be made about generics.
> If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong.
Wonderfully missing the point again.
> You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess.
Oh boy, ain’t that one for Principal.
> You know everything!
You’re the person declaring sum types useless in the face of decades of evidence and completely incapable of handling the idea of disagreement.
> I am but a simple blubbite, too dim, too dim to get it.
I see you don’t understand the blub paradox either.
I don’t hate Scala and I’ve even written a few PRs in Scala, but I have had trouble picking it up for actual projects.
Go is extremely pragmatic and often favors clarity in how code will execute and simplicity in syntax and grammar. It’s basically a GC’d successor to C in many regards. It eschews classes for interface-based polymorphism, it compiles and runs code very fast, and above all, I’ve found it easy and rewarding to pick up.
I don’t want all of the expressiveness of Scala. Just a bit more than Go has today. Not much more.
But that's already possible, just declare arguments and return values as values instead of references. I mean you'll get the zero value if you don't use those functions properly, but those won't cause nil pointer dereference errors.
I mean, it's a tradeoff between performance and developer competency. To be harsh, I think nil pointer dereferences are developer error, not a flaw in the language.