It's really interesting you used those as your examples because that need was fully met in a type-safe way already, and other examples are actually much rarer to come by.

Fast-forwarding to today, could Co-pilot have saved them the trouble?

Oh good grief. There are 32,768 programming languages. People are free to pick the ones they want to use and nobody wants your pity.

for sum < 1000 { sum += sum }

`type any interface{}` would declare a new type, while an alias is exactly another name for the same type.

    type any = interface{}

    type Any = interface{}

I don't buy that a staff SWE and a new grad will write very similar code in Go.

As far as simple language. It is possible to design simple languages that are very expressive, Lisp and Erlang come to mind.

“ZeroVer is satire, please do not use it”

Less has my favorite version numbering system. Sequential.

Latest stable release: Version 598

https://www.greenwoodsoftware.com/less/

https://github.com/gopherjs/gopherjs

The majority of Go I've been hired to improve has suffered immensely from not using accepted idioms. Most of my work has been focused on introducing those idioms systemically.

But it was just after the death of IE ;) [Call me lucky]

My 2 cents: widespread adoption is not synonym with long term perenity.

That is complete nonsense.

The ability to create an open set of types is powerful, so is the ability to create a closed set of types, and they are not exclusive.

But go currently has only one of the two, which significantly limits its expressivity and type safety.

I challenge you to read the source for the Go standard library and maintain that position. Lambdas are orthogonal to generics in pretty much every aspect. You need to stop thinking in terms of "filter or map". Programming languages that didn't include these idioms existed long before Go, and will exist long after Go.

I welcome the introduction of generics, but I still don't have many places in many code-bases where they'll be used.

    let x = match may_fail_who_knows() {
        Ok(y) => Ok(another_computation_which_can_fail(use_value(x))),
        Err(e) => with_some_error_handling_that_can_rescue(
            some_error_processing(e)),
    };
    match x {
        Ok(y) => y,
        _ => a_default_value,
    }

Also: by avoiding functors there are fewer subtle lifetime issues and `move ||` stuff to deal with and you can return from the containing function and use the `?` operator.

During the discussions of how `.await` was going to work for rust async there was the proposal to add other suffix keywords. So this would look like:

    may_fail_who_knows()
    .match {
        Ok(y) => Ok(another_computation_which_can_fail(use_value(x))),
        Err(e) => with_some_error_handling_that_can_rescue(
            some_error_processing(e)),
    }
    .match {
        Ok(y) => y,
        _ => a_default_value,
    }

    match may_fail_who_knows() {
      Ok(success) => {
        do_something_with_success(success)?
      },
      Err(failed) => {
        some_error_processing(failed)
      }
    }

    let result = may_fail_who_knows()?
      .use_value_which_might_also_fail()?
      .use_a_different_way_that_might_fail()?;

Upgrading is the problem in this scenario. Let's say 727 is the modern version. If users upgrade to 728, when 728 is based on 402, we have an issue.

It's useful for Ubuntu, because each Ubuntu release is a hodgepodge of lots of unrelated updates. Some will be breaking, some will be fine.

Considering most places I've worked at just bump the minor number in perpetuity, a date-based version conveys a bit more info. Also so much easier to know when it's going out if you have a release cycle (e.g. you don't have to guess what date 3.12354.0 is going to prod, you would know it already from a version like 2021.12.25).

You can't do the same with git commit hashes because you can't sort them based on the hash alone. I have no idea how to compare deadbeef and cafebabe without checking the code itself.

For example for, having done Java, Scala, Python, Groovy, Haskell, Typescript and a couple others, Go reads extremely horrible. It feels as bad as enterprisey Java to me.

I especially like f"{foo=}" for debugging.

there are tools to do this, they’re not widely used because it doesn’t fit Go well. You’re trying too hard to write Go in the style of another language.

If you want an exhaustive type switch that badly, it’s usually a sign that your interface definition is wrong. https://github.com/nishanths/exhaustive

here, have fun. You’re gonna write some tests, make new types to satisfy interfaces for testing, and then wind up with branches for your test paths in your live code, but go for it, I guess. You know everything! I am but a simple blubbite, too dim, too dim to get it.

lol. That’s not how this works.

For me an easy to understand program is one where the way memory is structured and the way execution modifies said memory is easy to follow. That's why Go, despite being very verbose in some cases, it's easier to reason about, than codebases doing similar things in higher level programming languages.

      choices.forEach(async (ce) => {
        let ce = choices[index]
        Deno.sleepSync(220);
        let cf = await getChoice(ce); // this makes the API call
        Deno.sleepSync(220);
      });

      for (index = 0; index < choices.length; index++) {
        Deno.sleepSync(220);
        let cf = await getChoice(ce); // this makes the API call
        Deno.sleepSync(220);
      }

1. Some languages on your list are very flexible, and that allows them to be written in a very readable form with great discipline. People tend to not have great discipline thought, for various reasons: their bosses are pushing them to go faster and cut corners, they aren't experienced enough yet, etc. I'd say that python and typescript/javascript fall into this category.

2. I think inheritance is the devil, and a more functional style is better (by functional I mean first class functions, passing parameters, etc not purely typed). Java/Groovy fall into this category, they overuse inheritance and things like dependency injection with xml or annotations rather than far easier to read function calls with parameters.

3. Then there is haskell :) Haskell requires a phd in rocket science to be proficient, and most people have other things they want to do with their life. You also can't hire a team of 1000 rocket scientists so most companies can't go this route.

