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

551–559 of 559 posts

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

#551

Post by derefr »

fire_lake wrote: post #537
derefr wrote: post #532

Earlier quoted context omitted.

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?

It tries, but it's really more of an operational benefit (i.e. works to your advantage to enable build traceability and avoid compile-time Heisenbugs, when you the developer can hold your workstation's build-env constant) than a build-integrity one (i.e. something a mutually-untrustworthy party could use to audit the integrity of your build pipeline, by taking random sample releases and building them themselves to the same resulting SHA — ala Debian's deterministic builds.)

Bazel doesn't go full Nix — it doesn't capture the entire OS + build toolchain inside its content-fingerprinting to track it for changes between builds. It's more like Homebrew's build env — a temporary sandbox prefix containing a checkout of your project, plus symlinks to resolved versions of any referenced libs.

Because of this, you might build, upgrade an OS package referenced in your build or containing parts of your toolchain, and then build again, Bazel (used on its own) doesn't know that anything's different. But now you have a build that doesn't look quite like it would if you had built everything with the newest version of the package.

I'm not saying you can't get deterministic builds from Bazel; you just have to do things outside of Bazel to guarantee that. Bazel gets you maybe 80% of the way there. Running the builds inside a known fixed builder image (that you then publish) would be one way to get the other 20%.

I have a feeling that Blaze is probably better for this, though, given all the inherent corollary technologies (e.g. objFS) it has within Google that don't exist out here.

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

#552

Post by derefr »

littlestymaar wrote: post #543
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.…

> No, they don't. Really, they do: there a millions of us coding in those other languages just fine, and automatic formatting has been a thing for decade, and I'm not aware of a single language out there that doesn't have such a formatting tool. The only exception with Go is that you cannot change the default settings. But that's it. In any other language you can use a code formatter with the default settings and the…

> You know that a failing git hook aborts the commit? So that with any language, if the formatter isn't installed in the machine, the commit cannot be performed, which means that the formatter can actually be relied upon anyway.

When making a trivial fix PR to an upstream FOSS project, if I find that a missing third-party linter install has force-rejected my commit (that I know has correct syntax)... then I just give up on making that PR. I can't be assed to install some random linter. (Third-party linters have a history of being horrible to install†.)

Small amounts of friction can be enough to shape behavior (see https://en.wikipedia.org/wiki/Nudge_theory.) Aggregated over a large project's entire community, this can make an appreciable difference in code quality over time.

† Mind you, a linter that exists as a library dev dependency of the project is fine, too. I had to pull the deps to build and run the tests, so the linter will be there by the time I attempt to commit. It's just linters that are their whole own projects that give me a jaw-ache.

> and the endless stream of Gophers who argue this are just ridiculing themselves in front of everybody else.

I don't even use Go! I mainly write Elixir, actually. Which also has a built-in auto-formatter.

To me, the nice thing about the formatter being built into Elixir (and of-a-piece with the compiler), is that when I use macros, the purely-in-memory generated-and-compiled code can be inspected in the REPL, and shows as formatted (because it passes through the auto-formatter), rather than looking like AST gunk. Without having had to pay that auto-formatting cost at compile time (because that would also be a cost you'd pay at runtime codegen time, which you might do a lot of if you've built a domain-specific JIT on top of the macro system.)

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

#553

Post by Mawr »

littlestymaar wrote: post #543
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.…

> No, they don't. Really, they do: there a millions of us coding in those other languages just fine, and automatic formatting has been a thing for decade, and I'm not aware of a single language out there that doesn't have such a formatting tool. The only exception with Go is that you cannot change the default settings. But that's it. In any other language you can use a code formatter with the default settings and the…

It's easy for programmers to focus on the technical details and forget the big picture. The technical aspects of automatically formatting code are relatively easy to solve. The difficulty is in the social parts. That's what Go solved by bundling gofmt with the language.

As a result, almost all Go code out there is formatted the exact same way and nobody has ever had to have the dreaded code formatting discussion about Go at their company. Eliminating such bikeshedding for every user of the language is a solid win.

That's why all the languages proceeding Go have adopted the same approach, e.g. Rust and Zig. Python's Black formatter has been directly inspired by gofmt as well.

What is provided by default really matters.

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

#554

Post by fire_lake »

taylodl wrote: post #545
fire_lake wrote: post #541

Earlier quoted context omitted.

Better than Go? Yes Rust, Haskell, OCaml all do it better. Better than those? Probably - the design space has hardly been explored!

I was looking to modernize my skills in systems languages as C++ is my systems language of choice at the moment and I'd been deciding between Go and Rust (I know, to call Go a "systems" language is a bit of a stretch, but what we call a "system" is also a bit different these days) and I've decided it's going to be Rust.

Go has more in common with Java or C# than Rust. You can get a Rust like experience with the latest C++ standard and a lot of tooling on top. That’s the true alternative in my view.

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

#555

Post by jurschreuder »

throwaway2037 wrote: post #501
jurschreuder wrote: post #264

Earlier quoted context omitted.

I actually really have a disrespect for them. I'm in a constant fight against developers that want to translate code in almost the same code but "only using language features from the Advanced book". I also wanted to add that I used inheritance only ONCE in all my years of writing Python in all other millions of lines of code inheritance was not the best solution. This is my daily struggle as a CTO. People using waaa…

> This is my daily struggle as a CTO This is a nice humblebrag. Why does it matter that you are a CTO for this comment? It doesn't. It would better written as: "This is my daily struggle with my team."

Haha I actually thought about that maybe 8 times haha I just wrote it and pressed send but exactly that I wanted to edit later XD.

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

#556

Post by knighthack »

tomjen3 wrote: post #436
AnonymousPlanet wrote: post #219

Earlier quoted context omitted.

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…

We have completely lost the plot by assuming that just because there are disagreements on somethings then any choice is equally as good as any other. Go is opinionated and it is opinion is wrong. Not having exceptions (but then having them anyway through panic, but whatever) is a choice - but the other reasonable alternative is the Maybe monad. What Go did is not reasonable. I might be okay if they had been working o…

> But then I try to write code in it and so. much. boilerplate.

If boilerplate is cause for you to dislike the language, fine.

But your unnecessarily strong language "Go is opinionated and it's opinion is wrong", "What Go did is not reasonable", "I have a specific hatred for Go" speaks more about you than Go.

Go's choice of trade-off much was practical and reasonable, engineering-wise.

Your opinion is entirely wrong.

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

#557

Post by tail_exchange »

Option instead of nil is amazing. Imo, the biggest flaw in Go's design is having nils instead of optionals.

I don't have a strong opinion on Result and Pattern matching - it seems nice, but I don't know if it adds much to the language. It is nice, but it may not be worth the complexity.

The error handling with ? is a no for me. I'd rather have something more like the go-errors/errors package in the standard library instead. This has been proposed before, and it was rejected for a good reason: it makes it too easy to be lazy and just bubble up errors instead of properly handling them.

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

#558

Post by anacrolix »

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.

Speak for yourself. Without decent error type handling, exception handling is inevitable.

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

#559

Post by damnever »

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.

Swift doesn't have explicit namespaces, which is a real inconvenience.
Post reply on HN