6 ms·

This is a retrospective written by Rob Pike, one of the creators of the Go language. I worked at Google at the time go was created and had coffee with Rob from

by dekhn 3y ago

This is a retrospective written by Rob Pike, one of the creators of the Go language. 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.

leetrout 3y ago
I dream of a world where we have Go or something similar with the same / similar UX of Jupyter Notebooks. I keep an eye on Julia but I never make the leap to use it and still pickup Python (or Go).
- zozbot234 3y ago
  https://github.com/evcxr/evcxr https://github.com/evcxr/evcxr can run Rust in a Jupyter notebook. It's not Golang but close enough.
- Art9681 3y ago
  https://github.com/gopherdata/gophernotes https://github.com/gopherdata/gophernotes I've had this bookmarked for some time and just havent gotten around to it.
leeoniya 3y ago
> 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. "just avoid cgo" is a something i've heard many times from all Go devs
liampulles 3y ago
Interesting context. I use Go a lot for enterprise backend type work and I have to say I'm glad its not geared towards being an HPC language, but to each their own.
randomdata 3y ago
> I believe they have now relaxed this opinion 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.
- coldtea 3y ago
  >Or is it that scientific computing is starting to realize that it can benefit from a systems programming language? 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.
  - randomdata 3y ago
    A huge percentage of scientific computing is scripting in nature. It would be silly to use anything other than a scripting language. 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.
    - galaxyLogic 3y ago
      There are 2 conflicting goals: 1) Having a language in which it is easy to express and try out ideas and 2) Producing fast and safe programs. 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?
      - randomdata 3y ago
        No doubt it starts as an open question and slowly moves towards knowing. 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.
google234123 3y ago
There’s engineers at Google trying to get things done, and ones trying to create new languages… they don’t talk to each other too much
mattbee 3y ago
I think Java's "green" threads only ran on a single core, a stop-gap for 90s machines that only had one. 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.
- zozbot234 3y ago
  Goroutines use thread-per-core but run stackful fibers on top of that. (A similar model is sometimes known as "Virtual Processors" or "Light-weight processes".) This is unlike the use of stackless async-await in other languages. This peculiar use of fibers in Go is also what gets in the way of conventional C FFI and leads to quirks like cgo.
  - jtasdlfj234 3y ago
    Excellently described. 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.
  - dekhn 3y ago
    In the future, I think thats what I'll say. Thanks.
    - pcwalton 3y ago
      I usually just say that Go implements "userspace threading", since that's really what it is. Some early, pre-pthreads, implementations of Linux threads worked the same way as Go does and they usually called such implementations "M:N", to indicate M userspace threads mapped onto N kernel threads, so "M:N" is a good descriptor too.
      - dekhn 3y ago
pphysch 3y ago
This seems misdirected. Go clearly wasn't designed for scientific computing, and that's okay. I've successfully written some multi-node MPI codes in Go, but there's not much advantage over C, and likely some disadvantages relating to the Go runtime and linking behavior. 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).
- theLiminator 3y ago
  I think the main issue with Python tends to not be performance (though it can be hard to speed up certain bottlenecks), but rather there's a point where maintaining it goes from very easy to very difficult due to lack of static typing. Where this occurs can be pushed further back with very careful programming discipline (or by adopting mypy et. al from the start). But I could see a world where something go-like with a little more expressivity could've become that glue language instead of python.
  - pphysch 3y ago
    This is a software engineering practices problem rather than a Python problem. Python has great tooling and language support for type annotations. I work on large Python codebases with ease because I leverage these things. My IDE is able to do static analysis and catch potential typing errors before runtime. 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.
npalli 3y ago
Good historical perspective thanks for it. Your comments on scientific computing/HPC are interesting. Golang could indeed have solved the two-language problem and taken off like a rocket in comparison to where it is (hovering in the top 15). However, I think it would have to tackle some very orthogonal concepts - to the systems language creators like Rob and others on the go team - like vectorization as first class concept, parallelism (not green threads) etc. which might have limited some of the initial implementation efficiencies, not sure. There is still room for such a language (Julia is getting there...) perhaps some disgruntled FORTRAN elder who is sick of C++ will create such a new language :-)
tejohnso 3y ago
> Rob hates Bjarne Stroustrup That sounds extreme. What did Bjarne do to him?
- aragonite 3y ago
  Don't know about Rob Pike in particular but Ken Thompson, who probably had the same reasons for "hating" Stroustrup, had this to say about him (from Coders at Work): 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.
  - aragonite 3y ago
    But also see previous discussion of these remarks on HN: https://news.ycombinator.com/item?id=27938122 https://news.ycombinator.com/item?id=27938122
