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

311–320 of 559 posts

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

#311

Post by noisy_boy »

Mawr wrote: post #298
noisy_boy wrote: post #260

Earlier quoted context omitted.

Rust without borrow checker is much less feasible than Go with Result/Option types to address the nil overdose problem. Unfortunately Go team refuses to acknowledge the common themes coming out of years of user complaints. They don't have to cater to every wishlist but when nil/enum related complaints are the majority in every discussion about issues with Go, one would think to acknowledge the legitimacy of those sho…

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 hasn't been a concerted effort to prioritize these top concerns (I will stand corrected if there is already something underway that I'm not aware of).

One of the proposals you linked has been raised in 2017 and it is still open with "No one assigned"; same fate for the other item. That doesn't inspire confidence in terms of Go team treating these things as top priority.

I think stuff developers are moaning about the most should be top priority but I guess that is just my simpleton thinking.

> I think the problem is not the lack of will on the part of the Go team, but rather that these issues are not easy to fix in a way that fits the language and doesn't cause too many issues with backwards compatibility.

They have made many changes to the language, some significant ones like Generics (which I would assume was also not an easy problem to solve) while they have largely left the elephant in the room unaddressed i.e. error handling - and the developers deal with that one on a daily basis and I would wager a lot more frequently compared to Generics. If I had to gauge their priority, I would go by where they they are putting their money instead of surveys and proposals. And their priorities seem to be different from what the populace is asking. And that is my point.

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

#312

Post by Alifatisk »

metadat wrote: post #5
PurpleRamen wrote: post #4

Earlier quoted context omitted.

Readme says transpile: "Borgo is a new language that transpiles to Go." And it's written in rust. Kinda unholy.

Yeah, the top of the project says "compiles", then the readme says "transpiles". Perhaps the author was just trying to get all the SEO terms in there. > And it's written in rust. Kinda unholy. Agreed, it's like, do you really hate writing Go so much that you'll really write all that Rust to get out of it? Haha. Reminds me of the web frameworks which generated the JS so you didn't have to touch it, like GWT of old. I'…

I’ve totally forgotten about Haxe!

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

#313

Post by ackseq »

to me the problem is not the language per se but the emerging complexity of a project written in a language. I.e. say I'm familiar with go and a k8s user. Does that mean that I can understand the architecture of k8s project and be meaningfully productive in a short period of time? Far from it.

Sometimes I think we focus too much and formalize on the first order tooling we use, language being one of them, while we neglect the layers upon layers of abstractions built on top of them. I wonder whether a meta-language could exist that would be useful in these upper layers. Not a framework that imposes its own logic. More of a DSL that can capture both business logic and architecture.

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

#314

Post by jurschreuder »

lelanthran wrote: post #293
jurschreuder wrote: post #265

Earlier quoted context omitted.

I know it can, the compiler can do one more "automatic" unit test based on the type checking system. But they decided not to add enums because it conflicted and overlapped too much with interfaces. I just want to add "my" experience that personally, yes maybe you can argue enums are nice, but I never missed them in Go. I personally agree with the Go team on how they argue and for me it would be a step back if they li…

> But they decided not to add enums because it conflicted and overlapped too much with interfaces. I'm very curious now about how it might conflict and/or overlap with interfaces. To reach the goal of an enumeration type (and all the strong type-checking that that brings with it), enums could look as simple as: type DayNames enum { Sunday Monday Tuesday Wednesday Thursday Friday Saturday } ... func isFunDay (dow DayN…

I think something like when a variable type in an enum was an interface it would destroy the galaxy or something, not 100% sure, would have to look it up... 1 sec.

Here you Go: https://go.dev/doc/faq#variant_types

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

#315

Post by foldr »

TwentyPosts wrote: post #170
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).

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.

Depends what you mean by 'enums' exactly, but now that generics has been added, a small change would be to allow interfaces defined via type disjunction to be used as concrete types:

    type Option1 struct { ... }
    type Option2 struct { ... }
    type MyEnum interface { Option1 | Option2 }

    var myValue MyEnum // currently not legal Go
That doesn't solve all the use cases for enums / sum types, but it would be useful.

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

#316

Post by lelanthran »

jurschreuder wrote: post #314
lelanthran wrote: post #293

Earlier quoted context omitted.

> But they decided not to add enums because it conflicted and overlapped too much with interfaces. I'm very curious now about how it might conflict and/or overlap with interfaces. To reach the goal of an enumeration type (and all the strong type-checking that that brings with it), enums could look as simple as: type DayNames enum { Sunday Monday Tuesday Wednesday Thursday Friday Saturday } ... func isFunDay (dow DayN…

I think something like when a variable type in an enum was an interface it would destroy the galaxy or something, not 100% sure, would have to look it up... 1 sec. Here you Go: https://go.dev/doc/faq#variant_types

> I think something like when a variable type in an enum was an interface it would destroy the galaxy or something,

Hah :-)

> Here you Go: https://go.dev/doc/faq#variant_types

Not quite the same: Variants are a constrained list of types. Enums are a constrained list of values.

Let's assume that I agree with the reasoning for not having a constrained list of types.

It still doesn't tell me why we can't have a constrained list of values.

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

#317

Post by pjmlp »

Thaxll wrote: post #202
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).

No one wants try/catch/exception in Go.

Because

    if err != nil {
      return err
    }
repeated all over the place, is the epitome of productivity!

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

#318

Post by [deleted] »

lelanthran wrote: post #276
randomdata wrote: post #239

Earlier quoted context omitted.

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

[deleted]

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

#319

Post by sevagh »

throwaway17_17 wrote: post #289

I am genuinely appreciative that a post like this, a GitHub link to a semi-slow moving, but clearly well considered and sincerely developed programming language, can not only remain on the front page of HN, but can generate a diverse and interesting group of discussions. It’s material like this that keeps me coming back to the site. I’m not sure if anyone needed this comment, but I’m sure my posting it isn’t going to…

[flagged]

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

#320

Post by pjmlp »

AnonymousPlanet wrote: post #219
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…

Go is a very opinionated language from it's inception. We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. Maybe it's part of good engineering to keep things simple and not allow hundreds of ways to do something. Maybe the people who use Go are the ones who just want to write and read simple and maintainable code and don't want it to be cluttered with whateve…

It baffles me that so many developers are unable to use pre-comit hooks for their code formatting tools, that exist since the 1990's, to the point go fmt became a revelation.
Post reply on HN