A “pure” function could instead work around it by returning (without executing) a query, accepting a state and returning a new, modified state, or otherwise returning some kind of commands to the caller without directly querying the database.

At least in Haskell due to lazyness this is (almost) always what happens. A monad is just one kind of deferred computation, with an operator >>= (“bind”) that happens to prevent compiler reordering or deduplication. Any IO actions are only executed when main is evaluated and no earlier. Strict functional languages to my knowledge don’t need monads to do IO since they don’t have the same issues with evaluation order that Haskell does (though they might want them for type safety purposes).

Is a database handle you can write to not … basically mutable state, the arch-nemesis of functional languages?

Well, kind of. You would treat it the same way you would treat pipe/terminal or file IO: You write some impure functions that do the actual IO (database calls), and some pure functions that work on your data types. Then you compose them together to make an application. Hopefully most of your code is in the pure part which means you can test it without having to mock the world.

This honestly isn’t all that different from how a well written imperative code bases turn out. You generally don’t want to put all of the IO and all of the business logic into one super function or method or even class, because that makes things really hard to test (and hard to reason about too if you go far enough).

You can have actual in-memory mutable state in functional programming too, you just don’t get it on every variable by default. At least in Haskell you would usually achieve this by using a type that does it for you, like IORef or ST or MVar or TVar. The reasoning above applies to those - You would generally use them sparingly, when you really need mutability (e.g. to pass data between threads), and not everywhere.

This isn’t a very good article IMHO. I think I agree (strongly) with what it’s trying to say, but as it’s written, it just isn’t it.

Wrappers and VMs and bytecodes and runtimes are bad: they make life easier but they are less efficient and make issues harder to troubleshoot.

Runtimes/“VMs” like the JVM also allow nice things like stack traces. I don’t know about the author but I much prefer looking at a stack trace over “segmentation fault (core dumped)”. Having a runtime opens new possibilities for concurrency and parallelism too.

The COSMIC desktop looks like GNOME, works like GNOME Shell, but it’s smaller and faster and more customisable because it’s native Rust code.

This just doesn’t make any sense. COSMIC is more configurable because it wants to be, this has absolutely nothing to do with Rust vs Javascript.

Dennis Ritchie and Ken Thompson knew this. That’s why Research Unix evolved into Plan 9, which puts way more stuff through the filesystem to remove whole types of API. Everything’s in a container all the time, the filesystem abstracts the network and the GUI and more.

And here the author just contradicts themselves. So wrappers, runtimes and VMs are bad, except when it’s Ken Thompson doing it in which case adding containers and a language runtime into a kernel is a great idea actually?

Lastly, I didn’t address the efficiency arguments in the quotes because it’s mostly just true… but I do think it requires some more careful consideration than “JS bad Rust good”. Consider this unscientific sample of different apps on my PC and how much of my (expensive!) RAM they use:

• Spotify (Electron): 1G
• Ghostty (Zig/GTK): 235M
• Decibels (Typescript/GTK): 140M
• Anyrun (Rust/GTK): 110M

Note that Electron, and only Electron, is a supermassive black hole of bloat. Whatever is going on here, it’s not Javascript.

deleted by creator

I can’t speak for everyday workflow (having discovered this project less than a week ago), but rebase being unnecessary and cherry-pick not creating duplicate commits seem like the most notable advantages to me.

I am very sorry to remind everyone about the existence of Visual Basic, but it has:

• VbCrLf
• VbNewLine
• ControlChars.CrLf
• ControlChars.NewLine
• Environment.NewLine
• Chr(13) & Chr(10)

And I know what you’re asking: Yes, of course all of them have subtly different behavior, and some of them only work in VB.NET and not in classic VB or VBA.

The only thing you can rely on is that “\r\n” doesn’t work.

To be fair that’s not the entire story, since you need to actually resolve the conflicts first, which is slightly scary since your worktree will be broken while you do it and your Linter will be shouting at you.

You may also want a dedicated merge tool that warns you before accidentally commiting a conflict and creating a broken commit.

Oh and non trivial resolutions may or may not create an evil merge which may or may not be desirable depending on which subset of git automation features you use.

Using git status often is definitely good advice though.

I agree.

You could say that about any kind of autocomplete. Why would people install snippet plugins into their vim/emacs? Sure you can just type everything by hand but it’s just more convenient.

Personally I find these kinds of inline AI suggestions make a more convincing use case than trying to prompt engineer a Chat based LLM and diverting your attention to phrasing specifics instead of the actual problem space.

If your build fails because you can’t track down the literal ≠ in the code I would recommend just looking at the compiler error. I understand the concerns about == vs = more but the vast majority of LSPs (and some compilers) will catch that too.

I have also yet to see any IDE enable ligatures by default, at least VS Code and the JetBrains suite both require opting into them even though their default fonts support them.