chaxor 3y ago
It's ok that Go didn't work out for scientific crowds, since Julia works better for the scientific community as a replacement for hacky Matlab/c++/Fortran conbled-together scripts.
rdtsc 3y ago
> Go is a systems programming language, 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".
- sevagh 3y ago
  From the same team that came up with the unique, searchable, and identifiable word "Go" for a programming language.
- kragen 3y ago
  rob pike's definition of 'systems software' from 02000 is in http://doc.cat-v.org/bell_labs/utah2000/utah2000.html http://doc.cat-v.org/bell_labs/utah2000/utah2000.html > 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
  - rdtsc 3y ago
    Then which languages aren’t systems languages? Python can connect things together, BASIC, Java, Javascript. I guess only some GUI DSL languages might not be.
    - kragen 3y ago
      some are worse at it
norir 3y ago
> 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). 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.
- randomdata 3y ago
  Thing is, there are several REPLs for Go. That we have quite a few comments pretending that Go doesn't have a REPL comes as a direct result of nobody – that is, beyond the REPL authors wanting to scratch an itch – ever needing one. After all, if a REPL was necessary, the people commenting that Go doesn't have a REPL would know that Go has a REPL as they would be users. Pike's point has proven itself here.
qaq 3y ago
Are there a lot of HPC workloads at Google compared to concurrent/parallel servers?
- kragen 3y ago
  well, now there are. but pagerank was one from the beginning
  - dekhn 3y ago
    pagerank was implemented as an iterative mapreduce on classic hardware (and sibyl later adopted this model, using MR as an engine to do what is really an HPC job). Not sure I really consider it HPC, more like high throughput. HOwever, the MR approach worked really well when google was scaling super-fast in the early days; if they'd chosen to solve the problem using MPI and infiniband on expensive SGIs, they probably wouldn't have become the company they are today.
    - kragen 3y ago
      agreed about infiniband and sgis, but numerically approximating the principal eigenvalue of a large sparse matrix seems solidly in the core of traditional hpc. btw pagerank predates mr by several years
tgv 3y ago
I can totally agree on excluding scientific computing. A lot of that simply is more cobbling something together than software engineering. And HPC wouldn't be happy with Go anyway. > 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.
sapiogram 3y ago
> 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. 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? [1] https://www.youtube.com/watch?v=HxaD_trXwRE https://www.youtube.com/watch?v=HxaD_trXwRE

by dekhn 3y ago

leetrout 3y ago

I dream of a world where we have Go or something similar with the same / similar UX of Jupyter Notebooks. I keep an eye on Julia but I never make the leap to use it and still pickup Python (or Go).

zozbot234 3y ago
https://github.com/evcxr/evcxr https://github.com/evcxr/evcxr can run Rust in a Jupyter notebook. It's not Golang but close enough.
Art9681 3y ago
https://github.com/gopherdata/gophernotes https://github.com/gopherdata/gophernotes I've had this bookmarked for some time and just havent gotten around to it.

leeoniya 3y ago

> 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. "just avoid cgo" is a something i've heard many times from all Go devs

liampulles 3y ago

Interesting context. I use Go a lot for enterprise backend type work and I have to say I'm glad its not geared towards being an HPC language, but to each their own.

randomdata 3y ago

> I believe they have now relaxed this opinion 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.

coldtea 3y ago
>Or is it that scientific computing is starting to realize that it can benefit from a systems programming language? 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.
- randomdata 3y ago
  A huge percentage of scientific computing is scripting in nature. It would be silly to use anything other than a scripting language. 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.
  - galaxyLogic 3y ago
    There are 2 conflicting goals: 1) Having a language in which it is easy to express and try out ideas and 2) Producing fast and safe programs. 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?
    - randomdata 3y ago
      No doubt it starts as an open question and slowly moves towards knowing. 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.

google234123 3y ago

There’s engineers at Google trying to get things done, and ones trying to create new languages… they don’t talk to each other too much

mattbee 3y ago

I think Java's "green" threads only ran on a single core, a stop-gap for 90s machines that only had one. 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.

zozbot234 3y ago
Goroutines use thread-per-core but run stackful fibers on top of that. (A similar model is sometimes known as "Virtual Processors" or "Light-weight processes".) This is unlike the use of stackless async-await in other languages. This peculiar use of fibers in Go is also what gets in the way of conventional C FFI and leads to quirks like cgo.
- jtasdlfj234 3y ago
  Excellently described. 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.
