jaen

By Haskell's type system do you mean with all the GHC extensions?

Because TypeScript has structural sub-typing, while standard Haskell (eg. `A | B | C`) has neither subtyping nor structural typing, which both are very useful features for safe "integration/glue" type of programs.

(String) literals form a fundamental part of the TS "row polymorphism" (record types) and eg. tuple union type implementation.

You can type a non-empty array that starts with zero...

    type Arr = [0, ...number[]];
    const a: Arr = [0, 1, 2, 3, 4]

Now try in Haskell.

These are not what are commonly called tagged unions. It's actually closer to an untagged union.

The C# union does not store any discriminator. Just look at the implementation - it's a single `object?` field.

The discriminative part is handled by run-time type information, which is stored in the object itself, not the union - which is why the C# built-in implementation requires boxing.

Also, you can use the same class/record type ("discriminator") in several different unions - again, a feature which ADTs/sum-types/tagged unions in most functional languages do not have.

You can even store one single object (ie. identical by reference equality) in several different union values at the same time, theoretically, which in combination with mutability is... uhh, certainly not common functional/mathematical semantics.

String literals are structural types which are way more expressive than regular (Haskell) ADTs, which are nominal types.

In TS in particular, in combination with other features (mapped types), they are equivalent to row polymorphism + whatever Haskell/GHC features enable type families to specialize on constant literal arguments (or you can use atomic types, but that's not structural / open-world)... so pretty advanced.

This is valid TS/Python:

    type ABC = "A" |"B" | "C"
    type AB = "A" | "B"
    const x: AB = "A";
    const y: ABC = x;

The equivalent Haskell requires using several extensions.

err... copyright-violation-as-a-service?

Wow, that's pretty cool. Translating (almost) arbitrary floating point programs into weird integer programs while also preserving equivalence under non-strict floating point semantics? Mathematics can be surprisingly wonderful.

open access arXiv link to pre-print for those that actually want to read it:

https://arxiv.org/abs/2507.03516

Part of FUNARCH 2025 (ACM SIGPLAN Workshop on Functional Software Architecture).

Links to other talks/abstracts: https://functional-architecture.org/events/funarch-2025/

Yeah, I'm fully aware, no point in "works for me"-ing this.

CGO_ENABLED=0 breaks nsswitch etc. and overall makes Go a poor ecosystem inhabitant. Only usable if you only care about your own system.

but... why not just use pnpm? It's generally a straightforward migration.

It has dependency cooldowns, build scripts disabled by default, and the setting you mentioned.

Server platforms definitely need UEFI or something very much like it. How else can a server boot from eg. a network card that's not directly supported by the firmware? You need something like UEFI to define a standard for option ROMs, and that standard needs a stable, backward-compatible ABI.

AFAIK, only UEFI and ACPI fulfill that requirement currently (ok, there's Open Firmware, but that's quite esoteric) - eg. Coreboot doesn't really work well in this situation: multiple vendors, different update lifecycles and possibly closed-source binaries.

Nah. Go also relies on libc if you do anything non-trivial, like look up a the IP address of localhost.

    $ go build -o hello main.go
    $ file hello && ldd hello
    hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, Go
        linux-vdso.so.1 (0x00007f9c7b404000)
        libc.so.6 => /usr/lib/x86_64-linux-gnu/libc.so.6 (0x00007f9c7b1ce000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f9c7b406000)

Uhh... did you read the same article?

Where does it propose re-inventing the wheel? It just says "make things addressable" eg. an URL for every object.

Regarding your examples, they don't even make sense in that context.. eg. how is eg. a terminal addressable, currently? You have to know a priori to wrap it in `tmux` and that's an ad hoc solution. (and it's not discoverable in any way that the current IDE pane is attached to session X)

This is just calling for "accessibility" of the internal states, which is not only useful for AI, but other automation as well.

Think more about URLs, MIME types, hypermedia etc.

Noticed this myself as a VSCode-derivative user.

But I think this is just because having multiple Python extensions enabled generally breaks the UX...

Since VSCode doesn't really have a nice way for multiple language extensions to cooperate, this looks like just a quick hack to make the initial UX better, unlikely to be "malicious".

EDIT: Silent downvotes, really? Prejudice is strong here...

Just by the (lack of) inter-model variance, I don't think SWEBench-Pro does a very good job of representing model capability. Terminal-Bench seems more challenging and separates the wheat from the chaff.

Also, *ops work, which in my experience can actually be more complicated than SWE is underrepresented there obviously.

For similarly sized models, not looking very good on the slightly-less-benchmaxxed Terminal-Bench 2.0:

  Laguna XS.2  33B-A3B params: 30.6
  Qwen 3.6     35B-A3B       : 51.5
  Devstral 2   123B          : 31.2

Quite a huge lead for Qwen... well, at least it's catching up to other smaller Western labs.

SEO spam link.

Actual webpage of the project: https://opencoworkai.github.io/open-codesign/

T3 Code should be similar: https://t3.codes/

Crystal has an explicit static type system and is actually optimized at the language level for AOT compilation. These features are pretty much required for compiling and maintaining large programs.

This is for a limited subset of Ruby - almost no popular Ruby gems would run under it. It's more like PreScheme [1] (ie. a subset of a language oriented at C compilation).

I don't think these compete in the same niches right now. Full Ruby almost certainly requires a JIT.

[1]: https://prescheme.org/

There are ways to partially improve or at least quantify the specification gap using LLMs, by analyzing variance in the output formal specification when given a natural language specification (by eg. generating many formal specs from an input description).

See eg. "Draft-and-Prune: Improving the Reliability of Auto-formalization for Logical Reasoning" [1].

[1]: https://arxiv.org/abs/2603.17233

No. Did you even read the article? It talks about the "specification gap", which is the difference between the formalized semantics and the intended semantics.

Every formal method has that problem (including the mentioned trivial ones like SAT and SMT).

LLM-generated slop. Could be written as two paragraphs.

C# is a great language with almost unlimited power and great ergonomics (as the article shows), but the .NET CLR (runtime) is a bit overcomplicated with a distinct "Java smell", and packaging and distribution is still meh.

If they could make the developer experience similar to Go, it would rule the world...

Maybe the content is great, but the AI writing style is really grating with its staccato sentences and faux-"profoundness". Can't bear it any more, stopped reading.

"You’re not checking logic. You’re checking shape.". Ugh.

Unfortunately, somewhat of a substanceless article, looks more like SEO spam.

Reiterates the same points everybody on HN has been making for the last couple of months and adds nothing new.

There are actually two different types of case fans - high airflow vs. high static pressure.

The CFM number alone doesn't show that.

I assume the high static pressure ones would do a much better job in this context.

I wish the "optimizations" meme would die as well, read my comment upthread on how that's generally inaccurate.

That's a blatant simplification, and does not match reality as far as I've seen.

The OS only only has one large source of memory it uses "optimistically" - the file/buffer cache. But that's tracked separately, so it doesn't show up in normal memory usage numbers (unless you don't know how to read them).

The other source of "extra" memory usage is memory mapped executable files, which can be unmapped and then read back on demand. That's quite small though.

Everything else (mostly) is actual memory usage caused by actual drivers and programs (though it can be swapped, but that's a major perf hit).

The major reason for Windows memory bloat is the hundreds of inefficient services from both Microsoft and hardware vendors that run at startup. The "optimization" pool (let's not call it that way) is way smaller than that.

eg. pre-loading an application is a pessimization if there's not enough memory - not only does it permanently eat away a portion of the total memory due to the intricacies of Windows working set memory management, it will need to be swapped out when actual demand for memory arises, competing with other disk access.

The only actual "optimization" in Windows is Superfetch, and that barely works these days.

It's a multi-level sauna though, so it's "choose-your-own-temperature" (due to the hot air gradient), not everybody is there for the 120C experience.

110C is not that unusual in the Nordics (although way above average, it's for tougher sauna goers). I've been in one. Not most people's cup of tea though, the experience is comparable to the opposite of a long cold plunge.

It doesn't write anything extra to the browser history. How about actually checking before exaggerating. If you are bothered by a single wrong title with the right URL, well... I think something else is wrong.

You are also completely speculating on the intent. Less drama please.