> X++

I was very deep into .NET until recently but somehow I didn't know this existed. Looks like C# with extra Linq-to-SQL syntax; I guess it's a DSL made with Roslyn for ERP jobs? I wonder how they picked the name.

The other team is also paid to make the whole thing work, though. That alone is not enough reason to yield.

In what world is Go an obscure programming language??

In 2026 world, whilst you're advocating for 1980.

I'm not advocating for anything in this thread, and definitely not for Go's outdated language design, although Typescript is so unsound it isn't better in my book. But obscure is not synonym for regressive.

The world of many, many companies.

Windows Notepad isn't a standalone product, but a Windows feature that has its title localized into every language as part of Windows, none of which are registered as a trademark.

And should it be considered a commercial product, Notepad alone is too generic so the trademark would probably be Windows/Microsoft Notepad, just like products named Something-Office both predate and followed Microsoft Office.

Already in 2008, as a millennial teen without internet at home, I was learning C# and XNA without a single book, just tutorials and official docs I downloaded from the library alongside Visual Studio Express. I couldn't have afforded books on it anyway, but I can't imagine teens in 2026 using anything other than Youtube and some tutorials to learn this stuff.

"Enabling wrapping behaviour" for signed integers disallows a lot of optimizations based on signed overflow being undefined behaviour, which is a matter of language and compiler design. This says nothing about the cost of checked arithmetic itself on the CPU.

It does, though. UB and associated optimisations wouldn't be an issue if defined behaviour would not have an impact on performance. If the cost would be zero or negligible, the compiler wouldn't need to care and hence warnings like this wouldn't need to be explicitly stated.

And yet Swift doesn't rely on these optimizations, preferring to trap instead. Again, the guess above was about the CPU and we're conflating language-specific UB optimisations.

This is kind of a thing already in the EU. Under NIS 2, vulnerabilities should be notified to a CSIRT as well as upstream, and the CSIRT shall identify downstream vendors and negotiate a disclosure timeline. I don't know whether they're any good at it or not, though.

Cool to see F# here! Emulators are a great way to learn a language. On first sight you chose well between more or less idiomatic F# for each job.

Some low hanging fruit to reduce allocations: the discriminated unions in Instructions.fs could be [<Struct>], reusing field names to reuse internal fields.

Also, minor nitpick but I'm confused about some of the registers. They are already of type byte, the setters with `a &&& 0xFFuy` don't add anything over `member val A = 0uy with get, set`. I'm guessing this changed over time.

The Register source has this comment:

    // Registers can't be a record type because the values need to be truncated to 8 bits when writing, so setters are needed
    // This is for the web renderer as Fable transpiles uint8 to Number (more than 8 bits) in JS and doesn't apply any truncation
    // Known non-standard behaviour in Fable (https://fable.io/docs/javascript/compatibility.html#numeric-types)

So, I think, it's just conservatively cleaning the data due to Fable's widening via js Number on the web target.

Oof, thanks for pointing that out, I hadn't noticed and I've only ever used F# on .NET.

That's terrible on Fable's part, the least they could do is truncate. I wasn't aware Fable's translation is so naive.

I haven't used Fable much, but apparently it maps .NET arrays to js TypedArray. Presumably you could keep the registers in 8-element array and fable will properly produce a Uint8Array. I'd like to benchmark that.

Fable is great but it has a surprising number of these hidden behaviour changes that are really hard to detect when writing code against it.

It’s really hard to please everyone all of the time on this front.

This kind of thing is why Roc compiles to WASM but not JS.

It's actually discussed in the article in the part where he ports it to fable (he also tried blazor)

I admit I skimmed from there on because I don't find web dev exciting, but you're right, it is. That's a terribly naive translation on Fable's part.

You probably meant Forgejo. Codeberg is a Forgejo instance exclusive for FOSS projects.

My guess is the camera itself was taking photos of shorter exposure and the final image was composed in post-production, yes.