Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Borgo is a statically typed language that compiles to Go

github.com

Post reply on HN
Print view View original

331–340 of 559 posts

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

#331

Post by leononame »

pjmlp wrote: post #320
AnonymousPlanet wrote: post #219

Earlier quoted context omitted.

Go is a very opinionated language from it's inception. We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. Maybe it's part of good engineering to keep things simple and not allow hundreds of ways to do something. Maybe the people who use Go are the ones who just want to write and read simple and maintainable code and don't want it to be cluttered with whateve…

It baffles me that so many developers are unable to use pre-comit hooks for their code formatting tools, that exist since the 1990's, to the point go fmt became a revelation.

That's hardly the point. The point is that there is a single format for the language itself and you don't have to argue about spaces vs tabs vs when to line break, whether you want trailing commas and where to put your braces.

You can format on save or in a pre commit hook. But that the language has a single canonical format makes it kind of new.

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

#332

Post by throwaway894345 »

bootsmann wrote: post #310
Mawr wrote: post #258

Earlier quoted context omitted.

The difference is that all code paths are explicitly spelled out and crucially that the programmer had to consider each path at the time of writing the code. The resulting code is much more reliable than what you end up with exceptions.

Do you really do that in practice, or do you just blindly go 'if err != nil return nil, err'? Because fundamentally the function you called can return different errors at any point so if you just propagate the error the code paths are in fact not spelled out at all because the function one above in the hierarchy has to deal with all the possible errors two calls down which are not transparent at all.

In Go, no one really blindly returns nil, err. People very clearly think about errors—if an error may need to be actioned on up the stack, people will either create a named error value (e.g., `ErrInvalidInput = errors.New(“invalid input”)` or a named error type that downstream users can check against. Moreover, even when propagating errors many programmers will attach error context: `return nil, fmt.Errorf(“searching for the flux capacitor `%s`: %w”, fluxCap, err)`. I think there’s room for improvement, but Go error handling (and Rust error handling for that matter) seem to be eminently thoughtful.

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

#333

Post by melodyogonna »

littlestymaar wrote: post #295
AnonymousPlanet wrote: post #219

Earlier quoted context omitted.

Go is a very opinionated language from it's inception. We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. Maybe it's part of good engineering to keep things simple and not allow hundreds of ways to do something. Maybe the people who use Go are the ones who just want to write and read simple and maintainable code and don't want it to be cluttered with whateve…

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

Rob Pike... and Ken Thompson, and Robert Grisemer.

Firstly, Ken Thompson is a master at filtering out unnecessary complexities and I highly rate his opinion of the important and unimportant things.

Secondly, the Go team were never against generics, the three early designers agreed the language needed generics but they couldn't figure out a way to add it orthogonally.

Go has gone on to be very successful in cloud and networked applications (which it was designed to cater for), which lends credit to the practicalities of what the designers thought as important, HN sentiments notwithstanding.

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

#334

Post by throwaway894345 »

dalyons wrote: post #226
AnonymousPlanet wrote: post #216

Earlier quoted context omitted.

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…

The huge volume of boilerplate makes the code harder to read, and annoying to write. I like go, and I don’t want exceptions persay, but I would love something that cuts out all the repetitive noise.

This has not been my experience. It doesn’t make the code harder to read, but it forces you to think about all the code paths—if you only care about one code path, the error paths may feel like “noise”, but that’s Go guiding you toward better engineering practices. It’s the same way JavaScript developers felt when TypeScript came along and made it painful to write buggy code—the tools guide you toward better practices.

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

#335

Post by pjmlp »

leononame wrote: post #331
pjmlp wrote: post #320

Earlier quoted context omitted.

It baffles me that so many developers are unable to use pre-comit hooks for their code formatting tools, that exist since the 1990's, to the point go fmt became a revelation.

That's hardly the point. The point is that there is a single format for the language itself and you don't have to argue about spaces vs tabs vs when to line break, whether you want trailing commas and where to put your braces. You can format on save or in a pre commit hook. But that the language has a single canonical format makes it kind of new.

Yes, because there is no one in the room able to configure the formating tool for the whole SCM.

A simple settings file set in stone by the CTO, such a hard task to do.

The fact that is even a novelty unaware of, only confirms the target group for the language.

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

#336

Post by pjmlp »

Hendrikto wrote: post #327
pjmlp wrote: post #317

Earlier quoted context omitted.

Because if err != nil { return err } repeated all over the place, is the epitome of productivity!

It actually is when debugging, because it makes control flow explicit. In JS, for example, people don‘t even know which functions could throw exceptions, and just ignore them, most of the time. Fast to write and looks nice, but is horrible quality and a nightmare to debug.

Ever heard of these funny tools called debuggers and exception breakpoints?

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

#337

Post by throwaway894345 »

BillyTheKing wrote: post #287
AnonymousPlanet wrote: post #216

Earlier quoted context omitted.

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…

I agree, I don't really understand everyone's issue with err != nil.. it's explicit, and linters catch uncaught errors. Yes the ? operator in Rust is neat, but you end up with a similar issue of just matching errors throughout your code-base instead of doing err != nil..

Yeah, also you almost always need to annotate errors anyway (e.g., `anyhow!`), so the ? operator doesn’t really seem to be buying you much and it might even tempt people away from attaching the error context.

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

#338

Post by throwaway894345 »

nyssos wrote: post #292
BillyTheKing wrote: post #287

Earlier quoted context omitted.

I agree, I don't really understand everyone's issue with err != nil.. it's explicit, and linters catch uncaught errors. Yes the ? operator in Rust is neat, but you end up with a similar issue of just matching errors throughout your code-base instead of doing err != nil..

The problem is that you're forced to have four possible states 1. err != nil, nondefault return value 2. err != nil, default return value 3. err == nil, nondefault return value 4. err == nil, default return value when often what you want to express only has two: either you return an error and there's no meaningful output, or there's output and no error. A type system with tuples but no sum types can only express "and…

I mean, I wish Go had sum types, but this really isn’t a problem in practice. Every Go programmer understands from day 0 that you don’t touch the value unless the error is nil or the documentation states otherwise. Sum types would be nice for other things though, and if it gets them eventually it would feel a little silly to continue using product types for error handling (but also it would be silly to have a mix of both :/).

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

#339

Post by foldr »

LinXitoW wrote: post #328
marcus_holmes wrote: post #300

Earlier quoted context omitted.

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…

Just because you can adapt to verbosity does not make it a good idea. I've gotten used to Javas getter/setter spam, does that make it a good idea? Moreover, don't you think that something like Rusts ? operator wouldn't be a perfect solution for handling the MOST common type of error handling, aka not handling it, just returning it up the stack? val, err := doAThing() if err != nil { return nil, err } VERSUS val := do…

I personally have mixed feelings about this. I think a shortcut would be nice, but I also think that having a shortcut nudges people towards using short-circuit error handling logic simply because it is quicker to write, rather than really thinking case-by-case about what should happen when an error is returned. In production code it’s often more appropriate to log and then continue, or accumulate a list of errors, or… Go doesn’t syntactically privilege any of these error handling strategies, which I think is a good thing.

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

#340

Post by rnmmrnm »

pjmlp wrote: post #336
Hendrikto wrote: post #327

Earlier quoted context omitted.

It actually is when debugging, because it makes control flow explicit. In JS, for example, people don‘t even know which functions could throw exceptions, and just ignore them, most of the time. Fast to write and looks nice, but is horrible quality and a nightmare to debug.

Ever heard of these funny tools called debuggers and exception breakpoints?

sane error handling in go is more productive any day.
Post reply on HN