Edit: One other thing I'll add about typescript/javascipt because it's a bit of an oddball. There really isn't a typescript/javascript style because most devs end up writing javascript. The java people try to write java in it, the python people python, etc. This alone makes it hard to jump into a random JS/TS codebase and figure out what's going on.

Regarding Go, it takes away a lot of flexibility, which makes the code longer generally, but it makes it much more consistent across code bases. It's lack of inheritance prevents the devil from showing up, and it's largely a simple function call with parameter passing style all the way through the code base. Structural typing is also a godsend.

Edit 2: Also, package management in python is a complete train wreck.

Python does. Ruby does. It's not just Java and JS. Go is very open about its approach being a departure.

> And actually, many APIs in the wild do represent errors as integers.

Many, many APIs in the wild are implemented in (or meant to be consumed from) C, which doesn't even have exceptions, so not using exceptions makes sense for them.

Very often idiomatic non-C host language wrappers for those APIs will fire exceptions when they get an error return.

> Your use of exceptions for flow control (i.e. goto) is considered harmful

Exceptions are a way to delegate error handling to the caller by giving them informations about the unexpected behavior. It implies that the expected behavior is the "happy path" (everything went well) and any deviations (errors) is unexpected.

This is far from a goto because you can have `try/finally` blocks without catch (or defer in golang).

Also, exceptions are just a kind of algebraic effects that do not resume. There was a proposal to JS for this: https://github.com/macabeus/js-proposal-algebraic-effects

This is also easier to test. assertRaises(ErrorType, func() { code... })

Almost every Go library I've seen just return an error (which is just a string), you'd need to parse it to assert that the correct error is returned in special conditions.

Zig manages to provide traces with very little overhead:

https://ziglang.org/documentation/master/#Error-Return-Trace...

I am baffled as to why error handling in Go remains so impoverished.

Not to mention that traditional exception handling advice I've been handed down from the gray beards is to always handle exceptions as early as possible, which is exactly what go forces you to do with their approach.

[1] https://pkg.go.dev/runtime/debug#Stack

However, doing this kind of ... sucks.

[1] https://github.com/SeaQL/sea-orm/blob/64c54f8ad603df0c1d9da8...

And it's not really a version numbering system that you're advocating for at that point, it's a strict rule about linear releases.

It is very weird that this subthread starts with "current state of the art".

And it is always most meaningful to handle it immediately, so what's the point of introducing a application-wide goto jump, amid Dijkstra's warnings that doing so is harmful when you're just going to catch right away anyway?

> The happy path of "make a request" is that there is no network error.

If there is a network error, you're still happy. It is not like you screwed up as a programmer. What is there to be unhappy about? The network error input to your function is very much expected and part of the "happy path" as much as any other input to your application.

> if there is an unexpected network failure, let it crash

Network failures are never unexpected. It would be exceptional to never experience a network failure.

> How do you check which errors you want to handle and which one you want to propagate with just a string describing your error?

Why would your errors be strings? When errors are just plain old values like any other it is true that you could resort to using strings to represent errors, but it would be quite unidiomatic to do so. Kind of like how you can overload exceptions to handle errors, but just because you can does not mean you should.

