okay but why? cost of living is less in america's burbs too. you are getting cause and effect reversed: the huge chain stores and PE firms, they are very efficient, i mean that's why they grow so big, and being efficient is strongly associated with lower prices.
In stuff like restaurants though it translates to increased margin not lower prices. Mom and pop restaurant margin is like a few percentage points if you are successful. Some franchises sniff 10 even 25% for say a chic fil a.
No, they have not. They have incentives to do so, but they are only obligated to follow the law and in the US, even that obligation is relaxed by a lot.
You are arguing against literally this because the idea of being ruled by democratic means may lead to democratic outcomes you do not want to partake in. For that I say you're free to start your own society while people are allowed to engage in creative destruction if they choose so.
Let's not act like the VC world is against creative destruction when it comes to enriching themselves, there's no reason why the public can't destroy things to benefit society either.
Perhaps we have different things in mind re: hardness. But to set that aside, what I should've said is that we can't do this quickly enough for it to be seen as an inexhaustible supply of training material. The consumer and producer are just not well matched.
When mythos was released - I guesstimated that we had 6 months until hackers had similar enough capabilities that we would start to see real problems in the wild. Unless there is some change in the trend line things are about to get really quite spectacular.
The rate at which software is produced has never been higher, nor has the rate at which it is thrown away for being broken and useless. It’s not at all obvious to me that if you control for both of those rate changes that the amount of useful software with a lifespan measured in years created per developer (ie, the software that actually has long term value) has actually changed all that much.
It doesn’t have a stable abi, how could it be easier? I would argue that the vast majority of what rust gives you comes at a direct cost of precisely the ergonomics of manual memory management. It’s a tradeoff that makes sense much of the time, but it’s still very obviously a tradeoff.
It’s easier in that you can cordon off the tricky parts being unsafe and define safe mechanics. Proof point: the Linux kernel using more and more rust and at once the platform support gets there more if the core memory management and what not will start getting ported too.
There’s also work actively ongoing to make certain constructs even easier to express more ergonomically and letting user programs implement some of the magic that’s currently restricted to the standard library
The Linux kernel has to balance security and performance concerns, security probably being primary, so it makes sense to make the tradeoff for more safety with worse ergonomics for memory management.
If all you care about is performance, you're going to be fighting Rust's memory model for no reason.
> If all you care about is performance, you're going to be fighting Rust's memory model for no reason.
If you actually care about performance where you'd start is with measurements. What we see so much from C++ isn't measurements it is dogma. Things C++ forces on you must dogmatically be imagined as free without measuring them, things C++ does not have get treated as expensive, again without measuring so as to justify their absence.
For example, the unstable sort in C++ (std::sort) is typically implemented in a way which introduces Undefined Behaviour if your ordering isn't coherent either because you didn't realise that was mandatory or through some minor programming error. In contrast all of Rust's unstable sort implementations have been entirely safe even in the face of such mistakes.
And your dogma might tell you OK, but the C++ sort must be faster. That's why we're doing unsafe things, it must be faster. Except, nope, slower. Slower, but unsafe. Pointlessly worse. Only acceptable because of dogmatic belief.
With all due respect, are you sure you're not the one being dogmatic here?
90% of the code I write these days is Rust. It's a great tool, and the performance/safety balance, as well as general developer experience makes it well-suited to a wide variety of applications.
But in the past I've also built an ECS implementation. For that to optimize performance (and yes I did measure this) you want to do bulk memory allocations memory, pack bytes in order to minimize cache misses, and dispatch multiple threads to read and write concurrently over your memory pool. You can do all that in Rust, and people have, but it's a pain in the ass.
And for example, if I were working on a high-frequency trading application, where every millisecond of additional latency represents millions of dollars of lost revenue, I wouldn't waste my time fighting the burrow checker just so I can have a prettier program.
Rust is an amazing tool, but that doesn't mean it's the optimal tool for every job.
I suspect that the additional friction in doing these things in Rust is still largely outweighed by everything else. I won't deny the friction - it's definitely there - but it has never been large enough for me to consider using anything else (especially reverting to C++!)
With that being said, I did write a compiler to specifically help me match C++ memory layouts in Rust [0], so I might be an outlier case :-)
You’ve played sleight of hand with the argument saying it’s easier to do it in C++ whereas before you were claiming it’s faster. I don’t disagree with the easier part and no one on this thread has. But it’s also super easy to shoot off your own foot with a hairline trigger. Rust at least has better tooling to both verify your unsafe code is safe for memory access (Miri is a stronger proof than sanitizers) while letting you define careful interfaces for using said memory safely.
Again - no one takes issue with the ease argument. The only issue was claiming that c++ somehow let you go faster. Indeed, it’s likely not the case because rust has stronger aliasing protections that let it emit more efficient code, closer to Fortran - that’s why the old math libraries you’re probably using in c++ are written in Fortran and not c++ (rust didn’t exist and Fortran enforces no aliasing whereas c++ doesn’t).
Redox OS, Asterinax. PD: my first distro was Debian Woody, comparable to Slackware with a 2.2 kernel back in the day, 2.4 was optional. So I've seen everything.
Rust will replace C++. C will we kept as a "low level ASM" similar to what inline ASM was for C.
Still, I can perfectly predict Rust based Qemu and FFMPEG's being rewritten from Bellard et all replacing the former C base. Legacy users can just use legacy machines with Hyperbola (and I'm one of them), but Rust will be almost mandatory to be protected against automatic AI attacks. Kinda like blaster/sasser but much worse. Multiplatform virii written in Golang for instance.
Servers getting poisoned media targetting ImageMagick/GM and FFMPEG on purpose, and VM's too. Thus, rustifying Qemu/Libvirt and FFMPEG will almost be a mandatory task.
> I wouldn't waste my time fighting the burrow checker just so I can have a prettier program.
I understand your argument as "it's easier to botch an implementation in C++ than in Rust", which is true and that is actually an argument in favour of Rust.
I strongly believe it is harder to write a C++ implementation that is sound and does not rely on UB.
The point is, there are some domains (data-oriented programming) where Rust actively resists the kind of work you need to do to solve the problem in an optimal way, and it makes sense to use a language built around the type of memory management required.
There's no point in using Rust when 90% of your work is deactivating the benefits Rust provides and working around its default behavior.
> With all due respect, are you sure you're not the one being dogmatic here?
Obviously like Michael Burry it is always possible that I'm wrong and I can't see why. But I did give you a specific example where the dogma says well we have to choose this unsafe way to do it, but the reality is that's not only unsafe it's also slower. It is just worse.
I am glad to hear that you measured. I've been yelling at people for not measuring for much longer than Rust has existed - if people measure and choose C++ because the numbers were better I feel a lot better about that outcome.
As to being the right tool, I firmly believe we should use a lot more niche languages which do only one narrow thing very well. One common thing you'll see argued about the Memory Safe languages is that they need runtime bounds checks and such checks are a performance cost the unsafe languages do not incur. WUFFS illustrates that if we're willing to give up generality we can have a language which is entirely safe but doesn't do runtime bounds checks - because it proved mathematically at compile time that your code has no bounds misses so such checks are needless.
Arguably for HFT in particular the dirty secret is that if things go badly enough wrong you just say "Oops" and get a do-over because money isn't real.
While this is true - and I see the same sentiment as i am about to make ad nauseam - it is kind of amazing how far the goal posts have moved in such a short space of time.
reply