I remember that being a meme of sorts. Most people understood that as a C/C++ replacement with operating systems and drivers being written in Go. System programmers laughed, of course. Eventually when it didn't look like it wasn't going happen, the token reply from Go devs became "Well not those kind of systems, we always meant a different kind of systems programming language, not what you all thought".
> Systems: Operating systems, networking, languages; the things that connect programs together. Software: As you expect. (...) What is Systems Research these days? Web caches, Web servers, file systems, network packet delays, all that stuff. Performance, peripherals, and applications, but not kernels or even user-level applications.
he goes into a lot more detail there on the things he sees in 'systems software research', and it goes pretty far beyond kernels and drivers. this is not a definition he retconned onto golang in 02014 or, i would claim, a definition unique to him
Goroutines use OS threads, but only create one OS thread per core. Go does the scheduling internally on top of those few "real" threads.
Java itself now provides a goroutine-type model with Virtual Threads, but as the programmer you've got to ask for it.
Well, I just felt like "green" is a confusing moniker in that context.
I'd love to see a resource that highlights these all on a table across programming languages as well as the associated strengths and weaknesses of such threading & concurrency models.
Perhaps a ByteByteGo graphic, if you will.
From https://github.com/golang/go/blob/c7d6c6000a84b61ac8bb2e38e8... I believe "worker threads" are OS threads.
So Java's green threads was not a stop-gap for the 90s machine which only had one core. That's preposterous. Does Go need to disable its goroutines to support the Raspberry Pi Zero that has only one core? Obviously not! The reason Java didn't support multi-core scheduling is that multi-core processors still weren't a thing, and SMP was too high-end for them to bother (and by the time they did start caring about high-end systems, they've already moved to kernel threads).
Nothing prevents green threads from supporting multi-core (Java 21's Virtual Threads obviously do that, but Erlang's processes also had SMP support well before Go).
I think the terms "green threads" or "user-space threads" are really not that confusing. Definitely not confusing enough to warrant inventing a new term like "goroutines". THAT is confusing. I'm happy the Project Loom team resisted the urge to give the Virtual Threads a fun name like "Jorutines".
they bought that off cray, but in 01995 a few months after they released java, they (a different division) released the dual-processor ultra 2 https://en.wikipedia.org/wiki/Sun_Ultra_series
but that wasn't sun's first smp machine; the sparcserver 630mp, among others, supported four cpus in 01991 https://en.wikipedia.org/wiki/SPARCstation#Server_systems
i had a dual-processor smp pentium pro under my desk by 01998, running windows nt 4.0 and occasionally java
really tho the bigger issue with java performance was that there was no supported native-code compiler until hotspot; though gcj was available, sun didn't support it, and i don't recall its performance as being that great. so by writing your code in java you were usually wasting 95% of your cpu on the bytecode interpreter, like python today. it wasn't something you'd do for things that required a lot of cpu
"just avoid cgo" is a something i've heard many times from all Go devs
He'd have had a point if the go compiler could reliably compile programs in faster than 50-100ms. The claims that go is a fast compiler always seem to be relative to c++ or something. Last time I checked just compiling hello world took over 200ms which was shocking to me given how I'd heard that one of the language's claims to fame was a fast compiler.
Pike's point has proven itself here.
That sounds extreme. What did Bjarne do to him?
Seibel: You were at AT&T with Bjarne Stroustrup. Were you involved at all in the development of C++?
Thompson: I'm gonna get in trouble.
Seibel: That's fine.
Thompson: I would try out the language as it was being developed and make comments on it. It was part of the work atmosphere there. And you'd write something and then the next day it wouldn't work because the language changed. It was very unstable for a very long period of time. At some point I said, no, no more.
In an interview I said exactly that, that I didn't use it just because it wouldn't stay still for two days in a row. When Stroustrup read the interview he came screaming into my room about how I was undermining him and what I said mattered and I said it was a bad language. I never said it was a bad language. On and on and on. Since then I kind of avoid that kind of stuff.
Seibel: Can you say now whether you think it's a good or bad language?
Thompson: It certainly has its good points. But by and large I think it's a bad language. It does a lot of things half well and it's just a garbage heap of ideas that are mutually exclusive. Everybody I know, whether it's personal or corporate, selects a subset and these subsets are different. So it's not a good language to transport an algorithm—to say, “I wrote it; here, take it.” It's way too big, way too complex. And it's obviously built by a committee.
Stroustrup campaigned for years and years and years, way beyond any sort of technical contributions he made to the language, to get it adopted and used. And he sort of ran all the standards committees with a whip and a chair. And he said “no” to no one. He put every feature in that language that ever existed. It wasn't cleanly designed—it was just the union of everything that came along. And I think it suffered drastically from that.
Seibel: Do you think that was just because he likes all ideas or was it a way to get the language adopted, by giving everyone what they wanted?
Thompson: I think it's more the latter than the former.
Professionalism and the tech industry are just starting to get acquainted.
As I read this while sipping my turmeric latte my monocle popped right out!
For instance: ask a lawyer what they think about the overturning of Roe v Wade. Now ask them what they think about their colleagues who disagree. Don't forget to duck.
Which isn't to say that we wouldn't all be much better off with more distance between our opinions and our identities. But the thing you're looking for is a cultivated practice that is often not at odds with 'egotism' (what is that, precisely, anyway?) but _entailed by_ it: the not-wanting-to-be-the-kind-of-person-who-does-XYZ.
Not all vanities are risible.
What you're looking for is a long-cultivated, inward practice that can be supported or hindered by all the usual forces, local context (culture, practice, etc) chief among them.
Put another way: your claim isn't that most programmers are unprofessional. It's that they're _uncollegial_. And you're right. So are a lot of other contemporary professionals. It's a shouty era.
I've found that it's extraordinarily valuable to separate these two cognitive modes wherever possible.
99% of [people], but especially the brilliant/well known ones [in any domain], are insufferable egotists.
IMHO this is normal. When somebody puts in a lot of effort in mastering something they intrinsically know that they are better than most people in that something. As social animals, getting "noticed" is a form of being conferred "status" in the group. Thus you tend to "act out" to acknowledge/confirm that recognition. It is fine as long as it is within acceptable social bounds and not out of touch with reality.
Or is it that scientific computing is starting to realize that it can benefit from a systems programming language?
Scripting langages are great for exploratory work, but if you want to put to work into production, scripting starts to really show its limitations. There is a reason systems languages exist. There is good reason why they both exist. They are different tools for different jobs.
Can't be it, since a huge percentage of scientific computing is done with a scripting language.
A systems programming language is still good for the backend libraries of scientific computing - but Go has zero share of that.
But not all. Whether or not it is Go that gets the job, a systems language of some kind would be beneficial in those circumstances.
A scripting language would seem to be good for the exploratory scientific research, because of that. Whereas when you need to create a performant library that can do heavy crunching with reproducible results on any platform you need the other. The questions is: Do you know what you want to implement, or is that still an open question?
Which isn't really much of a conflict. You can prove out your thoughts in a scripting language, and after the dust has settled you can move the workload to a systems language. Different jobs, different tools.
I guess if you're one of those weird religious types that insist there is only one true God (read: programming language) you might feel conflict, but nobody else cares.
And possibly different programmers.
Say your a (non-computer-) scientist. It is not (typically) part of your job to learn Rust or Haskell.
You might want to learn Rust if you are so inclined but many scientists are not.
Anecdotally, I work with a lot of scientists and they only write scripts. When systems are needed, they hand it off to the development team. Anyone can fumble through scripting, but there is a lot more to think about when building systems, and that's probably not something most scientists want to put effort into – for the same reasons they probably don't want to learn Rust.
Realistically, learning Rust is the easiest part of becoming a systems programmer. But there is little incentive to learn any system language if your workload is always scripting in nature. You are going to, rightfully, reach for a scripting language.
Why are they "conflicting"?
Common Lisp could do both quite well.
The only active, related discussion I am aware of is about the high call overhead imposed by the gc compiler. Of course, other Go compilers have different calling conventions. tinygo, for example, can call C functions from Go about as fast as C can call C functions. So that isn't really a Go issue, just a specific compiler implementation issue. And as you know (it's in the link!), the Go team themselves maintain two different compilers and pride themselves on Go not being defined by one compiler. To equate gc and Go as being one and the same would be quite faulty.
So obviously you are not talking about that one. What else are people discussing?
Obviously? Not of the above rings obvious to me.
A "specific compiler implementation issue" when said compiler is the compiler that 99% of Go users use, can just as well be called a Go issue.
Whether "the Go team themselves maintain two different compilers and pride themselves on Go not being defined by one compiler" is basically irrelevant in praxtice, since people using/interested in Go predominantly mean and use a specific compiler (unlike with C++ where they might use one of several available compilers equally likely).
>To equate gc and Go as being one and the same would be quite faulty.
No, it would be the most pragmatic thing to do. De jure and de facto and all that.
99% of Go users don't need an FFI story at all. They can choose a compiler on different merits. If you have an FFI story to consider, then it is logical that you will need to evaluate your choices on different attributes and very well might find that the compiler 99% of users with different problems won't match your own. gc is not ideally suited to FFI. But Go offers compilers that are. This is not a Go problem. Go provides solutions. What you speak of is only a gc thing.
What story do you have for us next? That your neighbourhood restaurant, with a full menu, has no hope because the one dish you tried wasn't to your existing taste – not having it occur to you that other items on the menu might be exactly what you are looking for?
It's worth noting that other new languages (e.g. Rust) are being adopted, because they have an reasonable FFI story.
Yes, obviously you can write scripts in a systems language, and systems in a scripting language, but you will have a better time if you write systems in systems languages, and scripts in scripting languages. There is good reason why we make a distinction between the two.
The scientists are almost certainly using Python. If not Python, R or Julia. And that is in large part because these are scripting languages. It is true that amongst the 1% that are systems, Rust has found a place, but it too will never make any serious headway into the scripting realm. It is also a systems language. Different tools for different jobs.
I, on the other hand, don't appreciate the ad hominem. What happened, have manners gone out of style?
Also, what exactly fault do you find with my original comment: that Go isn't really a player in scientific computing. Does your "research or though" suggest otherwise?
>99% of Go users don't need an FFI story at all. They can choose a compiler on different merits.
Users of X don't need Y is a self-fullfilling prophecy when X doesn't offer Y. Languages without Y don't tend to attract users who need Y.
We're also talking about users doing scientific computing here, where the vast majority does need an FFI story.
>gc is not ideally suited to FFI. But Go offers compilers that are. This is not a Go problem. Go provides solutions. What you speak of is only a gc thing.
And gc is 99% of what people understand and use as Go - not gccgo. Unless gc has a good support for certain features, scientific computing ain't gonna happen.
People aren't going to heavily invest in building scientific programming libs interop with Go, when those would just work fast enough in a different less used go compiler as opposed to the mainstream one.
>What story do you have for us next? That your neighbourhood restaurant, with a full menu, has no hope because the one dish you tried wasn't to your existing taste – not having it occur to you that other items on the menu might be exactly what you are looking for?
Yeah, because a different version of a compiler doesn't come with different maturity, different technical tradeoffs, different community using it, different support story, and so on, it's just like "picking another item from a menu".
If that's your understanding of the situation, I can see how your argument would make sense in your mind ("just change the compiler, it's easy").
Using another language as an example: If CPython didn't have a good interop story with scientific libraries, even if PyPy did, "Python" would have gone nowhere in that domain.
And people who can't understand this, would talk all day getting blue in the face about how "it's not a Python problem, it's a CPython problem", as if that would change anything.
Manners are for engagement between people. Forum-going is a solitary activity. Maybe there is a human out there twisting nobs and pulling levers to make the software work, but if so, that's just an implementation detail hidden from the user. If that were replaced with software, I wouldn't notice, or care.
> what exactly fault do you find with my original comment: that Go isn't really a player in scientific computing.
The original contextual comment, not first comment ever written...
> People aren't going to heavily invest in building scientific programming libs interop with Go
They aren't going to invest anyway, as the vast majority of scientific computing tasks are script in nature. Go is decidedly not a scripting language. It isn't trying to be, and doesn't want to be. There were already a number of good languages in the scripting space before Go came along.
This is like lamenting that wrenches aren't winning the race in nail driving dominance. Who cares?
It already has a substantial runtime (the usual pain of an REPL)
You can bet the Go compiler and runtime leverage that assumption.
Packages like Yaegi (that offers an interpreted Go REPL) have "know limitations, won't be addressed" also because of these assumptions.
https://github.com/golang/go/issues/4146
https://github.com/golang/go/issues/16522
https://github.com/traefik/yaegi?tab=readme-ov-file#limitati...
It isn't like a hypothetical C++ REPL would use unmodified LLM under the hood after all.
It has the limitations mentioned, which are necessary to make duck-typed interface calls reasonably efficient, if you assume no code generation at runtime, ever.
There's really no other way. If you don't know before hand all the interfaces that might exist, and/or all the types that might implement them, interface method calls would necessarily either need to be JIT generated, or a string based hash map lookup (runtime reflection, which exists, but is slow).
Go avoids both by knowing statically at compile time the list of all interface and the list of all types that can ever possibly implement them and building vtables for those.
Just because you are building a particular systems program does not mean everything you do has to be a systems problem. And, really, if you don't exactly know what you're building, it is probably too soon to consider any of it a systems problem.
Half the things I have seen replaced Python scripts. Seeing what your internal state is after taking X action is exactly what REPLs are good at...
I'm not sure who is talking about embedded work. That didn't come from me. There is nothing in this thread about embedded. Did you accidentally press the wrong reply button?
I say that Go is for systems. Do you think Go is actually designed for scripting? If so, why?
> Half the things I have seen replaced Python scripts
Python is often used to build systems.
Python is a scripting language, yes, but that doesn't mean you can't build systems in it – just as you can build scripts in a systems language. But there are tradeoffs in crossing paths like that. Systems languages will be better for building systems, and scripting languages will be better for building scripts.
Perhaps the applications you speak of are actually systems and that is why developers saw reason to convert them into using a systems language?
> Seeing what your internal state is after taking X action is exactly what REPLs are good at...
Quite good. But that workload is not systems in nature, so why would you ever do that in a systems language? That is a scripting workload. Naturally you would use a scripting language. And, lucky for you, most scripting languages include REPLs out of the box!
I've had this bookmarked for some time and just havent gotten around to it.
Python (largely) is the present and future of scientific computing because people realized you can write the mathy kernels in something low-level and just orchestrate it with ergonomic Python and its bountiful ecosystem/mindshare. Python adequately checks all the boxes and I don't see how a newcomer like "Scientific Go" or R or Julia will ever unseat it. Not to mention curmudgeonly researchers have little desire to learn new tricks.
But I do use Go when needed as a systems language, and it is fantastic for whipping out the occasional necessary microservice (due to network boundaries, etc).
The problem is we have researchers with no SWE expertise writing huge codebases in Jupyter notebooks inside a bespoke, possibly unreproducible Anaconda environment. That is going to be a maintenance disaster no matter which language is being used.
And if you force your researchers, who are using to being productive prototyping in Python, R, etc. to use a statically-typed language, they are going to complain and be a lot less productive at their job.
I think with proper type inference, there would be a lot less pain around static typing.
Ideally users should be forced to type their function signatures and everything else can be inferred.
Definitely I do agree with you that the situation today is much superior to even just 4-5 years ago.
R is only 2 years younger than Python (32 years old)
Julia's support for Autodiff
> Python was exploding in ML
It's very easy to start in Python. So it's taught everywhere, and everyone knows it. Until 10 years after the majority of colleges have replaced Python with another language, Python will stay dominant. From that point of view, Mojo is quite clever.
This comment deeply fascinates me, because I get the same feeling every time I go back and read/watch early Go resources from Rob Pike and others, but I've never actually heard it articulated before. I've always thought that surely they weren't that ignorant about PL theory and history? Or maybe Rob Pike himself was, but surely his team knew better?
It really feels like they thought they were making some special hybrid between threads and coroutines, combining the advantages of both. Like this 2011 talk[1] which demonstrated a classic coroutine code pattern implemented with goroutines and channels. But as time went on, goroutines became fully pre-emptive, and their programming model is now identical to threads. Using them as coroutines only leads to misery (read: data races) in my experience. They're faster than OS threads, sure, but that's an implementation detail at this point.
When do you think they eventually realized they were re-inventing the same green threads Java had created and scrapped 10 years earlier?
I worked at Google at the time go was created and had coffee with Rob from time to time and got to understand the reasons Go was created. Rob hates Bjarne Stroustrup and everything C++ (this goes back decades). C++-as-used at Google (which used far more threads that he says) had definitely reached a point where it was extremely cumbersome to work with.
I can think of some other things that they got wrong.
For example, when I first started talking to Rob and his team about go, I pointed out that scientific computing in FORTRAN and C++ was a somewhat painful process and they had an opportunity to make a language that was great for high performance computing. Not concurrent/parallel servers, but the sorts of codes that HPC people run: heavily multi-threaded, heavily multi-machine, sophsticated algorithms, hairy numerical routines, and typically some sort of interface to a scripting language with a REPL.
The answers I got were: Go is a systems programming language, not for scientific computing (I believe they have now relaxed this opinion but the damage was already done).
And a REPL wasn't necessary because Go compiled so quickly you could just write a program and run it (no, that misses the point of a repl, which is that it builds up state and lets you call new functions with that built-up state).
And scripting language integration was also not a desirable goal, because Go was intended for you to write all your code in Go, rather than invoking FFIs.
A number of other folks who used Go in the early days inside Google complained: it was hard to call ioctl, which is often necessary for configuring system resources. They got a big "FU" from the go team for quite some time. IIUC ioctls are still fairly messy in Go (but I'm not an expert).
I think Go spent a lot of time implying that goroutines were some sort of special language magic, but I think everybody knows now that they are basically a really good implementation of green threads that can take advantage of some internal knowledge to do optimal scheduling to avoid context switches. It took me a while to work this out, and I got a lot of pushback from the go team when I pointed this out internally.
IN short, I think go could have become a first-class HPC language but the go team alienated that community early on and lost the opportunity to take a large market share at a time when Python was exploding in ML.