BitsAndObjects

"Sir", not "Mr." if you're going to be pedantic about titles ;)

Edit: Oh and he has multiple honorary doctorates (at least 6!), so would be just as much "Dr." too!

And, of course, the Go programming language.

Further Reading for the curious:

On specifically the relationship between Occam and Transputer architecture: http://people.cs.bris.ac.uk/~dave/transputer1984.pdf

Wider reading: http://people.cs.bris.ac.uk/~dave

This post appears to have been hidden from the front page of HN?

It’s also worth highlighting that the mathematical purity of the designs were also partly the problem with them. As a field, we’re still developing the maths of Effects and Effectful Algebras that are needed to make these systems both mathematically ‘pure’ (or at least sound to within some boundary) and ALSO capable of interfacing to the real world.

Transputer and Occam were, in this sense, too early. A rebuild now combining more recent developments from Effect Algebras would be very interesting technically. (Commercially there are all sorts of barriers).

“Inspired by” is an understatement of the century lol. David May and Sir Tony worked very closely together to enable the architecture to be as pure a runtime for CSP as you could get - at least in early versions of the architecture and accompanying Occam language. It expanded and deviated a bit later on iirc.

Source: David loved to tell some of these stories to us as students at Bristol.

Inmos’ Occam-based verification of their FPU in collaboration with researchers at Bristol and Oxford iirc? Citation: http://people.cs.bris.ac.uk/~dave/formalmethods.pdf

David May was my PhD supervisor and always spoke very highly of Sir Tony Hoare.

Edit: I’m also lucky enough to have worked with Geoff Barrett, the guy that completed that formal verification (and went on to do numerous other interesting things). Some people may be interested to learn that this work was the very first formal verification of an FPU - and the famous Intel FPU bug could have been avoided had Intel been using the verification methods that the Inmos and University teams pioneered.

This is the modern internet at work. People assume that a completely neutral statement that (to reword my original comment into a longer form) "here's a link to the same post from previously, because you might want to see it was there" and assume there's some kind of complaint or problem and take offense to their own assumption, and then downvote.

It's completely the opposite of HN "assume good faith" policy. Sigh.

And what in my comment said anything about there being a problem??

:thumbs-up:

