I read this for the first time probably 15 years ago, and to this day I can't think about IPv6 without thinking about this passage from the guide:
What does this suggest to you?
That we need a lot more addresses. That we need not just twice as many addresses,
not a billion times as many, not a thousand trillion times as many, but 79 MILLION
BILLION TRILLION times as many possible addresses! That’ll show ’em!
You’re saying, “Beej, is that true? I have every reason to disbelieve large numbers.”
Well, the difference between 32 bits and 128 bits might not sound like a lot; it’s
only 96 more bits, right? But remember, we’re talking powers here: 32 bits represents
some 4 billion numbers (232), while 128 bits represents about 340 trillion trillion
trillion numbers (for real, 2128). That’s like a million IPv4 Internets for every
single star in the Universe.
We have a small but growing team working on a diverse range of projects with the common thread of connecting vehicles, to the internet and to each other. We are enabling exciting new possibilities in vehicle functionality including cooperative and remote driving, real-time data collection and monitoring, predictive maintenance, automatic vehicle updates, and much more.
You would be creating software on embedded Linux-based on-board connectivity control units. You would be involved in all aspects of the software lifecycle including design, implementation, testing, deployment, and maintenance.
As an engineering service provider, our main asset is engineering competence, so we work hard to ensure the personal and technical growth of all our team members.
Mostly C and C++. Personally I am working in a C++ codebase right now and I struggle with all sorts of finicky cross-compilation and linking problems that just wouldn't exist in Go.
We also do some Python and Javascript for scripts and web work.
Interesting read, and I admit there is some of that. But my point isn't to say that those features aren't useful or powerful, but rather that with the constraint of working with a large group of programmers of varying skills, simplicity has more value than power (as long as we can deliver software that meets our requirements). It is similar to point 4 in the "Problems with the Blub Paradox" section.
I must say that whenever there is a discussion about the merits of the Go programming language, it really feels hostile in the discussion thread. It seems that people are seriously angry that others even consider using the language. It is sort of painful reading through the responses which implicitly declare that anybody who enjoys programming with Go is clueless.
It also really makes me wonder if I am living in some sort of alternate reality. I am a professional programmer working at a large company and I am pretty sure that 95% of my colleagues (myself included, as difficult as it is for me to admit) have no idea what a reified generic is. I have run into some problems where being able to define custom generic containers would be nice, but I don't feel like that has seriously hindered my ability to deliver safe, functional, and maintainable software.
What I appreciate most about Go is that I am sure that I can look at 99% of the Go code written in the world and I can understand it immediately. When maintaining large code bases with many developers of differing skill levels, this advantage can't be understated. That is the reason there are so many successful new programs popping up in Go with large open-source communities. It is because Go is accessible and friendly to people of varying skill levels, unlike most of the opinions expressed in this thread.