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

261–270 of 559 posts

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

#261

Post by Kamq »

drdaeman wrote: post #175
TwentyPosts wrote: post #170

Earlier quoted context omitted.

The issue is that it's more or less impossible to graft onto the language now. You could add enums, but the main reason why people want them is to fix the error handling. You can't do this without fracturing the ecosystem.

> but the main reason why people want them is to fix the error handling Why do you think so? Maybe I'm an odd case, but my main use case for enums is for APIs and database designs, where I want to lock down some field to a set of acceptable values and make sure anything else is a mistake. Or for state machines. Error handling is manageable without enums (but I love Option/Result types more than Go's error approach, e…

> but I love Option/Result types more than Go's error approach

The thing is, these don't add much on their own. You'd have to bring in pattern matching and/or a bunch of other things* that would significantly complicate the language.

For example, with what's currently in the language, you could definitely have an option type. You'd just be limited to roughly an api that's `func (o Option[T]) IsEmpty() bool` and `func (o Option[T]) Get() T`. And these would just check if the underlying point is nil and dereference it. You can already do that with pointers. Errors/Result are similar.

A `try` keyword that expands `x := try thingThatProducesErr()` to:

    x, err := thingThatProducesErr()
    if err != nil {
        return {zero values of the rest of the function signature}, err
    }
Might be more useful in go (you could have a similar one for pointers).

* at the very least generic methods for flat map shenanigans

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

#262

Post by jhoechtl »

TwentyPosts wrote: post #170
H1Supreme wrote: post #165

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

The issue is that it's more or less impossible to graft onto the language now. You could add enums, but the main reason why people want them is to fix the error handling. You can't do this without fracturing the ecosystem.

I would like to have proper stack traces. With that the error handling in go would be fixed.

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

#264

Post by jurschreuder »

pdimitar wrote: post #193
jurschreuder wrote: post #174

Earlier quoted context omitted.

I've never needed either. Try/catch is super confusing because the catch is often far away from the try. And in Python I just put try/catch around big chunks of code just in case for production. I think Go is more stable and readable because they force you not to use the lazy unreadable way of error handling. Enums I honestly never used in Go also not the not-type-safe ones. But I'm also someone who used interfaces i…

Your comment could have been a nice opinion that proves to a drive-by reader that needs can differ drastically between programmers. But you ruined it with "fancy things" which shows offhand disregard and disrespect. A question like "what do you need these features for?" would have been a better contribution to the forum.

I actually really have a disrespect for them. I'm in a constant fight against developers that want to translate code in almost the same code but "only using language features from the Advanced book".

I also wanted to add that I used inheritance only ONCE in all my years of writing Python in all other millions of lines of code inheritance was not the best solution.

This is my daily struggle as a CTO. People using waaayy too many "fancy" features of languages making it totally unreadable and unmaintainable.

It's their ego they want to show off how many complex language features they know. And it's ruining my codebases.

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

#265

Post by jurschreuder »

kbenson wrote: post #183
jurschreuder wrote: post #174

Earlier quoted context omitted.

I've never needed either. Try/catch is super confusing because the catch is often far away from the try. And in Python I just put try/catch around big chunks of code just in case for production. I think Go is more stable and readable because they force you not to use the lazy unreadable way of error handling. Enums I honestly never used in Go also not the not-type-safe ones. But I'm also someone who used interfaces i…

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 listened to the herd that does not take all sides of the story into consideration but just keeps pushing enums.

Try/catch is just a really bad thing all "hacky solution" alarm bells go off for me if you want to change error handling to giant try/catch blocks.

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

#266

Post by mplewis »

randomdata wrote: post #248
Mawr wrote: post #240

Earlier quoted context omitted.

You're absolutely technically correct, in the "spherical cow in a vacuum" sense. In reality though, essentially all Go code out there handles errors through the pattern of checking if the error in a `(value, error)` tuple returned from a function is `nil` or not. That is what the discussion here is about - the way errors are handled in a language in practice, not in theory. Therefore, pedantry. Basically, discussions…

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.

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

#267

Post by Scramblejams »

speed_spread wrote: post #130
Scramblejams wrote: post #96

Earlier quoted context omitted.

The author notes[0] that it keeps the Rust syntax to avoid having to write a parser. I have no issue with the syntax but I think the chance of uptake would be considerably improved if the syntax were as close to Go's as reasonably possible. That's because I estimate Go programmers to be a better target for this than Rust programmers, but maybe I'm wrong. [0] https://news.ycombinator.com/item?id=36847594

Having a soft-Rust alternative is a recurring topic in the Rust community and is acknowledged as being of interest by core members: https://www.reddit.com/r/rust/comments/j2l9v9/revisiting_a_s...

Yeah, it'd be great to see something come of it. Been a while, though.

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

#268

Post by FuckButtons »

Mawr wrote: post #255
slt2021 wrote: post #222

Earlier quoted context omitted.

>the error handling was one of the many positive features. sounds good on paper, but seeing "if err!=nil" repeated million times in golang codebases does not create positive impression at all

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.

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

#269

Post by Mawr »

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.

Sure, I just don't think it's that significant. Humans don't read/parse code character-by character, we do it by recognizing visual patterns. Blocks of `if err != nil { }` are easy to skip over when reading if needed.

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

#270

Post by Mawr »

Kamq wrote: post #261
drdaeman wrote: post #175

Earlier quoted context omitted.

> but the main reason why people want them is to fix the error handling Why do you think so? Maybe I'm an odd case, but my main use case for enums is for APIs and database designs, where I want to lock down some field to a set of acceptable values and make sure anything else is a mistake. Or for state machines. Error handling is manageable without enums (but I love Option/Result types more than Go's error approach, e…

> but I love Option/Result types more than Go's error approach The thing is, these don't add much on their own. You'd have to bring in pattern matching and/or a bunch of other things* that would significantly complicate the language. For example, with what's currently in the language, you could definitely have an option type. You'd just be limited to roughly an api that's `func (o Option[T]) IsEmpty() bool` and `func…

Using an Option instead of a pointer buys you the inability to forget to check for nil.

Just need to make sure the Option exposes the internal value only through:

    func (o Option[Value]) Get() (Value, bool) {
        return o.value, o.exists
    }
Accessing the value is then forced to look like this:

    if value, ok := option.Get(); ok {
        // value is valid
    }
    // value is invalid
Thus, there's no possibility of an accidental nil pointer dereference, which I think is a big win.

A Result type would bring a similar benefit of fixing the few edge cases where an error may accidentally not be handled. Although I don't think it'd be worth the cost of switching over.

Post reply on HN