As I said, the contribution is good, it's the communication via this blog post that I don't entirely like. It could have been different. It could have acknowledged better ways of engaging with ffmpeg (that would've benefitted both Meta and ffmpeg/the community, not _just_ ffmpeg).

But corporate blog posts often go this way. I'm not mad at them or anything. Just a mild dislike ;)

I've also had that experience of patching an OSS project internally, with the best intention of upstreaming externally-useful improvements in the future (when allowed).

However, my interpretation of the article was that they did a lot more than just patching pieces. They, perhaps, could have taken a much earlier opportunity to work with the core maintainers of ffmpeg to help define its direction and integrate improvements, rather than having to assist a significant overhaul now (years later).

Yes, they contributed to open source - this is a good thing.

But personally, I took issue with the tone of the blog post, characterised by this opening framing:

>For many years we had to rely on our own internally developed fork of FFmpeg to provide features that have only recently been added to FFmpeg

Could they not have upstreamed those features in the first place? They didn't integrate with upstream and now they're trying to spin this whole thing as a positive? It doesn't seem to acknowledge that they could've done better (e.g. the mantra of 'upstream early; upstream often').

The attempt to spin it ("bringing benefits to Meta, the wider industry, and people who use our products") just felt tone-deaf. The people reading this post are engineers - I don't like it when marketing fluff gets shoe-horned into a technical blog post, especially when it's trying to put lipstick on a story that is a mix of good and not so good things.

So yeah, you're right, they've contributed to OSS, which is good. But the communication of that contribution could have been different.

Same HN post from 6 days ago: https://news.ycombinator.com/item?id=47224355

[Edit: Why is anyone downvoting me linking to the previous post of this? What possible objection could you have to this particular comment?]

P.s. In career terms, it's become a defining career area for now because there's basically no interesting work outside of AI-related stuff.

That'll change in a few year's time. The industry can't sustain this level of obsession forever (for one thing, venture capitalists will move on to the next big thing, as per the very definition of their business model).

For now, it's a case of make hay while the sun shines.

Picking up another tool and figuring out where it's useful to integrate it into my workflow. Much the same as when I picked up BeyondCompare, VSCode (replacing Visual Studio) and numerous other tools that have come (and some, since gone).

The only major difference to past experiences of new tools is that AI appears to have a wide range of likely-looking uses (and even more _marketed_ uses), and only recently have specific use-cases/patterns started to emerge with any stability. Many of the likely-looking uses turn out to be minor or no improvement (in a good number of cases, actually worse), which cumulatively _change_ the workflow but don't _improve_ it. Then there's a few specific areas where it helps (sometimes enormously).

To be more concrete:

1. AI helps with being more specification-driven (AI UX people have inadvertently replaced with the word "specification" with "plan"). Think upfront, do research, plan the design, then get AI to scaffold the code, then spend lots of time cleaning up and dealing with filling-out to a full production-worthy implementation.

2. AI can (on average) help with writing anything which is easily scaffolded from existing 'stuff': boiler plate code; adding an extra piece of infrastructure following established patterns; writing commit messages for small commits with clear intentions from the code, and similarly for PRs.

3. AI is useful as a search and diagnostic tool. Impenetrable or just long error message? AI can summarise that and pull out the useful specifics (e.g. the target line of code and the actual likely interpretations of the message). And Google search has become so poor for specific searches that I rely more and more on Claude for finding (verifiable-by-me) answers.

- Has it changed my workflow? Yes.

- Has it replaced me? Not even close.

- Has it displaced some of the work I used to do? Yes. More time spent on architecture and debugging than on writing code. Debugging workload has gone up due to the convincing-but-wrong code AI often generates that then takes a while to pull apart and fix; or when the code just doesn't match a production-worthy architecture despite extensive planning: too much training on open-source which is made up of crumby code (by volume, not by popularity).

Sadly, (1) above has also meant that some of the joy of "diving into a problem and scrubbing around in the code to figure out what's going on" has been lost. Instead, just ask AI to "delve into it". For many people, this has removed a part of the process they found tedious. They just wanted to get to a solution. For some people, this has removed a part of the problem-solving challenge that was good fun. Professionally, it's a shift, and it's still hit or miss as to whether it's overall more productive or not. For hobby projects, it's a choice whether to start or continue using AI or not.

Parting thought: AI has been pretty great for web tech stuff. I can see why so many engineers (particularly in Silicon Valley) think it's going to rule the world. But outside of web tech (e.g. computer architecture), it's pretty pants. It's junior-engineer-quality/reliability on stuff it's had huge amounts of training on (web tech, infrastructure, fantasy art, etc.) but useless at things it's got much less coverage of (computer architecture, technical diagrams, 3D spatial reasoning, etc.). This is a comment on where LLMs like Claude and ChatGPT and others are at today. It is not a comment on the future potential, nor on what can be achieved using other forms of AI or combined forms of AI.

This is a personal viewpoint and experience, not on behalf of any current or former employer.

For a single machine, yeah Wireguard is fine. For my multi-user multi-machine many-service home lab, it’s quite helpful to have the extra small features that Headscale offers (and some it exposes in a more convenient way).

Edit: Tailscale has a fairly frank page on Wireguard vs Tailscale with suggestions on when to use which: https://tailscale.com/compare/wireguard

Have a look at Headscale to avoid the cost of Tailscale for small home setups.

(This affected TypeScript, .NET and other folk too)

The Faster Python project would’ve got further if Microsoft hadn’t let the entire team go when they made large numbers of their programming languages teams redundant last year. All in the name of “AI”. Microsoft basically gave up on core computer science to go chase the hype wave.

<3

An expert would’ve at least taken a backup or checked existing backups weren’t going to be destroyed. Silently - without asking their manager - they just do defensive engineering as a good practice. Or they would’ve, at minimum, highlighted the suggestion, which doesn’t seem to have happened in this case. As someone who recently did a short term contract to capture manually created AWS infrastructure into CDK, I can tell you this was one of my first moves!

So, Claude as a tool: sure, this is user error. Claude could be improved by making it suggest defensive steps and making it push harder for the user to do them first, but it’s still down to the user. I’ve repeatedly encountered this issue that Claude doesn’t plan for engineering - it just plans to code - even with Claude.md and skills and such.

Claude as a replacement for engineers? Well, yeah, the marketing is just that: marketing.

Sounds like something Claude could fix… /s

True.. though an experienced engineer would also risk getting fired for doing all the other stuff the OP did too. Especially if they made minimal attempts to highlight consequences/outcomes to management in advance..

Use Zulip.

The migration out of Slack is actually quite easy and preserves all messages, files, etc. Even the user migration is straightforward, keeping Google or whoever as the identity provider if you prefer.

That depends.

As per my root comment, if you ignore a lot of the marketing of AI and view it as just a tool, then I agree with your point about it doing what you tell it but I still want the tool to help me avoid making mistakes (and I’d like it to work quite hard at that - much harder, it seems, than it currently does). And probably to the extent that it refuses to run dangerous commands for me and tells me to copy/paste them and run them myself if I really want to take the risk.

If, however, we swallow the marketing hook, line and sinker: then yeah, I want the AI to behave like the experienced engineer it’s supposed to be.

"Anything that can go wrong, will go wrong. Including deleting production."

I'm also waiting for the day we see a "Claude sold my production database on the darkweb" post haha.

Yeah the videos hyping up Claude and other such AI tools don't help matters.

For sure I've made mistakes. But I also don't write the following on my CV:

"PhD-level expert in infrastructure and trained on the entire internet of examples of what to do and what not to do; I can replace your entire infrastructure team and do everything else in your codebase too, without any review."

And yet that's how Claude is marketed. AI tools in general have been repeatedly marketed as PhD-level experts in _every_ area of information-era work, especially code. They encourage hands-off (or consent-fatigued) usage.

[Just to be clear, in case anyone wants to hire me in future: I've never accidentally deleted a production database. I've never even irrecoverably destroyed production data - nor had to rely on AWS (or another provider) to recover the data for me. I've made mistakes, mostly in sandbox environments, sometimes stressful ones in production, but nothing even close to what the OP did.]

"To err is human; To really foul things up requires a computer."

Extended with: "To really foul things up quickly, requires an AI tool."

This is the purpose of sandbox environments.