Well, at a low level they are still basically the same. x86 still starts in 16-bit real mode. Mice still use USB 1 from the 90s.

Mostly it's just a lot faster and covered with more layers of abstraction.

I mean, nobody uses Python for execution speed precisely because it is so slow.

Facebook and Google are the customers that use this feature.

Apparently. Does anyone know what they use it for?

I feel like they could ask way more interesting questions. Probably the only really interesting thing here is people's top complaints about Rust, which is to be fair a really great list.

I would really love to see something similar for other languages. Imagine if you could see ranked pros and cons for every language!

200?! I can pretty confidently say approximately nobody is anything like you 😄

would not be considered bugs but maybe change requests.

That's just playing with semantics. They are clearly bugs. They are literally called "defect reports".

Without a spec how would you argue that a system/product is safe?

1. Lots of testing, including randomised testing and ideally formal verification.
2. Comprehensive test coverage - both code coverage (lines, branches) and functional coverage (hand written properties).
3. Functional safety features (ECC, redundancy, error reporting & recovery, etc.)
4. Engineering practices known to reduce the chance of bugs (strong static types, version control, CI & nightly tests, rigorous engineering processes - requirement tracking and so on, and yes ideally well written specifications for all the tools you are using).

There are many aspects to safety and it's definitely a good idea to have a spec for a language, but it doesn't automatically mean safety is impossible without it.

Software in itself cannot be safe or unsafe because without hardware it cannot do anything.

The nice thing about abstraction is that you can talk about software without considering the hardware, more or less. If one says "this software is safe", it means it's safe assuming it's running on working hardware.

It doesn't always hold up - sometimes the abstraction leaks, e.g. for things like spectre and rowhammer. And there are sometimes performance concerns. But it's pretty good.

Ugh, I was working on a DIY smart lock. "I'll use Matter!" I naively thought.

Ok you need a border router for Thread support. No problem, I'll buy one. Should be cheap right since an ESP32 can handle it. Nope! You pretty much can't buy a standalone border router. All the articles are "don't worry, you might have one already if you have a Nest Hub or a Home Hub or...". Well I don't have one.

Pretty lame. I guarantee if they make a vendor neutral border router dongle you can just plug into your router's ethernet port and sell it at cost price (like £5) they'll see triple the uptake.

What language are your apps written in? Generally the best options are:

1. Qt (C++) or PyQt (Python wrapper if you hate yourself). Old school desktop GUI. Works extremely well though.
2. Web based, then you can pick from a gazillion frameworks, most popular is React. You generally have a Typescript based frontend and a backend in whatever language you want. The downside is you have to deal with the frontend/backend communication which can be a pain.

There's also Flutter which is pretty nice, but again you have to use Dart for the GUI so if the rest of your app is in another language you'll have some friction.

But yeah, I would say the language you want to write your "business logic" in is the biggest factor to choosing. Also if you care about exposing your app over the web.

That appears to not support comments. How they made that mistake after JSON is a mystery.

Git LFS does actually support file locking. But in general I find LFS to be hackily pasted onto Git and not very good (as with submodules).

I think even in languages that do a lot at compile time (Rust, Haskell, etc.) it's still standard practice to write tests. Maybe not as many tests as e.g. Python or JavaScript or Ruby. But still some.

I work in silicon verification and even where things are fully formally verified we still have some tests. (Generally because the formal verification might have mistakes or omissions, and occasionally there are subtle differences between formal and simulation.)

Even if "isn't that bad" were true, it's hardly a stunning endorsement. I wish Linux aimed higher than "not that bad", but it always seems to hit "only some bits are broken".