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

481–490 of 559 posts

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

#481

Post by usrnm »

randomdata wrote: post #457
usrnm wrote: post #410

Earlier quoted context omitted.

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

What would you use when you actually have an exception, then? Exception and exception handlers are a useful construct, but, like everything else, become problematic when used outside of their intended purpose. Just because exception and error both start with the letter "e" does not mean they are in any way related. They have very different meanings and purposes.

If they are really exceptional situations that should never happen, just crash the process. The moment recover was added they become just another error handling mechanism

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

#482

Post by randomdata »

SleekoNiko wrote: post #472
randomdata wrote: post #413

Earlier quoted context omitted.

No, I am thinking of encoding/json. It uses Go's exception handlers to pass errors around, much like the code above.

Forgive me as I'm not experienced in Go. I had a look at the API reference for encoding/json[1] and performed a (very hasty) search on the source code[2]. The API reference doesn't state that panics are a part of the expected error interface, and the source code references seem to be using panics as a way to validate invariants. Is that what you're referring to? I'm not entirely sure if the panics are _just_ for sani…

The use does not transcend package boundaries, but you will find its use within the package itself, which is within the Go codebase spoken of earlier.

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

#483

Post by Capricorn2481 »

IshKebab wrote: post #479
Capricorn2481 wrote: post #469

Earlier quoted context omitted.

> But generally it's extremely tedious and verbose Is it? In my experience it's very short, especially considering you can catch multiple errors. Do my users really need a different error message for "invalid sql" vs "sql connection timeout?" They don't need to know any of that. > There's also the fact that stack traces are not proper error messages I would say there's not a proper error message to derive from explic…

> Do my users really need a different error message for "invalid sql" vs "sql connection timeout?" Yes! A connection timeout means it might work if they try again later. Invalid SQL means it's not going to fix itself. But in any case, the error messages are probably the minor part. The bigger issue is about properly handling errors and not just crashing the whole program / endpoint handler when something goes wrong.…

> "Contact an admin" is pretty much always bottom of the list because it rarely works. More likely options are "try again later", "try different inputs", "clear caches and cookies", "Google a more specific error"

You're totally misunderstanding what I'm saying. If I have an error the user can act on, I'll make that error message for them. If they can't act on it, I will make a generic catcher and ask them to contact an admin because that's the only thing they can do. It is not my experience that any of these things you've written (try again later, try a different input) are applicable when an error comes up in my apps. It's always an unexpected bug a developer needs to fix, because we've already handled the other error paths. And the bug is not from "not explicitly handling the error."

> Think about the best possible action that the user could take for different failure modes.

What if contacting an admin IS the best possible action? Which is what I'm referring to.

In the case of invalid sql, your route should crash because it's broken. Or catch it and stop it. It's functionally the same thing.

You seem to be under the impression that having exceptions mean people can't handle errors explicitly? It just prevents the plumbing of manually bubbling up the error. It means you can do so MORE granularly. Also, there are some errors that are functionally the same whether you handle them explicitly or not. There are unexpected errors, and even Golang won't save you from that. Golang doesn't even care if you handle an error. It will compile fine. Even PHP will tell you if you haven't handled an exception.

> If you have written a "something went wrong" error I literally hate you.

Lol.

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

#484

Post by randomdata »

demi56 wrote: post #465
randomdata wrote: post #360

Earlier quoted context omitted.

Okay, but how does that relate to what was said?

You’re just complaining because the compiler isn’t complaining

And you're panicking because the other commenters haven't helped recover for you. Try as you might, sadly they are not here to catch you. No need to throw a fit over it. You are not as exceptional as you think you are.

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

#485

Post by randomdata »

usrnm wrote: post #481
randomdata wrote: post #457

Earlier quoted context omitted.

What would you use when you actually have an exception, then? Exception and exception handlers are a useful construct, but, like everything else, become problematic when used outside of their intended purpose. Just because exception and error both start with the letter "e" does not mean they are in any way related. They have very different meanings and purposes.