- dekhn 3y ago
  In the future, I think thats what I'll say. Thanks.
  - pcwalton 3y ago
    I usually just say that Go implements "userspace threading", since that's really what it is. Some early, pre-pthreads, implementations of Linux threads worked the same way as Go does and they usually called such implementations "M:N", to indicate M userspace threads mapped onto N kernel threads, so "M:N" is a good descriptor too.
    - dekhn 3y ago

pphysch 3y ago

This seems misdirected. Go clearly wasn't designed for scientific computing, and that's okay. I've successfully written some multi-node MPI codes in Go, but there's not much advantage over C, and likely some disadvantages relating to the Go runtime and linking behavior. 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).

theLiminator 3y ago
I think the main issue with Python tends to not be performance (though it can be hard to speed up certain bottlenecks), but rather there's a point where maintaining it goes from very easy to very difficult due to lack of static typing. Where this occurs can be pushed further back with very careful programming discipline (or by adopting mypy et. al from the start). But I could see a world where something go-like with a little more expressivity could've become that glue language instead of python.
- pphysch 3y ago
  This is a software engineering practices problem rather than a Python problem. Python has great tooling and language support for type annotations. I work on large Python codebases with ease because I leverage these things. My IDE is able to do static analysis and catch potential typing errors before runtime. 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.

npalli 3y ago

Good historical perspective thanks for it. Your comments on scientific computing/HPC are interesting. Golang could indeed have solved the two-language problem and taken off like a rocket in comparison to where it is (hovering in the top 15). However, I think it would have to tackle some very orthogonal concepts - to the systems language creators like Rob and others on the go team - like vectorization as first class concept, parallelism (not green threads) etc. which might have limited some of the initial implementation efficiencies, not sure. There is still room for such a language (Julia is getting there...) perhaps some disgruntled FORTRAN elder who is sick of C++ will create such a new language :-)

tejohnso 3y ago

> Rob hates Bjarne Stroustrup That sounds extreme. What did Bjarne do to him?

aragonite 3y ago
Don't know about Rob Pike in particular but Ken Thompson, who probably had the same reasons for "hating" Stroustrup, had this to say about him (from Coders at Work): 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.
- aragonite 3y ago
  But also see previous discussion of these remarks on HN: https://news.ycombinator.com/item?id=27938122 https://news.ycombinator.com/item?id=27938122

chaxor 3y ago

It's ok that Go didn't work out for scientific crowds, since Julia works better for the scientific community as a replacement for hacky Matlab/c++/Fortran conbled-together scripts.

rdtsc 3y ago

> Go is a systems programming language, 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".

sevagh 3y ago
From the same team that came up with the unique, searchable, and identifiable word "Go" for a programming language.
kragen 3y ago
rob pike's definition of 'systems software' from 02000 is in http://doc.cat-v.org/bell_labs/utah2000/utah2000.html http://doc.cat-v.org/bell_labs/utah2000/utah2000.html > 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
- rdtsc 3y ago
  Then which languages aren’t systems languages? Python can connect things together, BASIC, Java, Javascript. I guess only some GUI DSL languages might not be.
  - kragen 3y ago
    some are worse at it

norir 3y ago

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

randomdata 3y ago
Thing is, there are several REPLs for Go. That we have quite a few comments pretending that Go doesn't have a REPL comes as a direct result of nobody – that is, beyond the REPL authors wanting to scratch an itch – ever needing one. After all, if a REPL was necessary, the people commenting that Go doesn't have a REPL would know that Go has a REPL as they would be users. Pike's point has proven itself here.

qaq 3y ago

Are there a lot of HPC workloads at Google compared to concurrent/parallel servers?

kragen 3y ago
well, now there are. but pagerank was one from the beginning
- dekhn 3y ago
  pagerank was implemented as an iterative mapreduce on classic hardware (and sibyl later adopted this model, using MR as an engine to do what is really an HPC job). Not sure I really consider it HPC, more like high throughput. HOwever, the MR approach worked really well when google was scaling super-fast in the early days; if they'd chosen to solve the problem using MPI and infiniband on expensive SGIs, they probably wouldn't have become the company they are today.
  - kragen 3y ago
    agreed about infiniband and sgis, but numerically approximating the principal eigenvalue of a large sparse matrix seems solidly in the core of traditional hpc. btw pagerank predates mr by several years

tgv 3y ago

I can totally agree on excluding scientific computing. A lot of that simply is more cobbling something together than software engineering. And HPC wouldn't be happy with Go anyway. > 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.

sapiogram 3y ago

> 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. 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? [1] https://www.youtube.com/watch?v=HxaD_trXwRE https://www.youtube.com/watch?v=HxaD_trXwRE