Live data from Hacker News

Borgo is a statically typed language that compiles to Go

github.com

401–410 of 559 posts

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

#401

Earlier quoted context omitted.

It doesn't not use exception handlers as a primary way of handling errors either, though. Go doesn't specify any error handling mechanism. Using exception handlers is just as valid as any other, and even the standard library does it, as noted earlier. The only error-related concept the Go language has is the error type, but it comes with no handling semantics. Which stands to reason as there is nothing special about…

I would be happy if they would add in compiler some thing that'll allow to ignore error return values and in this case compiler would just throw exception^Wpanic from that point. I think it even makes sense for go purists, like you need to handle errors or get panicked. And I'd just mostly ignore errors and will have my sweet exceptions.

You can get pretty close with generics:

    func Must[Value any](v Value, err error) Value {
        if err != nil {
            panic(err)
        }
        return v
    }

    Must(strconv.Atoi("not a number"))
(https://go.dev/play/p/NnrZ30TflDI)

;)

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

#402
post #335

Earlier quoted context omitted.

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.

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

It does seem hard thing to do. Working over dozens of enterprise shops in last 15 years I have not see such setting done or dictated at all. So whole codebase used to be mishmash of person styles.

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

#403

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…

> give some kind of coherence to it (looking at you Java and C++)

I have never done any real programming in Java itself, but the parts of Java world that I learned while writing some Clojure circa 2015 felt pretty coherent. Now I'm curious what I missed.

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

#404

Earlier quoted context omitted.

It doesn't not use exception handlers as a primary way of handling errors either, though. Go doesn't specify any error handling mechanism. Using exception handlers is just as valid as any other, and even the standard library does it, as noted earlier. The only error-related concept the Go language has is the error type, but it comes with no handling semantics. Which stands to reason as there is nothing special about…

I would be happy if they would add in compiler some thing that'll allow to ignore error return values and in this case compiler would just throw exception^Wpanic from that point. I think it even makes sense for go purists, like you need to handle errors or get panicked. And I'd just mostly ignore errors and will have my sweet exceptions.

> I think it even makes sense for go purists, like you need to handle errors or get panicked.

You think wrong. Go preaches that zero values should be useful, with means in the common (T, error) scenario, T should always be useful even if there is also an error state. Worst case, you will get the zero value in return, which is still useful. This means that the caller should not need to think about the error unless it is somehow significant to the specific problem they face. They are not dependent variables.

I understand where you are coming from as in other languages it would be catastrophic to ignore errors, but that's not how Go is designed. You cannot think of it like you do other languages, for better or worse.

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

#405

Earlier quoted context omitted.

Well, flexibility has its price. And yeah, if you need to work in a team that uses a very different style, then you won't like it. On the other hand, if you carefully select your team or work alone, then this is not a problem at all. Btw, there isn't really "one" idiomatic scala style - therefore I tend to believe that you are not familiar with the language and the community.

> Btw, there isn't really "one" idiomatic scala style That is their point. There's too many styles.

What "point" is that though? That's like saying "there is too many programming languages".

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

#406
post #335

Earlier quoted context omitted.

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.

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

And then you have a 100 companies with 100 CTOs resulting in 100 different styles.

With Go there is only one style everywhere.

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

#407
post #349
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…

Suggesting try/catch indicates that you have virtually no experience using Go. You're standing on the side lines yelling stupid/non-sensical feature requests and getting upset when you're not taken seriously.

Adding exceptions to golang doesn't make any sense for a very simple reason: they're already there. The fact that they're called differently doesn't change anything, panics walk like exceptions, swim like exceptions and they quack like exceptions.

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

#408
post #319

Earlier quoted context omitted.

[flagged]

Nor yours.

This kind of pandering horseshit from throwaway accounts add no value and should be downvoted on sight. Especially if you bake self-deprecation into it, "uwu I'm... I'm not sure if a-anybody is going to like my comment..."

Just let the good conversation unfold without patronizing meta-commentary. This isn't Reddit.

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

#409

Earlier quoted context omitted.

the day the go codebase throws random panics is the day I quit the company.

So you quit the day encoding/json was written?

You are probably thinking about (proto)reflect.

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

#410
post #231

Earlier quoted context omitted.

> That said, suggesting adding exceptions to Go is about as reasonable as adding a GC to Zig. Suggesting the addition of exceptions to Go is as reasonable as suggesting the addition of loops to Rust. Which is to say that it already has exceptions, and always has. Much of the language's design is heavily dependent on the presence of exceptions. Idioms dictate that you probably shouldn't use exceptions for errors (nor…

Go doesn't use exceptions as a primary way of handling errors, which is what we're talking about here. Pedantry is not welcome.

Then it shouldn't have added exceptions in the first place. But exceptions in go exist and so does exception (un)safety, and denial only leads to buggy code. I cannot count how many times I've seen exception unsafe code in go exactly because everyone keeps ignoring them
Post reply on HN