Honestly this looks like it sits in the useless middle ground between “proper CI that has all the features you expect” and “just write a Python/Deno script or whatever”. I can’t see what you gain.

Also you say “no painful YAML pipelines” but it uses YAML??

TCL & CMake are fully stringly typed. Both pretty terrible languages (though TCL can at least claim to be a clever hack that was taken far too seriously).

It is INT_MIN. Seems like a much more sensible value than 0 IMO.

Try interacting with anything that uses u64 and you’ll be a lot less happy!

Anyway JavaScript does have BigInt so technically you are choosing.

that insanity is how C and Intel handle NaN conversions.

It’s not actually quite as bad as the article says. While it’s UB for C, and it can return garbage. The actual x86 conversion instruction will never return garbage. Unfortunately the value it returns is 0x8000… whereas JS apparently wants 0. And it sets a floating point exception flag, so you still need extra instructions to handle it. Probably not many though.

Also in practice on a modern JS engine it won’t actually need to do this operation very often anyway.

Yeah. I think the smallest number of number types you can reasonably have is two - f64 and arbitrary precision integers types. One of the few good decisions Python made.

That’s not a network effect.

They’re clearly not going to be able to afford $100m/year in free CI.

Relatively minor for source code forges.

The reasons everyone uses GitHub:

• Free, even for private repos. No ads.
• Free CI - this is huge. Nobody else does this because it costs Microsoft around $100m/year to provide.
• It’s quite good.

If anyone can ever compete with that then I doubt network effects will keep people there.

Terrible title. The article is about the risks of everyone using GitHub. That doesn’t mean GitHub is destroying the open source ecosystem. In fact it’s the complete opposite - GitHub massively helps the open source ecosystem. That’s why everyone uses it in the first place!

Interesting idea, but your trick is never really going to help (you can store up to 255 bytes instead of 254). Also always using 256 bytes for every string seems wasteful.

I think LLVM’s small string optimisation is always going to be a better option: https://joellaity.com/2020/01/31/string.html

This comment perfect captures why I don’t like Lisp. Essentially “it’s simple, this easy to read code transforms to this AST”. Lisp basically says “we can make parsing way easier if we force programmers to write the AST directly!” which is really stupid because computers can perfectly well parse syntax that is easy for humans to read and turn it into ASTs automatically.

It makes it easier to parse for computers at the cost of being much harder to parse for humans, which is really the wrong choice in most cases. (The exception is if you’re DIYing your compiler, e.g. if you’re teaching how to write a compiler then Lisp is a good target.)

I’m not a fan of Lisps either. But I also thing the Nix language is kind of awful… So maybe in comparison it’s ok?