you can say that without a spec as well but what does “wrong” mean then? It just means you personally disagree with its behavior.

Nope. Specs can have bugs. Here are the bugs in the C++ spec for example:

https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_toc.html

As I said, specifications are useful and desirable, but the SIL's dogmatic "no spec = unsafe" is clearly not based in reality.

Eh, it practice it works extremely well. I can't remember a single instance where a PDF document rendered incorrectly.

The format is very old so it's not surprising it has picked up a few WTFs. I'm happy to keep those hidden below the abstraction.

I wish we had something like McMaster Carr in the UK. I don't even care if it's fast! You guys had better appreciate how good you've got it.

That's cool, but in my experience if you get to the OOM killer then 80% of the time it's too late and your system is basically dead. My laptop hard reboots most of the time when this happens.

Hopefully it works with the early-OOM hacks.

IMO Julia just had way too many big issues to gain critical mass:

1. Copied 1-based indexing from MATLAB. Why? We've known that's the worse option for decades.

2. For ages it had extremely slow startup times. I think because it compiles everything from C, but even cached it would take like 20s to load the plotting library. You can start MATLAB several times in that time. I believe they improved this fairly recently but they clearly got the runtime/compile time balance completely wrong for a research language.

3. There's an article somewhere from someone who was really on board with Julia about all the issues that made them leave.

I still feel like there's space for a MATLAB replacement... Hopefully someone will give it a better attempt at some point.

Sooo much inane naysaying in that Rust for Filesystems article. I'm glad there are people with the stamina to push through it.

Part of the problem, Ted Ts'o said, is that there is an effort to get "everyone to switch over to the religion" of Rust

I would say a bigger problem is that there are people that think Rust is some kind of religion with acolytes trying to convert people. Is it really that hard to distinguish genuine revolutions (iPhone, Rust, AI, reusable rockets, etc.) from hyped nonsense (Blockchain/web3, Metaverse, etc.)?

These things are very obvious IMO, especially if you actually try them!

I mean... let's just hope he isn't doing this professionally.

Quite a lot of misunderstanding here I think.

This will make the point of your language being compiled entirely moot imo.

Not at all. Compiling to machine code rather than bytecode isn't about avoiding having a runtime. Hell, C has a runtime. It's called the C RunTime (CRT).

ML/Scheme/CLisp achieve memory safety through closures. Haskell achieves this through Monads.

No they use garbage collection and bounds checking just like imperative languages. There are some slight differences but those are nitpicks.

Functional languages have a property which allows them to be be both compiled into machine code and bytecode, and also, interpreted like an scripting language.

Absolutely nothing to do with being functional or not. Dart is not functional and it supports AoT and JIT compilation.

You can’t describe what C does with math.

You absolutely can describe what C does with maths. I understand it's very hard but check out CBMC for example.

What C does depends on the platform, the CPU, etc.

So does Rust to some extent, e.g. usize.

Semantics here is clear. Right?

I have no idea what you're trying to say here. The lifetime is completely irrelevant here because you have no references.

What is a ‘function’ in C? Well most C compilers translate it to an Assembly subroutine, but what if our target does not support labels, or subroutines?

The C specification says what a function is.

You see what I am arriving at?

Not even remotely lol

You were so preoccupied wondering what asinine comment you could make that you never bothered to read the article and learn the reasons that they should.

I totally agree, though I think it's worth adding:

• The advantages of static types is not just finding bugs (though it does do that quite well). It also massively helps with productivity because a) types are now documented, b) you can use code intelligence tools like renaming variables, go-to-definition, find-references, etc. (assuming you use a good editor/IDE).

• In general stronger types are better but I do think there is a point at which the effort of getting the types right is too high to be worth the benefit. I would say Rust hasn't reached that point, but if you look at formal verification languages like Dafny, it's pretty clear that you wouldn't want to use that except in extreme circumstances. Similarly I think the ability to use an any or dynamic escape hatch is quite useful, even if it should be used very sparingly.

Really? I might have agreed for some other languages, but Go is so bare bones it feels like it takes way longer to write simple stuff than with Rust - you have to tediously write out loops all the time for example.

Tbf I haven't used it since it got generics. Maybe it is better now.

These long confusing errors are near universal in languages / libraries that have complex types. You get the same thing in C++ code that uses template metaprogramming e.g. Eigen.

It is quite annoying but I don't really know of a solution other than using a library that doesn't express full expressions as types.

Chumsky does something similar but it also has a .boxed() modifier you can use to type erase the types at strategic points to keep them a manageable size. I believe Xylem is going to do the same with its statically typed widget tree. Maybe Diesel offers something like that?