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

461–470 of 559 posts

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

#461

Post by neonsunset »

rendaw wrote: post #271
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…

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.

C# is much better at doing systems-programming adjacent tasks than either Java or Go, as it actually exposes all the necessary features for this: C structs, actual, proper generics, fast FFI, etc.

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

#462

Post by rubenvanwyk »

derefr wrote: post #439
callc wrote: post #284

Earlier quoted context omitted.

Thanks for your response AnonymousPlanet. I agree there is value in the pursuit of a minimal set of features in a PL which brings many benefits. And of course the opposite - an overly feature packed and/or extensible PL as a core feature has tradeoffs. Over this range of possibilities my preference probably falls somewhere in the middle. I see an effect where the languages whose primary goal is a particular set langu…

> Maybe in the pursuit of an opinionated language, even if the designers are reasonable at the language's inception, the community throws out logic and "opinionated" becomes a in-group out-group tribal caveman situation. I think you've got this backward. It's not that the particular choices are important. It's a thing happening on a higher meta level than that. Some programming languages are, by design intent, "livin…

Best comment in the thread. I think defining certain languages as "crystallised", rather than "set", explains well the underlying structure has taken a specific shape based on specific tenets. Well said.

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

#463

Post by groestl »

Keats wrote: post #370
groestl wrote: post #211

Earlier quoted context omitted.

True, as a non-native speaker: naming variables in a native language (that's not English) is objectively bad.

So if you have a concept that doesn't have an equivalent in English you just kinda translate it and add a comment for other people of your language to understand what it is?

Sure. And for a concept that's so foreign there is no English equivalent, I hope there's plenty of documentation. I mean, to each their own, but for me, a software team using native language for variables is a red flag.

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

#464

Post by demi56 »

littlestymaar wrote: post #344
melodyogonna wrote: post #333

Earlier quoted context omitted.

Rob Pike... and Ken Thompson, and Robert Grisemer. Firstly, Ken Thompson is a master at filtering out unnecessary complexities and I highly rate his opinion of the important and unimportant things. 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. Go has gone on to be very successful in cloud and…

> 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

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

#465

Post by demi56 »

randomdata wrote: post #360
mplewis wrote: post #266

Earlier quoted context omitted.

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.

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

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

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

#466

Post by demi56 »

taylodl wrote: post #438
Thaxll wrote: post #202

Earlier quoted context omitted.

No one wants try/catch/exception in Go.

It's 2024. We need an effective means for error propagation and the battle-tested solutions are try/catch exceptions or Optional types. Go's error handling would have been great in the 1970's, it's not so great now some 50 years later.

Sooo what’s the new 2025 way?

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

#467

Post by demi56 »

dalyons wrote: post #226
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…

The huge volume of boilerplate makes the code harder to read, and annoying to write. I like go, and I don’t want exceptions persay, but I would love something that cuts out all the repetitive noise.

> The huge volume of boilerplate makes the code harder to read, and annoying to write

That may be superficially true but don’t forget our brain is structured to optimize every repetitive work or some boilerplates, we can basically use “strcpy” and “string_copy” we are so used to all these that even if repeated a billion times it can be processed fast

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

#468

Post by demi56 »

noisy_boy wrote: post #311
Mawr wrote: post #298

Earlier quoted context omitted.

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…

I guess I should have been more clear that I mean actions that have resulted from the feedback. Sure, the survey brings out the concerns in a structured form, but to anyone who has seen more than a few discussions about Go, the feedback regarding error handling or enum or sum types etc would not have been news. I can't imagine Go team at Google is stunned by developer demand for these things. Question is why there ha…

Dude if the 70% don’t care they don’t care besides it’s open source

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

#469

Post by Capricorn2481 »

IshKebab wrote: post #458
Capricorn2481 wrote: post #398

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." 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 wit…

> 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 explicitly handling sql errors. Certainly not a different message per error. I would rather capture all of it and say something like "Something went wrong while accessing the database. Contact an admin." Then log the stack trace for devs

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

#470

Post by jjice »

randomdata wrote: post #451
jjice wrote: post #448

Earlier quoted context omitted.

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 s…

> A tag-only union is not the same thing, even if you can find some passing similarities

Why not? Seems to function the same way.

Post reply on HN