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

441–450 of 559 posts

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

#441

Post by saghm »

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…

> 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, and pretty much everyone Rust developer I've talked to agrees with this (even if they aren't in the portion that would use this).

It's also pretty common for me to see people asking why someone would use a low-level, C++ language for something like web development, and I think the explanation is pretty similar; people like a lot of what Rust has to offer besides the low-level C++-like semantics, but there isn't something higher-level that offers enough of those features yet. Probably the language that would come closest to this is OCaml, but stuff like the documentation and "multiple preludes" are exactly the kind of thing that add friction to getting up and running, which is something Rust has invested a lot of time into reducing.

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

#442

Post by derefr »

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

> Go is a very opinionated language from it's inception. True. > We could probably argue for all eternity about code formatting, for instance. But Go went and set it in stone. This is part of the story that Rob Pikes uses to justify how opinionated Go is, but it's a bit stupid given that most language do fine and I've never seen any debates about the code formatting after the very beginning of a project (where it's a…

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

In most languages, in a repo without formatting automation, reviewers are often passed these stupid messy PRs that intermingle actual semantic changes, with (often tons of) random formatting touch-ups — usually on just the files touched by the submitter's IDE.

There's a constant chant by code reviewers to "submit formatting fixes as their own PR if there are any needed" — but nobody ever does it.

Golang 1. fixes in place a single "house style", removing the speedbump in the way of automating formatting; and 2. pushes the costs of formatting back to the developer, by making most major formatting problems (e.g. unneeded imports) into compile-time errors — and also, building a formatter into the toolchain where it can be relied upon to be present and so used in pre-commit hooks, guaranteeing that the code in the repo never gets out of sync with proper formatting.

"Getting in the way of the users" is the right thing to do, when "the users" (developers) fan in 1000:1 with code reviewers and release managers, who have to handle any sloppiness they produce.

(Coincidentally, this is analogous to other Google thinking about scaling compute tasks. Paraphrasing: "don't push CPU-bottlenecked workloads from O(N) mostly-idle clients, out to O(log N) servers. Especially if the clients are just going to sit there waiting for the servers' response. Get as much of the compute done on the clients as possible; there's not only far more capacity there, but blocking on the client blocks only the person doing the heavy task, rather than creating a QoS problem." Also known as: "the best 'build server' is your own workstation. We gave you a machine with an i9 in it for a reason!")

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

#443

Post by jntun »

pjmlp wrote: post #427
theshrike79 wrote: post #406

Earlier quoted context omitted.

> A simple settings file set in stone by the CTO, such a hard task to do. And then you have a 100 companies with 100 CTOs resulting in 100 different styles. With Go there is only one style everywhere.

Most people only care about the code of their employer.

[flagged]

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

#444

Post by derefr »

pjmlp wrote: post #428
geodel wrote: post #402

Earlier quoted context omitted.

> A simple settings file set in stone by the CTO, such a hard task to do. It does seem hard thing to do. Working over dozens of enterprise shops in last 15 years I have not see such setting done or dictated at all. So whole codebase used to be mishmash of person styles.

A clear management failure then.

Any CTO who is aware of the impact that having an incoherent programming style can have on employee productivity, is likely going to arrive at the conclusion that the most efficient way to set such policy is to "outsource" it to the programming language, by requiring projects to use an opinionated language.

Then again, any such CTO is likely also going to be someone who tends to think about things like "the ability to hire developers already familiar with the language to reduce ramp-up time" — and will thus end up picking a common and low-expressivity opinionated language. Which usually just means Java. (Although Golang is gaining more popularity here as well, as more coding schools train people in it.)

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

#445

Post by skydhash »

SomeoneFromCA wrote: post #375
AnonymousPlanet wrote: post #363

Earlier quoted context omitted.

Can you name a language that provides more freedoms? I used Lisp as an example for that side of the spectrum because I'm familiar with it, having used it for many years in the past. But maybe there are better examples.

What kind of "freedom", precisely, are you talking about? Freedom to write purely functional programs? Well, then you need Haskell or Clojure at least. Freedom to write small, self sufficient binaries? Well you need C or C++ then. CL is a regular multiparadigm language with a rich macro system, relatively good performance but nonexistent dependency management, too unorthodox OOP, with no obvious benefits compared to…

All of them. You can do imperative, functional, and oop programming in lisp. As for small libraries, it’s because cruft is an actual hindance in lisp. It’s like unix tools, you can do a lot of stuff with them, but a more integrated tool that do one thing better will fare worse in others. A big library brings a rigid way of thinking to lisp flexible model. Dependency management? Think of it like the browser runtime, where you can bring the inspector up and do stuff to the pages. It’s a different devloment models where you patch a live system. And with the smaller dependency model, you may as well vendor the libraries if you want reproductibility. Unorthodox OOP? CLOS is the best oop model out there.

The thing is that Common Lisp has most of what current programming languages are trying to implement. But it does require learning proper programming and being a good engineer.

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

#446

Post by tubthumper8 »

saghm wrote: post #441
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…

> 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

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

#447

Post by derefr »

pjmlp wrote: post #427
theshrike79 wrote: post #406

Earlier quoted context omitted.

> A simple settings file set in stone by the CTO, such a hard task to do. And then you have a 100 companies with 100 CTOs resulting in 100 different styles. With Go there is only one style everywhere.

Most people only care about the code of their employer.

Many shops have to write and submit patches to upstream projects. Some shops have to maintain their own "living fork" version of an upstream project.

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

#448

Post by jjice »

randomdata wrote: post #417
mark38848 wrote: post #324

Earlier quoted context omitted.

How the fuck do you release a language without enums?

You'll have to ask the Rust community. Rust lacks enums. Go, however, most definitely has enums (and exceptions too!). type E int const ( A E = iota B C ) It's funny how people who have clearly never even looked at Go continually think they are experts in it. What causes this strange phenomena?

Go has a way to implement enums - I'll give you that. Rust does have enums though: https://doc.rust-lang.org/book/ch06-01-defining-an-enum.html

They can have values like sum types, or not.

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

#449

Post by shpongled »

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

Lack of sum types and not much support for a functional programming style. I am totally uninterested in any modern programming languages (e.g. post 1980s) that only allows me to express AND (product types, e.g. records, tuples) but not OR (sum types)

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

#450

Post by hgs3 »

pjmlp wrote: post #317
Thaxll wrote: post #202

Earlier quoted context omitted.

No one wants try/catch/exception in Go.

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

It's a tradeoff. Alternatives like exception handling make control flow less obvious and shorthands like the ? operator lock you into a specific return type (Result in the case of Borgo or Rust).
Post reply on HN