Borgo is a statically typed language that compiles to Go

That's hardly the point. The point is that there is a single format for the language itself and you don't have to argue about spaces vs tabs vs when to line break, whether you want trailing commas and where to put your braces.

You can format on save or in a pre commit hook. But that the language has a single canonical format makes it kind of new.

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 language. It might enlighten you in many other ways. It won't be the last language you learn, but it might be the most fruitful experience.

Rob Pike... and Ken Thompson, and Robert Grisemer.

Firstly, Ken Thompson is a master at filtering out unnecessary complexities and I highly rate his opinion of the important and unimportant things.

Secondly, the Go team were never against generics, the three early designers agreed the language needed generics but they couldn't figure out a way to add it orthogonally.

Go has gone on to be very successful in cloud and networked applications (which it was designed to cater for), which lends credit to the practicalities of what the designers thought as important, HN sentiments notwithstanding.

give some kind of coherence to it (looking at you Java and C++)

I have never done any real programming in Java itself, but the parts of Java world that I learned while writing some Clojure circa 2015 felt pretty coherent. Now I'm curious what I missed.

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!")

Maybe in the pursuit of an opinionated language, even if the designers are reasonable at the language's inception, the community throws out logic and "opinionated" becomes a in-group out-group tribal caveman situation.

I think you've got this backward. It's not that the particular choices are important. It's a thing happening on a higher meta level than that.

Some programming languages are, by design intent, "living" languages, evolving over time, with features coming and going as the audience for the language changes.

"Living" languages are like cities: the population changes over time; and with that change, their needs can shift; and they expect the language to respond with shifts of its own. (For example: modern COBOL is an object-oriented language. It shifted to meet shifting needs of a new generation of programmers!)

If you were able to plot the different releases of a living language in an N-dimensional "language-design configuration space", these releases would appear to arbitrarily jump around the space.

Other languages, though, are, by their design intent, "crystallized" languages — with each component or feature of the language seeing ever-finer refinement into a state of (what the language maintainers consider) perfection; where any component that has been "perfected" sees no further work done, save for bugfixes. For such languages, creating a language in this way was always the designers' and maintainers' goal — even before they necessarily knew what they were creating.

"Crystallized" languages are like paintings: there was an initial top-down rough vision for the language (a sketch); and at some early point, most parts of the design were open for some degree of change, when paint was first being applied to canvas. But as the details were filled in in particular areas, those areas became set, even varnished over.

If you plot the successive releases of a crystallized language in design configuration space, the releases would appear to converge upon a specific point in the space.

The goal with a crystallized language is to explore the design space to discover some interesting point, and then to tune into that interesting point exactly — to "perfect" the language as an expression of that interesting concept. Every version of the language since the first one has been an attempt to find, and then hit, that point in design space. And once that point in design space is reached, the language is "done": the maintainers can go home, their jobs complete. Once a painting says what it "should" say, you can stop painting it!

