Live data from Hacker News

Borgo is a statically typed language that compiles to Go

github.com

351–360 of 559 posts

Re: Borgo is a statically typed language that compiles to Go

#351
post #202

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.

Having the exceptions support does not mean the code will be scattered with try/catches - it is not used for the code flow, but ensuring no error slips silently. And when the exception is thrown, the stack trace is captured so you can get to the code and debug.

Re: Borgo is a statically typed language that compiles to Go

#353

Earlier 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…

This matches my experience _hard_; there is simply no comparison in practice. Go does it better nearly every time

Re: Borgo is a statically typed language that compiles to Go

#354
post #317

Earlier 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…

Also known as The Apple Answer.

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

#355
post #213

Earlier 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".

Scala is the perfect example of why you want to limit expressivity. It's seems so cool and awesome at first, but then you have to support a code base with other engineers and you quickly come to the view that go's limited expressivity is a blessing.

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

#356

Earlier 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…

Most of people who tend to brag about Lisp's (Common Lisp) superiority, never actually used it. It is not as impressive as many legends claim.

Re: Borgo is a statically typed language that compiles to Go

#357

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).

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…

Try-blocks with ~one line are best practice on code based I have worked with. The upside is that you can bubble errors up to the place where you handle them, AND get stack traces for free. As a huge fan of Result, I have to admit that that's a possible advantage. But maybe that fits your definition of lazy :).

Re: Borgo is a statically typed language that compiles to Go

#358

Earlier 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.

So you quit the day encoding/json was written?

Re: Borgo is a statically typed language that compiles to Go

#359

Earlier 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…

Actually this is precisely same cadence as in good old C. As someone who writes lots of low-level code, I find Go's cadence very familiar and better than try-catch.

Re: Borgo is a statically typed language that compiles to Go

#360

Earlier 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.

Okay, but how does that relate to what was said?
Post reply on HN