I believe every reader understands that Claude’s behavior is faulty here, what the disagreement is whether or not it is a tragedy. As the result of the error is a minor inconvenience, there is no tragedy.
giving AI access to delete all your files -> human in the wrong for sure
I'm not saying the AI did make a mistake, but it should have been limited to the file it was working on, not everything in the dropbox. and yes, that's an error from the human
This is obviously bad model behavior (though I'd personally like to see the full transcript to see if there are any clues in there as to why it made the mistake.)
It's hardly new, though. We've been talking about models making stupid mistakes like this for years.
> We've been talking about models making stupid mistakes like this for years.
It seems like it should be a bigger issue that despite years of updates and improvements, AI agents still shit the bed in spectacular fashion like this. Simply shrugging our shoulders and accepting "agents be crazy" is precisely the opposite reaction we should take, especially as tech professionals.
Perhaps the joke about how meteorologists are the only professionals who can screw up badly on the regular and keep their jobs needs to be updated to include LLMs.
The post you replied to literally doesn't care about upgrades.
More enforcement also doesn't matter if its what you need to get specifically _what was asked for_, which is a thinner device in this case.
I also wouldn't like an X60 if it meant I have to leave things out of my bag.
AFAIK, the language is and was used in JB's projects.
JB is just very picky about when he wants people to see things.
He doesn't want outside voices influencing him and he still has some things he wants to think through. Doing that mostly solo takes time - it's not like the PL is the only thing he has been doing
If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I would like you to elaborate on how still being in closed beta is an argument against the thesis. To me it just looks like avoiding feature-requests, nitpicks and community interactions for a product he doesn't even want to sell.
I'd agree more except that as far as I know (I'll admit I've not been following the development that closely) he's been significantly building it in public on Twitch. So he's happy to spend time sharing it with the public, and has been from the start; it's just taken a long time to get it to a usable state.
> If you are fine with getting there 80% his claim is correct. That he's using the language for his games proves it to me. Of course, if you require it to be both open and popular to be a success you kind of reach a stalemate. In a world where everyone can quickly whip up a language I would expect most to be closed to the public anyway.
I think we're firmly in agreement here, except that IMO the default for software that's not for public consumption is to throw it over the wall, put the source up on GitHub or something, and not bother with documentation, explanation, or interaction. A carefully curated closed beta is kind of the opposite of that. If anything he's spending more time promoting it than I would expect.
Do people miss the word "ergonomically" in my original comment? Because yeah, the semantics is essentially the same, just as it would be the same for e.g.
double.TryParse("5.x5", out double val, out bool ok);
if (ok) { ... }
in case of a hypothetical variant of C# that doesn't have functions, only procedures, so you'd have to return the data from subroutine calls by ref/out/globals exclusively. It's still would be the same semantics — but quite different ergonomics.
So out of those three choices: return all results by assigning to ref/out parameters; return one result directly, all other by assigning to ref/out parameters; return all results directly — I personally prefer the last one. Almost nobody prefers the first one, yet people seem to be strangely attached to the second variant for some reason.
the set theoretic type system variant has one issue I think the algebraic one avoids:
An overlap between types is ambiguous, i.e. "int | int" doesn't make any sense to write. In a function parse_postal_code, where you either get the postal code, or an error code you wouldn't be able to differentiate.
You could write your own types for that, but now you've essentially recreated what the algebraic versions do by forcing a selection through the type constructor on the inner type instead of the wrapping union type.
That being said, in cases where there is no overlap I don't see why "the old way" shouldn't behave like typescript through implicit conversion as there is only one applicable constructor. Forcing explicit selection if there is overlap, but do it automatically when there is none seems like reasonable behavior that is a strict superset of what you wrote before.
At least the fallout will be less if you have to resolve your custom domain differently in the intranet due to something like this.
If github is "taken down" you can't just resolve the whole domain differently, you need to only resolve the packages differently. If your "Golang domain" is taken down, it should be a lot easier to hotfix until something proper is implemented (the quickest and dirtiest would be a hostfile-entry).
As far as I know you might want to read the GLSL or Vulkan specification. At least there (and by extension in SPIR-V) you can select different floating point behaviors.
Historically graphics programming has been more concerned with looking good rather than being accurate, and behavior is likely different on each GPU. It's a "hop into the water and learn to swim" kind of thing as far as I'm concerned.
You will find errors for things you'll never have thought about and there is hardly any way to brace for it except trying on the go.
In short: Benchmark numbers were always more important than consistency (traditionally, GPU vendors competed on frames-per-second, not on image quality).
E.g. floating point behaviour is only the tip of the iceberg. Every GPU vendor also does mipmapping differently (to balance image quality versus required memory bandwidth).
You can share with header files and respective (shared) object files regardless of the build system you're using.
Likewise you could just share the source. None of this needs a build system.
I was just being a bit sardonic because the C++ ecosystem is so fragmented that something like tokio couldn't really exist. It would be one of three executors in boost, abseil, or folly, and you would never see the kind of downstream ecosystem build on top of them because C++ shops are allergic to external dependencies.
Any organisation that cares about security should be allergic to external dependencies, that is why companies like Nexus and JFrog exist, with companies paying to keep internal repos infrastructure in shape.
One just doesn't install willy nilly from the Internet into the CI/CD pipeline.
Well, they do, and then spend a few late nights when there is a bunch of CVE to fix.
Using an artifactory instance as the origin is not functionally different from installing something 'willy nilly' from the internet. It addresses a narrow range of threats while predominantly being more reliable and faster than public repositories.
It doesn't fix the actual problems with C++, which is that it's significantly more difficult to get and use external dependencies because of the compilation and linkage model of C++ libraries.
If C++ were as easy to build and link as modern programming languages you'd see the same kinds of tools as cargo, and the same kinds of ecosystem evolution as rust, like tokio. But you don't, because C++ code sucks to build, package, distribute, update, and reuse.
(I'm aware/have used conan/meson/vcpkg/etc - doesn't change my opinion).
It surely does, because in most companies that care about security it isn't a mirror, rather the only third party packages that developers are allowed to use beyond the standard library.
Additionally, making new packages available for consumption requires approval from IT and possibly legal, before they become available for consumption.
What is hard is people educated in scripting languages not wanting to learn about toolchains.
The moment Rust depends on other programming languages, we get a build.rs spaghetti file, depending on the knowledge of those writing it, or people throwing away Cargo altogether, and replacing it with Bazel, buck2 and co.
I think the crowd will split into those who just cared about it being rust and those who wanted some kind of leverage to tempt others into doing something.
The former crowd will cease being, while the latter looks for something new to push.
I believe that one does not need to be overly concerned here. As with most things you will never satisfy zealots so it is sufficient to reconsider every once in a while when the status quo changed enough to warrant the effort (i.e. the actual arguments change).
It is always a choice to participate in these "culture wars" or whatever you want to call this. If you can stick to a decision you can limit the impact quite a bit, I've come to realize.
I've never been someone to tell others to rewrite in Rust but I am a huge fan of the language and have in fact rewritten a lot of things in Rust. I'd be happy for another programming language to excite me as much as Rust has for the last 10 years, and then maybe I'd join that evangelism club instead :). Not sure how PL evolution is going to go in an era of coding agents though, very curious how that'll play out.
Files not recovered -> human in the wrong
Files recovered due to independent backup -> no problem
Is there any scenario in which you'd accept Claude's behavior as faulty here?
reply