Live data from Hacker News

Borgo is a statically typed language that compiles to Go

github.com

201–210 of 559 posts

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

#201

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…

https://www.postgresql.org/docs/current/datatype-enum.html

Then wrap appropriately. Something like sqlc will actually generate everything you need.

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

#202

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!

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

No one wants try/catch/exception in Go.

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

#203
post #146

Why compile to Go rather than less-than-ideal (or even slightly-unsafe) Rust? I find it conceptually compelling, I'm just surprised the target would then be in the GC'd, larger-binary'd direction. Like 'Java expressiveness with C simplicity, transpiles to Java'. Perhaps 'just' because it's a lot simpler to just expand the target language slightly and then you only have to deal with mapping the new bits into implement…

I suspect emitting safe Rust would necessitate your very own implementation of a borrow-checker, or a weak flavor of it, in the language frontend. From there you place yourself in the author's shoes and consider the tradeoffs that come with emitting unsafe Rust. My interpretation of _that_ tradeoff is emitting "something like C++" or "something like Java," to use your analogy. There appears to be less to get wrong.

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

#204
post #202

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

No one wants try/catch/exception in Go.

panic/recover/error?

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

#205

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…

[deleted]

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

#206

Rust is not as complicated as the opening graphic indicates. I usually see this meme from less experienced people but I'm frankly surprised to see it from somebody that's capable of writing a compiler in rust .

There are no labels on the graph's axes :^)

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

#207

Earlier quoted context omitted.

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…

Rust is targeting both users who know the original definition as well as people who don’t. Differentiating between real enums and sum types means the language gets another keyword for a concept that overlaps.

From a PL theory perspective, enum denotes an enumerable set of values within a type. It just happens that sums slot in well enough with that.

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

#208

Earlier quoted context omitted.

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?

I would stand by my original statement, as i don't consider that "intended" or common by modern day standards. Humans hand wrote binary for a while too hah.

If it's not clear, these are just my opinions. Not an attempt at an objective fact or anything.

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

#209
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…

Choosing names is something that often is in the bucket of oh I wish I had thought a little more before sharing these names.
Post reply on HN