Earlier quoted context omitted.
An Enum type has to be on the core Go team's radar by now. It's got to be tied with a try/catch block in terms of requested features at this point (now that we have generics).
No one wants try/catch/exception in Go.
Borgo is a statically typed language that compiles to Go
351–360 of 559 posts
Re: Borgo is a statically typed language that compiles to Go
#352Re: Borgo is a statically typed language that compiles to Go
#353Earlier quoted context omitted.
Yes, it's the ability to unwind the stack to an exception handler without having to propagate errors manually. Go programs end up doing the exact same thing as "try/catch around multiple lines" with functions that can return an error from any point, and every caller blindly propagating the error up the stack. The practice is so common that it's like semicolons in Java or C, it just becomes noise that you gloss over.
Go programs generally do not “blindly prepare the error up the stack”. I’ve been writing Go since 2011 and Python since 2008, and for the last ~decade I’ve been doing DevOps/SRE for a couple of places that were both Go and Python shops. Go programs are almost universally more diligent about error handling than Python programs. That doesn’t mean Go programs are fre from bugs, but there are far, far fewer of them in th…
Re: Borgo is a statically typed language that compiles to Go
#354Earlier quoted context omitted.
Because if err != nil { return err } repeated all over the place, is the epitome of productivity!
I would have to go through my comment history for exact numbers. In analyzing a real, production service written in Go where multiple dozens of contributors over hundreds of thousands of lines over several years, "naked" if-err-return-err made up less than 5% of error handling cases and less than 1% of total lines. Nearly every error handling case either wrapped specific context, emitted a log, and/or emitted a metri…
Plenty of The Go Way arguments apply to software we were writing from the dawn of computing until the 1990's, and there are plenty of reasons why, with exception of Go (pun intended), the industry has moved beyond that.
Re: Borgo is a statically typed language that compiles to Go
#355Earlier quoted context omitted.
Comments like this are what drives me away from Go; comments that enforce a particular belief about how or what features you should or should not use/introduce in your PL. Talking in absolutes is so far removed from a logical arguments and from good engineering. I would appreciate if anyone could recommend a language like Go (static, strong typed, not ancient, good tooling) with a friendly community, that won’t ostra…
I'd say Scala. It has its flaws, but the latest version (Scala 3) is really really good. The community is open to different styles of programming - from using it as a "better Java" to "pure functional programming like in Haskell".
Hilariously I was using a gen AI (phind) and asked it to generate some scala code and it no joke suggested the code in both implematic scala and in java style, and all you had to do is look at it and you could see java style was 1000X easier to read/maintain.
Re: Borgo is a statically typed language that compiles to Go
#356Earlier quoted context omitted.
> Go is a very opinionated language from it's inception. True. > We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. This is part of the story that Rob Pikes uses to justify how opinionated Go is, but it's a bit stupid given that most language do fine and I've never seen any debates about the code formatting after the very beginning of a project (where it's a…
Seriously, if you feel patronised by how someone designs a programming language, it might be best to move on. It's obviously not for you. Especially when you feel compelled to bad faith assumptions and ageism over it. For those who want to feel the wind of coding freedom blow through their hair, I can recommend to spend some time learning Lisp. It offers the most freedom you can possibly have in a programming languag…
Re: Borgo is a statically typed language that compiles to Go
#357Earlier quoted context omitted.
An Enum type has to be on the core Go team's radar by now. It's got to be tied with a try/catch block in terms of requested features at this point (now that we have generics).
I am so tired of reading Java/C++/Python code that just slaps try/catch around several lines. To some it might seem annoying to actually think about errors and error handling line by line, but for whoever tries to debug or refactor it's a godsend. Where I work, try/catch for more than one call that can throw an exception or including arbitrary lines that don't throw the caught exception, is a code smell. So when I lo…
Re: Borgo is a statically typed language that compiles to Go
#358Earlier quoted context omitted.
func try(fn func()) { fn() } func catch(fn func(any)) { if v := recover(); v != nil { fn(v) } } func throw(v any) { panic(v) } func fail() { throw("Bad things have happened") } func main() { try(func() { defer catch(func(v any) { fmt.Println(v) }) fail() }) } Sorry.
the day the go codebase throws random panics is the day I quit the company.
Re: Borgo is a statically typed language that compiles to Go
#359Earlier quoted context omitted.
The ability to quickly parse, understand and reason about code is not superficial, it is essential to the job. And that is essentially what those verbose blocks of text get in the way of.
As an experienced Go dev, this is literally not a problem. Golang code has a rhythm: you do the thing, you check the error, you do the thing, you check the error. After a while it becomes automatic and easy to read, like any other syntax/formatting. You notice if the error isn't checked. Yes, at first it's jarring. But to be honest, the jarring thing is because Go code checks the error every time it does something, n…
Re: Borgo is a statically typed language that compiles to Go
#360Earlier quoted context omitted.
That's a lot of pedantry you've got there for someone who claims it is not welcome. Rules for thee, not for me? But, if you'd kindly come back to the topic at hand: > That is what the discussion here is about - the way errors are handled in a language in practice, not in theory. While I'm not entirely convinced that is accurate, I will accept it. Now, how does: - "That said, suggesting adding exceptions to Go is abou…
It’s not simply a common pattern. It is a way of doing things in the community. The stdlib uses it, the libraries use it, and if you do not use it, people will not use your software.