If they are really exceptional situations that should never happen, just crash the process. The moment recover was added they become just another error handling mechanism

You would crash the process. But, sometimes it's useful to do a little bookkeeping first.

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

#486

Post by foobiekr »

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.

s/fracturing/having to use older libraries in the existing manner/

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

#487

Post by IshKebab »

Capricorn2481 wrote: post #483
IshKebab wrote: post #479

Earlier quoted context omitted.

> Do my users really need a different error message for "invalid sql" vs "sql connection timeout?" Yes! A connection timeout means it might work if they try again later. Invalid SQL means it's not going to fix itself. But in any case, the error messages are probably the minor part. The bigger issue is about properly handling errors and not just crashing the whole program / endpoint handler when something goes wrong.…

> "Contact an admin" is pretty much always bottom of the list because it rarely works. More likely options are "try again later", "try different inputs", "clear caches and cookies", "Google a more specific error" You're totally misunderstanding what I'm saying. If I have an error the user can act on, I'll make that error message for them. If they can't act on it, I will make a generic catcher and ask them to contact…

> You seem to be under the impression that having exceptions mean people can't handle errors explicitly?

Not at all! It's possible, but it's very tedious, and the lazy "catch it in main" option is so easy that in practice when you look at code that uses exceptions people actually don't handle errors explicitly.

> It means you can do so MORE granularly.

Again, it doesn't just mean that you can; it means that you will. And for proper production software that's not a good thing.

> There are unexpected errors

Only in languages with exceptions. In a language like Rust there are no unexpected errors; you have to handle errors or the compiler will shout at you.

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

#488

Post by Capricorn2481 »

IshKebab wrote: post #487
Capricorn2481 wrote: post #483

Earlier quoted context omitted.

> "Contact an admin" is pretty much always bottom of the list because it rarely works. More likely options are "try again later", "try different inputs", "clear caches and cookies", "Google a more specific error" You're totally misunderstanding what I'm saying. If I have an error the user can act on, I'll make that error message for them. If they can't act on it, I will make a generic catcher and ask them to contact…

> You seem to be under the impression that having exceptions mean people can't handle errors explicitly? Not at all! It's possible , but it's very tedious, and the lazy "catch it in main" option is so easy that in practice when you look at code that uses exceptions people actually don't handle errors explicitly. > It means you can do so MORE granularly. Again, it doesn't just mean that you can ; it means that you wil…

That has nothing to do with having exceptions, Rust just has a good type system (something go doesn't have).

But again, handling an error doesn't necessarily prevent bugs. Just because you handled an error doesn't mean the error won't happen in Prod. It just means when it does, you wrote a message for it or custom behavior. Which could be good, or it might be functionally as effective as returning a stack traces message. It depends on the situation.

For what it's worth, I've never seen people not handle errors that the user could do anything with. If it's relevant to the user, we handle it.

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

#489

Post by littlestymaar »

demi56 wrote: post #464
littlestymaar wrote: post #344

Earlier quoted context omitted.

> 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. This is a PR statement that has been introduced only after Go generics landed, for years generics were dubbed “unnecessary complexity” in user code (Go has had generics from the beginning but only for internal use of the standard library). > Go h…

> I have nothing against Go, it's a tool that does its job fairly well and has very interesting qualities (fast compile time, self-contained binaries, decent performance out of the box), but the religious worship of “simplicity” is really annoying. Typical Gate keeping the gate keepers of simplicity and pretty sure you code 23.5 hours a day on Haskell

> Typical Gate keeping the gate keepers of simplicity and pretty sure you code 23.5 hours a day on Haskell

I've no idea what you mean, you should keep your argumentation simpler ;)

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

#490

Post by fridental »

I understand that you like some Rust features like Result and Option types, enums, and pattern matching.

These features provide for more safety, and at the same time, they reduce productivity by forcing the developer to statically type everything.

The question is then why do we need to transpile to Go, a language with GC and slower than Rust?

If we already agree on super-safe static typing, why not just use Rust? Are there any libraries in Go that are not available or of worse quality in Rust?

Post reply on HN