The example even used unwrap_or_else where they should use unwrap_or. Then it uses std::i64::MIN as fallback value where they could use something like 0 that would be a better example and honestly make more sense there.

let parsed_numbers = ["1", "not a number", "3"]
    .iter()
    .map(|n| n.parse().unwrap_or(0))
    .collect();

// prints "[1, 0, 3]"
println!("{:?}", parsed_numbers);

Even without trimming this to something less convoluted, the same functionality (with different fallback value) could be written in more readable form.

Obviously in the context of the page something like this would make way more sense:

maybe_number.unwrap_or(0)

Or perhaps more idiomatic version of the above:

maybe_number.unwrap_or_default()

Is that Rust? Assuming a is an Option (which would be close approximation of OP’s nullable type) and assuming b is not null, then this would be closer to the original idea:

a.unwrap_or(b)

It returns value of a if it’s not None rather than Option.

I don’t have much experience with TS, but in other strongly typed language it goes even further than string vs number.

For example you can have two numbers Distance and TimeInSeconds and even though they are both numbers, the type system can make sure that you won’t do distance+time.

It can also let you do distance/time and return Speed type.

It will prevent many logical errors even though everything is technically a number.

I’m not sure where this idea of high profile target comes from. The sim swap attack is pretty common. People just need to be in some credentials leak DB with some hint of crypto trading or having some somewhat interesting social media account. (either interesting handle or larger number of followers)

There are now organized groups that essentially provide sim swap as a service. Sometimes employees of the telco company are in on it. The barrier to entry is not that high, so the expected reward does not need to be that much higher.

Yeah it’s pretty amazing system all things considered. It’s kind of as if 8-bit home computer systems continued to evolve, but keep the same principles of being really closely tied to the HW and with very blurry line between kernel and user space. It radiates strong user ownership of the system. If you look at modern systems where you sometimes don’t even get superuser privileges (for better of worse) it’s quite a contrast.

Which is why it reminds me of Emacs so much. You can mess with most of the internals, there’s no major separation between “Emacs-space” and userspace. There are these jokes about Emacs being OS, but it really does remind me of those early days of home computing where you could tinker with low level stuff and there were no guardrails or locks stopping you.

GNU Hurd is going to be mainstream any minute now.

I couldn’t help but think of Emacs when I was reading A Constructive Look At TempleOS. It’s like TempleOS that is actually finished, it just lacks kernel.

Perhaps it’s kind of inevitable to have some bloat. For example apps these days handle most of the languages just fine including emoji, LTR/RTL and stuff. Some have pretty decent accessibility support. They can render pretty complicated interface at 8k screen reasonably fast. (often accelerated in some way) There is a ton of functionality baked in - your editor can render your html or markdown side by side with source code as you edit it. You have version control, terminal emulator, language servers, etc…

But then there’s Electron, which just takes engine capable of rendering anything and uses it to render UI, so as a result there’s not much optimization you can do. Button is actually a bunch of DOM elements wrapped in CSS… Etc… It’s just good enough for the “hardware is cheap” approach.

I think Emacs is a good example to look at. It has a ton of built in functionality and with many plugins (either custom configuration or something like Doom Emacs) you can have very capable editor very comparable to the likes of VS Code. Decades back Emacs had this reputation of being bloated, because it used Megabytes of RAM. These days it’s even more “bloated” due to all the stuff that was added since. But in absolute numbers it does not need as much resources as its Electron based peers. The difference can easily be order of magnitude or more depending on configuration.

This is programmerhumor so perhaps allow for a bit of hyperbole on my part. I wasn’t completely factual.

However the initial days of Docker were effectively promising to solve the exact same “it works on my laptop” problem. The idea was that developer builds docker image and pushes it to repository where it can pass through CI and eventually the same image gets to production.

As you can see, this effectively reproduces the EXACT content as well, because you transfer the files in a set of tar files.

It didn’t work for many reasons. One of which is the fact that it’s often not so much about the exact files, but the rest of the environment like DBs, proxies, networking, etc that is the problem. I’ve seen image misbehaving in production due to different kernel version/configuration.

Replace “nix flakes” with “Docker” and you have your answer from almost decade ago.