C++ has std::sort() and std::stable_sort(). You should write what you mean, and you should know and understand your tools. Blaming the tool for your ignorance marks you as significantly less than an artisan.
Sort specifically is kind of a weird example, but C++ is full of awful naming.
std::map (which is not a hash map, which is what most people would expect), std::move (which doesn't move), std::vector (which is not a vector), and std::vector<bool> (which is not even a std::vector).
Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming.
That's not actionable information, except in the sense that the correct action is "don't use C++". Because sure, I know about sort stability, and I know about pointer provenance, and about memory ordering, but there might be any number of things I do not know and unfortunately in C++ "you should know and understand" absolutely everything at all times, which is not viable.
† The C++ standard library sorts are both much slower than in Rust, but hey, they're also both less safe so you're really getting the worst of both worlds
> Sure, both languages offer both generic comparison sorts†. But the defaults matter and as always in C++ the defaults are wrong, here it's reflected in naming.
Why, exactly, is the c++ std::sort "wrong"? There are tradeoffs both ways. You happen to prefer stable sorting to speed, but that is a preference not an objective fact.
It's silently an unstable sort, which is surprising, and then to add insult to injury it's also slower. Yeah, I know, the C++ unstable sort is so slow it's slower than Rust's stable sort.
YMMV for input types, sizes etc but generally that's what the numbers look like and though it's not universal it's actually quite common. "I bet the C++ is faster" is the wrong instinct, sometimes by a large margin.
And stable sorting typically allocates large amounts of memory, which is also an unpleasant surprise.
I prefer the C++ naming convention, because it matches my expectations. When I studied CS, quicksort was considered the default sorting algorithm, and stable sorting was therefore a special case.
My pet peeve is that standard library sorting algorithms are still mostly single-threaded. Multicore CPUs have been the norm for ~20 years, but standard libraries still don't offer reasonable algorithms for sorting large arrays.
I work maintaining the toolchain and language runtimes for a commercial safety-certified embedded operating system. I am deeply familiar with C and C++ because I live it and breathe it every day and have done so for over 40 years.
Most of our customers use C, probably for historic reasons but also because it is much much easier to reason about and that becomes very important when auditing for functional safety certification. If someone's life depends on your software, you really want to be able to reason about its correctness because orange jumpsuits enhance no one's complexion.
Many of customers are now using C++. From the problems they have reported, well, they just shouldn't. It's not that it is a bad language (it isn't) or that it is inherently unsafe (it really isn't: exceptions are safer than propagating return values as long as you use them in exception conditions, because not catching one will return you to a designed safe state very quickly, and RAII is the best thing since sliced cheese). It's that cutting and pasting from Stack Overflow, and now vibe coding, makes for massive codebases that are next to impossible to reason about. I now see a lot of problems from customers where my first reaction is "don't write code like that" and "you can write bad JavaScript code in any language, can't you?". While it butters my bread and I enjoy the language, I really recommend against using C++ for safety-certified embedded software. Stick to C.
I think this hits the nail on the head. All the features of C++ help you write a code which you should have written in a much simpler way in the first place.
Neither Rust nor Zig are appropriate at this time for certified functional safety. Given the definition of the languages is "it does what one particular implementation of its compiler, runtime, and standard library does at this time" it's not possible to construct a workable safety case for their use.
Enthusiam and neat ideas are not sufficient to certify a development tool for functional safety.
If only C actually had fat pointers as Dennis Ritchie, one of the authors, proposed to WG14.
It is quite relevant to note that the C authors, were keen to explore Alef as alternative on Plan 9, and based on the learnings reduced C's role on Inferno, and eventually took part in Go's design.
Even though they were not keen into using C++ (Plan 9 doesn't even support it), they were also aware C wasn't to be used for everything.
ISO/IEC 14882 contains many uses of the word "deprecation", including all the sections of Appendix D that explicitly lists all of the deprecated and removed features of the language and library.
I don't know about the typical HN contributor but I personally lack the cash to but all the stocks in the S&P. There are 503 stocks tracked in the S&P 500 index. It would cost about 2.8 million USD to buy 100 shares (one board lot) of each if you were naive enough to weight your purchases that way. If you were to weight the stocks differently (eg. total market capitalization of each company) the amount would be higher.
Or, I can pick up 100 shares of an index ETF for a few thousand and have someone else do all the work for me including rebalancing and doing all the other required calculations (lot tracking and cost basis calculations etc.).
Trading in lots of 100 hasn't been required since I dunno, the 90s?
Assuming you're in the US there are several competent brokers that sell fractional shares. Any broker will do lot tracking and cost basis calculatioms for you, they're required to.
Rebalancing might be a pain, yes. I'd bet the drift isn't too bad most of the time, but it's probably effort every time you add or remove money. You'd want to build a tool to tell you how to add and remove to get closer to the index. If you can get the index weights and your holdings in a machine readable format, it would seem pretty tractable, but it would take time to setup; there's a reason funds have expenses, but index fund expenses are small.
I'm 100% invested in funds because it's a lot less work, but if you felt strongly about excluding certain stocks, I think it's pretty doable for say S&P 500. Tracking a total market index, or an international index would be more challenging. Bond indexes are also challenging to track, even for bond funds.
Drones are haploids so probably nothing. I suspect you'd need the full chromosome set to get the full developmental effect of the royal treatment.
Given that when a hive goes queenless the workers start laying eggs including in the royal chambers they're desperately building, and since the workers are unfertilized all of the eggs are haploids that hatch into drones, it has probably happened many times throughout apian history. No drag queens have been spotted.
When you get down to it, there is no better way to display text than to use a text display.
No amount of cartoons or colourful bouncy animation of pictures on the screen can replace simply displaying text when what you need to do is display text on the screen. And it turns out that text is a really good way to display information.
A picture is worth a thousand words but why would you use 1000 words when only one or two will do?
reply