Borgo is a statically typed language that compiles to Go • Hacker News Board

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

#411

Post by randomdata » Wed, May 01, 2024, 2:21 PM UTC

blueberry87 wrote: post #190

randomdata wrote: post #182

Earlier quoted context omitted.

> my main use case for enums is for APIs and database designs, where I want to lock down some field to a set of acceptable values and make sure anything else is a mistake Then what you are really looking for is sum types (what Rust calls enums, but unusually so), not enums. Go does not have sum types, but you can use interfaces to archive a rough facsimile and most certainly to satisfy your specific expectation: type…

annoyingly go can't have proper sum types, as the requirement for a default value for everything doesn't make any sense for sum types

Said "requirement" is only a human construct. The computer doesn't care.

If the humans choose to make an exception for that, it can be done. Granted, the planning that has taken place thus far has rejected such an exception, but there is nothing about Go that fundamentally prevents carving out an exception.

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

#412

Post by Too » Wed, May 01, 2024, 2:22 PM UTC

randomdata wrote: post #232

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.

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…

The problem with go exceptions (panics) is that they are a second class citizen. Leading to ignorance of using “defer”-statement when needed, opening up risk of leaving mutexes and other critical handlers open.

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

#413

Post by randomdata » Wed, May 01, 2024, 2:23 PM UTC

kubanczyk wrote: post #409

randomdata wrote: post #358

Earlier quoted context omitted.

So you quit the day encoding/json was written?

You are probably thinking about (proto)reflect.

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

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

#414

Post by tbrockman » Wed, May 01, 2024, 2:25 PM UTC

nobleach wrote: post #253

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…

I have to disagree. I'm on record here lamenting Go. I've never really enjoyed writing it. When I've had to use it, I've used it. Lately though, I've found a lot more pleasure. And much of that comes from the fact that it does NOT have all these features. The code I write, is going to look like the code written by most other on my team. There's an idiomatic way to write Go, and it doesn't involve those concepts from…

I'm open to alternatives, but I haven't experienced any language constructs that strike as good of a balance between forcing you to handle errors/options when a function indicates it returns them, and allowing you to do so without too much ceremony. I don't think match is enough on it's own, but when combined with if-let/let-else/?-operator I don't feel like I'm sacrificing significant time and effort in dealing with Results/Options, so I'm not encouraged to cut corners and write worse code to avoid returning them in the first place.

The idiomatic way to write Go discourages you from robust error handling; return an opaque error, which callers will probably deal with as a string (or bubble-up as much as possible) because knowing its potential concrete types requires either reading source code or having documentation available (as the idiomatic function return type won't tell you anything about it). The path of least resistance only goes as far as forcing you to acknowledge there might be an error, it doesn't help you make good decisions about how to deal with it.

I think without also having to learn about lifetimes and dealing with async that this still presents an attractive trade-off for people who want to be quickly productive and don't care as much about garbage collection.

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

#415

Post by 4star3star » Wed, May 01, 2024, 2:28 PM UTC

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.

What does Java offer that dotnet does not?

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

#416

Post by Too » Wed, May 01, 2024, 2:30 PM UTC

mark38848 wrote: post #324

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

How the fuck do you release a language without enums?

To be honest I haven’t seen a single programming language that has decent enums.

With that I mean fundamental and fool proof functions for to/from a string, to/from an int, exhaustive switch cases, pattern matching, enumerating.

Seems like something that wouldn’t be too hard but everybody always fails on something.

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

#417

Post by randomdata » Wed, May 01, 2024, 2:30 PM UTC

mark38848 wrote: post #324

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

How the fuck do you release a language without enums?

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?

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

#418

Post by Capricorn2481 » Wed, May 01, 2024, 2:37 PM UTC

valenterry wrote: post #405

Capricorn2481 wrote: post #389

Earlier quoted context omitted.

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

Too many styles "in Scala," specifically. The point is that some people (not me) prefer to use something restrictive because it keeps everyone on the team from getting too clever with code and making it unreadable. The little bit of extra typing is worth the easier time reading because that's most of what you'll be doing as a coder.

As opposed to an expressive language with powerful macros. Another person could hop on the team and write something that only makes sense to them, and now you have to understand their half-baked DSL.

The burden is on you, in an expressive language, to have a style guide for your team or enforce a style through code reviews. Whereas Golang just has that built-in and obviously is more than capable for writing production software.\

This is a criticism often levied against Scala because you can do pretty much any paradigm in it, and there's lots of disagreements over when to do what paradigm.

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

#419

Post by nindalf » Wed, May 01, 2024, 2:43 PM UTC

lelanthran wrote: post #325

nindalf wrote: post #278

Earlier quoted context omitted.

The ? Operator in Rust?

Good point. I only briefly tried Rust and was turned off by the poor ergonomics; I don't think (i.e. open to correction) that the Rust way (using '?') is a 1:1 replacement for the use-cases covered by Go error management or exceptions. Sometimes (like in the code I wrote about 60m ago), you want both the result as well as the error, like "Here's the list of files you recursively searched for, plus the last error that…

> that the Rust way (using '?') is a 1:1 replacement for the use-cases covered by Go error management or exceptions.

It is a 1:1 replacement.

I think you're thinking of the case when you have many results, and you want to deal with that array of results in various ways.

> Result implements FromIterator so that a vector of results (Vec>) can be turned into a result with a vector (Result, E>). Once an Result::Err is found, the iteration will terminate.

This is one such way, but there are others - https://doc.rust-lang.org/rust-by-example/error/iter_result....

This doesn't handle every case out there, but it does handle the majority of them. If you'd like to do something more bespoke, that's an option as well.

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

#420

Post by randomdata » Wed, May 01, 2024, 2:44 PM UTC

Too wrote: post #416

mark38848 wrote: post #324

Earlier quoted context omitted.

How the fuck do you release a language without enums?

To be honest I haven’t seen a single programming language that has decent enums. With that I mean fundamental and fool proof functions for to/from a string, to/from an int, exhaustive switch cases, pattern matching, enumerating. Seems like something that wouldn’t be too hard but everybody always fails on something.

> I haven’t seen a single programming language that has decent enums.

There's not much you can do with an enumeration. It's just something that counts one-by-one.

A useful tool when you have a large set of constants that you want to number, without having to manually sit there 0, 1, 2, 3... But that's the extent of what it can offer.

> With that I mean fundamental and fool proof functions for to/from a string, to/from an int, exhaustive switch cases, pattern matching, enumerating.

While a programming language may expose this kind of functionality, none of these are properties of enums. They are completely separate features. Which you recognize, given that you are able to refer to them by name. Calling these enums is like calling if statements functions because if statements may be layered with functions.