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

471–480 of 559 posts

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

#471

Post by kazinator »

SomeoneFromCA wrote: post #356
AnonymousPlanet wrote: post #307

Earlier quoted context omitted.

Seriously, if you feel patronised by how someone designs a programming language, it might be best to move on. It's obviously not for you. Especially when you feel compelled to bad faith assumptions and ageism over it. For those who want to feel the wind of coding freedom blow through their hair, I can recommend to spend some time learning Lisp. It offers the most freedom you can possibly have in a programming languag…

Most of people who tend to brag about Lisp's (Common Lisp) superiority, never actually used it. It is not as impressive as many legends claim.

Doesn't ring true; why would a non-user of Common Lisp evangelize it?

Are there online examples? Can you point to someone's blog where they are proselytizing regarding Common Lisp, but it's obvious they don't have experience in it (perhaps betrayed by technical problems in their rhetoric).

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

#472

Post by SleekoNiko »

randomdata wrote: post #413
kubanczyk wrote: post #409

Earlier quoted context omitted.

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.

Forgive me as I'm not experienced in Go. I had a look at the API reference for encoding/json[1] and performed a (very hasty) search on the source code[2].

The API reference doesn't state that panics are a part of the expected error interface, and the source code references seem to be using panics as a way to validate invariants. Is that what you're referring to?

I'm not entirely sure if the panics are _just_ for sanity, or if input truly can cause a panic. If it's the latter, then I agree - yikes.

[1] - https://pkg.go.dev/encoding/json

[2] - https://cs.opensource.google/search?q=panic&sq=&ss=go%2Fgo:s...

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

#473

Post by latchkey »

jjallen wrote: post #297
latchkey wrote: post #109

Earlier quoted context omitted.

Which IDE do you use? Mine would flag this as an error pretty quickly.

Goland. How would an IDE know that you intended a struct field to be public or not?

Any non-private usage of a private struct is a compile error.

If you're using goland, it would report this as an error as it is effectively compiling your code as you write it.

Also, autocomplete wouldn't work when you tried to use the private struct.

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

#474

Post by kazinator »

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.

If it were true, it would be because nobody who wants exceptions uses Go. The use of the language is self-selected based on the match between preferences and available features, so then the preferences aren't surprising.

But in fact, there probably exists a minority of developers who somehow had Go foisted upon them, and who would would like it to have basic features like exceptions.

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

#475

Post by derefr »

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 think, for any language that "targets the Golang runtime", you do need some way to express to the runtime to "use the zero-value default initializer." Otherwise, you'd have no hope of code in your language being able to be used to define e.g. protobuf-compatible types; or of using Golang-runtime reflection (due to e.g. the interface zero-value.)

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

#476

Post by kazinator »

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…

> ostracize the non-believers

It is rather the non-believers in exception handling who are the lunatic fringe that benefits from a healthy dose of ostracism.

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

#477

Post by saghm »

deergomoo wrote: post #460
saghm wrote: post #441

Earlier quoted context omitted.

