Null doesn't. `union(Int?, String?)` will only have 1 type of null, unlike a proper discriminated union.

The C# unions as described are discriminated unions.

The fact that they flatten a union of optional types into an optional union of the corresponding non-optional types is indeed a weird feature, which I do not like, because I think that a union must preserve the structural hierarchy of the united types, e.g. a union of unions must be different from a union of all types included in the component unions, and the same for a union of optional types, where an optional type is equivalent with a union between the void/null type and the non-optional type, but this C# behavior still does not make the C# unions anything else but discriminated unions, even if with a peculiar feature.

> that a union must preserve the structural hierarchy of the united types, e.g. a union of unions must be different from a union of all types included in the component unions, and the same for a union of optional types, where an optional type is equivalent with a union between the void/null type and the non-optional type

This is exactly the difference between simple union types and discriminated unions. This c# feature is what typescript has, not what Haskell/java/f#, etc.

The word "discriminated" by itself does not specify this property.

"Discriminated" just means that at run time you can discriminate the values of a union type by their current type, so you can use them correctly in expressions that expect one of the component types.

I agree that the right implementation of discriminated types is that mentioned by you and which is that of many important programming languages, but even if I disapprove of this property that the C# unions have, which in my opinion may lead to unexpected behavior that can cause subtle bugs, the C# unions are still discriminated unions, where you can discriminate the current type at run-time, with a "switch".

In my opinion, one should avoid this weird behavior of C#, by always defining only unions of non-optional types. Where needed, one should then define an optional type having as base a union type. Then these unions will behave like the discriminated unions of other languages.

Whether you use or not this policy, there are types that the C# unions cannot express, but if you use this policy, at least the limitations become explicit.

Take your pick :) https://www.templatemaker.nl/en/

Can you set your clock forward or does this also require phoning home to a central server to install an app on your computer?

It'll be interesting to see how the timing is enforced. Can you just set up your own NTP server to fool your phone into thinking it's really the future (and not just you adjusting your phone's clock manually). Will Google run a clock that you have to get a timestamp from (would it be easy to setup your own MITM proxy to get around this?). If the time somehow jumped backwards, would you lose the ability to install apps? Can google remotely disable this after it's already enabled (I think yes)?

It requires an internet connection to adjust the toggle.

I think it would be a bad idea to require an internet connection (for one thing, you might want to write your own app that does not require a internet connection); but, even if it doesn't, would not mean you can set the clock to avoid the delay, because it could be made to reset the delay if the clock is set.

Here's a version from 2014 in the same style if you're curious: https://web.archive.org/web/20140702092610/https://news.ycom...

They're not doing so here, but shipping a wasm-compiled binary with npm that uses node's WASI API is a really easy way to ship a cross-platform CLI utility. Just needs ~20 lines of JS wrapping it to set up the args and file system.

Doesn’t this seem excessive over just using rust’s cross platform builds?

There's no such thing as a truly "cross-platform" build. Depending on what you use, you might have to target specific combinations of OS and processor architecture. That's actually why WASM (though they went with WASI) is a better choice; especially for libraries, since anyone can drop it into their environment without worrying about compatibility.

there’s 3 os and 2 architectures minus darwin-amd64 so you just need to do 5 builds to avoid the WASM performance tax.

(freebsd runs linux binaries and the openbsd people probably want to build from source anyways)

I think GP's point is that instead of having 3 target-specific rust-built binaries, they have 3 target-specific node binaries running rust-built wasm plus wrapper code.

Can you link to a sample of how I can do this?

We guarantee 5 nines of uptime, and 1 nine of not killing people

It's just a regional thing. Neither is correct or wrong. You may as well yell at a french person that the word is "cheese", not "formage".

From the very article you linked:

> In English, the noun mathematics takes a singular verb. It is often shortened to maths or, in North America, math.

I lowkey am enjoying this conversation lol.

This is cutting off the "Access to private data" leg of the lethal trifecta. One of the few ways to actually make an agent secure.

Ohhhh... So that's why it's called Y combinator.

That's essentially correct. Extraction is a term in roqc. A rocq program contains both a computational part, and proofs about that computation, all mixed together in the type system. Extraction is the automated process of discarding the proofs and writing out the computational component to a more conventional (and probably more efficient) programming language.

The original extractor was to ocaml, and this is a new extractor to c++.