No, it doesn’t. For a single computation like this, that pattern is roughly equivalent to Maybe (which contains no information about the case where there is no success result besides that it is absent) rather than Result (which has error information, kind of like an exception, but in the normal return path.)

For a series of computations, the composability of both Maybe and Result means that they are semantically richer.

Most people who use Go have specifically chosen to use it though (or at least sought out opportunities, given that it's not something entrenched like Java being used due to inertia), so yes, most of them are fine with how Go is or they wouldn't be using it in the first place. If Go had generics from the start, I'd imagine most users would be fine with that too due to self-selection.

I didn't say it is. I said it should be. But here is a similar functionality that I just googled: https://www.learnrxjs.io/learn-rxjs/operators/filtering/thro...

I'm neither a javascript pro, nor a fan of this language. There are probably better solutions out there.

> And, your code is not easier to reason about for me than the synchronous golang code

I never said it is. If you would be familiar with only assembler, then assembly code would most easy to read. And you need to spend some time upfront to learn other languages/techniques that can make certain problems easier.

So here's the thing. Let's change the idea of this code a little bit and make it a challenge.

Let's say we want to improve the code:

1. Improve performance by sending requests as quickly as possible while respecting the rate limit. I.e. if we have 3 requests, send them all at once. If we have 7 requests, then they should all be sent after 1 second has finished.

2. If a request fails, we retry it up to 3 times and don't count it towards the api rate limit

3. If all retries for a request fail, we just skip it and continue with the rest.

I think this is a very practical real world example. I'm curious how elegant this can be solved in Go. I will also solve it and post my online-runnable solution afterwards. :-)

And then we reevaluate which solution is easier to read.

What's the vanilla way in ts/js to do the equivalent of this golang code where getChoice makes an HTTP call and can't make more than 5 per second?

    for _, v := range choices {
      getChoice(v)
      time.Sleep(200)
    }

> I also think that a dev who just graduated college would be able to jump into my code and work on it fairly easily. I think they'd need a lot of extra training/learning to understand yours.

this nails it. It's also what Go was designed for. People just shouldn't make the mistake to assume that this means would also be easier to understand a whole code base. It's not, it takes longer, since there will be so much more code. We pay the long upfront costs to learn our languages and tooling for the same reason we sent people to school for years: in the end it pays off.

> One question about yours, is it using a separate OS thread for each HTTP call, or some kind of async io?

Just like Go it uses "green threads" and will work and run requests in parallel even when just having one thread and/or cpu core.

The reason that the Scala code is so much shorter is because streams compose really well and a lot of common building blocks (such as the throttling) can be provided. This effect gets more important when the code base is growing.

Also, when things become more complicated, loops like the one you wrote tend to become very complicated. At least that has been my experience. It's fun to write it, but not so much to read or maintain it.

A language or API (things you program against) are pretty much the things for which SemVer makes sense.

> The major version should represent major language changes, not whether its a breaking change or not

I don’t care if changes are “major”, I care if the code I wrote for version X is expected to need modification to work correctly in version Y. SemVer gives me that, Subjective Importance Versioning does not.

I like this because it emphasizes the community's commitment backwards compatibility, which I greatly value. I've spent a good deal of time writing Javascript, where library developers seem to have very little respect for their users and constantly break backwards compatibility. In ecosystems like that, upgrading fills me with dread. When I see a library on version 4, I have learned to keep looking - if they weren't thoughtful enough about their API design for the first 3 major releases, I shouldn't expect it to be much better going forwards.

For an application, I'm pretty open to version numbers signifying big features - Firefox and Chrome do this, and it's helpful with marketing. But for a programming language? A programming language is a tool, and when upgrading you need to carefully read the changelog anyways. A programming language is no different from a library (in Clojure it literally is a library), and backwards compatibility is /literally/ the main thing I care about. Is my tool going to intrude on /my/ schedule, and force me to make changes /it/ wants instead of being able to spend my time making changes /I/ care about? I want to know that.

[0]This is apparently an awful example as I've just learned that Java is actually doing the major version only thing. It still sort of works because the only reason they can do that is because they Will Not Break Compatiblity.

I don't agree. I usually don't care so much when a particular feature was introduced into a language (and if I do, it's usually a Wikipedia search away). I mostly care whether or not code written assuming version X can be compiled with version Y of the compiler. Semantic versioning can tell me the latter. Making versioning arbitrarily depend on what someone considers a "big" feature doesn't help me.

A language update comes with the most fundamental set of libraries and APIs: the standard library (doubly so in Golang, which has a lot of batteries included).

It also potentially affects the behavior (if there are breaking changes) of all other third party libs.

The "silliness" part is a non sequitur from what proceeded it (and the following arguments don't justify it either).

>Your version is not really telling you the main things you care about.

The main thing (nay, only thing) I care about (for my existing code) from a language update is whether there were breaking changes.

I could not care less to have reflected in the version number whether a big non-breaking feature was introduced.

I can read about it and adopt it (or not) whether there's a accompanying big version number change or not.

>It's much much more useful to the users to say, 2.0 introduced generics, it's distinct.

That's quite irrelevant, isn't it?

It's not useful to users that follow the language (page, forums, blogs, etc.) and would already know which release introduced generics.

And it's also not useful to new users that get started with generics from day one of their Go use either.

So who would it be useful to?

Such a use would make the version number the equivalent of a "we got big new feature for you" blog post.

Why?

Old code still work and unless you are purposefully maintaining an old system you are expected to use the last version anyway. What does it actually change that generics were introduced in version 1.18 rather than 2.0? From now on, Go has generics. As there is no breaking change, it’s not like you had to keep using the previous version to opt out.

Languages are software; they are dependencies of other software (the only unavoidable dependency!) and as such should absolutely be versioned.

Versioning isn't for marketing or providing easy ways for users to remember when features were released. It's a tool for change management. Exciting features often come with breaking changes, but not vice versa.

This is actually very important. If something is a major change or not is pretty subjective.

Additive changes can be breaking changes quite easily, as those additions are adopted within a minor version range, as automated tooling needs to distinguish their presence, as documentation fragments.

My next biggest gripe with semver—that 0.y.z has entirely different semantics from any other major version—may actually be semantically better if adopted wholesale. If your interface changes, major version bump. Else you’re fixing bugs or otherwise striving to meet extant expectations.

Major language changes almost implies breaking changes, like Python 2 to 3 was major changes that break things everything from how modules were changed, where they were, and some syntactic and fundamental changes as well.

1. Min version in go.mod 2. Add a build tag for what to do for new/old version of go (These tags are automatic, you just need to set them in the files)

When a language adds any features, if your dependencies (whether real library dependencies or just things you're copying from Stack Overflow) start using the new features, you must upgrade to the new language version. That is an inherent usability constraint, and every time a language designer chooses to add a feature, they're making a tradeoff. But if upgrading to the new language version is trivial, then it's generally a worthwhile tradeoff.

For instance, suppose I find some code that uses Python's removeprefix() method on strings. I need to use Python 3.9 or newer to use that code. It doesn't matter that this is a very small feature.

However, I can generally expect to upgrade my Python 3.8 code to Python 3.9 without trouble. It's different from, say, code that uses Unicode strings. For that code, I need to upgrade from Python 2 to Python 3, which I can expect to cause me trouble. The version numbers communicate that. It's true that Python 3 was a "big" change - but "big" isn't really the point. The point is that I can't use Python 2 code directly with Python 3 code, but I can use Python 3.8 code directly with Python 3.9 code. There are plenty of "big" changes happening within the Python 3 series, such as async support, that were made available in a backwards-compatible manner.

As it happens, Python does not use semantic versioning. But they have a deprecation policy which requires issuing warnings for two minor releases: https://www.python.org/dev/peps/pep-0387/ It's technically possible, I think, that a change like Unicode strings could happen within the Python 3.x series, but that's okay, provided they follow the documented versioning policy. This policy addresses the same question that semantic versioning does, but it provides a different answer: you can always upgrade to one or two minor versions newer, but at that point you must stop and address deprecation warnings before upgrading further.

You are, of course, free to also have a marketing version of your project to communicate how big and exciting the changes are. Windows is a great example here: Windows 95 was 4.0 (communicating both backwards incompatibility with 3.1 and major changes) and Windows 7 was 6.1 (communicating backwards compatibility with Vista but still major changes).

that's why semver works; the definition of major change is defined, and that's when you update the major version number.

Also they may have sneaked it in because they're implicitly acknowledging fault in their previous design decision to exclude it.

Yours is a pretty good one, i think that software versions should be indicative of what it contains to the people using them, whereas some others primarily care about the compatibility with the other versions. Semantic versioning is better suited to the latter group, because it doesn't really care about what's in the software, beyond what the changes are when compared to the other versions - breaking functionality, non-breaking functionality or just fixes of some sort.

My own alternative would take a slightly different approach yet - a system that would indicate when something was released, as well as whether the release is supposed to be stable (think MySQL 5.7, but in a format like 2021-stable-1234), or something more like a rolling release/nightly build with the latest changes (in format like 2021-latest-2345), an idea that in part i shamelessly stole from the Unity game engine, Ubuntu and JetBrains IDEs, since having a glance at their versions makes it apparent what you're looking at.

I actually wrote about that idea on my blog: https://blog.kronis.dev/articles/stable-software-release-sys...

Since then, i've started using that scheme for a few internal libraries in my dayjob to see whether it will work out (where switching to something else would be a matter of updating the CI, so less than an hour), as well as some personal projects.

Of course, each versioning scheme has advantages and disadvantages.

I'm just saying that they could have done something different, if they had wanted to, without working out a complete theory for that different thing.

Or alternatively, complain loudly.

Modern C++ compilers are not necessarily available on all platforms. For example, Solaris, AIX or old RedHat versions. Go doesn't have this problem yet, but it will.

Let's start with the fact that newer doesn't mean better. With already deployed compiler you have tested it and know that it works good enough (code it generates, bugs you have workarounds for, etc). Where with new compiler you are on step one. You must do work again.

Or vendors just support particular version they have patched.

Or you are scared of GPL3.

The first difference is that there isn't just a single compiler, but rather a standard that gets implemented by different compiler vendors. It's gotten better since then, but typically it would be a while between the updated standard being released and the standard being supported by most compilers. (And even then, some compilers might not support everything in the same way. For example, two-phase lookup was added in C++03, but MSVC didn't correctly handle it until 2017 [0].)

The second difference is that the C++ compiler may be tightly coupled to the operating system, and the glibc version used by the operating system. Go avoids this by statically compiling everything, but that comes with its own mess of security problems. (e.g. When HeartBleed came out, the only update needed was for libopenssl.so. If a similar issue occurred in statically compiled code, every single executable that used the library would need to be updated.) So in many cases, in order to support an OS, you need to support the OS-provided compiler version [1].

As an example, physics labs, because that's where I have some experience. Labs tend to be pretty conservative about OS upgrades, because nobody wants to hear that the expensive equipment can't be run because somebody changes the OS. So, "Scientific Linux" is frequently used, based on RHEL, and used up until the tail end of the life-cycle. RHEL6 was in production use until Dec. of 2020, and is still in extended support. It provides gcc 4.4, which was released in 2009. Now, gcc 4.4 did support some parts of early drafts of C++11 (optimistically known at the time as C++0x), but didn't have full support due to lack of a time machine.

So when I was writing a library for use in data analysis, I needed to know the language and stdlib feature support in a compiler released a decade earlier, and typically stay within the features of the standard from almost two decades earlier.

[0] https://devblogs.microsoft.com/cppblog/two-phase-name-lookup...

[1] You can have non-OS compilers, but then you may need to recompile all of your dependencies rather using the package manager's version, keep track of separate glibc versions using RPATH or LD_LIBRARY_PATH, and make sure to distribute those alongside your library. It's not hard for a single program, but it's a big step to ask users of a library to make.

https://docs.microsoft.com/en-us/dotnet/csharp/language-refe...

You seem to have misunderstood. We're not pointing out that "semver is semver", we're pointing out that semver as defined with respect to compilers, which is to say, the ability of existing code to run with a new version of the compiler, and what you "perceive to be a limitation in semver" are fundamentally in tension.

The only non-perf changes that would be allowed as non-breaking changes if we addressed what you perceive to be limitations in semver are precisely those changes which would be breaking in semver-as-it-exists, and those permitted in semver-as-it-exists are precisely those which you perceive as limitations.

Happy to discuss semver, but fundamentally the thing here is that what would address your perceived limitations is... the literal opposite of semver. Which is fine! But something not being its literal exact opposite isn't exactly a flaw in the thing itself; you simply want something else entirely.

A fix is not a breaking change in the API, because “breaking” refers to expected behavior (so, yes, code that relies on a bug can be broken by a fix; presumably, if you've coded to an observed behavior differing from the spec you are aware of having done so.)