Go 1.11 and Beyond

"Solved" by having lots of meaningless unsafe glue code. That's not a solution.

It sounds like you're going to reject proposals for generics on the grounds that "you could just cast values of type `interface{}`" unless someone can show you a situation where you can't do that. The problem is that the people who want this sort of feature don't think that's even a solution.

It really does. Our codebase is very large and I'm a member of the team responsible for the build system and language tooling. Java library resolving in our repo can take 45mins from a clean build. Python is better, and we've managed to lock it down to offline only sources so libraries never update on us out of the blue. I've been a gopher since the the first announcement and I'm so excited that Russ Cox discovered a simple way to declare and resolve dependencies that avoids the SMT solver nightmare that I've seen bog down progress in every major project I've been involved in, from Ocaml and Haskell to python, java, rust and javascript (security nightmares every night here).

One of my greatest hopes is I can convince my teammates that its be worth the time investment to transition all our dependencies management ecosystems into the Minimum Version Selection algorithm.

It’s a slightly simplified version of Cargo which itself is an evolution of what yarn/npm/sbt/etc are doing. This is explicitly called out in the vgo paper.

It only seems like a revolution because the previous situation in Go was such a mess. As someone that writes a lot of both Rust and Go I’m not nearly as impressed.

>It vastly improves on and simplifies anything that existed in this domain before.

I've read the specs and justification posts. I don't find it gives anything better (and in some ways it's worse) than what can be achieved with, e.g. cargo.

>It's like saying Copernican heliocentrism didn't bring anything extraordinary to the table compared to Ptolemaic geocentrism

Yeah, it's like saying that, with the only difference that we're actually talking about something that brought nothing extraordinary here (as opposed in the contrived example).

What am I missing? It's a dependency declaration file.

This might be seen as a problem, but it allows the OpenBSD devs to push the envelope of expectations and find bugs across the entire software ecosystem.

An example of this was the change to 64-bit time_t back in 2013 (talk: https://www.openbsd.org/papers/eurobsdcon_2013_time_t/ ), and evolving syscalls like pledge(2) that changed syntax between releases as the problems/benefits of a specific implementation choices were learned.

Windows calls their syscall wrapper ntdll.dll, not libc.so; but it's conceptually the same thing. The ntdll.dll ABI is public & stable, the underlying syscall ABI isn't. Several unixoids do the same thing, where their libc.so ABI is public & stable, but the underlying syscall ABI isn't.

That's mostly what I mean. I love godoc and the philosophy behind it; its a massive improvement over the manual documentation build steps of Java, JS, Python, etc. But even more modern languages, like Rust and Elixir, do it better. There's a lot of low-hanging UX and usability fruit to be fixed in godoc which can make the experience better.

It's funny how these things are so personal. I love Godoc, mostly because everything is on one page, with very little JS and a good, almost monochrome colour palette. At the same time, I really can't stand Rust's docs, because everything seems to get its own page, it's colours galore, and of course there is a sidebar.

The mileage does vary greatly apparently.

ExDoc does not miss links to the source code. (Click on any Module/function and there should be brackets "<>" that point to the source code.) Types are also present in any module that defines them.

No, they solve a complex problem.

Have a look at modern web development. Because they have no macros, they wrote a bunch of tools which "compile" different domain specific languages (DSL's) to "the real stuff". Nowadays you compile pseudo HTML, pseudo CSS and JavaScript (modern style) to HTML, CSS and JavaScript (backward compatible, a.k.a. old style JS). That's insane. On the other hand, whiteout those code-transformation tools – which are called macros if they are built into the language – all those fancy and simple web-tools would not be feasible.

Ignoring macros means to me oversimplifying programming. Which results into not solving the real (meta) problem. For a while you will get away without macros/code generation, but in the long run they are inevitable.

> Macros are a cop out of language design. They mean "everybody do what you want and create your own language, we don't care anymore".

I prefer safe AST based macro than runtime reflection like Go has. The latter is actually a cop-out, unlike the former in the context of type safety at compile time.

Well, they sort of give the same message already, but with custom code-level solutions instead of macros...

"Everybody go an invent your own way to handle error checking/propagation" etc...

Instead one gets to use go generate for the same purpose.

Indent your code with 4 spaces to prevent HN from eating the newlines:

    func Foo(x int) (int, error) {
        var err error
        a, err := whatever()
        if err != nil {
            return 0, err
        }
        b, err := whatever()
        if err != nil {
            return 0, err
        }
        ...
    }


    func Foo(x int) (int, error) {
        var err error
        whenever err != nil {
            return 0, err
        }
        a, err := whatever()
        b, err := whatever()
        ...
    }

Kubernetes has enormous masses of repetitive code that is essentially a workaround for the absence of generics or other kinds of improved types. The reliance on "union types" -- really, exclusive arcs -- gives me the heebies and also guarantees that there is a bottleneck for new features: PRs to core. And then there's the whole TypeMeta thing. An entire dynamic type system because Golang can't express what Kubernetes needs.

And no, I don't see code generation as a good thing. It's fragile and difficult to safely upgrade.