If a crystallized language is small, it can achieve this state of being entirely "finished", its spec set in stone, no further "core maintainer" work needed. Some small crystallized languages are even finished the moment they start. Lua is a good example. (As are most esolangs — although they're kind of a separate thing, being created purely for the sake of "art", rather than sitting at the intersection of "work of art" and "useful tool" as crystallized languages do.)

But large crystallized languages do exist. They seek the same fate as small crystallized languages — to be "finished" and set in stone, the maintainers' job complete. They just rarely get there, because of how large a project it is to refine a language design.

You might intuitively associate a "living" language with democratic control, and a "crystallized" language with a Benevolent Dictator For Life (BDFL) figure with an artistic vision for the language. But this is not necessarily true. Python was a "living" language even when it had a BDFL. And Golang is a "crystallized" language despite its post-1.0 evolution being (essentially) directed by committee.

---

The friction you're describing, comes from developers who are used to living languages, trying to apply the same thinking about "a language changing to serve the needs of its users" to a crystallized language.

Crystallized languages do not exist primarily to serve their users. They exist to be expressions of specific points in design space, quintessences of specific concepts. Those points in design space likely are useful (esolangs excluded); but the expectation is that people who don't find that point in design space useful, should choose a different language (i.e. a different point in design space) that's more suited to their needs, rather than attempting to shift the language's position in design space.

Adding a bridge is a sensible proposal for a city. You can get entire streets of buildings torn down to make way for the bridge, if the need is there. But adding a bridge is not not a sensible proposal for a (mostly-finished) painting. If you want "this painting but with a bridge in it", that's a different painting, and you should seek out that painting. Or paint it yourself. Or paint the bridge on some kind of transparent overlay layer, and hang that overlay in front of the painting.

Conveniently for this discussion, Borgo here is exactly an example of a language that's "someone else's painting, but now with the bridge I wanted painted on an overlay in front of it." :)

Go doesn't use exceptions as a primary way of handling errors, which is what we're talking about here. Pedantry is not welcome.

Well, flexibility has its price. And yeah, if you need to work in a team that uses a very different style, then you won't like it.

On the other hand, if you carefully select your team or work alone, then this is not a problem at all.

Btw, there isn't really "one" idiomatic scala style - therefore I tend to believe that you are not familiar with the language and the community.

libraries, and I thank God I don't have to work on Windows and thus don't know how smart Visual Studio Enterprise is, but IJ is world class in the number of bugs it'll catch

"+ frontend" only if you squint really hard, I think

I nearly wrote "you are holding it wrong" to nod to that quote. But it is really true - most errors in long running services are individual and most applications I've worked in ignore this when (ab)using exceptions.

In our Go codebases, the error reporting and subsequent debugging and bug fixing is night and day from our Python, Perl, Ruby, PHP, Javascript, and Elixir experiences.

The one glaring case where this is untrue is in our usage of Helm which, having been written in Go, I would expect better error handling. Instead we get, "you have an error on line 1; good luck" - and, inspired, I looked at their code just now. Littered with empty if-err-return-err blocks - tossing out all that beautiful context, much like an exception would, but worse.

https://github.com/search?q=repo%3Ahelm%2Fhelm%20%20if%20err...

sane error handling in go is more productive any day.

So you quit the day encoding/json was written?

As an experienced Go dev, this is literally not a problem.

Golang code has a rhythm: you do the thing, you check the error, you do the thing, you check the error. After a while it becomes automatic and easy to read, like any other syntax/formatting. You notice if the error isn't checked.

Yes, at first it's jarring. But to be honest, the jarring thing is because Go code checks the error every time it does something, not because of the actual "if err != nil" syntax.

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

Rust's error handling is clearly better than Go's, but Go's is better than exceptions and the complaints about verbosity are largely complaints about having to actually consider errors.

Sure, I just don't think it's that significant. Humans don't read/parse code character-by character, we do it by recognizing visual patterns. Blocks of `if err != nil { }` are easy to skip over when reading if needed.

I find that knowing where my errors may come from and that they are handled is essential to my job and missing all that info because it is potentially in a different file altogether gets in the way

Good point.

I only briefly tried Rust and was turned off by the poor ergonomics; I don't think (i.e. open to correction) that the Rust way (using '?') is a 1:1 replacement for the use-cases covered by Go error management or exceptions.

Sometimes (like in the code I wrote about 60m ago), you want both the result as well as the error, like "Here's the list of files you recursively searched for, plus the last error that occurred". Depending on the error, the caller may decide to use the returned value (or not).

Other times you want an easy way to ignore the error, because a nil result gets checked anyway two lines down: Even when an error occurs, I don't necessarily want to stop or return immediately. It's annoying to the user to have 30 errors in their input, and only find out about #2 after #1 is fixed, and #3 after #2 is fixed ... and number #30 after #29 is fixed.

Go allows these two very useful use-cases for errors. I agree it's not perfect, but with code-folding on by default, I literally don't even see the `if err != nil` blocks.

Somewhat related: In my current toy language[1], I'm playing around with the idea of "NULL-safety" meaning "Results in a runtime-warning and a no-op", not "Results in a panic" and not "cannot be represented at all in a program"[2].

This lets a function record multiple errors at runtime before returning a stack of errors, rather than stack-tracing, segfaulting or returning on the first error.

[1] Everyone is designing their own best language, right? :-) I've been at this now since 2016 for my current toy language.

[2] I consider this to be pointless: every type needs to indicate lack of a value, because in the real world, the lack of a value is a common, regular and expected occurrence[3]. Using an empty value to indicate the lack of a value is almost certainly going to result in an error down the line.

