It's a shame that the tyranny of volumetrics referenced in the article means that in the UK some of my favourite crisp flavours have been brief one-off novelty runs - coronation chicken, baked bean, and numerous flavours rolled out for world cups in the form of nationality-themed assortment bags.
Built-in graphics commands are a massive win, and a big gap in today's standard language offerings for kids. Any old timer will tell you that the ability to trivially get sprites up on the screen, or hell even a coloured circle, is the clue to the young programmer that putting together a simple game is within their immediate grasp, and this is very much the gateway drug to programming in general.
A microwave needs two dials - one for power level, and one for time. Not a calculator keypad, not buttons with +1 and +10 on them or any of that nonsense - dials please. And start/stop buttons if you insist. That's it. It does not need a 'defrost chicken drumsticks' programme cluttering up the ui, because that function is far better fulfilled by a human repeatedly running the thing at low power for a few mins then poking the food with a finger
Sure the performance isnt hindered. The microwaves will keep microwaving.
The food will just be blasted into an inedible state.
Dealing with this right now; At someone's place with such a dial microwave and they work around its incredible lack of precision at the consequence of burned or frozen food.
many years ago an older relative went on a holiday to Spain and was outraged that their apartment did _not_ have carpet. I deemed it futile to point out that carpeting is desirable here because our climate is so wretched, but as flooring in a hot country would actually be pretty icky.
I had no idea that each 'Spoons has its own custom carpet design. They are a much-derided chain but this is a nice detail, and by keeping drinking affordable they ensure the next generation of Britons can keep alive the vital tradition of a night in the pub laughing and talking bollocks.
In the UK a misplaced apostrophe (in a plural or in possessive its) is called a "greengrocers' apostrophe", presumably due to folks in that trade being particularly susceptible to errors in their signs, in turn partially due to the slightly unusual nature of the nouns they are pluralising; "bananas" is slightly teasing you to stick one in, but "mangos" more so as just looks like a Greek island otherwise, unless you opt for the -oes form.
Ha. That makes sense, I wonder why or how that became a thing?
It's the same case in the US -- you see it most in locally owned mom-and-pop style stores, especially ones that have been around for a while.
It genuinely makes me wonder if it's out of ignorance, or if it's intentionally keeping a kind of old-school charm. "If apostrophes were good enough for my grandfather, they're good enough for me!"
Of course, there's also a store local to me that has "&" on its big sign instead of "&", so I don't want to read in too much intention. (And you can tell it's not the kind of business that can afford to have a replacement sign made.)
It's worth reiterating that Go was created by Google to solve Google's problems. If it also solves your problems, or a worthwhile subset thereof, then that is a happy serendipity, but it's not a design goal.
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt." – Rob Pike 1
The problem Go solves is that google has a bunch of people who can hack out code, but don't really know the theory of computer science, can't understand high level abstractions and complex type systems... So they need a language for "the average programmer", or as pg would say, "the blub programmer".
They invented the blub language. Blub programmers are everywhere at google, and they are everywhere in the industry, so its primary design goal is applicable to almost every company in the world.
I agree that this is a real problem, but newer languages like Swift and Rust are targeting newbie coders while keeping the benefits of advanced type systems. The key is to surface errors in compiler diagnostics, so that the newbie coders know when they're getting it wrong. It's using the compiler as a friendly TA. Golang doesn't really solve the problems of newbies, it just punts the issues to runtime where they will likely end up causing breakage in production.
> Golang doesn't really solve the problems of newbies, it just punts the issues to runtime where they will likely end up causing breakage in production.
The GC in Go punts the issue of memory management to the runtime, but does so in a largely correct way. In that one way, Go is easier than rust in a way which genuinely does not cause any real production issues.
However, the most important tradeoff when talking about Go vs Rust on this startup-infested hellsite is not related to the quality of code at all.
The goal of a startup is not to produce working production code, but rather to convince VCs of its trajectory. VCs don't care about buggy code. Every company has buggy code, it's expected you have bugs. Normal. Possibly even a good sign. "Move fast and break things". What matters more is the number of warm programmer butts you have in seats. VCs want you to hit your headcount targets, and unfortunately, hiring programmers that will make your codebase a buggy spaghetti mess is much easier than hiring Rust programmers.
Said another way, good code might actually be a problem in startup-land since it will make it harder to meet VCs hiring expectations.
> The key is to surface errors in compiler diagnostics, so that the newbie coders know when they're getting it wrong.
That "key" is making Rust the complexity issue it is. Which is why it is considered so hard to pick up, both by newbies, and by experienced programmers. And yes, I know, there will be people who say "Rust is easy!". Well, show me people who learned most there is know of Rust over a weekend, or who understood a large Rust codebase while still learning the language. In Go, I personally know several people who did both. In Go I onboarded people who never before even saw any Go code, without an issue.
> Golang doesn't really solve the problems of newbies, it just punts the issues to runtime
These are not problems of newbies.
Yes, GCs are an adequate solution to the complex problem of memory management. Most real world production code written doesn't have performance constraints that prohibit the use of a GC.
No, it was created by a group of distinguished engineers who just wanted to create a language they liked. As I understand it they wanted to improve on C but take a radically different direction from C++, which they disliked.
Rather than being explicitly designed for problems Google was facing, it took a fair amount of time to find a niche (initially, log processing).
Go was created to solve the problem of how to write real world code solving practical problems in the space of backends, systems (not system) programming and microservices, where performance matters, with a language that is easy to learn, the code of which is easy to read and maintain, which is easy to understand for tooling, and which lends itself naturally to projects where many coders of different skill levels and personal preference work on the same thing.
I believe that it is very much a problem many entities that aren't Google like to have a good solution for.
These things are quite subjective. In practice though, Go lacks the kinds of features that would make very large scale codebases (the sorts of codebases where "many coders ... work on the same thing") truly surveyable, understandable and easily maintained. I mean, it's not a complete disaster like Python or JavaScript. It has some features to support modularity and programming "in the large". But other modern languages like Rust or even Swift are quite a bit better on that side of things, and it shows.
There's an aside to that: Supposedly within google itself, they have super-magical tooling (ie: rename `dev.foo.bar(abc)` to `abc.dev.v2.foo(bar)`), so it's less important to have those "in the language", when "they" can just refactor "everything".
Us mere mortals are trying to pick up Thor's hammer at the end of the day.
And yet the largest Go projects seem to be doing fine, dwarfing the largest Rust or Swift projects in the level of activity, number of contributers, and general impact on the ecosystem. And I speak as someone who prefers to write Rust.
Perhaps these features you speak of don't matter as much as we think.
Slightly younger than the punch card era, but one bit of "old" tech I don't miss is the line printer. We had one in an office with a nylon carpet, and you'd approach that thing with utter dread because some combination of the action of the paper spewing out at speed, the metal guide bars for the ejected paper, and that bloody carpet meant that collecting a printout gave you an even chance of a massive static electricity shock.
