This comment? https://fedia.io/m/programmer_humor@programming.dev/t/1239473/-/comment/7462582
I honestly do not understand what similarity you see between “this post seems like it will make linguists angry” and “the languages in this joke actually use English keywords and standard library names.” The post isn’t even about keywords and names.
Ah, right, the old “communism has never been tried”
To be pedantic, I didn’t ask a question, I just said I was surprised! I am still surprised.
Surprised nobody has complained so far about the Rust comparison. I guess any objection would appear to prove the point, or at least reinforce the “evangelist” stereotype.
From your comment, I’m not convinced you do get it. You wrote a lot of words completely beside the point of the joke, which is a series of analogies, not a statement about the natural languages involved in the creation of programming languages.
I wonder what the best programming analogue is for combining words into one where other languages keep them separate; maybe the functional-style chains of adapters?
Ah. Rust’s macros and the C preprocessor’s exist in vastly different universes. The C preprocessor is literally just a fancy programmatic copy-and-paste tool. Rust macros read the input source code and then execute other source code (the macro definition) to generate new source code that the compiler then reads.
I love Rust, but Rust macros are arguably more of a footgun than compile-time reflection would be, and as amazing as serde is (and no, there’s nothing comparable in standard-compliant C++ yet), there’s a strong argument that compile-time reflection would be a preferable technique for deriving serialization, argument-parsing, and similar feature.
What macros or attributes provide serialization in C++?
For runtime reflection, no, you’d specifically be able to do things that would be impossible to optimize out.
But the proposal is actually for static (i.e. compile-time) reflection anyway, so the original performance claim is wrong.
If you look at the proposal, this is specifically “static reflection”, i.e. compile-time reflection. So it doesn’t actually have any of the downsides you mention, as far as I can tell.
I read “happy ___ starts with ___” as stating that happiness was the eventual result of a process that started with ___.
It’s probably not “provable” one way or the other, but I’d like to see more empirical studies in general within the software industry, and this seems like a fruitful subject for that.
Cool! Oracle, a company famous for making good-will decisions, and open to being “urged” into doing the right thing. 🙄
I suppose the open letter is a nice gesture, and I hope that the petition to cancel the trademark succeeds.
Extension modules can be, and are, written in Rust and C++. And PyPy has a compatibility layer to run extensions (such as numpy) that are written for CPython.
The reason extension modules are typically in C is of course the API is in C, but that’s true of cffi as well (though you’re right that cffi is more portable). And the reason the API is in C is more fundamental than “CPython is written in C”.
For what it’s worth, Ada and Spark are listed separately in the Wiki article on dependent typing. Again, though, I’m not a language expert.
The reason C becomes relevant to Python users isn’t typically because the interpreter is written in C, but because so many important libraries (especially numpy) are implemented in C.
Whatever you want to call them, my point is that most languages, including Rust, don’t have a way to define new integer types that are constrained by user-provided bounds.
Dependent types, as far as I’m aware, aren’t defined in terms of “compile time” versus “run time”; they’re just types that depend on a value. It seems to me that constraining an integer type to a specific range of values is a clear example of that, but I’m not a type theory expert.
It sounds like you’re talking about dependent typing, then, at least for integers? That’s certainly a feature Rust lacks that seems like it would be nice, though I understand it’s quite complicated to implement and would probably make Rust compile times much slower.
For ordinary integers, an arithmetic overflow is similar to an OOB array reference and should be trapped, though you might sometimes choose to disable the trap for better performance, similar to how you might disable an array subscript OOB check.
That’s exactly what I described above. By default, trapping on overflow/underflow is enabled for debug builds and disabled for release builds. As I said, I think this is a sensible behavior. But in addition to per-operation explicit handling, you can explicitly turn global trapping behavior trapping on or off in your build profile, though.
It depends what kind of errors you’re talking about. Suppose you’re implementing retries in a network protocol. You can get errors pretty regularly, and the error handling will be a nontrivial amount of your runtime.
[warning: “annoying Rust guy” comment incoming]
I don’t think Rust is perfect, but arguably I do “idolize” it, because I genuinely think it’s notably better both in design and in practice than every other language I’ve used. This includes:
In a literal sense, I agree that all (practical) languages “are flawed.” And there are things I appreciate about all of the above languages (…except Tcl/Tk), even if I don’t “like” the language overall. But I sincerely believe that statements like “all languages are flawed” and “use the best tool for the job” tend to imply that all (modern, mainstream) languages are equally flawed, just in different ways, which is absolutely not true. And in particular, it used to be true that all languages made tradeoffs between a fairly static, global set of binary criteria:
Looking at these, it’s pretty easy to see where most of the languages in my list above fall on each side of each of these criteria. What’s special about Rust is that the core language design prevents a relatively novel set of tradeoffs, allowing it to choose “both” for the first two criteria (though certainly not the latter three; the “ease-of-use” one is debatable) at the expense of higher implementation complexity and a steeper learning curve.
The great thing about this isn’t that Rust has “solved” the problem of language tradeoffs. It’s that Rust has broadened the space of available tradeoffs. The assumption that safety necessarily comes at a runtime cost was so pervasive prior to Rust that some engineers still believe it. But now, Rust has proven, empirically, that this is not the case! And so my ultimate hope for Rust isn’t that it becomes ubiquitous; it’s that it inspires even better languages, or at least, more languages that use concepts Rust has brought to the mainstream (such as sum-types) as a means to explore new design tradeoff spaces. (The standard example here is a language with a lightweight garbage-collecting runtime that also has traits, sum-types, and correct-by-default parallelism.)
There are other languages that, based on what I know about them, might inspire the same type of enthusiasm if I were to actually use them more:
…but, with the exception of Swift, these are all effectively “niche” languages. One notable thing about Rust is that its adoption has actually been rather astounding, by systems language standards. (Note that D and Ada never even got close to Rust’s popularity.)