Linux distros don't differ too significantly from each other nowadays (systemd plus a different package manager most of the time), so I'm almost sure this is not the source of problems.

Nonetheless, I can only add that we have ridiculous slowdowns in some standard library network calls on Linux, and at that point it is just not true that it will "seamlessly run on Linux", unfortunately.

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.

> Union types — exhaustive matching over a closed set of types

> Closed hierarchies — exhaustive matching over a sealed class hierarchy

> Closed enums — exhaustive matching over a fixed set of enum values

I believe the last one would be sum types (disc. unions). This one allows overlapping types.

As the language designer notes in the comments, these are named unions, as opposed to anonymous ones, but they are also working on the latter.

"Sealed" is probably not the correct word to use here, as it would be sealed in both case (it doesn't really make sense to "add" a type to the A | B union). The difference is that you have to add a definition and name it.

An example that may show the difference: if you have a language with nullable types, then you basically have a language with union types like String|Null, where the Null type has a single value called `null` and String can not be null.

Now if you pass this around a function that itself may return `null`, then your type coalesces to String|Null still (you still get a nullable string, there is no doubly nullable). This is not true for Maybe/Option whatever you call types, where Some(None) (or Optional.of(Optional.empty())) is different from None only.

Rich Hickey once made a case that sort of became controversial in some FP circles, that the former can sometimes be preferred (e.g. at public API surfaces), as in for a parameter you take a non-nullable String but for returns you return a String|Null. In this case you can have an API-compatible change widening the input parameters' type, or restricting the return type - meanwhile with sum types you would have to do a refactor because Maybe String is not API compatible with String.

/s

Being memory safe without being managed is what makes rust a truly novel and interesting language for which it rightfully gets the hype.

Besides, they probably do a separate analysis on server side either way, so they can check a true positive to false positive ratio.

It would just simply not make sense for them to let other companies' improvements go out of the window, unless they can directly monetize it. So it doesn't apply to every project, but especially these low-lying ones would be safe even without any sensible license.

People way overestimate the actually intelligent part of LLMs vs simply being good at recalling context-related stuff from the training data.

Birds burn a ton of energy flying (at least the birds in question here, other birds can glide for long times), it's not something they would willingly do to no ends.

It is just an optimization that makes sense -- writing an OS that is compatible with all sorts of hardware is hard, let alone one that is performant, checked for vulnerabilities, etc.

Why would each gigacorp waste a bunch of money on developing their own, when they could just spend a tiny bit to improve a specific area they deeply care about, and benefit from all the other changes financed by other companies.