Russ Cox is stepping down as the Go tech lead

Huhhh? Have you ever worked at a large enough company where stakeholder interests are not aligned?

That’s unfair. There’s plenty of drama in projects with all sorts of funding situations. Look at eg Rust. Lots of drama and it’s anyone’s guess if the code you wrote a year ago would work today.

Getting paid has nothing to do with drama. Plenty of high paid people get involved in drama and infighting across all walks of life including tech.

And yet we've had lots of drama in Linux and Redhat mailing lists, involving people paid to work on the respective projects, and using their work email.

I would rather say that it is easy to have zero drama when most of the committers come from a single large companies.

Yes. And?

Programming languages more than almost any other type of project end up swamped with thousands of competing requests to implement mutually incompatible features. Some languages do better than others at saying no, and those languages tend to be the ones that achieve widespread adoption.

Yep. It takes a lot of bravery and I appreciate it!

Good

Are there any Go team members that don’t work for Google? It’s a lot easier to remain civil/avoid drama when people know each other personally, and work together at a big company with an HR department.

One reason I consider it so good

I mean they did say almost no breaking changes, depending how much has changed in the language, a small handful of breaking changes in niche use cases may be considered almost none by some. I'm not sure I would say the comment is absolutely inaccurate.

I don't recall this off-hand; which change was that?

Mostly this comes down to recognizing the value of simplicity. I like Rust and Go, but I am infinitely grateful that Go is as minimal as it is. I wouldn't have had as much success ramping my team on Rust.

s/fought against it/rejected superficial proposals that were mostly about syntax bikeshedding and didn't include enough research on how the proposal would play along with the rest of the language and ecosystem/

And the telemetry drama.

Go doesn't really lend itself that much into code with a lot of abstraction layers. If you try to do that, you will start to run against the language.

The more enterprisey software usually have lots of layers for organizational reasons, and go doesn't really fit there. So I don't think it will really be a hit in the enterprise.

yes there are orm solutions and DI frameworks and all that, but they always feel like they don't belong in the language.

(Also, java and .net and php are much older and have much bigger enterprisey ecosystem.)

I have seen go replacing the php stack though, and in some way the "original" python stack - but python now has ML.

ASP.NET or Spring

