The easier a language is to use the faster programmers code with it.

The average developer who uses static typing wastes 2/3rds of their development time on it. Duck typing enables shorter more concise programs with architectures not possible or prohibitively expensive when using static typing.

Micro-services are usually the right answer then using single threaded scripting languages like Python. The relevant benefits of micro-services vs monoliths change significantly in the duck typed world.

"it's literally impossible for them to do it everywhere" technically in the statically typed Rust programming language there is no need to specific the types of anything anywhere (the same is not true for the lifetimes). Needing to write the types in the function headers is actually a design decision, it can be all auto inferred.

It takes 2/3rd of your time as a software developer to use static typing. It's been measured. When happens is a software feature that takes 1000 lines of Python takes 3000 lines of C++ or Java. You probably naively believe that static typing has no drawbacks but it has one of the most terrible drawbacks imaginable.

Since you mentioned Rust and it's limited auto typing, what is the effect of that compared to C++? “Rust teams at Google are as productive as ones using Go, and more than twice as productive as teams using C++.” @larsberg_

What about when we move from Go to Rust? Well Turborepo's rewrite showed that 20,000 lines of Go code is equivalent to 80,000 lines of Rust code and the development time increased x4 to match.

As the typing starts to disappear the development speeds increase.

General commercial software development.

I'm discussing real world projects. You basically writing what someone who has no experience of writing duck typed code in a commercial environment incorrectly assumes.

When you are developing code in duck typed code, your correctness comes from unit tests and your maintainability comes from micro-services. You split the code-base into small easier understood chunks that communicate via well defined interfaces. That's why so many people are so confused about micro-services because they show their benefits most when used with duck typing.

I'm not saying unit tests make up for it, I'm saying that they surpass it. You are better off spending the time you spent on static typing on just writing more unit tests.

Modern IDEs auto complete duck-typed code. It's just a misconception that they don't.

Whilst it is good that you like to document your code, sadly because you spent all your limited developer time on static typing you won't be writing that documentation. Documentation techniques in the duck typed world such as FastAPI generally blow the documentation you are thinking off out of the water.

Duck typing, unit tests and micro-services is for when you want to ship commercial quality code quickly. Ignoring the code performance it is the better software development approach.

You are currently advocating for a vastly inferior software development approach and you are doing so out of ignorance.

Duck typing and unit tests does a lot better job at finding bugs per developer hour spent. Type systems are really really inefficient on developer time. When developer resources are limited duck typing and unit testing is the way to go. In the real world, no one cares that your billing system crashed (typing helps here), they care that you sent out the wrong bills (unit tests helps here).

The point of type systems is to enable better performance from compiling your code not to check your code is correct.

You can use type systems in-place of unit tests in some languages but the trade-off is that your code will be completely unreadable to other developers.

Yeah, I think I should have read the code not just the CVE. It looks to me like a direct port of the C code with every other line being unsafe. I would put serious doubt on "efficient reasons". There are always multiple ways to write efficent code and one of those ways is usually safe or in the case of a data structure like this there will be a way to write it which involves much less unsafe code.

I've read the code now. So the safety statement is "unsafe { node_inner.death_list.remove(self) };" is okay because a node is either in a single list or in no list at all.

But "for death in death_list {" breaks this because it's moved part of the list onto the local stack. When you iterate though a list in Rust, it consumes the list destroying it. You avoid that by doing "for death in &death_list {". The fix just makes the safety statement true by deleting the nodes in place. This requires you to lock each node as you delete it but that isn't the fix in it's self.

And you can't create a copy of list a and take that out of lock's scope because you will get back "lifetime may not live long enough". Rust solves this exact problem but not when you are mixing it with C.

Rust doesn't allow you to release locks before you are done with the list. When you lock a resource in Rust, it remains locked until the resource is out of scope. In Rust, it's { let a = resource.lock() }. The unlock happens due to the }. There isn't an .unlock() call like C/C++. The issue is that the Linked List is a C implementation in the Linux Kernel, which is why Rust needs to use unsafe to access it.

It's fixable, they just need to write a Rust wrapper for the C Linked List they are calling in the Kernel. Then via the Rust wrapper the bug won't be possible. We can fix this bug forever is a much better story then it will just keep happening and we are going to live with it.

If the code was all Rust then it wouldn't compile. Rust would complain about the lifetimes of the references in the copy of the list.

The problem is that the Rust compiler can't check the C code the Rust code is calling. If the C Linked List was written in Rust, then the compiler would have caught the race condition. The typical Rust program doesn't use unsafe. You need unsafe in Rust for 3 things: Writing data structures, Hardware access and calling C code. For data structures such as Linked List (through that's in the Rust standard library), you cargo import a pre-written and well tested version. I mean there is only like 16 data structures that programmers regularly use. No need to roll your own. Whilst the data structure itself technically could be bugged the Rust compiler verifies that the code using it is correct. Rust would have caught this error if std::collections::LinkedList was used. For hardware access, you write unsafe code and then you create a safe wrapper around it. Then the rest of your code calls your safe wrapper. You can enforce at compile time that the calls to the hardware are made in the right order, etc. See type state pattern. But obviously you need to code in how your network card actually functions before the Rust compiler can check it.

Don't know about Texas but in the UK buying power from the grid and selling it to customers is only a 2 person operation.

This is kinda of silly since in the wide open general case fully optimized Rust code is 1% faster than fully optimized C/C++ code. Rust enables additional compiler optimizations that are not possible in C/C++. Now you might say well no one has really implemented these additional optimizations but it's irrelevant because eventually people will.

AI's technical definition is "Whatever is currently being studied by AI researchers at the moment" To give a quick list AI has referred to: Scheduling algorithms, Prolog, Genetic Algorithms, Neural Networks and now it refers to LLMs. There is also the term hard AI for machines that actually think, but research into hard AI is considered to be stalled.

Hunter Biden's laptop was found in a state that Hunter Biden has never been too and is the only state in the US where a repair shop guy can take ownership of a laptop and reveal the content?

Not only is it a lie, it's such a blatant lie you would have to be a complete moron to fall for it.

*not that long

Actually, we are on the track to make the planet uninhabitable. After global warming, the increased CO2 levels will make us suffocate to death. It's a 100 years away but that that long all things considered.