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

531–540 of 559 posts

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

#531

Post by Capricorn2481 »

IshKebab wrote: post #518
Capricorn2481 wrote: post #488

Earlier quoted context omitted.

That has nothing to do with having exceptions, Rust just has a good type system (something go doesn't have). But again, handling an error doesn't necessarily prevent bugs. Just because you handled an error doesn't mean the error won't happen in Prod. It just means when it does, you wrote a message for it or custom behavior. Which could be good, or it might be functionally as effective as returning a stack traces mess…

> That has nothing to do with having exceptions It absolutely does. Checked exceptions sort of half get there too but they are quite rarely used (I think they are used in Android quite well). They were actually removed from C++ because literally nobody used them. > handling an error doesn't necessarily prevent bugs. I never made that claim. > I've never seen people not handle errors that the user could do anything wi…

> We already talked about "something went wrong" messages. Surely you have seen one of those?

My point is that "something went wrong" messages are for errors the user CANT and SHOULDNT do anything with.

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

#532

Post by derefr »

fire_lake wrote: post #510
derefr wrote: post #442

Earlier quoted context omitted.

> most language do fine No, they don't. Most languages turn dealing with code formatting, into an externality foisted upon either: • the release managers (who have to set up automation to enforce a house style — but first have to resolve interminable arguments about what the given project's house style should be , which creates a disincentive to doing this automation); or • the people reviewing code in the language.…

Ironic given how much effort is going into Bazel remote build executors.

Snarky response: that's more steps toward the long-held dream of the Google operations department: to be able to just issue all devs cheap commodity Chromebooks, because all the compute happens on a (scale-to-zero) Cloud Shell or Cloud Workstation resource.

Actual response:

• For dev-time iteration, you want local builds; for large software (e.g. Chrome), you make this work by making builds incremental. So it takes a few hours to build locally the first time you build, but then it's down to 30s to rebuild after a change.

• But for building releases, you can't rely on incremental builds; incremental builds (i.e. building on top of a cache from previous arbitrary builds) would be non-deterministic and give you non-reproducible builds, exactly what a release manager doesn't want. So releases, at least, are stuck needing to "build the world." You want to accelerate those — remote build infra is the way to go. Remote, distributed build infra, ideally (think: ccache on Flume.)

These remote/distributed builds do still cohere to the philosophy in the abstract, though — a remote build is not the same as a CI build, after all; the dev's own workstation is still acting as the planner and director of the build process.

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

#533

Post by lsaferite »

throw-the-towel wrote: post #506
Capricorn2481 wrote: post #398

Earlier quoted context omitted.

> The idea that error handling is "not part of the code" is silly though. My impression of people that hate Go's explicit error handling is that they don't want to deal with errors properly at all. "Just catch exceptions in main and print a stack trace, it's fine." I'm honestly asking as someone neutral in this, what is the difference? What is the difference between building out a stack trace yourself by handling err…

> What is the difference between building out a stack trace yourself by handling errors manually, and just using exceptions? You cannot force your dependencies to hand you a stack trace with every error. But in languages that use exceptions a stack trace can be provided for "free" -- not free in runtime cost, but certainly free in development cost.

This one frustrates me a lot. Not getting a proper trace of the lib code that generated an error makes debugging what _exactly_ is going on much more of a PITA. Sure, I can annotate errors in _my_ code all day long, but getting a full trace is a pain.

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

#534

Post by rnmmrnm »

pjmlp wrote: post #352
rnmmrnm wrote: post #340

Earlier quoted context omitted.

sane error handling in go is more productive any day.

Calling if boilerplate sane is an oxymoron.

tbh only like 50% of my `if err != nil { return err }` are mindless. rest of the time, the fact that error handling is explicit and in my face has helped me alot during my time with go.

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

#535

Post by rnmmrnm »

randomdata wrote: post #358
rnmmrnm wrote: post #281

Earlier quoted context omitted.

the day the go codebase throws random panics is the day I quit the company.

So you quit the day encoding/json was written?