[3] Which is where there are so many common ways of handling lack of a value: For PODs, it's quite popular to pick a sentinel value, such as `(size_t)-1`, to indicate this. For composite objects, a common practice is for the programmer to check one or two fields within the object to determine if it is a valid object or not. For references NULL/null/nil/etc is used. I don't like any of those options.

More than just that, Result in general also prevents from accessing the value when there is an error and accessing an error when there is a value.

In Go, no one really blindly returns nil, err. People very clearly think about errors—if an error may need to be actioned on up the stack, people will either create a named error value (e.g., `ErrInvalidInput = errors.New(“invalid input”)` or a named error type that downstream users can check against. Moreover, even when propagating errors many programmers will attach error context: `return nil, fmt.Errorf(“searching for the flux capacitor `%s`: %w”, fluxCap, err)`. I think there’s room for improvement, but Go error handling (and Rust error handling for that matter) seem to be eminently thoughtful.

I don't see how it's possible to do it blindly unless the code gets autogenerated. If you're typing the `if err != nil` then you've clearly understood that an error path is there.

There's no requirement for the calling function to handle each possible type of error of the callee. It can, as long as the callee properly wrapped the error, but it's relatively rare for that to be required. Usually the exact error is not important, just that there was one, so it gets handled generically.

See the example with the `?` operator: https://github.com/borgo-lang/borgo?tab=readme-ov-file#error...

The main benefits of a Result type are brevity and the inability to accidentally not handle an error.

exactly.. yes, I understand why ? is neat from a type POV since you specifically have to unwrap an optional type whereas in Go you can ignore a returned error (although linters catch that) - so at the end of the day it's just the same boilerplate, one with ? the other with err != nil

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

    func SetThermostat(temperature Temperature) {
        switch temperature {
        case Hot:
            fmt.Println("Hot")
        case Cold:
            fmt.Println("Cold")
        }
    }

    type Temperature int

    const (
        Hot  Temperature = 0
        Cold Temperature = 1 
    )

    func SetThermostat(temperature Temperature) {
        switch temperature {
        case Hot:
            fmt.Println("Hot")
        case Cold:
            fmt.Println("Cold")
        }
    }

Enums are exactly sums of unit types (types with only one value).

Couldn't the zero value be nil? I get that some types like int are not nil-able, but the language allows you to assign both nil and int to a value of type any (interface{}), so I wonder why it couldn't work the same for sum types. i.e. they would be a subset of the `any` type.

Said "requirement" is only a human construct. The computer doesn't care.

If the humans choose to make an exception for that, it can be done. Granted, the planning that has taken place thus far has rejected such an exception, but there is nothing about Go that fundamentally prevents carving out an exception.

You can just default to the first variant, no?

How is that better than

    if value != nil {
        // value is valid
    }
    // value is invalid

Of course, this is often left out, but you can just as easily do:

    value, _ := option.Get()

Using an Option instead of a pointer buys you the inability to forget to check for nil.

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.

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

Machine code is intended to be written by humans. That was the only way to program computers at one point in time. Given a machine code target, would you say it is product of transpilation or compilation?

, but I think it requires a level of willful obtuseness or excessive pedantry to deny that there is something behind the concept of a transpiler.

Transpiler means something. Fuzzily. And it defines and denotes nothing of practical utility.

This discussion wouldn't even be happening if transpiler were a completely meaningless term

This discussion wouldn’t even be happening if (people like) JS programmers didn’t insist on using terminology that implied some archaic view of technology, like “compilers emit machine code”—the distinction between high- or low-level target languages aren’t interesting anymore, even if it might have been novel to normie programmers in the 90’s or something.

> Bizarre take.

Bizarre in what way? If compilers are somehow different, then they mustn't target systems, as that's what your previous comment says transpilers do. Which leaves even your own classical definition to be contradictory, if they are somehow different. What does that leave?

> Yes.

But it seems you do not consider them different, which was the divergent path in the previous comment. But evaluating both the "if" and the "else" statement is rather illogical. The evaluation of both branches is what is truly bizarre here.

I don't think anyone here is saying we shouldn't have the word "transpiler" at all

This thread chain is in response to jerf's comment "transpiler shouldn't be a word" (simplifying his comment for brevity's sake)

We shouldn't have the word "transpiler" at all.

Ah, my mistake, I thought you were making an earnest inquiry and not a joke. Carry on.

> The fact that this was a bug at all makes me fear for the rest of the code base.

The fact that the commit was accepted into a release without any changes to accompanying tests is what is most concerning. You should be afraid.

Is the wrong code in the new part of the diff or in the old one?

Generally getting zero value from a map is a feature, but the code that the diff replaces did look overly complex and fragile to me already tbh

> Result<T, E> is required to be checked before the value can be accessed.

Which is a flaw in Borgo, at least when interfacing with Go code, as in Go both T and E should independently valid states.

It whooshed right past your head.

Go is stone cold simple to pick up. ITs simple to reason about. I can decompose a project and spoon feed it to a JR engineer and they can get through it.

Rust is none of those things.

Its great for low level stuff, it is in the kernel right next to C and go will NEVER be there. Why, because that is what rust is good at.

At least now generics are supported, unless one needs gccgo, maybe in 10 years we get Pascal enumerations.

Again I like rust. Crates being colored (as in functions), the shitty compile and tests times... these are things that are holding back rusts adoption in more places... None of this stuff is on the road map to get fixed, it's quite the glass house you have.

Go is going to replace a fair bit of python/ruby in the next few years... Is it going to be rust or zig that eats into c/c++? If the rust community keeps on the way it has been, zig will eat all the core apps we depend on.

Well stdlib normally doesn't have stuff like Oracle drivers and such. I think one of the reasons why PHP tends to need so few external dependencies is because it has so many extensions to cover basically anything that you don't need PHP libraries all that much. I don't personally see it as a bad thing but it's something worth considering.

I've never really had that trouble. There are typically relatively few places that

1. a given interface is provided via a DI module 2. said modules are included in a binary

With decent codesearch, finding the implementation of a particular injection for a given deployed binary is usually a fairly short search.

I'm sure there is all sorts of extra voodoo you can get up to, but the straightforward DI case is, well, straightforward.

My experience is that there is a great, big in-between where folks are just chugging along and aren't thinking about project/codebase level architectural decisions. Without that active thought and foresight, you end up shooting yourselves in the foot, a bit. With DI frameworks, the _default_ ends up typically being the right thing to do so it unburdens people from a particular slice of cognitive load.

I just ran into this earlier today - it makes navigating code with grep more difficult.

I had a YAML file using `some_property_name`, which was turned into `SomePropertyName`, and it's a small annoyance. It's not a huge deal, but it adds friction where some languages have none. (Or alternately, getting reordered in a separate system like `property_name_some`.)

I do the same way like you. My logic was that I can tell where the value is coming from. I would use the same type but different name.

Is it coming from a client via http? Then it needs to be checked and saved

The database? then it has an id field which could be null in other cases.

Or I just create a new instance?

Naming things is hard tho, sometimes I do think I should just name them the same and stop caring. I'm not sure if I gain productivity but it gives me some comfort that I can instantly tell the source of the data.

I have the benefit of writing mostly C++ where there is really no globally agreed idiomatic naming. At $JOB we use snake_case naming for C++ functions and objects (as opposed to types), which also matches the python naming convention we use.

Snake case is not idiomatic for xml, but we still happen to use it for leaf config options.

The main benefit is reducing ambiguity to what maps to what across files. Ease of grepability is also an advantage.

So if you have a concept that doesn't have an equivalent in English you just kinda translate it and add a comment for other people of your language to understand what it is?

Very true but “bad” is always subjective so at least they came up with an evaluation that is binary — either you have capitalization in your language or you don’t, either the analogy fits or it doesn’t.

(Some linguist will point out that Bongo-Bongo has half-capitalization, or half has capitalization).

You're also very kind, and I realized that it's possible there were a bazillion "watch out"s on the docs and was just trying the <PublishAot>true trick when I saw your comment

However, it seems this brings my docker experiment to an abrupt halt, and is going to be some Holy Fucking Shit to re-implement that $(for GOOS) loop in any hypothetical CI system given the resulting explosion

  /usr/bin/sh: 2: /tmp/MSBuildTemproot/tmp194e0a13157b47889b36abb0ce96cd2d.exec.cmd: xcodebuild: not found