TehPers

(Yes)

Rust does not check arrays at compile time if it cannot know the index at compile time, for example in this code:

fn get_item(arr: [i32; 10]) -> i32 {
    let idx = get_from_user();
    arr[idx] // runtime bounds check
}

When it can know the index at compile time, it omits the bounds check, and iterators are an example of that. But Rust cannot always omit a bounds check. Doing so could lead to a buffer overflow/underflow, which violates Rust’s rules for safe code.

Edit: I should also add, but the compiler also makes optimizations around slices and vectors at compile time if it statically knows their sizes. Blanket statements here around how it optimizes will almost always be incorrect - it’s smarter than you think, but not as smart as you think at the same time.

What’s wrong with 3.13?

Rust’s memory safety guarantees only work for Rust due to its type system, but another language could also make the same guarantees with a higher runtime cost. For example, a theoretical Python without a GIL (so 3.13ish) that also treated all mutable non-thread-local values as reentrant locks and required you to lock on them before read or write would be able to make the same kinds of guarantees. Similarly, a Python that disallowed coroutines and threading and only supported multiprocessing could offer similar guarantees.

Converting CSV to JSON is probably just a matter of translating column names to property and wrapping them all in a list. But if that’s the case, it may be worth opening an issue on FreeTube to have the docs and code updated.

Yes

Are you suggesting that Rust can perform compile time array bounds checking for all code that uses arrays?

I’ll answer this question: no.

But it does make some optimizations around iterators and unnecessary bounds checks written in code at least.

But yes it does runtime bounds checking where necessary.

C, C++, and Rust come to mind as other languages with sizes as part of an array’s type. This is necessary for the compiler to know how much stack memory to reserve for the values, and other languages that only rely on dynamically sized arrays and lists allocate those on the heap (with a few exceptions, like C#'s mostly unknown stackalloc keyword).

Do you mean memory safety here? Because yes, for memory safety, this is proven. E.g. there are reports from Google that wide usage of memory-safe languages for new code reduces the number of bugs.

Memory safety is such a broad term that I don’t even know where to begin with this. Memory safety is entirely orthogonal to typing though. But since you brought it up, Rust’s memory safety is only possible due to its type system encoding lifetimes into types. Other languages often use GCs and runtime checking of pointers to enforce it.

Then, first, why don’t the claims that statically compiled languages come with claims on measurable, objective benefits? If they are really significantly better it should be easy to come up with such measures?

Because nobody’s out there trying to prove one language is better than another. That would be pointless when the goal is to write functional software and deliver it to users.

I have seen no such report - in spite of that they now have 16 years of experience with it.

I have seen no report that states the opposite. Google switched to Go (and now partially to Rust). If they stuck with it, then that’s your report. They don’t really have a reason to go out and post their 16 year update on using Go because that’s not their business.

And just for fun, Python itself is memory safe and concurrency bugs in Pyhton code can’t lead to undefined behaviour, like in C.

Python does have implementation-defined behavior though, and it comes up sometimes as “well technically it’s undocumented but CPython does this”.

Also, comparing concurrency bugs in Python to those in C is wildly misleading - Python’s GIL prevents two code snippets from executing in parallel while C needs to coordinate shared access with the CPU, sometimes even reordering instructions if needed. These are two completely different tasks. Despite that, Rust is a low level language that is also “memory safe”, except to an extent beyond Python - it also prevents data races, unlike Python (which still has multithreading despite running only one thread at a time),

Go is neither memory safe…

?

…nor has it that level of concurrency safety

That’s, uh, Go’s selling point. It’s the whole reason people use it. It has built-in primitives for concurrent programming and a whole green threading model built around it.

If you concurrently modify a hash table in two different threads, this will cause a crash.

This is true in so many more languages than just Go. It’s not the case in Python though because you can’t concurrently modify a hash table there. The crash is a feature, not a bug. It’s the runtime telling you that you dun goof’d and need to use a different data structure for the job to avoid a confusing data race.

It’s not hard to find articles explaining the benefits of using TypeScript over JavaScript or type hints in Python over no type hints online. It’s so well known at this point that libraries now require type hints in Python (Pydantic, FastAPI, etc) or require TypeScript (Angular, etc) and people expect types in their libraries now. Even the docs for FastAPI explain the benefits of type hints, but it uses annotated types as well for things like dependencies.

But for a more written out article, Cloudflare’s discussion on writing their new proxy in Rust (which has one of the strictest type systems in commonly used software programming languages) and Discord’s article switching from Go to Rust come to mind. To quote Cloudflare:

In fact, Pingora crashes are so rare we usually find unrelated issues when we do encounter one. Recently we discovered a kernel bug soon after our service started crashing. We’ve also discovered hardware issues on a few machines, in the past ruling out rare memory bugs caused by our software even after significant debugging was nearly impossible.

Can also confirm - Pyright is a god send.

There’s no scientific evidence that pissing in someone’s coffee is a bad idea, but it’s common sense not to do that.

You seem to be looking to apply the scientific method somewhere that it can’t be applied. You can’t scientifically prove that something is “better” than another thing because that’s not a measurable metric. You can scientifically prove that one code snippet has fewer bugs than another though, and there’s already mountains of evidence of static typing making code significantly less buggy on average.

If you want to use dynamic typing without any type hints or whatever, go for it. Just don’t ask me to contribute to unreadable gibberish - I do enough of that at work already dealing with broken Python codebases that don’t use type hints.

TIL there’s such a thing as idiomatic C.

Jokes aside, microbenchmarks are not very useful, and even JS can compete in the right microbenchmark. In practice, C has the ability to give more performance in an application than Java or most other languages, but it requires way more work to do that, and it unrealistic for most devs to try to write the same applications in C that they would use Java to write.

But both are fast enough for most applications.

A more interesting comparison to me is Rust and C, where the compiler can make more guarantees at compile time and optimize around them than a C compiler can.

Python 3.13 has really good support for typing now and while it doesn’t support more complex types, opting out with typing.Any or # type: ignore still works.

Type hints have been largely helpful from my experience, especially when the code itself came from someone else and is incomprehensible otherwise.

I’m inclined to say no since it wouldn’t be a question otherwise, but hopefully the article answers it. I’ll update if it does (reading it now).

Edit: first paragraph says

with one estimate suggesting that Saturday was among the biggest ever single-day protests in US history.

So no, I guess.

It’s the EFF. They’re not neutral. They advocate for stuff - that’s their whole thing.

Thanks. I couldn’t find a date on it.

Honestly I’m surprised this is even still discussion. I plan to read this, but who out there is arguing against static typecheckers? And yes, I know it’s probably the verifiable NPCs on Twitter.

40 months is just 3y 4mo. Do people get new phones every two years or something? I usually just get a new one when my old one’s not working for me anymore.

A full license still costs more than the whole machine, assuming you just want to buy a license. The machine you bought probably had an OEM license on it though, which is priced differently. Also, there are cheaper places to buy Windows keys online, so nobody should really be spending $200 on a license for their home machine.

Why it costs $200 for pro and they still try to sell you shit in the settings menu is beyond me. I’m still on the hunt right now for a Linux distro I like that isn’t a nightmare to maintain with a modern NVIDIA GPU though, so I’m stuck with it for now.