Comment by Someone1234 | Hacker News Reader

Comment by Someone1234 | Hacker News Reader

This article was absolutely fantastic.

It kind of lost me right up until the first example code, where I did in fact have different expectations. Then how it broke down why, and gave different potential solutions was just wonderful. I learned a lot.

I will add though that other languages have a distinction between const and string object too (at least under the hood), they just go to great lengths to hide it from programmers. For example a const + const call might do the same thing as Rust under the hood, but it is transparent. Rust seems like it requires the extra steps because it wants the programmer to make a choice here (or more specifically stop them from making mistakes: like having immutable data stay immutable, rather than automatic conversion to mutable sting inc. the data cost involved even, automatic conversion is more convenient but also a performance footgun).

I don't think Rust is wrong, I think it is opinionated and honestly as someone that like immutability I kinda dig it.

Glad you enjoyed it :)

And yeah, under the hood those other languages do all kinds of wild optimizations with their "immutable" strings like sharing substrings between different strings and pooling to reduce allocations. I intentionally left out those nuances because from the user's perspective, those are all implementation details (even if they can surface in the form of performance changes).

It is well-enough written where it treats Rust, but almost lost me, too, for its abuse of "C/C++", treating the two very different languages as if they were trivial variations. Where string handling is concerned, as in so many other places, they are fundamentally different.

This "C/C++" bad habit is very commonly used, around Rust, to slyly imply there is no effective difference, but in a way that permits an injured response to criticism that "it just means C or C++". But it doesn't, unless you are talking about object file symbols or compiler optimizers; and often enough not then. What it does is encourage sloppy thinking, and resultant falsehoods. These falsehoods show up in the article, revealed if you change "C/C++" to "C or C++" in each case.

In several places, it says just "C++" yet is clearly still talking about C. It is OK not to know C++, or not like it. But things are hard enough without active falsehoods. It is not hard to get it right: if you are talking about C, write "C". That will always be correct. If you are talking about C++, say "C++".

Rust stands or falls on its own. It doesn't need invidious editorializing.

The only thing I claimed about the two as a category was that "strings are not immutable, they're data structures" (which applies to Rust too). I purposely didn't go into much more detail than that because it wasn't really the point of the article. I did mention that C works with strings as raw char arrays, and C++ has a struct around a char array that manages length-tracking and reallocation automatically.

I believe these two statements are accurate, though I'm happy to be corrected if they aren't. It's been a few years since I wrote C++. Beyond that, I see my claims as "abstract" and not "falsehoods".

A false abstraction is no less false.

I don't know when you went to school, but most places still teach using C++98, which is two generations removed from current practice. It is not unusual for TAs assigned to teach C++ to resent being taken away from their glorious combinators, and teach their resentment.

If coding C++ was not immense fun, you may be certain you were Doing It Wrong.

You're correct. I don't know why people downvote you. A lot of C++ comments are grayed out. Does HN has an agenda or what?

I am not sure what you mean by "false abstractions" in this article. Could you cite some concrete examples in the article that support your claim?

The author isn't claiming to go into a deep dive into C or C++. They are trying to talk about Rust. Your argument seems to be against the author's use of "C/C++" vs. "C and/or C++", which seems to me like some nitpicking, as the author uses "C/C++/Rust" later on. It isn't like they are pooling the languages as being the "same". Rather, they are talking about having similar, lower-level of control over "strings" as a data structure, as opposed to the primitives they seem to be in other high-level languages like C#, Python, Java, Go, Kotlin, Swift, or JavaScript.

This "C/C++" bad habit is used everywhere across the C and C++ industry, including reference books, FAANG, WG14 and WG21 papers.

And yes even if you give them C++20, many devs will code in the C subset, because a large majority doesn't care, isn't in HN or Reddit, or even bothers to spend hours of their life watching CppCon, C++Now or ACCU talks, unless it is mandated by their boss.

I imagine you know who Lakos and Victorio are on the C++ community,

"C++11/14 at Scale - What Have We Learned?"

https://www.youtube.com/watch?v=H8wzuvynV78

Reply on news.ycombinator.com