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

291–300 of 559 posts

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

#291

Post by jjallen »

randomdata wrote: post #114
jjallen wrote: post #107

Earlier quoted context omitted.

I spent quite a few hours tracking down bugs due to miscased struct fields unfortunately. Strongly prefer explicitness over implicitness

The casing rules are quite explicit and enforced by the compiler. A build would have immediately failed on whatever mismatch you had. A few hours and you didn't even think to try compiling it? I'm guessing you are talking about something else entirely, like, perhaps, decoding JSON into a struct using reflection and encountering a situation where the field names didn't match? Indeed, implicitness can bite you there. T…

The rules are explicit but the actual changes in code are very small and unique to this language (or unique from the languages I had ever used). It’s one of those things that you can forget about — because it’s a small difference in code and arguably isn’t explicit.

I forget what it was, but basically my code wasn’t working the way I thought it should and it was solely due to a lowercased struct field. It happened twice where I spent at least a little while trying to figure it out.

And yeah I would guess that I tried to compile. Would be very dumb if I hadn’t although wouldn’t be the dumbest thing I’ve ever done

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

#292

Post by nyssos »

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

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", not "or".

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

#293

Post by lelanthran »

jurschreuder wrote: post #265
kbenson wrote: post #183

Earlier quoted context omitted.

I think what this comment is missing is any sort of analysis of how your experience maps to the general go user, and an opinion on while you've never needed either whether you think it could have provided any benefit when used appropriately. For example, and option type with enums combined can ensure return values are checked by providing a compile time error if a case is missing (as expressed in the first few exampl…

I know it can, the compiler can do one more "automatic" unit test based on the type checking system. But they decided not to add enums because it conflicted and overlapped too much with interfaces. I just want to add "my" experience that personally, yes maybe you can argue enums are nice, but I never missed them in Go. I personally agree with the Go team on how they argue and for me it would be a step back if they li…

> But they decided not to add enums because it conflicted and overlapped too much with interfaces.

I'm very curious now about how it might conflict and/or overlap with interfaces.

To reach the goal of an enumeration type (and all the strong type-checking that that brings with it), enums could look as simple as:

    type DayNames enum {
       Sunday
       Monday
       Tuesday
       Wednesday
       Thursday
       Friday
       Saturday
    }
    ...
    func isFunDay (dow DayNames) {
       // This must fail to compile, because there is an unhandled enumeration
       switch {
          case Sunday: ...
          case Monday: ...
          case Tuesday: ...
          case Thursday: ...
          case Friday: ...
          case Saturday: ...
       }
       ...
    }
    ...
    isFunDay (0)   // Compile failure
    var x int
    isFunDay (x)   // Compile failure
And I don't see how that conflicts or overlaps with interfaces.

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

#294

Post by Mawr »

RedComet wrote: post #272
Mawr wrote: post #256

Earlier quoted context omitted.

See the example with the `?` operator: https://github.com/borgo-lang/borgo?tab=readme-ov-file#error... The main benefits of a Result type are brevity and the inability to accidentally not handle an error.

Yes, but that isn't necessarily a feature of option types. Is it the case that similar sugar for the tiresome Go pattern couldn't achieve similar benefits?

Perhaps, but there have been several proposals along those lines and nobody seems capable of figuring out a sensible implementation.

A funny drawback of the current Go design that a Result type would solve is the need to return zero values of all the declared function return types along with the error: https://github.com/golang/go/issues/21182.

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

#295

Post by littlestymaar »

AnonymousPlanet wrote: post #219
callc wrote: 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…

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 always settled quickly in the few case where it happens in the first place).

The real reason why Go is opinionated is much more mundane: Rob is an old man who think he has seen it all and that the younger folks are children, and as a result he is very opinionated. (remember his argument against syntax coloring because “it's for babies” or something).

It's not bad to be opinionated when designing a language, it give some kind of coherence to it (looking at you Java and C++) but it can also get into the way of users sometimes. Fortunately Go isn't just Rob anymore and isn't impervious to changes, and there is finally generics and a package manager in the language!

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

#296

Post by networked »

ReflectedImage wrote: post #237
toolz wrote: post #6

Earlier quoted context omitted.

It's a language known for having a great runtime and tooling but subpar language semantics. Makes sense to me, at least. Most of the benefits of go with fewer drawbacks.

Ahh the failure to recognize that the great runtime and tooling is due to the language semantics.

I think the most complained-about semantics of Go have been the lack of generics, the lack of algebraic data types, nil, and the error handling. Generics are now implemented, and just about nobody considers the tooling and the runtime ruined because of them. Projects like Borgo and Oden are evidence that you can have what people like about the Go runtime and tooling combined with ADT-based error handling and restricted nil.

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

#297

Post by jjallen »

latchkey wrote: post #109
jjallen wrote: post #107

Earlier quoted context omitted.

I spent quite a few hours tracking down bugs due to miscased struct fields unfortunately. Strongly prefer explicitness over implicitness

Which IDE do you use? Mine would flag this as an error pretty quickly.

Goland. How would an IDE know that you intended a struct field to be public or not?

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

#298

Post by Mawr »

noisy_boy wrote: post #260
owenpalmer wrote: post #225

This looks like an interesting sweet spot. Rust is often praised for the borrow checker, but honestly I really only like rust for the type system and error handling. Go is praised for it's simplicity, but hated for it's error handling.

Rust without borrow checker is much less feasible than Go with Result/Option types to address the nil overdose problem. Unfortunately Go team refuses to acknowledge the common themes coming out of years of user complaints. They don't have to cater to every wishlist but when nil/enum related complaints are the majority in every discussion about issues with Go, one would think to acknowledge the legitimacy of those sho…

I'm not sure what exactly you mean by acknowledgement, but here are some counterexamples:

- A proposal for sum types by a Go team member: https://github.com/golang/go/issues/57644

- The community proposal with some comments from the Go team: https://github.com/golang/go/issues/19412

Here are some excerpts from the latest Go survey [1]:

- "The top responses in the closed-form were learning how to write Go effectively (15%) and the verbosity of error handling (13%)."

- "The most common response mentioned Go’s type system, and often asked specifically for enums, option types, or sum types in Go."

I think the problem is not the lack of will on the part of the Go team, but rather that these issues are not easy to fix in a way that fits the language and doesn't cause too many issues with backwards compatibility.

[1]: https://go.dev/blog/survey2024-h1-results

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

#299

Post by marcus_holmes »

thefounder wrote: post #238
Thaxll wrote: post #202

Earlier quoted context omitted.

No one wants try/catch/exception in Go.

Let’s hope Go never gets try/catch exceptions

ESBuild, one of my favourite Go projects, uses panics to handle try/catch exceptions.

The syscall/js package [0] throws panics if something goes wrong, rather than returning errors.

Go already has try/catch exceptions. We just don't use them most of the time because they're a really bad way of handling errors.

[0] https://pkg.go.dev/syscall/js

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

#300

Post by marcus_holmes »

FuckButtons wrote: post #268
Mawr wrote: post #255

Earlier quoted context omitted.

Yes but the impression is largely superficial. The error handling gets the job done well enough, if crudely.

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, not because of the actual "if err != nil" syntax.

Post reply on HN