quicknir

Ah okay, didn't know that. Good luck wherever you are!

FWIW, as a high performance C++ dev who likes Rust but considers unsafe the biggest issue by far, it's encouraging to see important folk within the project believe there are issues. Too often as a relative Rust outsider it feels like the attitude is "but the unsafe situation is okay because you'd barely ever actually need it!". Hope that unsafe continues to improve!

It's honestly unfortunate that rust has been sold so hard on memory safety, so that when C++ folk don't spend tons of time in memory issues they think rust is pointless.

I don't want rust for memory safety. I want it for things like proc macros, a sane module system, a good and accepted error handling system, destructive move, constrained generics, unified static and dynamic polymorphism, language level customization points, and many more things.

Duplicating meaning that the smart pointer deleter is going to need a copy of the allocator (or a pointer to it if you prefer, but allocators are already typically pointers). If your container is storing N separately allocated elements, holding them by unique_ptr instead of raw pointer will waste N pointers worth of space with commensurate extra cache use. Fine for homework but not production data structures.

If you control the order of destruction, then you're just manually asking for things to be destroyed, and not actually making use of the smart pointers main functionality. Why use them at that point? That's why I also used the phrase "meaningfully" use them earlier.

Look inside the STL, boost, abseil, etc. You'll very rarely see smart pointers used to implement containers/data structures.

I think there's a bit of confusion here around "value semantics".

No C++ smart pointer has "value semantics", relative to its target T. You can see this because == performs address comparison, not deep comparison, and `const` methods on the smart pointer can be used to mutate the target (e.g. in C++, operator* on unique_ptr is always const, and yields a T&).

This is in contrast to Rust, where Box performs deep equality, and has deep const/mut. In Rust, Box is basically just a wrapper around a value to have it on the heap (enabling things like dynamic polymorphism, like in C++). In C++, the pointer is its own entity, with its own separate equality, and so on.

Const-ness of operations, operator==, and assignment/copying behavior all have to be consistent with each other. For example, if `box` was simply `unique_ptr` with a copy constructor (somehow, and as the table in the blog post basically implies), then you would have that after `auto a = b;`, `a != b`, which obviously doesn't work. This means that the hypothetical `std::box` would have to have its comparison and const-ness adjusted as well. In C++ terms, this isn't really a pointer at all. The closest thing to what the author is suggesting is actually `polymorphic_value`, I believe, which IIRC has been proposed formally (note that it does not have pointer in the name).

Also as an aside, smart pointers are not suitable a) for building data structures in general, and b) building recursive data structures in particular. The former is because meaningfully using smart pointers (i.e. letting them handle destruction) inside an allocator aware data structure (as many C++ data structures tend to be, and even data structures in Rust) would require duplicating the allocator over and over. The latter is because compilers do not perform TCO in many real world examples (and certainly not in debug mode); if you write a linked list using `std::unique_ptr` the destructor will blow your stack.

It's a pretty drastic assertion (and quite HN worthy) that a whole industry is abusing their developers, based on not even one job, but your impression of a job based on an interview. And assertions like "they expected us never to see our family", because you couldn't take your laptop home? Maybe if you had taken that job, you would have left the office at 5 pm, 95% of the time. Maybe not, of course, but you don't actually know.

I've been working in HFT for nearly ten years, in multiple different roles. I've met well over a hundred developers in the business, have at least a dozen I'd call friends, who are spread over nearly as many companies at this point in time. Most folks have had overwhelmingly positive experiences in the industry. Like anything there are exceptions, but I've seen no evidence of a systemic problem in the field. I know a few people who left my firm to go to Facebook and found it more stressful there, for instance. Certainly, I've worked with very very experienced ex-gamedevs, who would say unequivocally that developer abuse is a far bigger systemic issue in game dev than in finance.

Obviously it's fine to post your take but it should be tempered by the relative amount of experience you have.

I would encourage you to benchmark linear search and binary search on a dynamic array (std::vector) of a million elements. You may be in for a surprise.

I can only assume you have 4KB of ram.

IIRC, Java interfaces are subtype polymorphism. Ad hoc polymorphism would be, for example, overloading.

I would assume that within unsafe you could simply do the same kinds of shenanigans you would do in C++, e.g. you have a fixed size struct that is just the "header", it's only created on the heap, and it's immediately followed by the variable amount of data which you get access to by casting. If you couldn't do this in unsafe rust this seems like a pretty huge limitation.

It's hard to say. I think a lot of the Rust community actually hails from more of the web world, where security is rightfully a big concern, and the that's where actix was positioned. So maybe with something like HFT it wouldn't be as big of a deal.

On the other hand, very little of the Rust community actually does HFT, or understands the trade-offs. In HFT code, "caching pointers" to just about everything is extremely common, because it's super fast. So you'd be using unsafe a ton. If people got a glimpse of some of the code, I have a strong feeling that some subset would start lecturing (unironically, engineers with a decade of experience in HFT) about safety vs perf trade-offs, and ask "have you actually benchmarked", etc.

Very curious where you work, because there's only really a handful of major places doing HFT (as opposed to algorithmic trading) and haven't heard of Rust being used at any of them.

I think this picture of how HFT and games work doesn't have much connection to how it actually does. In these industries you can't just get all or even most of the high performance stuff you need off the shelf for a variety of reasons. You have to write a lot of it yourself, and likely you'd need to write quite a lot of unsafe code (certainly in HFT, speaking from experience).

Yes, he may well improve some algorithm, or rewrite some commonly used tool to improve efficiency. And researchers are often not incentivized to do that, so it would be great. But a far cry from the picture people are painting about him soaking up the field and using his genius to solve some major problem quickly.

If by "techie" you mean, professional software engineer, that's fine, but there's no reason to assume that a professional software engineer is going to be magically better at AI research than... professional AI researchers? He's probably going to be substantially worse.

Also, your statement below:

> That's probably true. I look at this as Carmack running his own PhD program. I expect he will expand what we know about computation and the AGI problem before he's done.

Makes it clear to me that you don't really get it. Carmack, at best, might know enough right now to be in a PhD program. I doubt that he has anywhere near as much knowledge, insight, or ideas for research, as top graduate students. He's in no position to mentor graduate students.

I normally don't bother but this comment is so profoundly ridiculous I had to say something.

Tenured ML professors at the top 100 or so universities in the world aren't "most of us". A very large chunk of these people are geniuses. Those jobs are incredibly hard to get, and most of these people are reading everything that is getting published, on an ongoing basis, and are outputting something novel, on an ongoing basis.

The fact that you think that John Carmack, because he's a name that you've actually heard of, is going to go into ML and suddenly make some giant advance that all the poor plebs in the field weren't able to do, is only a reflection of your misunderstanding of what's already happening in academia, not on Carmack's skills or abilities.

You're acting as though everyone are just low level practitioners using sklearn, and it would be a great idea to have some smart people work on developing something novel. Guess what: that's already happening, with incredibly smart people, on an incredibly large scale. Carmack doing it would just be another drop in the bucket.

Except that in HFT we don't generally disable RTTI or exceptions. I work at a top HFT firm, have friends/colleagues at other top firms, have seen multiple people like Carl Cook at Optiver state in talks that they use exceptions... So what on Earth are you talking about?

Not using some or most of the standard library is precisely not an example of subsetting C++. Just because the C++ standard library has a hash table available doesn't mean that every project has to use it. Companies standardizing their own high performance data structures where it makes sense, and other things as well, is just something that happens and often makes sense independent of language.