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

451–460 of 559 posts

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

#451

Post by randomdata »

jjice wrote: post #448
randomdata wrote: post #417

Earlier quoted context omitted.

You'll have to ask the Rust community. Rust lacks enums. Go, however, most definitely has enums (and exceptions too!). type E int const ( A E = iota B C ) It's funny how people who have clearly never even looked at Go continually think they are experts in it. What causes this strange phenomena?

Go has a way to implement enums - I'll give you that. Rust does have enums though: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html They can have values like sum types, or not.

> Rust does have enums though

It does not. You'll notice that if you read through your link. A tag-only union is not the same thing, even if you can find some passing similarities.

If you mean it has enums like the Democratic People's Republic of Korea has a democracy, then sure, it does have enums in that sense. I'm not sure that gives us anything meaningful, though.

If we're being honest, sum types are the better solution. Enums are hack for type systems that are too limited for anything else. They are not a feature you would add if you already have a sufficient type system. It's not clear why Rust even wants to associate itself with the hack that are enums, but your link shows that its author has a fundamental misunderstanding of what enums even are, so it may be down to that.

To be fair, Swift made the same mistake, but later acknowledged it. It is interesting that Rust has chosen to double down instead.

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

#452

Post by theshrike79 »

pjmlp wrote: post #427
theshrike79 wrote: post #406

Earlier quoted context omitted.

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

Most people only care about the code of their employer.

Very few employers do 100% of the code in-house, everyone uses libraries and code from the internet.

Which will have a different style you need to contend with.

But with Go every single sane piece of code you find will be formatted with gofmt and will look mostly the same.

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

#453

Post by mdaniel »

4star3star wrote: post #415
rendaw wrote: post #271

Earlier quoted context omitted.

Aside from "not ancient" Java has everything you want! I'd consider the best tooling (Intellij), static, strongly typed, has enums now (sealed interfaces), composeable error handling, null safety with new module flags, etc. Not sure about the community, but the maintainers I've worked with seemed nice enough. I imagine the community has a lot less ego than rust/go due to the general perception of the language.

What does Java offer that dotnet does not?

libraries, and I thank God I don't have to work on Windows and thus don't know how smart Visual Studio Enterprise is, but IJ is world class in the number of bugs it'll catch

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

#454

Post by pjmlp »

derefr wrote: post #444
pjmlp wrote: post #428

Earlier quoted context omitted.

A clear management failure then.

Any CTO who is aware of the impact that having an incoherent programming style can have on employee productivity, is likely going to arrive at the conclusion that the most efficient way to set such policy is to "outsource" it to the programming language, by requiring projects to use an opinionated language. Then again, any such CTO is likely also going to be someone who tends to think about things like "the ability t…

It is going to be a very clueless CTO, if they aren't aware of tooling that is even older than themselves.

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

#455

Post by pjmlp »

derefr wrote: post #447
pjmlp wrote: post #427

Earlier quoted context omitted.

Most people only care about the code of their employer.

Many shops have to write and submit patches to upstream projects. Some shops have to maintain their own "living fork" version of an upstream project.

Yeah, and apparently use Notepad, since they are unable to have a configuration file for formatting.

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

#456

Post by pjmlp »

zer00eyz wrote: post #150
pjmlp wrote: post #108

Earlier quoted context omitted.

Go could have been like Modula-3, D or C#, instead they decided to revamp Oberon and Limbo, the version 1.0 of those languages from the 1990's, not what was latter done from their learnings, e.g. Active Oberon. Now thanks to Docker and Kubernetes adoption success, we're stuck with it. At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.

It whooshed right past your head. Go is stone cold simple to pick up. ITs simple to reason about. I can decompose a project and spoon feed it to a JR engineer and they can get through it. Rust is none of those things. Its great for low level stuff, it is in the kernel right next to C and go will NEVER be there. Why, because that is what rust is good at. > At least now generics are supported, unless one needs gccgo, m…

Looking forward for AI research in Go taking over the world.

