It would be better to say that "Metalness" is a sort of "Feature Set". IMO, most programmers would tend to agree that C++ is far closer to Java than C is, yet C++ is every bit as low level as C is. Indeed, even a managed language like C# supports raw pointers and even inline assembly if one is willing to get their hands dirty.
Low and high level languages have two definitions I have seen, one is more objective, but utterly useless: only assemblies are low-level, everything else is high. The other one is more about what can be controlled in a given language’s idiomatic usage, I believe that’s what most people actually refer to intuitively - e.g. C#/Java have ways to manipulate pointers, but you would generally not say that.
In that regard, C, C++, Rust are quite close to the metal with the latter two actually being even closer as they have native control over SIMD datatypes as well, while C doesn’t have that. Note, this is only a partial ordering, as e.g. C#/Java also have control over vector instructions, yet I wouldn’t go around claiming them closer to the metal as C.
Going back to expressivity, C++ is very expressive, while C is very inexpressive, but that is a completely orthogonal axis.
I have seen so, so, so many examples of systems where latencies, including and especially tail latencies, end up mattering substantially and where java becomes a major liability.
In my experience, actually, carefully controlling things like p99 latency is actually the most important reason C++ is preferred rather than the more vaguely specified "performance".
Edit: And probably for that specific example it’d be best to go all the way to some optimized library like FAISS, so maybe C++ still wins?
FWIW I consider shared_ptr a bit of a code-smell that you don't have your ownership model well understood, there are cases to use it but 90% of the time you can eliminate it with a more explicit design(and avoid chances of leaks + penalties from atomics).
But even if you think they have some value, it isn't a flaw in a language if it's not immediately obvious how to write code in it for people that are new to it. If you're coming from Python or Java, then learn how to write C++. There are probably as many books on C++ as on any other language out there.
It wasn't until the 90s that it became clear that C was not appropriate for applications work (and this was in the era of 4-16MB machines), although that took a long time to sink in.
The statement "the alternative to C was assembly" is simply incorrect.
On the limited environment where C got created, it was the only option. And everybody suddenly adopted that limited environment, because it was cheap. And then it improved until you could use any of those other languages, but at that point everybody was using C already.
Still, that was a much more powerful machine than the ones people wrote C for. And when the cheap segment of those "fridge computers" became powerful enough to run whatever you wanted to put on it, people started using small workstations. And when those workstations became powerful enough, we got PCs.
It's only when the PCs got powerful enough that we could start to ignore the compiler demands and go with whatever language fit us better. (The later reductions all were based on cross-compiling, so they don't matter here.)
Let not say that a 1961 system is more powerful than a PDP-11.
https://www.cs.virginia.edu/~evans/cs655/readings/bwk-on-pas...
One of the major problems, as I recall, was that Wirth's basic Pascal definition was very limited---the max 256 character strings, for example. So the makers of "production" Pascal compilers added extensions to do all of the things that you would want to do and unfortunately those extensions were all incompatible.
Here are two, RatC, Small-C.
Additionally what do you think GCC C is, in regards to K&R C and ANSI C?
Several years later, a similar encounter with Mesa's evolution, Mesa/Cedar, gave birth to Oberon.
As for being ahead of its time, very much indeed.
Many people relate to Smalltalk and Interlisp-D, and are unaware of strong typed systems programming at Xerox, with a tooling that only decades cater came to be.
Mesa authors were quite adamant that in order to succeed, Mesa had to support comparable tooling to Smalltalk and Interlisp-D environments.
It's really dependent on which field you're in. Not all scientific computing requires a beefy computer, but for a very long time it (and I guess LISP) dominated scientific computing. That said, I think it's a very good point to bring up the network effect of using C - if I need to hire a developer in 1985, it's probably easier to find someone with industry (not academic) experience who knows C than it is to find someone who knows Fortran.
I do kinda prefer Fortran to C though, it's so much cleaner to do math in. Maybe somewhere there's an alternate universe where IBM invented C and Bell invented Fortran to win the popularity war.
The other mainstream language at the time was BASIC, comparable to the way PHP is viewed today by many.
And with the advent of the 32 bit x86 era GCC and djgpp as well as early Linux systems really unlocked a lot of power. Before then you'd have to have access to a VAX or a fancy workstation to get that kind of performance out of PC hardware. It's funny how long it took for the 386 to become fully operational, many years after it was launched you had to jump through all kinds of hoops to be able to use the system properly, whereas on a 68K based system costing a tiny fraction that was considered completely normal.
How did people see Fortran back then - nowadays it's seen as outdated but fast, but was it seen as interesting, and what drove you to seek it out?
Other side question if it's okay, I keep seeing references to VAXen around historical documents and usenet posts from the 80s and 90s, what made them special compared to other hardware you had back then?
The reason that library existed in FORTRAN was that it had a native 'vector' type and allowed for decent optimization on the proper hardware (ie: multiply and accumulate) which we did not have. But the library had been validated and was approved for civil engineering purposes, porting it over would have been a ton of work and would not have served any purpose, besides it would have required recertification.
As for VAXen: A VAX 11/780 is a 32 bit minicomputer, something the size of a large fridge (though later there were also smaller ones and today you could probably stick one on a business card). It had a - for the time - a relatively large amount of memory, and was a timesharing system, in other words, multiple people used the same computer via terminals.
They weren't special per se other than that a whole raft of programmers from those days cut their teeth on them either because they came across them in universities or because they worked with them professionally. They were 'affordable' in the sense that you did not need to be a multinational or a bank in order to buy one, think a few hundred thousand $ (which was still quite a fortune back then).
I had occasional access to one through the uni account of a friend, but never did any serious work with them. The first powerful machine I got my hands on was the Atari ST, which had a 68K chip in it and allowed the connection of a hard drive. Together those two things really boosted my capabilities, suddenly I had access to a whole 512K of RAM (later 1M) and some serious compute. Compared to a time shared VAX it was much better, though the VAX had more raw power.
Concurrent to that I programmed on mainframes for a bank for about a year or so, as well as on the BBC Micro computer (6502 based) and the Dragon 32 (a UK based Color Computer clone).
Fun times. Computing back then was both more and less accessible than it is today. More because the machines were so much simpler, less because you didn't have the internet at your disposal to look stuff up.
The 386 was hampered by backwards compatibility with the weird memory architecture for the 286 and 8086, IIRC. 68Ks were just soooo much easier.
I remember making a bootloader for my own OS using TurboC that somehow had to fish four files from a minix based filesystem and dump them in memory at certain addresses and then switch to flat mode and start executing the kernel which would then initialize the system properly. That was some really weird mixed mode voodoo to switch back and forth between protected mode and real mode to be able to both use BIOS calls to fetch blocks from disk and to be able to park the data in the right spots in contiguous memory.
Very tricky stuff to get right, it took me forever before I had the first indication that something was executing after the inevitable hail Mary jump to the first instruction in the loaded kernel. But I got it to work. I actually had a guitar footpedal hooked to the reset button because it took me too many dives under the desk to recover from a crash. That was a very slow development cycle without any chance of debugging. At some point I had 8 leds hooked up to the printer port to use some 'out' opcodes to tell me where I had gotten to in the code. Poor mans emulator :)
I remember meeting people who could not wrap their heads around the idea that function parameters weren't all passed by reference. The idea of recursion would have caused them to detonate.
So that left C (before cfront was introduced). And we ran with it, everybody around was using C, there wasn't the enormous choice in languages that you have today, you either programmed in C or you were working in assembler for serious and time-critical work.
Easily proven by looking into computing magazine archives.
So lets not distorce history.
As if the BBC Micro was an example of the industry adoption at large during those days.
Any Byte, Computer Shopper, DDJ, The C Users Journal (later The C/C++ Users Journal), Crash, Amiga Format, Input, PC Techniques, You Computer, Your Sinclair,... from 1980 - 1995 thereabouts, shows a different picture in article contents and ad sections, in terms of language adoption and available set of compilers being sold.
It's a bit like me saying that today Erlang is widely adopted. Yes it is, in some circles and I absolutely love it. But even though it has some adoption the big heavy lifters today are Python, C++, C and Java. Maybe C# on account of MS and probably Javascript should rate a mention. That doesn't mean that the other 2500 or so computer programming languages do not exist or do not have relevance. But it is a realistic reflection of market share. At the computer store where I occasionally worked you could see this reflected in the requests for boxed copies of compilers and interpreters for various languages.
FoxPRO + Delphi became a very powerful combination for SME administrative systems (and before that DBIII) and once Apple launched Objective-C that got some significant market share on their platform too. But any kind of commercially developed software outside of those niches was likely to be built on the list above.
I've taken a great interest in various programming languages and learned a lot of them to the point that I could write code in them to compare them, so I'm well aware all of these (and many more!) existed. The machines I worked with were: Dragon32, BBC Micro, Acorn Atom, Apple II, C64 (though, mostly from a hardware point of view, to fix them), Atari ST (lots of work on that one), IBM PC, some mainframes (notably: IBM 4381, Sperry 1100/90) and probably others that I don't remember right now.
Some of those only had proprietary languages and compilers on them, and on some things were more free. If there was a language on any of those systems that made it large enough to rate an article in the magazines you mentioned I probably played with it. But across all of the people that I worked with at the time I've met exactly one person the programmed in Pascal and they abandoned the project because it was dog slow (it got ported to assembly...) and Modula-2 or Oberon I've never come across in the wild other than with my own experiments.
BASIC, COBOL, Assembly and C were the languages that I recall being in mainstream use. That does not invalidate your experience, it may simply not match mine.
What triggers me is the usual kind of message that C wiped everything away, being the first of its kind, when on other realities, it only started to matter when UNIX tooling became part of the picture.
On my bubble C became a thing, when Windows 3.0 went mainstream.
Coding in C on MS-DOS was mostly preparing exercises for Xenix programming classes, a single tower that students had to take turns on, so we need to prepare everything in advance on Turbo C 2.0.
On Amiga it was mostly Assembly and AMOS, on the demoscene community I was part of.
In 1992, using a mix of Turbo Pascal, DBase III+ and Clipper on MS-DOS computers, and Novell Netware.
No, I was just curious. Why would you even think I was trying to trick you? And into what?
You normally make a ton of sense but in this thread I can't follow you and I sense a ton of emotion and projection that are entirely out of character for you.
"Object oriented programming is just functions with persistent state and multiple entry points, and we all learned how bad that was in the 70s."
I'm talking about applications developers who came out of the small mainframe/minicomputer world of the 70s and into the workstation/microcomputer world of the 80s. They started with assembly, and prying them off of it was as hard as convincing engineers to use FORTRAN. Convincing those application developers to use a garbage collected language, Java, was hard in the 90s.
No, it almost always is. The designers of a generic library can't anticipate the use case, so can't make appropriate tradeoffs.
For example, compare `std::unordered_map` to any well written C hash table. The vast majority of hash tables will never have individual items removed from them, but a significant amount of complexity and performance is lost to this feature.
A library author can spend ridiculous amounts of time refining and optimizing their implementations, far more than any application programmer could afford or justify.
The designers of a generic library can't anticipate the use case, so can't make appropriate tradeoffs.
This is definitely not true. Take C++ for instance, not only is it possible to specialize generic code for particular types, but it's absolutely routine to do so. Furthermore, with all sorts of C++ template features (type traits, SFINAE, CRTP, Concepts, etc) even user-defined types can be specialized, in fact it's possible to provide users with all sorts of dials and knobs to customize the behavior of generic code for their own use case. This functionality is not just a quality-of-life improvement for library users, it has profound implications for performance portability.
For example, compare `std::unordered_map` to any well written C hash table.
std::unordered_map is a strawman. There are a plethora of generic C++ hash tables which would match, if not soundly outperform, their C counterpart. Also, even if we blindly accepted your claim, then how do you explain qsort often being beaten by std::sort or printf and its variants being crushed by libfmt? What about the fact that Eigen is a better linear algebra library than any alternative written in C?
That's true. But simply having knowledge of the goal and a few simplifying assumptions can beat all the optimization in the world. In other words, a polished sub-optimal approach isn't as good as just having a better approach. `std::unordered_map` is heavily optimized, but can't make any tradeoffs because it's a general tool.
> plethora of generic C++ hash tables which would match, if not soundly outperform, their C counterpart.
Post one.
> not only is it possible to specialize generic code for particular types, but it's absolutely routine to do so.
Yep, it can do type base specialization, not application based specialization though. That requires a programmer.
> how do you explain qsort often being beaten by std::sort
a standard library C function often cannot be inlined to remove the comparison function pointer call, whereas std::sort trivially can.
If you wrote one yourself for a particular problem, it would not have this issue. This is actually a great example of where C excels because the choice of sorting algorithm so much depends on the kind of data you are sorting.
Let me be clear about my claim: tailor made solutions to each problem will almost always be faster than generic solutions. Do you really disagree with that? If you want to argue that maybe it's not productive to work that way, that's a different argument.
I disagree with it in the sense that I disagree with the statement "A human will always be able to write the same or better assembly than a C compiler, because humans can learn the compiler's tricks and make optimizations which the compiler is not allowed to make." It's a true statement, but it's so detached and irrelevant that it hardly matters.
Generic code has proven itself time and time again, even Go caved in and supported it.
> Generic code has proven itself time and time again, even Go caved in and supported it.
I'm not saying anything against the language feature generics. There is plenty of use for them even in a self contained code base.
Abseil or folly both have optimized hashtables, I believe. Rust's standard HashMap follows the same design. It involves SIMD to look for a bucket whose hash matches the query's so redoing it in C every time you need a hash table will be quite impractical.
Did I get it right that you argue for re-implementation in every of your apps of some sorting algorithm which is most fit to your data?
Why not use instead a generic library implementing a particular sorting algorithm parameterized by the data type and maybe by some policies specifying minor variations of the algorithm?
"Let me be clear about my claim: tailor made solutions to each problem will almost always be faster than generic solutions. Do you really disagree with that?"
I do. I don't think even you invent a special sorting algorithm for each of your applications that need sorting.
> Yes, you read that correctly: my naive Rust was ~32% faster than my carefully implemented C.[0]
> As a result, this code spends all of its time constantly updating an efficient data structure to be able to make this decision. For the C version, this is a binary search tree (an AVL tree), but Rust (interestingly) doesn’t offer a binary search tree — and it is instead implemented with a BTreeSet, which implements a B-tree. B-trees are common when dealing with on-disk state, where the cost of loading a node contained in a disk block is much, much less than the cost of searching that node for a desired datum, but they are less common as a replacement for an in-memory BST[1]
> So, where does all of this leave us? Certainly, Rust’s foundational data structures perform very well. Indeed, it might be tempting to conclude that, because a significant fraction of the delta here is the difference in data structures (i.e., BST vs. B-tree), the difference in language (i.e., C vs. Rust) doesn’t matter at all.[1]
> Implementing a B-tree this way, however, would be a mess. The value of a B-tree is in the contiguity of nodes — that is, it is the allocation that is a core part of the win of the data structure. I’m sure it isn’t impossible to implement an intrusive B-tree in C, but it would require so much more caller cooperation (and therefore a more complicated and more error-prone interface) that I do imagine that it would have you questioning life choices quite a bit along the way. (After all, a B-tree is a win — but it’s a constant-time win.)[1]
> All of this adds up to the existential win of Rust: powerful abstractions without sacrificing performance.[1]
[0]: http://dtrace.org/blogs/bmc/2018/09/18/falling-in-love-with-...
[1]: http://dtrace.org/blogs/bmc/2018/09/28/the-relative-performa...
No amount of optimisation will make a hash table designed for items to be removed competitive with one where items do not need to be removed.
>Take C++ for instance, not only is it possible to specialize generic code for particular types, but it's absolutely routine to do so.
So it's not a generic data structure, then. When you specialise a template, you essentially write a concrete data structure for a particular type. Rather than writing a big generic data structure that's inefficient then specialise it to the particular type, it is much easier just to write that specialised data structure in the first place.
>std::unordered_map is a strawman. There are a plethora of generic C++ hash tables which would match, if not soundly outperform, their C counterpart.
How is it a strawman? It's in the standard library.
>Also, even if we blindly accepted your claim, then how do you explain qsort often being beaten by std::sort or printf and its variants being crushed by libfmt?
printf is on the order of 50 years old. libfmt as written about 5 minutes ago. Do you take into account in your comparison the many more years in which printf has been useful? Do you take into account the amount of time it takes printf to compile vs a huge C++ library like libfmt?
Do you take into account all the code that has been slowed down by C++ programmers writing bad code and assuming a sufficiently smart compiler will inline everything for them? Do you take into account all the horrifically slow iostreams code out there?
qsort and std::sort do completely different things. Comparing them is absurd. qsort takes the size and comparison operator at runtime. std::sort requires them to be specified at compile times. I frequently use qsort in a way that you simply could not use std::sort, because those things are runtime-variable.
The proper comparison to std::sort is the implementation of a sorting algorithm written in C, specialised to the code it was written to work with. Then you can debate 'is it worth using this for the minor performance gain' etc. But comparing it to qsort is inane and demonstrates you don't even know what the two functions do.
In generic C++ code, you can specialize a part of the generic algorithm to tune it to a particular use case. Usually it takes the form of a small class template which can be specialized for a particular type and is used by the generic algorithm operating on that type. This class template is called trait, policy or strategy depending on the way it is used.
"qsort and std::sort do completely different things. Comparing them is absurd. qsort takes the size and comparison operator at runtime. std::sort requires them to be specified at compile times."
Not at all, you can pass a function pointer to std::sort just as well if you need to [0]. Most of the time you don't need this indirection but in C you are stuck with it unless you copy-paste-edit qsort.
https://github.com/tmmcguire/rust-toys/blob/master/alternati...
is a program that mmap's an anagram dictionary file and builds a fast-n-dirty hashmap dictionary over the file data. It took about an afternoon to write and was pretty decent.
https://maniagnosis.crsr.net/2014/08/letterpress-cheating-in...
But, generally one should just reach for a library first before doing a complex data structure regardless of language. And for example, the linux kernel does a fine job of doing some fairly complex data structures in a reusable way with little more than the macro processor and sometimes a support module. In a way the ease of writing linked lists/etc are why there are so many differing implementations. So, if your application is GPL, just steal the kernel functions, they are reasonably well optimized, and tend to be largely debugged, are standalone, etc.
Gnome programs are largely still written in C, but it isn't actually C. Not really. It's glib, which is almost a whole new language written on top of C. It's its own little world and it's not a good world. For example, it calls abort() whenever it fails to allocate memory.
Of course you do, especially in applications where there is no benefit to be gained versus using a GC. This is why Java was such a huge success, despite offering very little else over C++ other than GC (I think OCaml is a much better example of a GC language). Consider that an entire book has been written on such details as move semantics. For most GUI apps, a GC or other automatic memory management has proved fine.
> Gnome programs are largely still written in C, but it isn't actually C.
It's still C whatever libraries are used. It's still manual memory management with footguns. This is why they created "Vala".
I am afraid you misunderstood my comment. Of course C isn't good for writing code that calls 'malloc' millions of times per second. That's just bad code, which you can write in any language. You should not be dynamically allocating memory all over the place. If you have sane allocation strategies, then having to 'manually' manage them is completely fine.
>This is why Java was such a huge success, despite offering very little else over C++ other than GC (I think OCaml is a much better example of a GC language).
Java is the quintessential example of a language that was made popular through marketing and hype.
Getting reasonable performance out of the JVM requires far greater expertise than doing the same in C. The JVM's GC is insanely complicated and has a million different knobs which can drastically affect performance. Or they can apparently do nothing. Until you turn other knobs...
>Consider that an entire book has been written on such details as move semantics.
There are no 'move semantics' in C. Yet another way in which it is superior to C++. C++, which is a horrible language designed by nerds who enjoy standardese more than they love their own children, has 'move semantics' bolted on with an arcane 'rvalue references' mechanism that gets more complicated in every version of the standard.
>For most GUI apps, a GC or other automatic memory management has proved fine.
Retained-mode UI is something that is only reasonable with automatic memory management. The way that lifetimes of objects works in those APIs really does require a garbage collector because it's all so dynamic.
The immediate-mode UI approach, which has many other benefits as well, works perfectly fine with manual memory management.
>It's still C whatever libraries are used. It's still manual memory management with footguns. This is why they created "Vala".
Objective-C is more like C than "glib" C is. As the suckless guys said:
"glib - implements C++ STL on top of C (because C++ sucks so much, let's reinvent it!), adding lots of useless data types for "portability" and "readability" reasons. even worse, it is not possible to write robust applications using glib, since it aborts in out-of-memory situations. glib usage is required to write gtk+ and gnome applications, but is also used when common functionality is needed (e.g. hashlists, base64 decoder, etc). it is not suited at all for static linking due to its huge size and the authors explicitly state that "static linking is not supported"."
What systems are you thinking about?
Another answer is that C doesn't have much in the way of guardrails; in a world where programmer time is much more expensive than machine time, guardrails make programming much faster.
Your answer is just buzzword after buzzword. What makes C bad for writing applications?
Plus, legacy code.
Burroughs, IBM, DEC, Xerox, ETHZ, MIT, Intel,....
I really don't think this is true. I've worked in CAD and video games and embedded software, and in all those you're likely using C++ (not to mention a lot of desktop software that can't afford to embed a chromium instance for electron.) For some reason people here just assume that anything that isn't web development or backend server CRUD stuff is a niche.
As much attention as something like Rust or whatnot gets on hacker news, the reality is that if you can't afford garbage collector pauses, and you need performance, you're using C/C++ most of the time.
The set of reasons to start a new project in C/C++ are few and the list is shrinking by the day.
For tooling, I can context switch out of C++ which does have boost, into [rust, go, python… etc] and deal with that switch, or just be lazy and write it in C++. I’ve tried to write three tools in Rust so far, and the pain of not having a good stdlib, of essentially searching the internet for a blog post that solves my issue then finding the blog post was written by one dev 4 years ago to pump up their library that was written 4 years ago and then never supported after that… it’s a bit exhausting.
Again, before ya’ll attack. This is from the perspective of a willing, excited customer. I want to use Rust at work and advocate for it. Just saying, it’s not easy in the state it’s in.
C-410 from Qualcomm, which is a whole different world, I can’t even look at the source code.
But when it works, wow. This has been the most fun embedded project I've ever done with the least debugging.
Edit:spelling
It’s all beta software, but here is what they list in the docs:
Services like Wi-Fi, HTTP client/server, MQTT, OTA updates, logging etc. are exposed via Espressif's open source IoT Development Framework, ESP-IDF. It is mostly written in C and as such is exposed to Rust in the canonical split crate style:
a sys crate to provide the actual unsafe bindings (esp-idf-sys) a higher level crate offering safe and comfortable Rust abstractions (esp-idf-svc) The final piece of the puzzle is low-level hardware access, which is again provided in a split fashion:
esp-idf-hal implements the hardware-independent embedded-hal traits like analog/digital conversion, digital I/O pins, or SPI communication - as the name suggests, it also uses ESP-IDF as a foundation if direct register manipulation is required, esp32c3 provides the peripheral access crate generated by svd2rust. More information is available in the ecosystem chapter of The Rust on ESP Book.
> The set of reasons to start a new project in C/C++ are few and the list is shrinking by the day.
That'd be true if every project started from scratch with only the language standard library. And yet..... almost any project you start is going to be dependent on a large chunk of code you didn't write, even on greenfield projects.
I think this is true, and I'd refine my original statement accordingly. My original comment was thinking more from first principles, not as much about pragmatic considerations of ecosystem support.
If we were to disregard the momentum of existing ecosystems, I think C/C++ would be niche choices today: very important for certain, focused use cases, but not meant for the masses. Taking into account the momentum of existing ecosystems however, they still play a large role in many domains.
I have a couple of languages in my belt C, C++, Go, Python, Java are the primary ones. C and C++ are reserved for "power use". For power use, I mean scientific, HPC stuff or any code I need the full capacity of the processor.
To get that, sometimes you need -ffmast-math, sometimes said undefined behavior, or code patterns which translate to better code for the processor you target.
Rust doesn't allow any of that, moreover limits me the way I can write my programs, no thanks.
For security-sensitive compiled code, I can use Rust, but I can't use Rust anywhere, and everywhere. It also has its niche, and it can't and won't replace C or C++ at the end of the day. It'll get its slice (which might be sizeable), a couple of compiler implementations, and will evolve to become another mainstream , boring language, which is good.
Also, if you give half an effort, C++ is pretty secure and robust to begin with, esp. on the pointers department. Just be mindful, and run a couple of valgrind tests on your code, and you're set. Been there, done that.
> Just be mindful, and run a couple of valgrind tests on your code, and you're set.
Thousands of severe CVEs every year attest to the effectiveness of that mindset. "Just git gud" is not a meaningful thing to say, as even experienced devs routinely make exploitable (and other) mistakes.
In the tests, it became evident that the speed of the code is limited by the memory bandwidth of the system, yet for the processors I work with that limit is also very near to practical performance limit of the FPUs, as well. I could have squeezed a bit more performance by reordering the matrices to abuse prefetcher better, but it was good enough and I had no time.
Well, the method I verify the said codebase is here [0]. Also, if BSD guys can write secure code with C, everybody can. I think their buffer overflow error count is still <10 after all these years.
That’s a bold claim to make without evidence. Things like that totally seem doable in Rust without a lot of ceremony. You might have to launder some lifetimes through unsafe if you can’t convince the compiler statically, but that’s not that hard.
> Also, if BSD guys can write secure code with C, everybody can. I think their buffer overflow error count is still <10 after all these years.
As was the problem with Linux enthusiasts claiming Linux was safer bedside fewer CVEs, BSD similarly benefits from having almost no attention paid to it + very few core developers so the feature growth rate is minimal. I don’t but the claim that BSD’s qualities extrapolate anywhere rather than a more mundane explanation or that BSD is the exception that proves the role somehow given no other successful project seems to be able to do the same.
> I don’t but the claim that BSD’s qualities extrapolate anywhere rather than a more mundane explanation or that BSD is the exception that proves the role somehow given no other successful project seems to be able to do the same.
It's mostly about "it's done when it's done" mentality and always putting the discipline before writing code fast. It's a vastly different mentality when compared to modern, conventional software development. This mentality also makes what Debian is Debian.
On the other end of the spectrum, we have the stressed solo developer syndrome, which brings us OpenSSL with its all problems and grievances.
Why? Can you be more specific? Rust has built-in support for atomics and essentially the same memory model as C++, e.g.:
https://doc.rust-lang.org/std/sync/atomic/struct.AtomicU32.h...
And you can sidestep essentially any requirements of normal Rust using an `UnsafeCell` (e.g. that's how mutexes are implemented, with an `UnsafeCell` holding the data and an atomic).
I've written my share of lockless algorithms and I haven't really noticed any deficiency compared to C++, but then, I'm not an expert in this area, so if there is a deficiency here I'd love to hear about it.
> Rust doesn't allow any of that, moreover limits me the way I can write my programs, no thanks.
I'm willing to prove you wrong here. Can you give some concrete examples?
For -ffast-math you can most certainly enable it, but AFAIK for now only in a localized fashion through intrinsics, e.g.:
https://doc.rust-lang.org/std/intrinsics/fn.fadd_fast.html
https://doc.rust-lang.org/std/intrinsics/fn.fmul_fast.html
So instead of doing this the dumb way and enabling -ffast-math for the whole program (which most certainly won't need it) you can profile where you're spending the majority of your time, and only do this where it'll matter, and without the possibility of randomly breaking the rest of your numeric code.
Personally I find this to be a vastly better approach.
> So instead of doing this the dumb way and enabling -ffast-math for the whole program (which most certainly won't need it)...
When you write HPC enabled simulation code, you certainly need it, and this is where I use it.
Every piece of code you write is security-sensitive. IMO It is our professional responsibility to our users that we treat it that way.
For a vast majority of situations, even if you know what you are doing, you are human and therefore will make mistakes.
If the (probably) most heavily invested C++ codebase, Chrome, has memory use-after-free/overflow bugs, there is no way that truly safe C++ can be written at any product-scale.
No, not every application is CRUD, not every application is interactive and no, not every application serves users and communicate with outside world in a way allowing to be abused during its lifetime.
This doesn't mean it gives me the freedom to write reckless code all over, but the security model of an authentication module and a mathematical simulation is vastly different.
> there is no way that truly safe C++ can be written at any product-scale.
I agree to disagree here, because of my own experience.
Simulation precision and accuracy already carries tons of liability.
Talking like I or we don’t care about consequences is disturbing, esp. with the experience you have.
Any cybersecurity law that requires citzens votes for adoption, will certainly get my signature.
All this is done for a code which has no network access, no kernel level work, even doesn’t accept any input after parsing the input model and making sure that it’s well formed with no loose ends.
Imagine what I’d do if it does any kind of authentication or user affecting work.
We all agree that security is important and a lot of code running in security-sensitive contexts is bad. That's very different from saying that all code is security-sensitive.
Who sold you that notion?
Matlab is proprietary glue holding together modules written in Fortran, C, C++, Java that allows the adhoc inclusion of DLLS put together by graduate students on the fly.
In what universe is any of that "memory safe"?
Like the matrix handling, plotting, and other modules dragged in from the 1990s standard FORTRAN library era.
Don't get me wrong, I have placed a lot of trust in those kinds of numeric libraries since the 1980s - NIST and other national labs code and review to a high standard - but they weren't then and aren't now "memory safe" just very probably and mostly bug free.
Unless they were, say, rewritten in Java .. and that's a whole other big ball of issues .. translated code.
I'm happy to play along and agree that the JIT compiled 'Matlab language' parts of Matlab are memory safe - but to the best of my experience with past versions that's just the glue portions - the reason so many people use Matlab is for the chunks that get glued together.
They can still have bugs, memory issues, be called with parameters that cause resource blow outs and aren't "memory safe" in the sense that modern managed languages are.
Matlab is exactly as reliable as well written Fortran and C code can be.
There isn't really any fundamental limitation of Rust for those situations. A better reason why C++ is better than Rust for compute is the support for OpenACC, OpenCL, OpenMP, CUDA, ROCm/HIP, etc.
Also, if you give half an effort, C++ is pretty secure and robust to begin with, esp. on the pointers department.
The problem is that even if a "Safe" C++ could be defined, it would need to interoperate with the rest of the "Unsafe" C++ world. Perhaps a programmer can write absolutely safe C++ themselves but all bets are off once you're working with other programmers.
Just be mindful, and run a couple of valgrind tests on your code, and you're set. Been there, done that.
Seriously? A "couple of valgrind tests" would be insufficient for catching all but the most trivial and/or blatant memory safety issues in C++, especially when dealing with malicious users. Although I agree that dynamic analysis like valgrind and sanitizers should be the default for C++ development, industrial grade static analysis tools are at least as important. And needless to say, if you find Rust complains about code too much then just wait for what static analysis tooling will complain about.
If programming is a team sport, every team player should be up to the level your project needs. If they are not, they should raise their bars. Seriously.
Yes, seriously, be mindful. Implement allocation and destruction first, fill your code between these two steps.
A couple of Valgrind tests is actually a whole procedure. It's an unfortunate downplay by me [0], probably because I'm very used to use Valgrind as a second nature.
Also, this elitist notion of raising the bar is an instant “turnoff” for me, with all due respect, I can only assume from that that the given person may not be as much an expert as they think of themselves. Not saying that it applies to you as well, but you don’t leave me much other choice.
Ad absurdum it has quite great inline asm support.
I like rust and I dick around with it a bit on some small REST projects I have for home automation but for day-to-day work I stick with c++ until rust support picks up in the industry a lot more than it currently is.
Why do you think Bjarne Stroustoup main subject on conferences is how to write C++ properly without C style coding, for several years now?
I think that's because anything more "low level" (using the phrase freely) quickly becomes highly specialized, whereas web / CRUD development is a dime a dozen.
Source: Am web / CRUD developer. It's a weird one, on the one side I've been building yet another numeric form field with a range validation in the past week, but on the other I can claim I've worked in diverse industries; public transit, energy, consumer investment banking, etc. But in the end it just boils down to querying, showing and updating data, what data? Doesn't matter, it's all just strings and ints with some validation rules in the end.
But there's my problem, I don't know enough about specialized software like CAD or video games or embedded software to even have an interest in heading in that direction, let alone actually being able to find a job opening for it, let alone being able to get the job.
If nothing else musttail aids testing and debugging. Unoptimized code uses a lot more stack, both because it hasn't spent the time to assign values to registers, but people often debug unoptimized code because having values live on the stack makes debugging easier. The combination of unoptimized code and calls in tail position not made in a way that keeps stack size constant means you hit stack overflow super easily. musttail means that problem is at least localized to the maximum stack use of each function, which is typically not a problem for small-step interpreters. Alternatives to musttail generally involve detecting somehow whether or not enough optimization was enabled and switching to a safer, slower interpreter if not positive... but that just means you're debug and optimized builds work totally differently, not at all ideal!
VM and OS abstractions have been so successful that you can go a whole career without talking directly to hardware, but remember, at the bottom of the abstraction pile something has to resolve down to voltages on wires. Function calls, method names, and JSON blobs don't do that. So what does? What abstraction bridges the gap between ASCII spells and physical voltages?
Address space. I/O ports exist, but mostly for legacy/standard reasons. Address space is the versatile and important bridge out of a VM and into the wider world. It's no mistake that C and C++ let you touch it, and it's no mistake that other languages lock it away. Those are the correct choices for their respective abstraction levels.
I mean... yeah? I'd be surprised if most operating systems didn't have a facility for directly accessing memory mapped devices in some capacity. Even Windows does I think. Have any examples of an OS that doesn't support banging directly on memory?
> using a device with simple enough behavior that things like timing or extra/elided writes didn't matter
Yeah, but that's less of a function of the language like GP was referring to and more a property of using a non-RTOS that doesn't play nice with timing sensitive things from user-space. The language itself is not really the issue there, which was my point.
You might want to go and have a look at the implementation of 'mmap' in CPython. Here's a clue: it's in the name 'CPython'.
It is still “syscall”s at the end of the day, and many programming languages can output assembly just fine.
Personally I would like to see a native language which attempts to acknowledge and work with disjoint and/or "far away" address spaces. However the daunting complexity of such a feature would likely exclude it from any portable programming language.
For what its worth UMA/USM wasn't build to bridge a gap but rather to offer greater flexibility in resource utilization for embedded platforms, that's been moving upstream(along with tiling GPUs) over the years. With UMA you can page in other data on a use-case basis which is why they were relatively popular in phones, if you don't have a bunch of textures loaded on the GPU you can give that space back to other programs. Although come to think of it we used to stream audio data from GPU memory on certain consoles that didn't have large discrete system memory(the bus connecting System <-> GPU memory had some pretty harsh restrictions so you had to limit it to non-bursty, low throughput data which audio/music fit well into).
There's still a niche for it, but it's tiny and it keeps getting tinier.
Do you repeat this exercise when you upgrade or change compilers?
Besides, the industry hands down chose C++ for the truly performance-oriented workloads.
That is the key, right there.
In 1970, C may have been considered a general-purpose programming langauge. Today, given the landscape of languages currently available, C and C++ have a much more niche role. They are appropriate for the "power users" described above, who need every last bit of performance, at the cost of more development effort.
When I'm working in C, I'm frequently watching the assembly language output closely, making sure that I'm getting the optimizations I expect. I frequently find missed optimization bugs in compilers. In these scenarios, undefined behavior is a tool that can actually help achieve my goal. The question I'm always asking myself is: what do I have to write in C to get the assembly language output I expect? Here is an example of such a journey: https://blog.reverberate.org/2021/04/21/musttail-efficient-i...
I created the https://github.com/protocolbuffers/upb project a long time ago. It's written in C, and over the years I have gotten it to a state where the speed and code size are pretty compelling. Both speed and code size are very important to the use cases where it is being used. It's a relatively small code base also. I think focused, performance-oriented kernels are the area where C makes the most sense.