Why does a TV need Microsoft Copilot? While I think AI on the whole is a long-term net positive, but I just cannot understand Microsoft's insistence on putting Copilot everywhere. Even in places where it has no business being and against the user's wishes. I cannot remember the last time a company was this tone deaf. Why isn't Satya Nadella personally getting involved already? Seriously inexcusable.
Formula One teams are known to throw money (and lots of it) at problems. It works for them because:
- 2 drivers/cars per team.
- ~2 hour race on a weekend every ~2 weeks per season.
They don’t need to solve every problem and the solutions just need to work well during the race (at least for the pit crew).
The hospital needs to do this for hundreds of patients every day. They need solutions that can scale (cost less per person). This was about one specific problem (handover) but different patients could bring with them different complications and add new constraints.
Still very cool though. Glad they got some actionable insights.
It's more to do with the bureaucratic costs of getting a product licensed as a medical device. By the standards of the medical industry, an F1 wheel nut gun or a WEC refuelling rig isn't particularly expensive; the prohibitive part is getting a specialist item approved for medical use. Motorsport can do things that don't scale, because no-one is stopping them from using a one-off prototype made to precisely fit their needs. They (and their suppliers) iterate incredibly rapidly Bringing a new medical device to the market is an immensely expensive multi-year project. Obviously there are benefits to the precautionary principle, but I'm not sure that anyone has quantified the costs.
I personally loved using Go 8 years ago. When I built a proof of concept for a new project in both Go and Rust, it became clear that Rust would provide the semantics I’m looking for out of the box. Less fighting with the garbage collector or rolling out my own memory management solution.
If I’m doing that with a lot of ugly code - I might as well use idiomatic Zig with arenas. This is exactly the point the author tried to make.
Your last paragraph captures the tension perfectly. Go just isn’t the tool we thought for some jobs, and maybe that’s okay. If you’re going to count nanoseconds or measure total allocations, it’s better to stick to a non-GC language. Or a third option can be to write your hot loops in one such language; and continue using Go for everything else. Problem solved.
Go made it explicitly clear when it was released that it was designed to be a language that felt dynamically-typed, but with performance closer to statically-typed languages, for only the particular niche of developing network servers.
Which job that needs to be a network server, where a dynamically-typed language is a appropriate, does Go fall short on?
One thing that has changed in the meantime is that many actually dynamically-typed languages have also figured out how to perform more like a statically-typed language. That might prompt you to just use one of those dynamically-typed languages instead, but I'm not sure that gives any reason to see Go as being less than it was before. It still fulfills the expectation of having performance more like a statically-typed language.
By the common usage of the term, it is most definitely a systems language.
Systems are the "opposite" of scripts. Scripts are programs that perform a one-off task and then exit. Systems are programs that run indefinitely to respond to events. We have scripting languages and we have systems languages. While all languages can ultimately be used for both workloads, different feature-sets gear a language towards one or the other. Go is does not exhibit the traits you'd expect of a scripting language.
This idea that Go isn't a systems language seems to stem from "Rustacians" living in the same different world which confused sum types with enums, where they somehow dreamed up that systems are low-level programs such as kernels. To be fair, kernels are definitely systems. They run indefinitely too. But a user land server program that runs continuously to serve requests is also a system as the term has been normally used.
Long before Rust or Go existed, “systems languages” were commonly the ones you can write a whole system in to run on hardware, like C, Pascal or C++. I’m not opposed to that definition changing, but it certainly hadn’t when Go came out.
I agree that Rust enums should have been called unions, though.
While that does not match my memory, it works too. An assembly language is part of Go, so it fits among the languages you mention. The only constraint it imposes is your imagination (and what the hardware is capable of). However, it remains that "systems language" was caveated as being for network servers specifically. But no matter how you slice it, I think we can agree that Go isn't a scripting language, so it must be a systems language.
Rust does use enums under the hood in order to implement sum types, so the name as it is used within the language is perfectly valid. It's just not clear how that turned into nonsense like Go not having enums (which it does).
It says "more like", not "like". Javascript now performs more like a statically-typed language, as one example. That wasn't always the case. It used to be painfully slow — and was so when Go was created. The chasm between them has shrunk dramatically. A fast dynamically-typed language was a novel curiosity when Go was conceived. Which is why Go ended up with a limited type system instead of being truly dynamically-typed.
> Or a third option can be to write your hot loops in one such language; and continue using Go for everything else. Problem solved.
Or use Go and write ugly code for those hot loops instead of introducing another language and build system. Then you can still enjoy nicety of GC in other parts of your code.
I can see that being an option in a small team that works closely with one another and wants to keep things simple.
Though it is my personal opinion that forcing a GC-based language to do a task best suited for manual memory management is like swimming against the tide. It’s doable but more challenging than it ought to be. I might even appreciate the challenge but the next person maintaining the code might not.
The thing is, using an agent or AI to code for you is a learned skill. It doesn’t come naturally to most people. For you to be successful at it, you’ve got to adopt a mentor / lead mindset - directing vs doing. In other words, you have to be an expert at explaining yourself - communicating clearly to get great results.
Someone who hasn’t got any experience coding, or leading in any capacity, anywhere in life (or mentoring) will have a hard time with agentic development.
I’ll elaborate a bit more - the ideal mindset requires fighting that itch to “do it yourself” and sticking to the prompts for any changes. This habit will force you to get better at communicating effectively to others (including agents).
Supports MPS (Metal Performance Shaders). Using something that skips Python entirely along with a mlx or gguf converted model file (if one exists) will likely be even faster.
'Management' is not one size fits all. Every company is different. Its needs are different. What a manager is supposed to do is different too. If someone behaves the same way as a manager no matter the company or the people they work with, I think that's terrible.
Being a manager is about listening. It is about tuning into the environment. It is about being there for the team in whatever way they need support. Sometimes that means being a coach. Other times it means fighting for them. And sometimes, when an unpopular decision is made above your pay grade, it means breaking it down for the team in a way that they 'get it'. You want them to understand without completely losing morale or slipping into rebellion.
Brutal honesty sounds great on paper. But not everyone can handle it or is ready for it.
It is a balancing act. Even if everyone "knows", bitch*ng about the company to your reports can only lead to bad outcomes. So you acknowledge the company's shortcomings. At the same time, you try to help the team find purpose and fulfillment in other ways.
> I’m not the first person to pick on this particular Github comment, but it perfectly illustrates the conceptual density of Rust
Eh, that's not typical Rust project code though. It is Rust code
inside the std lib. std libs of most languages including Python are a masterclass in dark arts. Rust is no exception.
Thanks again for creating this and sharing it here. Honestly makes me want to pick up C++ for a project just to try it out (along with reflection and other new features).
reply