Zig is a Modula-2 (1978), with C like syntax, with added compile time, still has use-after-free, and a community that seems ideologically against binary libraries.

Good luck making it relevant, I am not buying into Bun ever taking over node.

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

#457

Post by randomdata »

usrnm wrote: post #410
Mawr wrote: post #231

Earlier quoted context omitted.

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

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.

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

#458

Post by IshKebab »

Capricorn2481 wrote: post #398
IshKebab wrote: post #280

Earlier quoted context omitted.

The idea that error handling is "not part of the code" is silly though. My impression of people that hate Go's explicit error handling is that they don't want to deal with errors properly at all. "Just catch exceptions in main and print a stack trace, it's fine." Rust's error handling is clearly better than Go's, but Go's is better than exceptions and the complaints about verbosity are largely complaints about having…

> The idea that error handling is "not part of the code" is silly though. My impression of people that hate Go's explicit error handling is that they don't want to deal with errors properly at all. "Just catch exceptions in main and print a stack trace, it's fine." I'm honestly asking as someone neutral in this, what is the difference? What is the difference between building out a stack trace yourself by handling err…

The biggest difference is that you can see where errors can happen and are forced to consider them. For example imagine you are writing a GUI app with an integer input field.

With exception style code the overwhelming temptation will be to call `string_to_int()` and forget that it might throw an exception.

Cut to your app crashing when someone types an invalid number.

Now, you can handle errors like this properly with exceptions, and checked exceptions are used sometimes. But generally it's extremely tedious and verbose (even more than in Go!) and people don't bother.

There's also the fact that stack traces are not proper error messages. Ordinary users don't understand them. I don't want to have to debug your code when something goes wrong. People generally disabled them entirely on web services (Go's main target) due to security fears.

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

#459

Post by tuetuopay »

Mawr wrote: post #394
LinXitoW wrote: post #328

Earlier quoted context omitted.

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…

Well we are in a discussion thread about a language that does just that :) I see two issues with the `?` operator: 1. Most Go code doesn't actually do return nil, err but rather return nil, fmt.Errorf("opening file %s as user %s: %w", file, user, err) that is, the error gets annotated with useful context. What takes less effort to type, `?` or the annotated line above? This could probably be solved by enforcing that…

For the first point, there are two common patterns in rust:

1. Most often found in library code, the error types have the metadata embedded in them so they can nicely be bubbled up the stack. That's where you'll find `do_a_thing().map_err(|e| Error::FileOpenError { file, user, e })?`, or perhaps a whole `match` block.

2. In application code, where matching the actual error is not paramount, but getting good messages to an user is; solutions like anyhow are widely used, and allow to trivially add context to a result: `do_a_thing().context("opening file")?`. Or for formatted contexts (sadly too verbose for my taste): `do_a_thing().with_context(|| format!("opening file {file} as user {user}"))?`. This will automatically carry the whole context stack and print it when the error is stringified.

Overall, what I like about this approach is the common case is terse and short and does not hinder readability, and easily gives the option for more details.

As for the second point, what I like about _not_ easily seeing all return paths (which are a /\? away in vim anyways), is that special handling stands out way more when reading the file. When all of the sudden you have a match block on a result, you know it's important.

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

#460

Post by deergomoo »

saghm wrote: post #441
tbrockman wrote: post #218

This addresses pretty much all of my least favorite things with writing Go code at work, and I hope--at the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias!) of the responses inspires Go maintainers to consider/prioritize some of these features, or renews the authors interest in working on the project (as some have commented, it seems to have gone without activity fo…

> the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias As someone who has the "Rust bias", I feel like it's a bit of an open secret that a _lot_ of Rust developers don't actually need the extreme low-level performance that it offers and use it more because of the quality of life things (including some of the features in Borgo, but also tooling like cargo, rustdoc, etc…

> but there isn't something higher-level that offers enough of those features yet

I think Swift would tick most of those boxes, it’s a shame it hasn’t really picked up outside Apple-land.

It can be a horribly complex language, but day-to-day it’s very nice to write.

Post reply on HN