You say your house is clean, yet nothing’s stopping me from dumping out this bucket of mud on your floor, curious!

It’s very different. You have to come at problems in a very different way because the tools at your disposal are not what you’re used to.

The language itself is quite elegant and simple, if you strip it down to its essence it’s basically “when you see A on the left side of the equals sign, replace it with B on the right side of the equals sign” repeated until your program has either errored out or been boiled down to a single value. The type checker ensures that the replacement will be legal no matter what’s happening at runtime, and can really help with getting things lined up just right because it’s very thorough.

The simplicity also leads to complexity, though, for a few reasons. The solution to any problem is usually generalizable, since there’s such a small surface area to the language itself and the type system allows for very abstract declarations of what a thing does, which leads to very beautiful solutions that are also so general and reusable that it can take work to figure out “okay, so this thing composes one function that is traveling recursively down the list of pairs, applying this function to the first item, and that’s composed into this other function that is pulling them apart into separate lists…” whereas if it had been written the “dumb” way it’d be more like “oh, we’re breaking these items into two lists and tweaking the first item as we go,” unnecessarily tied to the one particular scenario and totally unusable anywhere else in your code, but also more readable and concrete. There’s an entire vocabulary of functions that do abstract things that you have to learn to make sense of what’s going on sometimes.

Related to that is monads, which are such a common pattern in Haskell that the language has special notation for them; they’re an incredibly powerful tool for putting values in a context and/or creating an environment where background details can be handled out of sight, but they’re also so generalizable that they span from the simplest monad that basically just captures “this thing might not actually exist” all the way to the IO monad which, in a way, represents the entire universe, or at least your entire computer. Learning Haskell means wrapping your mind around them, which isn’t impossible, they’re actually quite simple, basically just 2 functions that need to follow a few rules, but it takes a few examples and explainers to really get it.

Generally I think any programmer benefits from at least trying out something like Haskell, even if you never become an expert or use it day-to-day, it’ll give you a new angle to think from and could spark thoughts you never would have had before.

I think Haskell would be a good choice. It’s mature, used for real things (amongst a particular crowd, at least) and it’s emphatic about being purely functional. Even when it is forced to enable other styles like imperative, it’s done in a way that’s syntactic sugar for a pure version (do notation being a great example of this, it’s really just a chain of lambdas). You can do functional style programming in a lot of languages now, but they’ll also let you mix and match other styles, which can make it easy to “cheat.” Haskell will teach you functional programming and that’s it.

Also, since it sounds like you’re familiar with Rust, it uses a lot of ideas from Haskell. Rust enums are a clone of Haskell’s algebraic data types, patterns are almost exactly the same, traits are typeclasses right down to the fact that the compiler can derive some common ones automatically, Rust strongly encourages immutability while Haskell basically requires it, and in both languages you’re only allowed to break the rules if you start using things with the word unsafe in them. My experience learning Rust was “oh, C and Haskell had a baby named Rust, cool!” The big difference is that in Rust, you’re programming from inside a C-style computer with RAM, while in Haskell you’re programming in a mathematical void and the computer is tidily packed away in a box labeled IO.

A fun guide for learning Haskell is here: https://learnyouahaskell.github.io/

It’s not undoing the division, it never happens in the first place. Remainders aren’t ever fractions, that’s the whole point, they’re left over because they can’t be divided evenly. 5 % 2, you can take 2 away twice and you’ll have 1 left over which can’t have 2 taken away.

(_|_)

A minimal but powerful language can feel like magic. Like, literally. The whole appeal of magic in stories is that you can step out of the normal rules and do something that defies belief, and who hasn’t fantasized about that in real life?

If the language you’re using has a lot of magic built into it, things that the language can do but you can’t do, you feel mundane, like the language is letting you look at the cool things it can do, but doesn’t let you do them yourself. A more minimal language, where the important things are in the library, means that the language designers haven’t kept that stuff to themselves. They built the language such that that power is available to everyone. If the language gives its standard library authors the power to do things beautifully and elegantly without special treatment, then your library is getting those benefits too.

It’s also a sign of good design, because just saying “well, this thing magically works differently” tends to be a shortcut, a hack, an indication that something isn’t right and couldn’t be fixed nicely.

Most people don’t need a file to be in two places at once, it’s more confusing than convenient. And if they do want two of a file at all, they almost certainly want them to be separate copies so that the original stays unmodified when they edit the second one. Anyone who really wants a hard link is probably comfortable with the command line, or should get comfortable.

The Mac actually kind of gets the best of both worlds, APFS can clone a file such that they aren’t hard links but still share the same blocks of data on disk, so the second file takes up no more space, and it’s only when a block gets edited that it diverges from the other one and takes up more space, while the unmodified blocks remain shared. It happens when copy-pasting or duplicating a file in the Finder as well as with cp on the command line. I’m sure other modern file systems have this as well.

