I develop in Go every day and it's by far the worst language I've ever used.
Having to explicitly handle every type of error immediately without any support for deferring, encapsulating, chaining, manipulating, transforming etc is antiquated and tiresome.
Rust has Option and Result types and all of the niceties along with it.
All your complains are doable, I mean you work with Go daily and you don't know how to wrap errors?
https://pkg.go.dev/errors
Rust has all those nice things and yet you still need to import two of the most popular error lib to work decently.
That is not remotely comparable to proper Option/Result types.
And in Rust you don't need to import anything.
hear me out. golang quality stdlib, with Option & Result types from haskell or rust.
The dream. Someone posted this, which is designed along these lines, here not long ago. https://github.com/borgo-lang/borgo
Don't forget enums. And lets get rid of the insane := syntax that makes no sense when basically every function is returning 2 values. Not to mention shadowing bugs like this:
[dead]
Native Option/Result types + algebraic data types would solve quite a few complaints I have about Go
It would solve many of my complaints as well.
But, to be honest to myself, I don't think anything will be too different in my day-to-day programming, nor that I would produce better code with less bugs.
Adts eliminate certain kinds of bugs like nil pointer dereferencing, and, if you model your types correctly, makes invalid states unrepresentable
Sounds like Scala Native: https://scala-native.org/en/stable
V is Go with Option/Result, enums, ORM etc:
https://vlang.io/compare#go
V is half-baked in many ways and shouldn't be considered for anything serious.
Odin[1] is a better alternative in the niche modern language space, and also shares many design choices with Go. It has operators like `or_return` and union types like `Maybe(T)`, which can in practice be used for improved error handling.
Though I honestly don't find Go lacking in this sense. The syntax is a bit verbose, but it forces you to think about how to handle every error, which is a good thing. There are far more important design topics worth discussing than this. Go usually makes more correct trade-offs where they matter compared to other languages, and most of the criticism it receives is unwarranted IMO.
[1]: https://odin-lang.org/docs/overview/
Odin can be considered even more "half-baked". It is not a mainstream "corporate approved" language either. It's one thing to suggest sticking with Go or using C# as an alternative, it is another thing to suggest languages like Odin, Zig, or some other almost unknown like C3. At least V has a place at the table, with being an actual useful alternative to Go. Has a significant following and hardcore fans, because V gives them the missing features that many Go users have been begging or looking for (enums, sum types, immutability, easier C interop...). Same can kind of be said for Zig, with having a significant following, and pushing it as an alternative compiler for C.
Anyone taking a serious look at Odin or C3 (strangely morphed from C2 into being more Jai-like or Odin-like), will know they are both no where near to being production ready or 1.0 (many years far away), despite both being old. Odin has less of a following, less contributors, minimal documentation, no books on Amazon, and many of its good ideals were admittedly "borrowed" straight from Jai. Many consider Odin a Jai-clone, where it would be better to wait on the "real McCoy", which would be Jon Blow's releasing of Jai to the general public. Jai fans[1] are about as hardcore as it gets. When Jai is finally released, nearly everybody will forget about Odin or C3 (even tsoding suggested dropping it for a public release of Jai), and very few people even know about them as it is. Just about whatever Odin (or C3) wanted or aims to do, Jai does.
[1]: https://jamesoswald.dev/posts/jai-1/ (Simplicity, Jai, and Joy)
It's not half baked lol.
Ah, you're the author. :D
I mean, kudos for sticking to it over the years in spite of the mountain of criticism, but I personally confirmed a few months ago that it's indeed half-baked. :) Certain features work sometimes, but often fail in cryptic ways. The documentation is a mixture of missing, outdated, wrong or aspirational. I've forgotten the specifics, but I remember being frustrated by it relatively quickly, and abandoning it altogether in less than a week. Good luck with it anyway!
That has been around for a long time now. V lang[1], child of Go and Rust, has them. That, and things like enums, sum types, etc...
[1]: vlang.io
Completely agree…
Forgetting to check any given err value leads to potentially undefined behaviour.