Ah okay, didn't know that. Good luck wherever you are!
205 karma · joined May 9, 2015
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.
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.
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.
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 can only assume you have 4KB of ram.
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.
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.
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.
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.
Your comments read like you're explaining optimization to a beginner, it's a bit bad faith tbh.
> As I said, it’s a superficial example, but I think it shows a general difference in philosophy between C++ and D. (If I wanted to make the difference even clearer, I’d use an example that needed iomanip in C++.)
iostreams are not in C++ because C++'s philosophy is actually that iostreams are great. Everyone knows they suck. They are there because without variadics, there isn't a good way to do type safe text output in the style of printf. And I mean, not even runtime type safe. Chaining of some kind is the obvious way to simulate variadics when you don't have variadics. And at the time, they thought it was better to get something type safe into the standard library, then gate it behind variadics which could (did) take a long time. Voila, iostreams.
C++ is quite literally in the process of standardizing a library that will bring type safe printf (a la D) to C++. The same way that 8 years ago, C++ finally managed to standardize variadics after quite a lot of effort.
The disadvantage of being an old language is that it can be hard to stay caught up with features. The advantage is that you get a huge base of existing developers, knowledge, libraries, etc.
Bloggers love to make things about big picture philosophy because it makes for better blurbs but many things in reality are just engineering decisions. D had the luxury of creating metaprogramming syntax from scratch after one if its creators was one of the main people to discover the power of "accidental" TMP in C++. C++ is still trying to bend accidental TMP into something more bearable to use without breaking everything. The differences here are more practical than philosophical.
Some people would argue that you can use D for equally high performance things to C++, and make sure you use the GC very selectively, etc. However, you don't appear to be making that argument. If you aren't, then there's just no real point comparing C++ and D. If you don't have any of those requirements, and you are ok with obscurity, you have much stiffer competition from many other languages like Haskell, Kotlin, etc.
Out of places that are vaguely keeping up with C++, the only thing I'd consider sub-setting that is commonly applied to C++, is disallowing exceptions and RTTI. There are at least decent reasons for this. Yes, there are places that have additional constraints (like "C with classes" style, i.e. no templates), but it's much more rare (and even more rarely technically justified).
Sub-setting should not be confused with the fact that in many cases, the language does not push you as hard down a specific path (for better or worse), yet it might be beneficial for a specific company in a specific domain to have a common solution for something, which results in the company style guide saying: "for this use case, use company_lib::foo, not XYZ".
Where I work we use pretty much all of C++, as appropriate, that is there is no blanket ban on anything, or official subset. That does not mean that e.g. there is virtual inheritance all over the codebase; that's a feature you should pretty much never need to use. Writing code appropriately and consistently can only ever be done via discussion and code review; no subset will ever magically fix these issues anyway.
This is a straw man. Nobody in the C++ community action like the next release is a silver bullet. On the other hand, people in glass houses...
Smart pointers help (but do not solve) memory issues by tying together access and resource destruction. If you access a resource through an object, and the resource don't go away until the object does, it makes it harder to access the resource after it's gone. Not impossible since you can do various things like grab a raw pointer/reference to the smart pointer and then call reset. In practice though, this doesn't occur that often; Murphy is a bigger problem than Machiavelli.
You're entitled to your opinion but it goes directly against my experience, and most industry experience. Most C and old C++ codebases, memory management over time just becomes a tangled mess of ad hoc delete calls. With smart pointers this just hasn't happened and in practice spent tiny fractions of my time still dealing with memory related issues. A language with e.g. real reflection would be a way bigger boost to my productivity than improved memory management.
As few people seem to realize, it's common for even the C standard library to be implemented in C++. Having to implement all of the printf variants (there's 8, I think, at least) using C macros is horrible. Instead, the actual implementation of printf/fprintf etc happens in a function template. You then have one line extern C functions implemented via calling this template, which are declared in the header (and defined in the .cpp, along with the template).
My guess is that in most (not all) cases C++ is usable instead of C, but the culture of such development is to prefer C. It's a real pity, because for someone with a moderate amount of judgement (i.e. not going off the deep end on unnecessarily complicated C++), it only takes a moderate amount of C++ knowledge to be able to write more maintainable and correct code that performs equally well.