You don't have to imagine it; you can browse the Linux Kernel mailing list!
Yep, learned it recently from a list of things that are, surprisingly, named after real people. Deb and Ian eventually got married but are now divorced.
I also hope that some of the people reading this realize that OP is also the person posting all of the "stop trying to suppress C" posts.
- Why do you keep posting the same rant about "going back to the roots", especially after multiple people have pointed out that C is not "the roots" of programming?
- Why do you have such strong opinions about a language that you're still learning?
- If you're that passionate about C and believe that people should use it instead of newer languages, why do you care about Nim or Nelua?
That's fair.
Probably more importantly, it runs on the JVM and is designed to interoperate with existing Java code. (FWIW, I actually think they made a major mistake in how they handle null Java objects, and that Kotlin did better here; but Kotlin is much newer.)
That's sort of obvious and seems to kind of miss the point of a programming language. A language is an abstraction over the capabilities of a (possibly virtual) machine. The machine itself can generally only do relatively simple things; but writing assembly code is usually more difficult than writing the same functionality in a higher level language, because individual machine instructions are such a small building block for designing higher-level behaviors. So it's hardly surprising that simple layers stacked on each other result in complexity. The point of the article (and of language design in general) is about how to balance expressive power versus simplicity of language concepts.
Why not just stick with Python until there's a need to learn something else?
No, if you try to index something out-of-bounds it will panic, which is not a memory-safety gap.
It doesn't mention him by name, but he's the "language designer of some renown" alluded to here:
If you were a language designer of some renown, you might convince a large and wealthy technology company to fund your work on a new language which isn’t so beholden to C runtime...
...yeah, sorry, I honestly can't tell what point you were trying to make, even with the explanation. You call it an "ad" but also say they're not trying to convince users to migrate, so what do you think they want?
BatmanAoD
0 post score0 comment score
You didn't say "programmers should be aware that rust doesn’t automatically mean safe". You said:
You then went on to mention
unsafe, conflating "security" and "safety"; Rust's guarantees are around safety, not security, so it sounds like you really mean "more safe" here. But Rust does make software more safe than C++: it prohibits memory safety issues that are permitted by C++.You then acknowledged:
...which seems to be the opposite of your original statement that Rust doesn't make software "more secure". But in the same comment:
...well, no, there IS a guarantee that Rust is "automatically" (memory) safe, and to violate that safety, your program must either explicitly opt out of that "automatic" guarantee (using
unsafe) or exploit (intentionally or not) a compiler bug.This is also true! "Safety" is a property of proofs: it means that a specific undesirable thing cannot happen. The C++ compiler doesn't provide safety properties[1]. The opposite of "safety" is "liveness", meaning that some desirable thing does happen, and C++ does arguably provide certain liveness properties, in particular RAII, which guarantees that destructors will be called when leaving a call-stack frame.
[1] This is probably over-broad, but I can't think of any safety properties C++ the language does provide. You can enforce your own safety properties in library code, and the standard library provides some; for instance, mutexes have safety guarantees.