you wrap those properly. believe me waking up in the middle of the night because someone abused panic to throw state around, end up being called from a new goroutine, just enough to crash the entire pod, sucks even more.

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

#536

Post by randomdata »

modulared wrote: post #524
randomdata wrote: post #480

Earlier quoted context omitted.

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…

> Enums produce values. Tag-only unions 'produce' types (without values). Source? Is this something that is widely accepted, or just how you think enums should be defined. My understanding is you are saying (using c++ as an example since it has both types) an `enum` is a "true" enum, while an `enum class` somehow isn't?

> Source?

To which language?

> `enum` is a "true" enum, while an `enum class` somehow isn't?

No. Enums are used in both cases. The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class.

This differs from Rust. Rust does not use enums. It relies on the type itself to carry all the information. C++ enum classes could have done the same, so it is not clear why they chose to use enums, but perhaps for the sake of familiarity or backwards compatibility with the regular enum directive?

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

#537

Post by fire_lake »

derefr wrote: post #532
fire_lake wrote: post #510

Earlier quoted context omitted.

Ironic given how much effort is going into Bazel remote build executors.

Snarky response: that's more steps toward the long-held dream of the Google operations department: to be able to just issue all devs cheap commodity Chromebooks, because all the compute happens on a (scale-to-zero) Cloud Shell or Cloud Workstation resource. Actual response: • For dev-time iteration, you want local builds; for large software (e.g. Chrome), you make this work by making builds incremental. So it takes a…

Appreciate a proper response to my throw away comment :)

> incremental builds (i.e. building on top of a cache from previous arbitrary builds) would be non-deterministic and give you non-reproducible builds

Isn’t this exactly what Bazel solves?

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

#538

Post by sushisource »

jdknezek wrote: post #164
sushisource wrote: post #154

Earlier quoted context omitted.

Most importantly: Null pointers still exist (yes I know they technically exist in unsafe Rust, to head off any pedants) Also: No `?` operator

There is a `?` operator: https://github.com/borgo-lang/borgo?tab=readme-ov-file#error...

Oh! Cool somehow I missed that

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

#539

Post by sharno »

Hasnep wrote: post #221

About a year ago, I tried writing a language that transpiled to Go with many of the same features, in my research I found other attempts at the same idea: - braid: https://github.com/joshsharp/braid - have: https://github.com/vrok/have - oden: https://oden-lang.github.io/

There was also purescript: https://github.com/andyarvanitis/purescript-native

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

#540

Post by modulared »

randomdata wrote: post #536
modulared wrote: post #524

Earlier quoted context omitted.

> Enums produce values. Tag-only unions 'produce' types (without values). Source? Is this something that is widely accepted, or just how you think enums should be defined. My understanding is you are saying (using c++ as an example since it has both types) an `enum` is a "true" enum, while an `enum class` somehow isn't?

> Source? To which language? > `enum` is a "true" enum, while an `enum class` somehow isn't? No. Enums are used in both cases. The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class. This differs from Rust. Rust does not use enums. It relies on the type itself to carry all the information. C++ enum classes could have done the same, so it is not cl…

> To which language?

I mean more in the sense of "where did you get this definition from."

> The difference there is in the types the enums are applied to. In one case, a basic integer-based type. In the other, a class.

I'm still not seeing a difference, mainly because when I went to see how c++'s `enum class` and rust's `enum`, they both seemed to work the same.

    #[repr(u8)]
    enum Words {
        Foo = 0,
        Bar,
        Baz,
    }

    const _: () = {
        assert!(Words::Foo as u8 == 0);
        assert!(Words::Bar as u8 == 1);
        assert!(Words::Baz as u8 == 2);
    };
vs

    enum class Words : uint8_t {
     Foo = 0,
     Bar,
     Baz
    };

    static_assert(static_cast(Words::Foo) == 0);
    static_assert(static_cast(Words::Bar) == 1);
    static_assert(static_cast(Words::Baz) == 2);
Post reply on HN