identity0

SVG is still a stupid format. Who wants to send image data through XML? It would be like sending a raster image through a big JSON array.

    String s = null;

That's not possible with nullable types. The whole point of nullable types is to mark types that can be null. So this is possible:

    String? s = null;

But now it's not much different than this:

    Option<String> s = None;

My point is that these are fundamentally the same thing. The only difference is syntax, ergonomics, and compiler support.

>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.

auto in function signatures is just really, really stupid.

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.

That's true, it's more like naming your language "BlockchainScript". I could totally see someone doing that today.

Oh come on, don't be pedantic. There is a term for non-physically-based rendered, it's called "rasterization". Just because it's technically incorrect doesn't mean it's any less of a colloquial term. To ignore this is to ignore how language actually works. Even the wikipedia page for Rasterization compares it with ray tracing.