Laws should be loser for autonomous vehicles with good safety records.
No one is protected by preventing waymos from making rolling stops, and driving like a human Uber driver.
The quality is much worse for me with uncommon words. I also plan to add a thin llm rewrite layer on top so I can write by just speaking but that will be later.
Usually when I go and read the github and zulip threads the reason for paused work comes down to the fact that no one has come up with a design that maintains every existing promise the compiler has made. The most common ones I see are the feature conflicts with safety, semver/encapsulation, interacts weirdly with object safety, causes post post-monomorphization errors, breaks perfect type class coherence (see haskells unsound specialization).
Too many promises have been made.
Rust needs more unsafe opt outs. Ironically simd has this so it does not bother me.
When I read these sorta of articles I ask if I would invest today if given the opportunity. Currently the answer is still yes.
They have barely even monetized users. I think it's possible the bubble pops and openai still continues to win.
So much of this article is copium pretending the world is not radically changing. Even if progress stops today massive numbers of jobs will be and are being replaced. I wish it wasn't true but what I wish has no bearing on reality.
At some point self driving cars will need their own loser driving laws.
Perhaps allowing them to drive around school buses is not a good idea, although personally I have felt far safer biking or walking in front of a Waymo than a human. But rules few humans follow, like rolling stops, and allowing them to go 5 over seems like a no-brainer. We have a real opportunity here to br more sensible with road rules; let’s not mess it up by limiting robots to our human laws.
The solution is strong compile time and runtime guarantees about code behavior.
The author is right there's no way an individual can audit all that code. Currently all that code can run arbitrary build code at compile time on the devs machine, it can also run arbitrary unsafe code at runtime, make system calls, etc..
Software is not getting simpler, the abundance of high quality libraries is great for Rust, but there are bound to be supply chain attacks.
AI and cooperative auditing can help, but ultimately the compiler must provide more guarantees. A future addition of Rust should come with an inescapable effect system. Work on effects in Rust has already started, I am not sure if security is a goal, but it needs to be.
Yes, it could replace all government ids, while allowing you to prove arbitrary statements about said signed government documents without revealing them (not saying it will happen).
Think of zk proofs as an extension of asymmetric cryptography to arbitrary logic.
A zkVM makes encoding the arbitrary logic as easy as writing a normal Rust program.
A proof is a probabilistic statement that a specific program run with some public inputs and maybe some private inputs was executed correctly.
For crypto zk proofs are mostly for their succinctness property, not for privacy.
Outside of crypto privacy is the more important property, let's say a government issues a signed document, I could prove any arbitrary statement about that document without revealing the document. We could use zk proofs for anything we use canonical documents for today and we would gain privacy. Will we do this, probably not, but it would be an improvement.
I am partial to property testing logic and integration testing servers.
This frequently requires some level of separation, the key is to do it only at the right points.
Don't start by saying how can I unit test this tiny bit of logic against several mocks, start with a simple integration test of your real routes.
As you add abstractions you are trading maintainable straightforward code for more granular testing. It's a hard trade off not a set of principles for good code.
What the author calls bad code is one way of writing idiomatic Rust. There are more complex techniques.
It's recommended to not split the low level details from. your business logic, in fact it's not just recommended the compiler slowly forces your hand.
If you write overly abstract code like the author recommends you will leave a large amount of performance on the table. Code like that doesn't play nicely with lifetimes, by trying to separate memory management from business logic you're left with only the least restrictive scheme owned heap allocated data.
The Rust type system teaches you not separate concerns, without giving up the ability to reason about your code.
This is such bad advice that I honestly couldn’t tell if it was a parody or not until I read the comment section—it’s not.
Attempting these design patterns is a common part of getting over OOP when new to Rust.
The result: over-abstracted, verbose, unmaintainable C++/Java written as Rust.
Every layer of indirection ossifies the underlying concrete implementations.
The abstractions inevitably leak, and project velocity declines.
I have seen the same types and logic literally copied into three different repositories in the name of separation of concerns.
Luckily people usually get over this phase of their Rust career after a couple of failures.
If you’d like to skip that part, here are a few rules:
1. Always start with concrete types.
Don’t abstract until you have at least two, preferably three, concrete implementations.