In this case it arguably helped. I do wonder how much longer that stalemate would have gone on without the blow up.
I don’t think it’s a good policy in general. Mostly I think it would just end up in alienation and people not wanting to work with you. And Martin did leave. But he had a point and it seemed to get resolved.
Seems like parent thread spoke from perspective of developer/tech savvy person.
But even from end-user perspective, maybe its hard to see change when you compare one year or so, but over somewhat longer period I definitely see improvements. Over say a decade or so, wifi/bluetooth/trackpad support has significantly improved. Over last 5 years, I think gaming has become huge and you can actually use Linux as gaming machine. In last 3 years or so, I think I've seen my 5k display using Thunderbolt work much better. Fractional scaling also works much nicer.
NVIDIA GPUs are not shitty to use on Linux, and AMD has been working great for slightly longer. UEFI/TPM works much better now as well, where I don't have to worry about booting in legacy mode when using GPU drivers.
I didn't have to think about any of these above. If I think harder, I can likely come up with many more.
Well ya, it's more useful in observability usecases than desktop ones. But recently I've been using for a consumer desktop usecase. I made a file watcher with it. I'm sure you're familiar with the woes of using inotify/fanotify.
eBPF vfs hooks based watchers are really nice.
[edit] details
- you setup a single `mount` - this is the only part that requires cap_sys_admin
- then you run a single daemon, this one only needs cap_bpf, and this runs once at startup and is its own self contained program
- this daemon writes events into a ringbuf referred to by a file in that bpf mount
- you then read that from your standard user program (this can be done by whichever application needs to consume the events)
the events are create, mkdir, delete. renames are automatically decomposed since we hook at the vfs layer. the hook itself is practically free to run and thus there is no question of a performance impact.
You may know more about what it powers. It has enabled much faster, higher quality, more stable security software on Linux. Many modern security tools are built on top of it. While end users might not know it by name, it has made Linux easier to support in the enterprise.
The thing is, is it's not a subjective thing. It's objectively bad. I think that's what the story is or the appeal of the post. It's calling out, something that everyone else thinks is so great, but it's actually really pretty bad compared to the competition. Trust me, I used to want Claude to win, but it's not.
Huh? Comparing model quality is something everyone is constantly doing here. If you need more specifics, it speaks in an incomprehensible way, stops working lazily, does a bad job and misses things constantly, and makes a lot more mistakes. I have both a $200/mo Codex and Claude subscription and swap between them when one runs out, and I'm always more miserable when I have to use Claude.
The Claude desktop app is also widely panned, as I mentioned, and for me this mainly is due to general UX and a poor remote control interface. Codex's connected machine support is top notch.
Afaik Herb Sutter largely stopped working on Cppfront a few months ago, and was never quite supposed to be a real thing, just a personal playground (or so Sutter claims at this point, anyway).
Afaik Carbon is at this point the only attempt at a successor language that's still going?
Stupid question, can't this trivially be solved by having a movable constructor / builder type that then gets turned into a non-movable type when built?
Sure, thats one reason why IntoFuture and Future exist. Imo, in hindsight this is also main mistake in aysnc Rust: The whole async system should be build around IntoFuture rather than Future (async fn should return impl IntoFuture).
That way you could pass around IntoFutures without being affected by auto traits leaking. Only when you actually call .await() or .poll() would the immovable Future materialize.
You're right that this is an important issue. I wrote a post explaining this in some detail, so at the very least we avoid having the same problem with generator functions:
Oh yeah, I've read about all your blog post on this topic :)
To dump some ideas on you:
I think one missing piece might be that FnOnce() -> impl Future should implement IntoFuture. Async runtimes would then use IntoFuture in their APIs agressively.
I call this a "workload blueprint" at work. Its a closure/type that contains all the info to start the workload, but in a minimal form. In Rust terms this would be a buildprint that is ideally Send + Move + Forget + 'static, even if the actual work (and the backing struct of the Future) is !Send (e.g. It holds an Rc across await points).
Runtimes could use this for their advantage: There would be a global pool of "workload blueprint" that can be stolen by any executer thread, but once a !Send workload has started on one thread it can't be migrated to another.
> Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something.
reply