(Disclaimer: I don't agree with HTMX rendering HTML chunks on the backend side, and I think that APIs should be HTTP-cacheable and use REST/JSON)

Currently I am trying to get better at using Go with WebAssembly for the frontend. I love to use the webview/webview bindings to build local GUIs, but the need for redundant code in JavaScript for client data transfers and input data validation are annoying me a bit much.

I am trying to find out a paradigm that could benefit from the strength of JSON marshalling, with the idea that you can map routes to structs, for example, and where a unified "Validate() (bool, error)" method as an interface is enough to use the same structs on both the frontend and backend, for both serialization and validation/sanitization.

Having said that, I think that what's missing the most in go right now is a good UI framework for the web, but it's hard to find a paradigm that fits nicely into the language while also being able to handle dynamic data/refreshes/render loops without getting too bloated too quickly.

Thankfully, it is enough that it is a must in DevOps space.

In my enterprise neck of the woods Go is steadily taking over backend development.

Go is displacing .NET where I work for backend development. We still use .NET for Windows GUIs but any sort of server code is mostly Go going forward.

It's not yet an enterprise language; along the languages/frameworks, there's a huge ecosystem of QA, monitoring, security, etc solutions in the Java/.NET space that just isn't there in Go.

I mean there's a slow shift, I keep hearing of "rewriting a Java codebase to Go", but it'll be a slow process. And especially the bigger projects that represent 30 years of Java development will and should be reluctant to start rewriting things.

I wonder who hurt them, that is, how much did unused variables/imports hurt at Google for them to make those a compiler error?

Insofar I know it, I can imagine C/C++ caused some issues like that because it's hard to figure out whether an import is used, but an unused import does have a cost.

Why not? Pretty sure it's used in a lot of places, so it does seem quite serious if a language.

The moment you see that you had misspelled a variable name by a single character when the compiler warned you about an unused variable, you'll realize Go is a serious programming language.

pointless features are added because maintainers are afraid

I wouldn't have described language designers' feelings that way, but you're absolutely right. For example, witness the recent features added to Python with little more justification than "other languages have it". It's pure FOMO - fear of missing out.

Yes about the language but also Google understands that both tooling and standard library is more important than the language. All of that makes Google internal maintenance much much better. Another artifact of google3 was the absolute shitshow of GOPATH and abysmal dependency management – because Google didn’t really need it, while people outside suffered. When they added go mod support Go became 10x more productive outside of Google.

Go is almost an anti-language in that sense, reluctantly accepting shiny lang features only after they’ve been proven to address major pain points. It’s almost more an “infrastructure deployment toolkit” than a language. Which strangely makes it extremely pleasurable to work with, at least for network-centric applications.

To be fair, with Go it's still painful to work with private repositories. And I'm invoking Cunningham's Law here when I say there's no convenient way to do so.

If you want to use a private repository (let's say it's a private GitHub repository), then you either have to do it the bad way (setting up your own GOPROXY and setting it up securely, which implies also ensuring it's not leaking your source code elsewhere for "analytics purposes"), or the worse way (doing brittle text replacement using weird git config stuff).

Or the annoying way of using a vanity import, and host that package in your domain with HTTPS using a wildcard certificate. But that would require either (1) only allowing access through WireGuard and hoping whatever reverse proxy you use has a plugin for your DNS registry; or (2) letting your VPS provider terminate DNS (e.g. Hetzner load balancer), but filter by IP address in your VPS firewall settings ensuring your public address (IPV4 /32 or IPV6 /64) is always up-to-date in the firewall.

Or using `replace` in `go.mod`, but these don't work transitively so these only work on "root" projects (i.e. they are ignored in dependencies), so I don't think this really counts as a solution.

I would have liked some way to force SSH access for a specific package, instead of HTTPS. Like for example `go.mod` supporting a `require-private` to use instead of `require` (or whatever similarly convenient directive for `go.mod` that implies authenticated SSH access is required).

Or in other words, say I have a package `github.com/_company/project`, and it depends on `github.com/_company/dependency`. I want to be able to do:

    git clone 'git@github.com:_company/project.git' 'project'
    cd 'project'
    go mod tidy  # Should just work.

(EDIT: Still, I'm agreeing with the point that Go's tooling is better than most other things I've tried. My only complains are this one about being inconvenient to use private repositories, and also that by default it leaks package names to Google whenever you do `go mod tidy`.)

I cannot recall anyone besides me ever using method chaining like .map .filter, etc.

Interesting. That's all anyone on my team ever used once it became available.

But, it highlights the point with Go. Working with Go for just a little while means I can easily read and work with nearly any Go project with a very short ramp up.

Haha interesting. I actually like .map/.filter/.find/etc. in JS and comprehensions in Python. I find they communicate the intent of the programmer really clearly as compared to a for-loop.

Explain how Google proxy "shenanigans" are any different than "npm proxy shenanigans" or "cargo shenanigans" or "pip shenanigans". It's a service to improve Go ecosystem with anti-spoof security design (which can't be said about those other code download services).

telemetry design is actually very thoughtful, limited and reasonable about what and how much data it sends. Motivation for sending the data is clear (improving Go). It's only a scandal for unreasonable people.

It's impossible to write complex and performant programs without null.

Well, clearly there is a need for a special value that is not part of the set of legal values. Things like std::optional etc. are of course less performant.

If I can dream, all of this would be solved by 72-bit CPUs, which would be the same as 64-bit CPUs, but the upper 8 bits can be used for garbage collection tags, sentinel values, option types etc.

Without pointers in some form or another, you can’t refer to allocated memory. You can change the name of pointers but they are still pointers.

Never met a programmer that thought these things were true.

It's impossible to write complex and performant programs without pointers.

Well, I'd rather not copy around a multi-hundred-megabyte (or gigabyte) 3D object around to be able to poke its parts at will.

I'll also rather not copy its parts millions of times a second.

While not having pointers doesn't make impossible, it makes writing certain kinds of problems hard and cumbersome.

Even programming languages which do not have pointers (cough Java cough), carry pointers transparently prevent copying and performance hits.

It's going to be much faster to enumerate the true things programmers believe.

Every type must have some sort of a default value. (A generalization of the first item, really.)

Every type is printable.

It’s 2024, every type is jsonable!

Nullable pointers are fine for those who need them. What we're asking for is non-nullable pointers.

An integer range is a very basic type, too

Not really, its semantics get hairy almost instantly. Eg does it incrementing it produce a new range?

I regularly find quite smart people assume Rust's references must be fat pointers to handle lifetimes, and check them all at runtime.

Iterators don’t really introduce any new syntax, strange or otherwise.

Go's is already "enterprisey" enough, thanks to Kubernetes ecosystem.

I do agree with his point that the implicit mutation of the loop body for an iterative will be difficult to debug.

Not obvious to me. We just implemented a streaming solution using the iterator interfaces. They are just functions so reading the code its easy to understand. Adding special language support only serves to obfuscate the actual code.

C#, python - here are the most mainstream examples of syntax that doesn’t look alien.

Only those instances make the news. And then get repeated time and time again. It's a super-biased view not at all representative of his day-to-day behaviour.

Also I've never seen Torvalds "chewing out people on mailing lists for something stupid they said", it's always been someone breaking something or something along those lines. That is: doing stupid. And it's also experienced maintainers Torvalds feels should have know better.

You can like or dislike Torvalds' style, but this little student from Finland created the world's most successful open source project, so I think he's probably doing one or two things right.

He may not be perfect, but being hung up over a few incidents over a 30-year time period is perhaps not too brilliant, and insinuating incompetence over this is quite the take. Imagine every outburst you have is public and pointed to for years to come.

Linux started on Usenet, and that was the normal communication style. People simply did not take it seriously back then, it was understood to be partly humorous.

Linus doesn't even rant frequently either. People point to the same 10 messages over and over again.

He also tolerates when someone snaps back at him, unlike in projects with double standards like CPython where the old boys can do whatever they like but you are not allowed to criticize back or point out their numerous mistakes, segfaults, threading bugs and generally low code quality.

Rasmus is not the BFDL for PHP.

PHP is governed by an RFC process requiring a 2/3 majority vote of a couple dozen core devs. This has been the case for nearly 20 years now. Rasmus rarely even votes these days.

IMO C++ would have benefitted from having a BDFL for a bit longer as well.

needs a lot more features to be usable

I guess what I'm caught up on is the idea of "usable" is entirely subjective. To my eyes and fingers, Go has been fine without generics, and since their addition I've only used them once to clean up an odd bit of code around instantiating "module" like initializers.

and makes developing in it a miserable experience.

Subjective or not I find this a bit harsh. I spent years in an environment where C was the only option that could be used and Go is a complete dream compared to this. You may dislike the environments, you may find fault with them, but there are many examples of both of them being used to build large and complex systems that aren't completely "miserable" to work on.

I wonder if the split is something like "batteries must be included." I don't feel this way. I'm content to mine up Zinc and Copper and forge my own batteries if needed. I'm not at all put out by this.

error handling is what I like about go.

ok errors.As is a little stupid, I'll give you that. But that's all.

This is why I prefer Rust over Go. Go is far too simple.

What do you mean it doesnt really work? There are a large number of programming languages and open source projects and a large number of approaches to this problem.

Python, Postgres, Rust..

A small amount of core contributors doesn't mean they all have to come from a single corporate entity either.

The notion that only Google could shepherd a programming language is hilarious.

> Can you name 3 apps/projects that use COBOL?

Does this imply that you see COBOL as having a trustworthy future, making it a great choice for a new greenfield application?

I think they mean Flutter, and Darts truly cross platform abilities.

I'll put it this way, the same doesn't apply with Rust.

I don't feel ashamed that I didn't manually come up with sorting algorithms. I was able to make a small Golang project and I had fun.