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

181–190 of 559 posts

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

#181

Post by unshavedyak »

randomdata wrote: post #102
unshavedyak wrote: post #82

Earlier quoted context omitted.

Yea, not sure i disagree with anything being said here. Though to me, transpiler just typically means it goes from one language i could write, to another i could write. I don't necessarily expect to enjoy reading or perhaps even understanding the JavaScript output from any lang that builds to JS, for example.

> transpiler just typically means it goes from one language i could write, to another i could write. What possible compiler target couldn't you write? Compilers are not exactly magic.

Fair, by "could write" i meant one intended for humans to write. Ie i would not say LLVM bytecode is intended for humans to write by hand. Can they? Sure.

The difference (to the parent comment) in my eyes is that the target language is the thing intended for humans, not the target output itself. As another commenter points out, transpiled code is often not intended for humans, even if the language is.

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

#182

Post by randomdata »

drdaeman wrote: post #175
TwentyPosts wrote: post #170

Earlier quoted context omitted.

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.

> but the main reason why people want them is to fix the error handling Why do you think so? Maybe I'm an odd case, but 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. Or for state machines. Error handling is manageable without enums (but I love Option/Result types more than Go's error approach, e…

> 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 Hot struct{}
    func (Hot) temp() {}

    type Cold struct{}
    func (Cold) temp() {}

    type Temperature interface {
        temp()
    }

    func SetThermostat(temperature Temperature) {
        switch temperature.(type) {
        case Hot:
            fmt.Println("Hot")
        case Cold:
            fmt.Println("Cold")
        }
    }

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

#183

Post by kbenson »

jurschreuder wrote: post #174
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).

I've never needed either. Try/catch is super confusing because the catch is often far away from the try. And in Python I just put try/catch around big chunks of code just in case for production. I think Go is more stable and readable because they force you not to use the lazy unreadable way of error handling. Enums I honestly never used in Go also not the not-type-safe ones. But I'm also someone who used interfaces i…

I think what this comment is missing is any sort of analysis of how your experience maps to the general go user, and an opinion on while you've never needed either whether you think it could have provided any benefit when used appropriately.

For example, and option type with enums combined can ensure return values are checked by providing a compile time error if a case is missing (as expressed in the first few examples of the readme).

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

#184

Post by samatman »

lordofgibbons wrote: post #40

Wow, this is everything I want from a new Go! Having worked on multiple very large Go codebases with many engineers, the lack of actual enums and a built-in optional type instead of nil drive me crazy. I think I'm in love. Edit: Looks like last commit was 7 months ago. Was this abandoned, or considered feature complete? I hope it's not abandoned!

While I have no particular beef with Rust deciding to call its sum types "enum", to refer to this as the actual enum is a bit much.

Enumerated types are simply named integers in most languages, exactly the sort you get with const / iota in Go: https://en.wikipedia.org/wiki/Enumerated_type

Rather than the tagged union which the word represents in Rust, and only Rust. Java's enums are close, since they're classes and one can add arbitrary behaviors and extra data associated with the enum.

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

#185

Post by nasretdinov »

2024throwaway wrote: post #180
nasretdinov wrote: post #131

Earlier quoted context omitted.

Look at your list of built-in modules though :)

So stdlib counts as dependencies now?

Well stdlib normally doesn't have stuff like Oracle drivers and such. I think one of the reasons why PHP tends to need so few external dependencies is because it has so many extensions to cover basically anything that you don't need PHP libraries all that much. I don't personally see it as a bad thing but it's something worth considering.

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

#186

Post by gr4vityWall »

samatman wrote: post #184
lordofgibbons wrote: post #40

Wow, this is everything I want from a new Go! Having worked on multiple very large Go codebases with many engineers, the lack of actual enums and a built-in optional type instead of nil drive me crazy. I think I'm in love. Edit: Looks like last commit was 7 months ago. Was this abandoned, or considered feature complete? I hope it's not abandoned!

While I have no particular beef with Rust deciding to call its sum types "enum", to refer to this as the actual enum is a bit much. Enumerated types are simply named integers in most languages, exactly the sort you get with const / iota in Go: https://en.wikipedia.org/wiki/Enumerated_type Rather than the tagged union which the word represents in Rust, and only Rust. Java's enums are close, since they're classes and o…

Haxe also has Enums which are Generalized Algebraic Data Types, and they are called "enums" there as well: https://haxe.org/manual/types-enum-using.html

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

#187

Post by randomdata »

unshavedyak wrote: post #181
randomdata wrote: post #102

Earlier quoted context omitted.

> transpiler just typically means it goes from one language i could write, to another i could write. What possible compiler target couldn't you write? Compilers are not exactly magic.

Fair, by "could write" i meant one intended for humans to write. Ie i would not say LLVM bytecode is intended for humans to write by hand. Can they? Sure. The difference (to the parent comment) in my eyes is that the target language is the thing intended for humans, not the target output itself. As another commenter points out, transpiled code is often not intended for humans, even if the language is.

Machine code is intended to be written by humans. That was the only way to program computers at one point in time. Given a machine code target, would you say it is product of transpilation or compilation?

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

#189

Post by samatman »

gr4vityWall wrote: post #186
samatman wrote: post #184

Earlier quoted context omitted.

While I have no particular beef with Rust deciding to call its sum types "enum", to refer to this as the actual enum is a bit much. Enumerated types are simply named integers in most languages, exactly the sort you get with const / iota in Go: https://en.wikipedia.org/wiki/Enumerated_type Rather than the tagged union which the word represents in Rust, and only Rust. Java's enums are close, since they're classes and o…

Haxe also has Enums which are Generalized Algebraic Data Types, and they are called "enums" there as well: https://haxe.org/manual/types-enum-using.html

Very well then: Rust is not the only one to call a variant type / tagged union an enum. It's a nice language feature to have, whatever they decide to call it.

It remains a strange choice to refer to this as the true enum, actual enum, real enum, as has started occurring since Rust became prominent. If that's a meaningful concept, it means a set of numeric values which may be referred to by name. This is the original definition and remains the most popular.

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

#190

Post by blueberry87 »

randomdata wrote: post #182
drdaeman wrote: post #175

Earlier quoted context omitted.

> but the main reason why people want them is to fix the error handling Why do you think so? Maybe I'm an odd case, but 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. Or for state machines. Error handling is manageable without enums (but I love Option/Result types more than Go's error approach, e…

> 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
Post reply on HN