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

271–280 of 559 posts

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

#271

Post by rendaw »

callc wrote: post #213
Thaxll wrote: post #202

Earlier quoted context omitted.

No one wants try/catch/exception in Go.

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.

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

#272

Post by RedComet »

Mawr wrote: post #256
RedComet wrote: post #251

Earlier quoted context omitted.

That just changes the boilerplate from if's to match's.

See the example with the `?` operator: https://github.com/borgo-lang/borgo?tab=readme-ov-file#error... The main benefits of a Result type are brevity and the inability to accidentally not handle an error.

Yes, but that isn't necessarily a feature of option types. Is it the case that similar sugar for the tiresome Go pattern couldn't achieve similar benefits?

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

#273

Post by bbkane »

smt88 wrote: post #249
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…

You have the same PL preferences as me. I haven't tried Rust yet, but Kotlin, modern C#, and F# all fit your requirements. Kotlin is closest because it uses the enormous Java ecosystem.

I haven't had time to really try to write anything in it, but https://gleam.run/ looks really good too. Like Elm for backend + frontend!

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

#274

Post by bbkane »

Mawr wrote: post #269
FuckButtons wrote: post #268

Earlier quoted context omitted.

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.

I agree, though I was really surprised to learn this when reading Go code. Much easier to skip over than I was expecting it to be

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

#275

Post by bbkane »

akira2501 wrote: post #113
odc wrote: post #90

Earlier quoted context omitted.

I love Go's letter casing. It's such a neat way to remove cruft.

> It's such a neat way to remove cruft. I don't disagree, the problem I have with it is, I have to pay for that up front and have to factor it into my design immediately. This also combines with the fact that the namespace is very flat with no heirarchy, so, choosing good public names is something I feel like I spend way too much time on. Go is the only language that causes me to pull out a thesaurus when trying to n…

ChatGPT is really good at suggesting 20 names for . Try it out!

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

#276

Post by lelanthran »

randomdata wrote: post #239
throwaway143829 wrote: post #234

Earlier quoted context omitted.

Enums and sum types seem to be related. In the code you wrote, you could alternatively express the Hot and Cold types as enum values. I would say that enums are a subset of sum types but I don't know if that's quite right. I guess maybe if you view each enum value as having its own distinct type (maybe a subtype of the enum type), then you could say the enum is the sum type of the enum value types?

> Enums and sum types seem to be related. They can certainly help solve some of the same problems. Does that make them related? I don't know. By definition, an enumeration is something that counts one-by-one. In other words, as is used in programming languages, a construct that numbers a set of named constants. Indeed you can solve the problem using that: type Temperature int const ( Hot Temperature = iota Cold ) fun…

Unfortunately, this:

    const (
        Hot  Temperature = 0
        Cold Temperature = 1 
    )
Isn't really a good workaround when lacking an enumeration type. The compiler can't complain when you use a value that isn't in the list of enumerations. The compiler can't warn you when your switch statement doesn't handle one of the cases.

Refactoring is harder - when you add a new value to the enum, you can't easily find all those places that may require logic changes to handle the new value.

Enums are a big thing I miss when writing Go, compared to when writing C.

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

#277

Post by lelanthran »

slt2021 wrote: post #222
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 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

> sounds good on paper, but seeing "if err!=nil" repeated million times in golang codebases does not create positive impression at all

Okay, but other than exceptions, whats the alternative?

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

#278

Post by nindalf »

lelanthran wrote: post #277
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

> sounds good on paper, but seeing "if err!=nil" repeated million times in golang codebases does not create positive impression at all Okay, but other than exceptions, whats the alternative?

The ? Operator in Rust?

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

#280

Post by IshKebab »

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.

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 to actually consider errors.

Post reply on HN