> the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias As someone who has the "Rust bias", I feel like it's a bit of an open secret that a _lot_ of Rust developers don't actually need the extreme low-level performance that it offers and use it more because of the quality of life things (including some of the features in Borgo, but also tooling like cargo, rustdoc, etc…

> but there isn't something higher-level that offers enough of those features yet I think Swift would tick most of those boxes, it’s a shame it hasn’t really picked up outside Apple-land. It can be a horribly complex language, but day-to-day it’s very nice to write.

Yeah, I think would be a good potential candidate if it had a full commitment to support on Linux and Windows, but unless that happens at some point, I don't think I'd consider it over Rust for anything other than Apple-specific development, which isn't something I do

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

#478

Post by saghm »

tubthumper8 wrote: post #446
saghm wrote: post #441

Earlier quoted context omitted.

> the very least--the overwhelming positivity (by HN standards -- even considering the typical Rust bias As someone who has the "Rust bias", I feel like it's a bit of an open secret that a _lot_ of Rust developers don't actually need the extreme low-level performance that it offers and use it more because of the quality of life things (including some of the features in Borgo, but also tooling like cargo, rustdoc, etc…

> I've said for a while that a language that focused on this sort of "developer experience" but used a GC to be a bit more flexible would probably be enough for a large portion of Rust developers Why then would Go not fit? It prioritizes developer experience (documentation, automatic formatting, etc.) with a GC

Those are only examples of things that I think would be necessary; I didn't intend for them to be treated as comprehensive. There are a decent number of things in Go that make me feel like my day-to-day experience of working in it is not a priority compared to a design goal of simplicity for its own sake. For example, when debugging code I often will comment and uncomment portions of it as I run it repeatedly to try to narrow down exactly where something unexpected is happening, and having unused variables be a hard error makes this tedious. Is it possible to work around this by manually "using" the variables I comment out in a way that does nothing? Of course. Would it be more "proper" to use a debugger rather than doing something hackish on my own? Possibly! But is this an actual thing that I expect a large number of other developers also do in pretty much every other language without issue? I strongly suspect the answer is yes.

Things like this might be small, but they add up, and at the end of the day, the frustrations that I encounter when writing Rust are smaller and less frequent than the ones I've had writing Go. Obviously stuff like this is subjective, and there's no way to make a language that satisfies everyone. I think there's empirical evidence that there's an audience for a language that fits the niche I describe that Go doesn't fill though.

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

#479

Post by IshKebab »

Capricorn2481 wrote: post #469
IshKebab wrote: post #458

Earlier quoted context omitted.

The biggest difference is that you can see where errors can happen and are forced to consider them. For example imagine you are writing a GUI app with an integer input field. With exception style code the overwhelming temptation will be to call `string_to_int()` and forget that it might throw an exception. Cut to your app crashing when someone types an invalid number. Now, you can handle errors like this properly wit…

> But generally it's extremely tedious and verbose Is it? In my experience it's very short, especially considering you can catch multiple errors. Do my users really need a different error message for "invalid sql" vs "sql connection timeout?" They don't need to know any of that. > There's also the fact that stack traces are not proper error messages I would say there's not a proper error message to derive from explic…

> Do my users really need a different error message for "invalid sql" vs "sql connection timeout?"

Yes! A connection timeout means it might work if they try again later. Invalid SQL means it's not going to fix itself.

But in any case, the error messages are probably the minor part. The bigger issue is about properly handling errors and not just crashing the whole program / endpoint handler when something goes wrong.

> I would say there's not a proper error message to derive from explicitly handling sql errors. Certainly not a different message per error. I would rather capture all of it and say something like "Something went wrong while accessing the database. Contact an admin." Then log the stack trace for devs

Ugh these are the worst errors. Think about the best possible action that the user could take for different failure modes.

"Contact an admin" is pretty much always bottom of the list because it rarely works. More likely options are "try again later", "try different inputs", "clear caches and cookies", "Google a more specific error".

Giving up on making an error message because you only have a stack trace and don't want to show it means users can't pick between those actions.

If you have written a "something went wrong" error I literally hate you.

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

#480

Post by randomdata »

jjice wrote: post #470
randomdata wrote: post #451

Earlier quoted context omitted.

> Rust does have enums though It does not. You'll notice that if you read through your link. A tag-only union is not the same thing, even if you can find some passing similarities. If you mean it has enums like the Democratic People's Republic of Korea has a democracy, then sure, it does have enums in that sense. I'm not sure that gives us anything meaningful, though. If we're being honest, sum types are the better s…

> A tag-only union is not the same thing, even if you can find some passing similarities Why not? Seems to function the same way.

Enums produce values. Tag-only unions 'produce' types (without values).

Realistically, there isn't a whole lot of practical difference. They were both created to try and solve much the same problem. As before, I posit that there is no need for a language to have both. You can do math on enum values, but that is of dubious benefit. In theory, tag-only unions provide type safety, whereas enums are just values so there is no inherit safety... But, as you probably immediately recognized a few comments back, with some static analysis you can take the greater view,

    type E int
    const (
        A E = iota
        B
        C
    )
and invent something that is just as useful as proper type safety. All the information you need is there. So, in reality, that need not even be significant.

But, technically there is a difference. Values and types are not the same thing.

Post reply on HN