Slashdot Mirror
Why ESR Hates C++, Respects Java, and Thinks Go (But Not Rust) Will Replace C (ibiblio.org)
Open source guru Eric S. Raymond followed up his post on alternatives to C by explaining why he won't touch C++ any more, calling the story "a launch point for a disquisition on the economics of computer-language design, why some truly unfortunate choices got made and baked into our infrastructure, and how we're probably going to fix them."
My problem with [C++] is that it piles complexity on complexity upon chrome upon gingerbread in an attempt to address problems that cannot actually be solved because the foundational abstractions are leaky. It's all very well to say "well, don't do that" about things like bare pointers, and for small-scale single-developer projects (like my eqn upgrade) it is realistic to expect the discipline can be enforced. Not so on projects with larger scale or multiple devs at varying skill levels (the case I normally deal with)... C is flawed, but it does have one immensely valuable property that C++ didn't keep -- if you can mentally model the hardware it's running on, you can easily see all the way down. If C++ had actually eliminated C's flaws (that is, been type-safe and memory-safe) giving away that transparency might be a trade worth making. As it is, nope.
He calls Java a better attempt at fixing C's leaky abstractions, but believes it "left a huge hole in the options for systems programming that wouldn't be properly addressed for another 15 years, until Rust and Go." He delves into a history of programming languages, touching on Lisp, Python, and programmer-centric languages (versus machine-centric languages), identifying one of the biggest differentiators as "the presence or absence of automatic memory management." Falling machine-resource costs led to the rise of scripting languages and Node.js, but Raymond still sees Rust and Go as a response to the increasing scale of projects.
Eventually we will have garbage collection techniques with low enough latency overhead to be usable in kernels and low-level firmware, and those will ship in language implementations. Those are the languages that will truly end C's long reign. There are broad hints in the working papers from the Go development group that they're headed in this direction... Sorry, Rustaceans -- you've got a plausible future in kernels and deep firmware, but too many strikes against you to beat Go over most of C's range. No garbage collection, plus Rust is a harder transition from C because of the borrow checker, plus the standardized part of the API is still seriously incomplete (where's my select(2), again?).
The only consolation you get, if it is one, is that the C++ fans are screwed worse than you are. At least Rust has a real prospect of dramatically lowering downstream defect rates relative to C anywhere it's not crowded out by Go; C++ doesn't have that.
He calls Java a better attempt at fixing C's leaky abstractions, but believes it "left a huge hole in the options for systems programming that wouldn't be properly addressed for another 15 years, until Rust and Go." He delves into a history of programming languages, touching on Lisp, Python, and programmer-centric languages (versus machine-centric languages), identifying one of the biggest differentiators as "the presence or absence of automatic memory management." Falling machine-resource costs led to the rise of scripting languages and Node.js, but Raymond still sees Rust and Go as a response to the increasing scale of projects.
Eventually we will have garbage collection techniques with low enough latency overhead to be usable in kernels and low-level firmware, and those will ship in language implementations. Those are the languages that will truly end C's long reign. There are broad hints in the working papers from the Go development group that they're headed in this direction... Sorry, Rustaceans -- you've got a plausible future in kernels and deep firmware, but too many strikes against you to beat Go over most of C's range. No garbage collection, plus Rust is a harder transition from C because of the borrow checker, plus the standardized part of the API is still seriously incomplete (where's my select(2), again?).
The only consolation you get, if it is one, is that the C++ fans are screwed worse than you are. At least Rust has a real prospect of dramatically lowering downstream defect rates relative to C anywhere it's not crowded out by Go; C++ doesn't have that.
He seems to think he has some great insight into why C is C, why C++ is C++. But really, he is so fucking clueless I don't know where to start.
There's enough business logic programmed in C++ and Java to keep both languages around until my kids retire and they're not yet in the workforce. Rust and Go, yeah doubt there's a single company of any size running their business processes on either.
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
He's a person, not a technical description.
We have enough abbreviations in tech.
Hate it when people do that.
Thank you, Bradley Manning, Edward Snowden and so many others, for courageously defending humanity, my freedom and more!
The higher the level of abstraction in your language, the higher the overhead it will create. Now, it needn't be so absolutely stupidly overengineered as .net is, but still the metric fits, the more safeguards and handrails your language comes with, the higher the overhead it incurs to have them. This is admittedly not really a huge problem in today's working environment because our computer speeds are far greater than our needs.
Still, somehow it feels silly that I need increasingly more powerful computers just to run the same kind of program, only because programmers can't be assed to learn their trade and instead rely on ridiculously overblown frameworks that is the equivalent of delivering a pack of soda with a semi because you have to bring a soda factory along with the workforce since the framework doesn't know how to deliver a single soda.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
The reason we have to say "don't do that" is because C++ remains compatible with C and older version of C++. There are literally billions of lines of existing C++ code out there, and the language committee realizes it can't just snap its finger and order everyone to rewrite all that old code (which is stable, functional, and debugged, btw) because we have something newer and better now.
It's pretty straightforward to write safe, new C++ code if you understand how to use the new features and abstractions. I wrote an entire game / game engine recently using modern C++, and it's amazing how few bugs I've had thanks to recent language improvements and techniques.
I'm not sure where this "large projects can't enforce code discipline" idea comes from. What does he think "coding standards" are, which nearly every major company, organization, or project has? And if someone doesn't understand how to use a smart pointer instead of a raw pointer or avoiding class inheritance hell at this point, then really, they shouldn't be contributing to your C++ projects.
I get it that some people dislike or distrust C++. It's a complex language that's hard to master. They don't like that it makes a lot of compromises in the name of practicality, but that real-world practicality is why many of us use it for large, performance-critical real-world projects. I'd never argue that C++ is the right language for every project. In fact, it's a fairly specialized language at this point. But that level of hyperbole is a bit annoying.
Irony: Agile development has too much intertia to be abandoned now.
Arguing that it's harder for large-scale projects to manage a 'well, don't do that' approach implies that he's completely missed the last 40 years of tool development. This is much more of a problem for small C++ projects than large ones. Large ones have pre-push hooks that run static checkers that enforce rules like no bare pointer and no operator new / delete. It's the smaller ones that rely on programmer discipline to do this that are more likely to have problems.
Go is a horrible language. It has multithreading as a core part of the language, but no memory model and no type system that can express notions of sharing or immutability. The designers clearly realised that generic types are important, and so added precisely one to the language (the map type, which is parameterised on the key/value types). It has a map type that maps from one object type to another, but no way for users to define what equality (or ordered comparison or hash) means on objects.
I am TheRaven on Soylent News
You mean to say, I don't know how to handle memory management and go does is all for me, without me knowing what it actually does, but it seems to work......... Oh please, Go is just Yet Another Programming Language which wasn't really necessary, but purely because some devs just didn't like other languages (or didn't know how to handle them properly).
The big problem when it comes to using anything other than Fortran, C or C++ is that 20 years after the first MMX and SSE instruction sets have been added to CPUs, there are only a handful of compilers that known how to vectorize even loops that are hand-crafted to be vectorizable - and the ones that can do it are all commercially licenced (GCC might theoretically have some support for it, but in reality it doesn't vectorize most things). And since most of the performance advancement in silicon has for a long time now been focused in SIMD units, that means that for any performance sensitive workload there are no feasible alternatives. If it has taken GCC 20 years to get not very far, how long will be be before much younger compilers get anywhere with this performance critical feature?
Take the low-level access provided by C, and then add the ability to construct both compile-time and run-time abstractions to an incredibly high level, but with as little cost as possible. That's C++.
C++ is an amazing achievement.
Every academic language approaches Lisp, but every practical language (you know, the ones that actually make the world turn) approaches C++; Bjarne said as much, and he was right.
Anything that allows us to reduce errors, increase functional complexity, reduce development time, improve readability and maintainability, and/or make it easier to code for a greater amount of people, is progress in my book. Working at a higher abstraction level achieves some or all of those goals.
And good frameworks help with that. When I build a house, I don't want a craftsman who takes time to learn how to use an adze so he can plane down lumber to the correct size for the job; I want a builder who knows he can get lumber of the correct dimensions right at the store. The skills to build instead of buy are useful in many trades (both building and programming), but they are expensive and a possible source of additional errors. Frameworks are often a good answer to that... as long as the developer understands the nature of the framework, its limitations, the licensing model, its viability, and thus can assess the consequences of using it.
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
What I find kind of annoying is that Ada fixed all these flaws decades ago with Ada 95, now it is at Ada 2012 and still gets no love, just because it's a bit more verbose than C if you use it correctly. (Though not necessarily more verbose than C++.) Sure it has some flaws, e.g. concerning aliases and their scoping rules, but these are mostly inconveniences and some of them have been fixed in Ada 2012. But it doesn't stop there, the same story can be said about dynamic languages. Take fancy new dynamic language X and you can be fairly certain that CommonLisp solved all the problems of the new language already in the 80s.
Maybe developers are in the end less rational than they think? It seems to me that a language must have serious flaws, lots of incoherent shortcuts and tricks, or at least a cryptic syntax to become really successful.
Usually, when you try to merge the 2 ideas, you end up with something as stupidly inefficient as run-time introspection.
So, because the guiding principle of C++ is "zero-overhead abstraction", perhaps it is the case that you must explicitly choose where the computation will occur—run-time or compile-time.
... then how are you not clueless?
Right now ESR is way ahead of you by having some actual thoughts to share, no matter how wrong they may turn out to be. You're nowhere near that. So you go on, pick any thing, start there.
Here, let me help you: Me, I think that ideology makes for poor abstracting in programs, so rust is out. Incidentally that "community" is full of people who are so full of it they "can't even". (Which is one reason why ESR would be wrong picking rust as a successor to C: rust people "can't even", C people very much just do.) Now you pick anything else, maybe the next thing you can think of right off the bat, and enlighten us with your insights.
I remember I interacted with him back when he started the irker project.
That pretty trivial piece of software, written in Python, was riddled with bugs, and no amount of bug reporting and discussing with him the design mistakes got anything fixed for a whole week, despite him actively trying.
I rewrote the whole thing in C++ in two days and it always worked robustly from the get go.
Personally, I think way more problems arise of terse syntax and high symbolic abstraction that C/C++ and derived languages like so much. I mean, I'm as lazy as the next programmer and that's why I like C (and its derived languages) but even I cannot ignore that
{ (a!=1)?b=!b:b=0}
is way less readable than
begin
if a is not equal 1 then set b equal complement of b else set b equal 0
end
You'd immediately spot an error in the second because the sentence would look "wrong".
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
C++ is just a mess. There are no real memory management tools
Yeah, except for smart pointers + RAII and the ability to override global, per-class, or even per-object allocators and add whatever sort of memory tooling you can dream up. Other than that, no memory management tools.
Irony: Agile development has too much intertia to be abandoned now.
If GC is the reason for 6 GB smartphones, why does booting your non-GC'd Windows desktop take more memory than booting a GC'd Lisp Machine OS?
Ezekiel 23:20
It's not always so clear cut. What you say is definitely true for naive compilers, but higher-level abstraction also often mean more information for the compiler and more freedom for the compiler. These can translate to better optimisations. To give a trivial example, languages like Java provide an abstraction that looks like a C struct, but don't require that the memory layout be visible to the programmer. Imagine that you create a struct-like Java object with RGB values to represent a colour and you do the same in C. Now you put them in an array and try to do some processing on them. The C version is constrained to lay out the objects as three fields with no padding (this is visible in the language with sizeof and will break ABIs if it dynamically changes). The Java version, in contrast, is allowed to put an unused padding field at the end of the struct. Why does that matter? If you want to vectorise the loop, then being able to guarantee 4-element alignment for every object in the array is a huge win. This is a legal transform for a Java compiler, but not a legal transform for a C compiler unless it can prove that no pointers to the array escape (and a few other constraints).
The big advantage of C was that a fairly simple compiler for a simple architecture could get very good performance. The disadvantage for C is that compilers quickly hit diminishing returns and the abstract machine makes a number of desirable optimisations unsound.
For example, if your language has a first-class notion of immutability, then this gives the compiler the opportunity to elide copies or add copies if they make sense for NUMA systems, and gives the compiler a lot more freedom with regard to reordering or eliding loads. Similarly, if your source language has higher-level notions of sharing then this means that you can avoid a lot of defensive memory barriers that you'd need for correct C/C++ code. If your language has stricter guarantees on aliasing, then a whole lot of optimisations suddenly become easier.
Any compiler optimisation is a mixture of two things: an analysis and a transformation. The analysis must be able to tell you if the preconditions for the transform are met. The more information you can give to the compiler, the more often the analysis can prove that the preconditions hold and enable the transform.
I am TheRaven on Soylent News
And good frameworks help with that. When I build a house, I don't want a craftsman who takes time to learn how to use an adze so he can plane down lumber to the correct size for the job; I want a builder who knows he can get lumber of the correct dimensions right at the store.
On the other hand, when all you want to build is a garden shed, you can do it yourself in a quick week-end afternoon project by quickly nailing a few planks together. You definitely don't want a several month-long adventure involving half a dozen sub-contractors (and each further down, their own individual group of a dozen of sub-contractors), plus hiring a few special planification manager (because sub-contracors D and Y each out-source their screw to a different sub-sub-contractor. Incompatiubles) which will all require two hectars of work space around your shed. And somehow the garden shed need to be connected to an industrial triphase 380V power connector in order to be able to function.
Some time, over reliance on frameworks and helpers means that some very simple projects that would be handled by a few dozens of C or C++ lines of code (perhaps a couple of hundreds top), suddenly need to pull more than 20 MiBs of libraries in the package and are dependent on 200 different github repositories (hoping that they'll not blocked on the dev's whim - see Node.js and string alignement). And you need to use special command line settings to tell the VM to allocate 2 GiB of memory for the process.
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
The higher the level of abstraction in your language, the higher the overhead it will create.
This is exactly why C++ remains popular among those who create large, complex, high-performance applications. C++ is well known for using zero-cost abstractions. That means you get the performance of low-level C code, but can design much safer interfaces and type safety in your code which allow the compiler, not a runtime, to validate that the code is correct and safe.
For certain types of applications, it's an effective compromise between the pragmatism of retaining backwards compatibility with decades-old ecosystems, while at the same time providing better safety and abstractions than C.
Irony: Agile development has too much intertia to be abandoned now.
Equivalent series resistance and root mean square, obviously
Time for bed, said Zebedee - boing
If you want to say that it explodes violently in your face from time to time, it has an attitude that few can stomach, is way overengineered for its supposed purposed and manages to go around in circles of trying to fight itself and stand in its own way instead of getting to the point and be done with it, yes.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Java doesn't guarantee anything with regards to timeliness of object destruction. A small object that just encapsulates a file descriptor may never be collected (until program exit - I think Java requires all objects are collected on program exit), and so its finaliser may never run and free the file handle while the program is executing. The same applies to closures - they're just objects and are not guaranteed to be deallocated.
I am TheRaven on Soylent News
With some extra spaces, and the whole thing changed to an expression (which is how ?: is supposed to be used) it's a lot easier to read.
b = (a != 1) ? !b : 0
The advantage of the ternary operator is that you only need the LHS part once, which helps if it's a more complex variable.
Pimpl is solvable by creating an implementation class and and interface class that has a reference to that class, and if you are crying about memory safety starting with C++ 11 there are smart pointers.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
How do I write drivers and firmware in Go? I think C is going to be around for awhile.
We'll make great pets
a) C and C++ are not and never have been worth a damn as a standard. Even in the absolutely best C and C++ code, there are so many platform abstractions and #ifdefs that it's a nightmare. Neither C or C++ are useful as a platform.
This is probably the most useful of your points which can be summarized as it's very hard to write something in C or C++ that is cross-platform even a standard. Doing so requires use of macros that can get quite complex at times (#ifdef __LINUX ). It also gets more complicated with Makefiles and makedepend. There are two problems:
1) The libraries available on the specific platform
2) C and C++ are compile time languages meaning that a C/C++ compiler compiles down into the native processor's instruction set whereas languages such as C# or Java compile down into platform agnostic byte code and then when run on another machine are dynamically compiled into that machine's native instruction set using the JVM (java) or the CLR (C#). Everything is a trade-off.
We'll make great pets
I'd like that stolen battery life back please
OK, just pay more for the extra development time, or use a version with fewer features. Every decision has trade-offs.
W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
But what happens when everybody buys lumber at the store? There still must be somebody that make sure the lumber is the right size and quality for your project. This problem is exactly why we today need giga range cpu's and ram just to watch a web page. Nobody knows how to deal with the details any longer, and so they end up building a new house every time there is a new problem.
A language that has keywords like `static_cast` or `thread_local` has reasons to be hated.
Slashdot, fix the reply notifications... You won't get away with it...
If your point was to make that part more readable, I think I want you on the other team in the next debate.
If you find that unreadable, I don't want you on my team in the next software project.
Well, I do have to say that the code would not pass my code review. Not because of the use of the ternary operator, because of the meaningless variable names. I'd also ask that "0" be replaced with "false".
Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
I think you meant: b = (a==1) ? 0 : ~b
C does not have a boolean type. Instead it tests for truthiness by checking whether the value is zero (false) or non-zero (true). That bit of code might not make sense, but it will compile.
In Soviet Russia, Jesus asks: "What Would You Do?"
For HPC (high performance computing) I don't see C++ going anywhere. For HPC the only viable languages I see are C, C++ and Fortran since they have the best optimizing compilers.
Mostly I use python for command and control with a simulator written in C++ and this seems to be a pretty common setup for HPC applications.Command and control often has a lot of code but is 1% of the compute time so write it in a high level language and then do the simulator is something that is FAST.
Computer modeling for biotech drug manufacturing is HARD!
A colleague and I were joking around one day, when a hardcore-dev (with a lot less humour, and chronic flatulence, as I remember) overheard us. He maintained that super-terse code is easier to read than the alternative. Since we were just messing about, we both just let him say his peace and then stated that the One True Language was of course Turbo Pascal 6 (which sort of ended the conversation).
My take on it is that the terse syntax does make sense (more quickly) to someone who knows the syntax really well. If you don't know it quite as well, then the long-form is better because as OP says "the sentence would look wrong". Also, actual words are 'googleable' where as it's hard to lookup the meaning of "~->" or whatever. Thus, the long-form plays to more average programmers.
The question then becomes... who should a language be for? For the super-expert, or for the midrange programmer, or possibly even the junior? IMHO, midrange is a good place to aim at because that's where the majority are, and if they're using your language then you'd want them to be able to do so reasonably easily and safely. That way, of all the billions of opcodes executed around the world as a result of your language, the majority of them will be reasonably safe and sensible.
A C compiler may add padding, but its ability to do so is constrained (or mandated) by the platform ABI. The layout of a struct is exposed directly in the language because you can ask for sizeof() the struct (which, if you subtract the size of all of the fields will tell you the total padding) and you cast a pointer to a field and a pointer to the struct to char*, subtract one from the other, and get the offset of each field. This means that it is effectively impossible for a C compiler to add padding to make optimisations easier (the only case in which they will reliably do it is for on-stack structs that are not address-taken).
I am TheRaven on Soylent News
ESR is making an early invalid assumption - that "fast transparent garbage collection will happen".
Sorry, no. The smartest people in the CS world - possibly the
smartest in the world, period (specifically those at MIT AI Lab,
Xerox PARC, BBN, TJ Watson, and Stanford) worked the GC problem
for literally 20 years, throwing hardware at it, software, tagged
architectures, secondary processors, all that.
They never cracked it. GCing at realtime speed is just a tough problem.
Unless ESR can show me code that can GC in faster than O(n) time
AND not have to freeze the allocator process for O(n) time, he's just
pitiably wrong.
(and no, I don't count flip and sweep GC as workable in this, as it
means that a buffer that DMA hardware is writing to will move without
warning. Nor is "generational" GCing, all that does is to stave off the
inevitable full-out GC for a few minutes to hours, which is fine for a
hacker sitting at a terminal but no good at all for a self-driving car or
SaaS server).
Now, I could be wrong; if he *has* a realtime garbage collection algorithm
then he deserves the Turing award.
But I'm betting "not".
People who do electrical engineering learn to read and understand the funky symbols they use in electricity. We don't expect them to write out everything in plain English. It's the same with programming. Your Pascal-y pseudo-code took how much more space and time to convey no extra information? Your pseudo-code actually took longer for me to parse and understand than the C version.
depends if b is expected to only be 1/0 at the end of this function even if it *may* be some other true value (why this would be the case I do not know), also !b is going to be faster than ~b in many cases. But! write it as it makes sense and profile to see if that speed is an issue or not.
Given the a b operators (yeah I know this is an example, but I'm running with it) this is likely an inline function that will be called very heavily in a nested loop or somesuch... as a result the speed of operators can have a very noticeable impact.
True story:
Had a co-worker that did something very similar to this, but b was a UINT64 and he used it to store a bool. used ~ operator to toggle it.
When he needed to make it look like he was busy and improved performance he switched it to a UINT32, then UINT16, then UCHAR, then to use the ! operator instead of the ~ operator.
I didn't rat him out because our manager was a dolt and my co worker was actually working on a hard problem, but manager was one of those "didn't see an improvement, so you were wasting time" people.
whois gawk date unzip strip find touch finger mount join nice man top fsck grep eject more yes exit umount sleep dump
While I certainly not found of C++ myself, I can certainly code in it. As it stands, most of the problems that I have to solve on a regular basis does not involve usage of that language directly. That said, I still think there is use for it, even beyond legacy compatibility. I typically work on user-land applications, data ETL jobs, and web services. For those, Java, C#, SQL, and the occasional bit of Python each are well suited for the job. There is less cognitive overhead to simply code for solving the problem, and then tweaking for minimizing performance issues and garbage-collector/resource leaks.
I have, on occasion, needed to interface with low-level hardware. In a Windows environment, C++ typically proves to be an excellent tool for the purpose. For the same purpose in Linux and DOS, I typically use "old fashioned" C if not using any APIs/libraries that would make C++ the better choice. I do not mind mind managing my heap in those cases and for C++ I can make use of RAII (stack).
This is not to say the Rust and Go (which I have not got around to trying) are bad choices for a project; however, I would not simply assume they are a silver bullet for a problem. I will also mention that sometimes a sub-optimal tool can be used for the job in a pinch. In the physical sense, I would normally use a hammer for a nail and a screwdriver for a screw-- I have used a hammer to beat in a screw and I have used the back of a screwdriver to insert a nail (and lamented the entire process).
Now, concerning ESR's position, I certainly see his reasons. Since my thoughts are difficult to articulate, I shall make a comparison to my browser: Firefox. I first started using it (under the name of Phoenix) because it was not Internet Explorer, but lighter weight than the then bloated Mozilla-branded browser. It had problems and it was lacking features, but it did provide enough customization that I was comfortable using it. Since then, missing features were added, security holes were patched, features that I had liked were removed since they were either troublesome or not popular, and it has gained bloat (likely to fulfilling features) similar to its predecessor. Other browsers are starting to look "shinier" to me. C++ is a language, but it, like application, will evolve to the niche of the target audience. Individual users, whether speaking of applications such as browsers or languages, will each have different needs and different limitations they are willing to tolerate. I prefer to focus on solving the problem, but I do not mind taking on the extra responsibilities if it brings me benefit. I have had talented co-workers that are absolutely allergic to idea of managing their own memory, but loves to "create clean elegant solutions." I have also had other talented co-workers that absolutely refuses to trust language/library provided mechanisms such as garbage collection, but they have the attention to detail and the background of knowledge to rapidly create lean and correct solutions to problems where they do have that level of control.
For the TL;DR, have a reasonable set of ability to use for the time and effort you are willing and able to invest in the niche that you can or want to fill. Find the right balance of flexibility and proficiency that matches the limited resources to invest and the opportunities available. Also, remember that ESR is a quasi-public figure with strong, sometimes bitter opinions: earnestly consider them, but take them with a grain of salt. I will also note that concerning his mention of the futility of trying to predict the future (the next big language), it is like predicting the stock market in that some things will stick around forever, but have only modest returns; however, a penny stock have the possibility of a minimal investment with a big return, but also carries a high risk of just being a useless waste of resources.
c) C and C++ are more versatile than any other languages because you can program at a register level if you choose to. ... "register" most likely got ignored.
Just try it, then look at the assembly code
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
The thing I note about better programming languages is that they mostly aren't better.
I've occasionally thought "This would be much easier to write in Perl than C."
I've never thought "This would be much easier to write in C++ than C".
Fewer lines of code doesn't mean much.
Thousands of line of assembler, is roughly as hard to write as hundreds of C.
A six line function can often replace a 500 line table.
Copy and paste code instead of using subroutine calls, and you too can be writing 500 lines of code a day.
It isn't significantly harder to write in assembly, that is not why we avoid writing assembly code.
IMO the successor to C won't be a higher level language at all.
It will be a language that gives as low, or even lower level access, but is more portable.
Something that let's me specify endian-ness, or bit rotation, or do atomic operations without the need to invoke a semaphore/system call.
Can do that, yes, and I've thought of going that route. But why not have a programming language that's expressive enough so that you don't have to resort to code generation, if it's not hard to do? And it's not hard. Many already do it in limited ways. In C/C++, macros and templates come to mind as means of generating code. Why not do more? Are they afraid of the compiler having to make multiple passes over the source code?
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
GC was hacked-on for decades to no avail (in bringing it low-level).But now here it works well (very fast, concurrent).
What changed? The language spec was made very simple.
Compiling was a very tricky, slow business. Now here it's fast and relatively simple.
What changed? A simpler language. Smart people who know which options to take away.
Only painfully low-level languages could work with raw memory pointers. Now we have that in 2 friendly, "default-safe" languages.
What changed? Realization a lot of power comes from low-level operations.
So C & it's layered C++ will break as safer variants with the same power begin to exist.
High level languages depended on dozens of C libraries and libc. Go needs none of those.
What changed? A realization this is important.
A fork of Go now runs without a kernel on bare-metal ARM. That's the right space to grow into a kernel-module-capable language. Languages aren't fast or slow, their implementations are. Go's ease of portage suggests it could show up in the kernel.
Science & open-source build trust from peer review. Learn systems you can trust.
Basically everything regarding padding - and even ordering of fields - is implementation dependent and not specified in any standard.
There are two relevant standards: the C language standard and the platform ABI standard. C compilers must comply with both for anything that is intended to interoperate. The platform ABI standard places much stricter requirements on structure layout than the language standard. This is important because the following is allowed in C (from your example):
In one compilation unit subtract a pointer to start of the struct from a pointer to the the l1 field and pass it to a function in another compilation unit.
In another compilation unit, construct a new instance of the same struct, cast the pointer to a char*, add the offset, and then cast it to a pointer to long, and assign to it.
The result of this must be a version of the struct with the l1 field assigned. This is a guarantee of the C language, and the platform ABI standard provides the rules that allow it to work between different compilation units from different compilers (e.g. in different libraries).
Oh, and the C standard actually does place some constraints that prevent the reordering that you describe. If you look at paragraph 6 of section 6.5.2.3, you'll see that, if a two structs start with the same fields then it is permitted to access the fields in either from a union. By induction, this means that struct fields must be ordered from the start, because anywhere else in the program (including other compilation units into which the compiler has no visibility) I can have structs that contained all of the prefixes of your struct (short, short long, short long short) and can declare a union of them and your struct and access the fields through them (and 6.7.2.1 paragraph 15 prevents there from being any padding at the start, so s1 must be at offset 0).
I am TheRaven on Soylent News
Why nobody mentions such valid and important points as packaging, modularity/reuse and build tooling?
Both C and C++ suck in this regard. Integrating 3rd-party project is usually an exercise in self-control and calm-keeping.
Autotools, CMake, Make, VS Studio, Ninja, Meson, Scons, whatever shit, a new Grand Shiny Build Tool is coming every year as The Only Solution.
No versioning. Everything is manual - binary dependencies, source dependencies, all has to be done manually for every project, with fuckload of weird compiler switches and preprocessor directives.
Most of the modern languages have acceptable solutions for that (I love Rust and crates.io in particular) - not perfect perhaps but working, except for stupid C/C++ legacy shit, and the fucking committee just keeps adding template madness instead of sanitizing it. The C++ compile times are getting bigger with each revision because another fuckton of header files are added.
How long have they been working on low latency garbage collection? If they have not developed it after decades of basically static hardware, then it will never exist. Garbage collection will always have lower performance than the alternatives so it is not suitable for low level code.
I agree with ESR that C and C++ are flawed but no modern language has solved those flaws either so I do not care.