>There are two main solutions: Use an option or maybe type or Use a nullable type
I don't get it. These are literally all exactly the same thing, all slightly varying in ergonomics and compiler support. They may differ slightly but to call them two different categories of solution is just creating a false dichotomy for yourself.
> However, the type system is a little more flexible than with option types. The type system understands that a union type is a supertype of its branches. In other words, int is a subtype of int?. That means we can pass a definitely-present-integer to something that expects a maybe-present-integer since that’s safe to do.
You can do that in Swift, despite being placed as an example of "Solution 1".
> The short answer is that, yes, it is entirely possible to live without null, and languages like Rust do.
If you can call say that Swift has "null", then you can equally say that Rust has "null"--it's called "None". The only way "None" and "null" from other languages differ is in built-in compiler support.
When I click a link, I want to know where I'm going. Where do you think "arewesmoothyet.com" will take you? If you guessed some Mozilla related thing purely from context, well you're also wrong. It's actually some WFH/affiliate marketing course. This was my point; domains are expensive and temporary for people who don't care. Because of this stupid joke, people actually interested in "Firefox Nightly hang telemetry visualization" or whatever have nowhere to go. One wiki, one page per topic, is all you need.
Well "next_ptr" is also a bad name, I agree, but I'm trying to name it something that indicates "this is a pointer to the 'next' pointer in the linked list".
What a waste of domain space (yes, I know they're abundant, but still.) areweaudioyet.com says nothing about its contents. areweasyncyet.rs had the right idea with the .rs domain name, but anyways, I feel like all of these would be better organized on one wiki, with one list for each category. Easier to search, edit, and hyperlink.
The top pattern is extremely common so comments are somewhat unnecessary since everyone would know what you're doing. In the second one, comments would be less necessary with a type annotation and perhaps a better name. Maybe "next_ptr" instead of "indirect"---all pointers are indirection, so that name is redundant. But the comments are necessary, to me at least.
I'm not so sure about that. Surely it would take longer to parse both branches of an if-constexpr then it would for the preprocessor to see the #if and discard half of it.
I wish more languages gave us a "|>" operator. Too many languages settle with dot notation, which confuses encapsulation/method calling with syntactical convenience.
I remember implementing the comment collapsing thing without JS, you have the "[-]" be a label for a checkbox button, and then you just use CSS to hide the sections for which the checkbox is checked.
Agreed. It's not a "foreign" function if everything is in WASM. All the VM sees is WASM code; it doesn't make a difference if it was originally written in C or Rust.
Have you ever seen a procedural language with a good REPL? Python maybe, but definitely no compiled procedural garbage-collectorless language. The "needing to put type signatures" is completely unrelated. I have no idea how that would stop Rust from being good in a REPL.
You mean like a REPL? Most languages are unusable for interactive programming. And it's not a downside if it stops use in a domain that was nobody's goal.
I have never seen a well-made but general solution beat a well-made and specific solution for one problem, in complexity or run time, ever. This is very true with allocators. A lot of the time people will just use 'malloc' without any thought into what they're actually allocating. For example, if you only allocate/deallocate from one thread, jemalloc is already way overblown in complexity.