Hint: the solution depends on a more realistic and physics-based model of the problem than you’re using. And, even bigger hint, it’s less intuitive now that light bulb technology has changed to become much more efficient, you should imagine this problem taking place with a '90s bulb.

I don’t understand why this works, but it does

What was happening before was this: Git received your commits and ran the shell script. It directed the script’s output stream back to Git so that it could relay it back over the connection to display on your local terminal with remote: stuck in front of it. Backgrounding the npx command was working, the shell was quitting without waiting for npx to finish. However, Git wasn’t waiting for the shell script to finish, it was waiting for the output stream to close, and npx was still writing to it. You backgrounded the task but didn’t give npx a new place to write its output to, so it kept using the same output stream as the shell.

Running it via bash -c means “don’t run this under this bash shell, start a new one and have it just run this one command rather than waiting for a human to type a command into it.”

The & inside the quote is doing what you expect, telling the subshell to background this task. As before, it’ll quit once the command is running, as you told it not to wait.

The last bit is &> /dev/null which tells your original, first shell that you want this command to write somewhere else instead. Specifically, the special file /dev/null, which, like basically everything else in /dev/, is not really a file, it’s special kernel magic. That one’s magic trick is that when you write to it, everything works as expected except all the data is just thrown away. Great for things like this that you don’t want to keep.

So, the reason this works is you’re redirecting the npx output elsewhere, it just goes into a black hole where no one is actually waiting for it. The subshell isn’t waiting for the command to finish, so it quits almost immediately. And then the top level shell moves on after the subshell has finished.

I don’t think the subshell is necessary, if you do &> /dev/null & I think it’d be the same effect. But spawning a useless shell for a split second happens all the time anyway, probably not worth worrying about too much.

I most associate it with Slashdot comments in the 2000’s, complaining about Microsoft spreading fear, uncertainty, and doubt about Linux and the GPL to scare companies into thinking that if they used Linux, they’d have to open source all their software, so yeah, definitely not just a cryptocurrency term.

I’m curious, what’s the worst case scenario in your eyes? I struggle to see why anyone would closed-fork it, or what threat it would pose if they did.

Why isn’t “it’s informed and you can just opt out” good enough for paid users? They could’ve developed a single system instead of two if that’s a sufficient standard of care for users’ data.

Opt out means “we will be doing this, without permission, unless you tell us not to” and opt in means “if you give us permission we will do this.” Codebases can contain important and sensitive information, and sending it off to some server to be shoved into an LLM is something that should be done with care. Getting affirmative consent is the bare minimum.

The right thing is to make it opt-in for everyone, simple as that. The entire controversy goes away immediately if they do. If they really believe it’s a good value proposition for their users, and want to avoid collecting data from people who didn’t actually want to give it, they should have faith that their users will agree and affirmatively check the box.

If free users are really such a drain on them, why have they been offering a free version for so long before it became a conduit to that sweet, sweet data? Because it isn’t a drain, it’s a win-win. They want people using their IDE, even for free, they don’t get money from it but they get market share, broad familiarity with their tool amongst software engineers, a larger user base that can support each other on third party sites and provide free advertising, and more.

The best, clearest code in the world will make it perfectly clear exactly what’s going on, but not why. “database.fetch(); // Fetch from the database” is a terrible comment, sure, but “// Resource loading is done lazily on first run, so we cannot depend on it being available right away” is something that can’t be conveyed through code alone.

They’re doing as much of a bad thing as they think they can get away with. I don’t feel a particular duty to carefully acknowledge that in some circumstances they feel obligated to do the right thing instead. If they don’t like the “misleading” aspects of that, they’re free to just do the right thing completely.

https://blog.jetbrains.com/blog/2025/09/30/detailed-data-sharing-for-better-ai/

I only use it when I’ve royally messed up and the commit I need to get back is no longer referenced anywhere. Accidentally deleted a branch, finished a merge or rebase before realizing I messed up, that kind of thing, just use the reflog to find it again, get a branch pointing to it, then try again.

Those images in the mirror are already perfect replicas of us, we need to be ready for when they figure out how to move on their own and get out from behind the glass or we’ll really be screwed. If you give my “”“non-profit”“” a trillion dollars we’ll get right to work on the research into creating more capable mirror monsters so that we can control them instead.

Fan art is generally protected because of a rule called “fair use”, which allows people to use copyrighted work without permission. For example, if you briefly quote a book, the author won’t have success if they go after you for copying from their book, even though you clearly did. Generally speaking, a person making fan art and not selling it is going to be protected under fair use. The law wants creators to have control of the thing they created, but we all live in a shared culture and we all deserve to participate in the art we experience, so there’s some wiggle room, and this has been the case long before AI was a thing.

What these AI companies are doing, on the other hand… well, it hasn’t really been tested in court yet, but they’re doing a lot more than single images or brief quotes, and they’re doing it for money, so they’ll likely have some work to do.