Avi-D-coder

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.

Yep, came here to say this. It's the only thing that makes macos useable.

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.

From what I have heard it's not the RISCy ISA per se, it's largely arm's weaker memory model.

I'd be happy to be corrected, but the empirical core counts seem to agree.

That's our job now, adding reliability. It's just pair programming.

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, two things helped. Less powerful glasses for closer work and high index lenses.

Those documents would need to be cryptographically signed machine readable data, json, a pdf (difficult).

Getting governments, banks, and other trusted third parties to sign documents is very difficult, but is happening in some cases.

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.

time to change the rules

yep,i agree on all of this and suspect a large portion of long timers do too.

Some one just has to do it.

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.

Higher order functions can be used for dependency injection.

Dependency injection and the Dependency inversion principle are not one and the same.

The principle makes a claim, that inversion is a good onto itself.

Injection is a tool not a claim.

Yes, the dependency inversion principle is not a commonly held principle in FP or imperative paradigms.

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.

2. Separation of concerns is a myth.

3. K.I.S.S.

As someone who has worked on haskell professionally, it's probably the easiest language to interview in/for. It's really easy to see how deep a dev has gone down the haskell rabbit hole. Forget a certificate, just talk for 5 minutes.

Any dev who has fully gone down the haskell rabbit hole can definitely grok any other paradigm. The challenge isn't technical skills with devs like this.

in my experience aerospace is way better in most ways.

there are a few oddities, and I need to file a couple of bug reports, but it has made macos so much more tolerable than amethyst.

My 2023 corolla will steer straight into a curb if a lane gradually exits.

until i learned it's habits driving with the assistance was very stressful.

> understand when the effect occurs requires examining the type signature of every function that is called. Since this is meaningful control flow, it seems very valuable to be able to identify points at which an error occurs without examining the signatures of each function call.

This is currently the case in rust. IO and other effects are frequently implicit. You don’t have to use ? or await they are *sugar. I have frequently seen reinventions of exceptions, unwind nonsense, adhoc interpreted tagged effects, etc..

Explicit syntax for effectfull calls should not be a goal. We don’t actually have that today.

The obvious fix is to remove the repo information, but do you grandfather in old files by redirecting to the new URL?

I’d say no, which I guarantee will break some legitimate packages that depend on files uploaded in GitHub comments.

This is really cool. I looked at the kalosm-sound, and noticed it's using candle, how is the perf compared to openai-whisper, whisper-cpp, faster-whisper, ext..?

I’ve liked using ractor.

https://github.com/slawlor/ractor

This tech will happen the trick is finding ways of preserving privacy without degrading user experience too much.

Small open LLMs can enable a kind of differential privacy prompt rewrite system.

I have worked with wasm in the browser in production. Yes, there are many issues, yes I have some critiques of the multithreading proposal, but in the long run portable workers solve lock-in.

Your right, but all of this will drive WASM adoption. I'm fine with papering over incompatibility as long as the costs continue to go down.