1. 35
  1.  

  2. 25

    “The C language combines all the power of assembly language with all the ease-of-use of assembly language” - Ancient Peasant Proverb

    -Expert C Programming by Peter van der Linden

    1. 11

      Note that Intel get paid according to the number of CPU cycles consumed to do any given task…

      In all seriousness, sometimes I wonder about how C has influenced chip design and how much Intel has benefited from it. C makes it easy to dereference memory locations, which is actually quite an expensive thing to do, and the proliferation of this type of programming ends up requiring a lot of CPU caching, prefetching, out of order execution while waiting for memory to arrive, and ultimately, hyperthreading to allow a core to make progress while waiting for memory. If all code had to be written in assembly, we’d probably end up with simpler data structures that are faster to execute and much simpler CPUs.

      1. 3

        In all seriousness, sometimes I wonder about how C has influenced chip design and how much Intel has benefited from it.

        Related: https://queue.acm.org/detail.cfm?id=3212479

        1. 2

          If you data structure requires heap/non-continuous memory access to implement it, you do it in any language. Yes, people did that in assembly days too: semantically it’s not any harder than in C.

        2. 16

          Love how many comments here obviously respond to the lede without any substantive response to the content of the article. It’s the biggest problem with Lobsters, tbh. People will see an article with a title that’s supposed to get attention, and then use it as a chance to go on barely related diatribes without even taking the time to read the article.

          1. 2

            There is one big claim: the title. The rest of the article is not that useful and says things repeated over and over (and over and over: RUST \o/ Hurray! Gooo \o/ yipee! Memory safe! Memory safe all over!).

            Not that is a bad thing (hurray!)… Once each of us empty its remark bag about memory safety and rust and go maybe comments will come back to a normal state.

            1. 7

              Do realize that this is a transcription of a talk that is up on youtube (media literacy is an important skill). At 3 minutes in the speaker spends less than half a minute saying anything about C being “the new assembly”, which is not in the title of his actual talk. At 4 minutes in the speaker specifically talks about how it’s not just about memory safety. The notes about memory safety from there on are mere sidenotes. The meat of the talk is actually about feature parity in Rust.

              1. 1

                Ah! thank you, I did not followed all the links on the page, my bad…

                So it is “one view over that engineer’s talk as seen by this journalist reporting it”. Makes sense now.

                [EDIT]: After all, we all need to party a bit from time to time…

            2. 0

              Doctors hate this one trick for creating titles that are informative as opposed to inflammatory clickbait!!1

            3. 5

              I can’t remember who said it but I always liked the description of C as “universal assembly language”.

              I love C, I’d say 50% of the code I write is in C. The other 50% is in Python. I think, though I’m not sure, that it’s going to eventually be 50/50 Rust/Go. The future is coming.

              (Along with the occasional assembly language, of course. I’m interested to see what architectures we come up with as silicon real estate gets less expensive. Intel was banking on almost-operating-system-on-a-chip with iAPX 432, maybe we’ll get there eventually.)

              1. 5

                I can’t remember who said it but I always liked the description of C as “universal assembly language”.

                I’ve never really liked that, because it gives people some incredibly misguided ideas about how C works on modern compilers and CPU architectures.

                Essentially people naively assume that they can predict what C “naturally” compiles to, and claim this as an advantage of C, when in fact they’re just assuming they have a grasp of what the compiler and CPU are doing when both are frequently doing something else entirely that’s faster but happens to preserve the semantics.

                1. 7

                  Look at Mr. I-Can-Afford-Something-Better-Than-A-PDP-11 over here.

                  1. 1

                    Hey, I’d love to be able to justify buying a working PDP-11. Found one for sale for about the price of a high-end laptop.

                  2. 3

                    Dont forget D, Nim, and Zig. Especially D given its maturity and compile speeds.

                    1. 11

                      Don’t get me wrong, but I feel like D has been “almost there” for like 20 years now.

                      (Fun fact combining my love of computer science and the history of western religion: “Nim” was originally named “Nimrod”. Nimrod was “a mighty hunter before YHWH” (the tetragrammaton, there’s a lot to discuss there, along with the exact meaning of “before”) in Genesis. “Nimrod” became an insult in English when Bugs Bunny mockingly called Elmer Fudd “a mighty hunter” and a “Nimrod” in a cartoon in the 1950’s.)

                      1. 6

                        Re D. The licensing situation caused a lot of it. Now, they have a lot of features, a fast compiler, and a compiler for faster executable. Maybe it just needs a killer app or big company backing it.

                        Re Nim. I knew about Nimrod. I assumed the negative connotations were why they changed the name. I never checked, though.

                        1. 8

                          The licensing situation caused a lot of it.

                          RIP REBOL

                          1. 7

                            RIP REBOL

                            Fortunately, there is the Red programming language

                    2. 2

                      I think, though I’m not sure, that it’s going to eventually be 50/50 Rust/Go

                      Both languages make a lot of sense and I can imagine smart companies having this kind of mix (with some JS or python added, probably). But it looks like a strange mix for a person in my opinion.

                      If you manage to maintain the ability and mindset to efficiently code in Rust (which is a real burden), is there really a reason to write anything in Go ? I don’t see one but I’d welcome your argument.

                      1. 1

                        If you manage to maintain the ability and mindset to efficiently code in Rust (which is a real burden), is there really a reason to write anything in Go ? I don’t see one but I’d welcome your argument.

                        Perhaps you are hoping for contributors who haven’t learned to live with the borrow checker. Perhaps your program is fairly simple, and you want to distribute cross-platform binaries (for cross-compilation, rust is better than C, but light years behind go)

                        1. 1

                          Depends on how well one knows/likes Go, really. I’m not good enough at it to think of it as replacing Python for quick-and-incremental tasks, but I could see where others might.

                        2. 1

                          I’d say 50% of the code I write is in C. The other 50% is in Python.

                          For me it’s 50% C and 50% Go. I like working with types too much.

                        3. 4

                          This is a poor, clickbaity write-up of a talk that was already posted here: https://lobste.rs/s/xvfyi0/intel_rust_future_systems_programming

                          1. 3

                            I for one appreciate a summary write-up of a video. It’s better if it’s not misrepresenting the contents, though. But I count on people who are more invested to check the write-up against the talk.

                            1. 3

                              You’re right: a summary write-up is not a bad thing at all. I should have separated those two points: (a) this is a write-up of a talk that was posted here earlier; and (b) it’s a poor write-up with a clickbait title.

                              I think the write-up is poor because it contains a lot of content that was not in the talk, presented as if it were. Additional context is not a bad thing, but in this case I didn’t find the quality of the extra material to be very high and I didn’t like that it isn’t clear what was in the talk and what has been added by the reporter. For example, there’s a section on “systems programming” that gives a definition that wasn’t used in the talk and does not include any acknowledgement that “systems programming” is a contentious term. The write-up then includes what the speaker actually said, implying that he said the earlier stuff too.

                              The other additional content also seems more journalistic than technical, if that makes sense. It doesn’t meet the technical standards I usually see on the lobste.rs front page. The author claims that Rust “does not have a … runtime system of any kind”. They say that bfloat16 makes interoperating with existing systems easier. It’s all sort of true but not quite right.

                              Mostly though it’s the clickbait title that annoyed me, especially because the speaker went out of his way to avoid making that sort of claim.

                              1. 2

                                Thanks a lot of taking the time to write this detailed critique!

                                I suspect that made this post blow up was the title, and (maybe) that it’s been featured on HN:

                                http://gerikson.com/hnlo/2019-08.html#20820583_drcxer

                                The original submission didn’t make as much of a splash on HN:

                                http://gerikson.com/hnlo/2019-08.html#cupk8w_20785623

                          2. 5

                            We know we have a problem with how fuzzy “systems programming” is defined and it’s only getting worse here.

                            Triplett broadly defines systems programming as “anything that isn’t an app.” It includes things like BIOS, firmware, boot loaders, operating systems kernels, embedded and similar types of low-level code, virtual machine implementations. Triplett also counts a web browser as a system software as it is more than “just an app,” they are actually “platforms for websites and web apps,” he says.

                            Browsers ? Then what about databases ? Libraries ? Frameworks ? Most of what people here are coding isn’t a final and complete user facing application. Is docker (notably written in go) systems programming ?

                            It seems we put in “systems programming” all the serious programming where consistent performances and reliability matter. Isn’t it time to drop or fix that notion ?

                            1. 4

                              It seems we put in “systems programming” all the serious programming where consistent performances and reliability matter.

                              Yep. This fuzziness caused problems for Go. The team making Go thought that “systems programming” meant building large, interconnected systems - i.e. distributed systems of servers. So they called Go a “systems programming” language. Then everyone complained at them for making it garbage collected. But garbage collection (especially a nice, low-latency GC) is a sensible choice for the sort of server programming that Go targets. Now they call Go the language of “cloud computing” (to which Rob Pike always adds, “What we used to call servers”) to try to avoid this confusion.

                              “Systems programming” always seems to mean, “The sort of programming that requires the features in my favorite language”.

                              1. 4

                                The type of garbage collection is important, too. Any type of garbage-collection is sensible for throughput oriented server programs. But for latency-oriented ones, you want incremental, small pause GCs. Otherwise, your tail-latency will be pretty bad. At work, we rewrote one of our servers from Java to C++ just for this issue.

                                1. 2

                                  Absolutely! There are some low-latency GCs for the JVM too - Azul do a lot of that work - but Go is particularly good here. This is quite a nice talk about it: https://blog.golang.org/ismmkeynote

                                  1. 2

                                    Very apt observation. I am becoming increasingly aware that a lot of the patterns Rust programs use for situations where the borrow checker don’t cut it amount to runtime checking for memory safety. Tracing GC is just one way to do that runtime checking, with its own set of tradeoffs.

                              2. 3

                                There are already a lot of programming languages that “compile” (transpile?) to C.

                                Socially, it might be true:

                                • “the kernel guys write in assembly” -> “the kernel guys write in C”
                                • “your daemon is in assembly! rewrite it in C!” -> “your daemon is in C! rewrite it in Rust¹

                                At some point every popular open source project in C gets to face the question: Do I ignore these Github issue to RIIR¹. Some do, some other do not.

                                Programming languages becomes communities more than projects: borrowing foreign code is the common place, and use 0 dependencies becomes the exception, even for libraries.

                                C does not have this feature of running “cc fetch” to download all libraries (pkg_add, pkg, apk, apt, yum, pacman, brew, … does it instead). And nobody but package maintainer ever deal with GNU’s autoconf mess (sorry for the rudeness, but spending time with it does not help).

                                This is the determinant difference that make so many C, C++ and Java developers look for fresh meadows to sleep on.

                                Rust and Go are taking the full attention with C being still actively used for less categories of softwares, but, like ASM did, but Rust and Go do not compile to C akin to C compiling to ASM.

                                Rust is backed by LLVM² and Go has its own architecture-independent intermediate assembly language³ to split the compilation in two steps. So Rust/Go -> C -> ASM -> machine code is wrong. It is different.

                                1. 1

                                  Actually Go’s approach to assembly may have changed a bit since I last saw it but the principles of keeping as much as possible architecture-independent is still there. The details are in .

                                  1. 2

                                    Interesting. I’m subscribed to golang-dev@ but haven’t heard of this. Do have an example?

                                    1. 2

                                      One mailing list to subscribe to! (might as well Go for Rust one).

                                      I’m only knowledgeable for a few bits and do not have the full picture, but from what I saw :

                                      1. 2

                                        The rust-dev mailing list has been defunct for years. You probably want https://internals.rust-lang.org

                                2. 1

                                  I had to write some assembly today for work, not even for performance reasons. I don’t think knowledge of assembly will be made obsolete any time soon the way the title is sort of implying.

                                  In my opinion, the more you know about your stack, the better. Having some knowledge about how your whole stack works, as well as an intimate familiarity with the few layers directly above and below where you’re at, is really valuable.

                                  1. 7

                                    I loved m68k assembly, but on modern “big” architectures even asm itself feels like a high-level language.

                                    CPU isn’t a CPU, but a bag of units and pipelines (which you’d hope to use optimally, but it’s implementation-dependent!). Cycle counting is mostly pointless: speed almost entirely depends on black-box branch predictors and runtime cache state. Even instructions and registers aren’t what they appear to be thanks to microcode and register renaming.

                                    1. 1

                                      I don’t think knowledge of assembly will be made obsolete any time soon the way the title is sort of implying.

                                      There’s a section within the talk about stabilizing support for inline assembly in Rust - so it’s importance is recognized and being worked on. I wouldn’t read much into the overly sensational title.

                                      1. 1

                                        There are people writing processors who are dealing with assembly all day long. For instance at Intel.

                                        But Intel’s ISA ties back to its very early design, and I think that some assembly written back in the day are obscure to most Intel engineers that write C most of their time.

                                        1. 2

                                          From what I understand, a fair amount of low level crypto primitives are still in assembly too – both for performance reasons, as well as to avoid certain compiler optimizations that may leak side channel data (more control over timing, register use, etc).

                                          1. 1

                                            Namely, libnacl released in 2008, now widely distributed as libsodium.

                                            This is 1 library, written 9 years ago. :)

                                            Ok, there might be a lot more crypto libraries written in assembly, or at least “optimized C” to through assuptions of how C compiles onto assembly (which changes over time!).

                                      2. 1

                                        Wasm is the new Assembly. RISC-V is the new microcode.

                                        1. 0

                                          If Rust is the future of systems programming, then how is C the new assembly?

                                          Rust doesn’t compile to C, does it? C isn’t arch-specific. What we’re really meaning here is that C is nearly deprecated.

                                          1. 5

                                            “New assembly” as in it’s the escape hatch. Something you have very little of in your project. Most C compilers haven’t had an explicit/mandatory foo.asm output step for decades.

                                            1. 2

                                              There are several ways to compile Rust to C and there are a variety of languages that compile to C by default.

                                              1. 1

                                                …but why?

                                                1. 2

                                                  The background of applications targeting C really goes back to seeking the portability offered now by the LLVM toolchain before that was such a popular compiler toolchain. Your choices were to either manually take the time to target every platform you want to support yourself, or to find a way to easily piggyback on the enormous man-hours invested in C99 compilers, and all the targets that are available from that. Now, LLVM is the toolchain of choice given its efficacy, interface, and portability. But even today I’m sure you can find some obscure target that may not be supported by LLVM but almost definitely has a C99 compiler.

                                                  1. 1

                                                    Why wouldn’t you just target LLVM bytecode?

                                                    1. 1

                                                      I described why in my comment.

                                                      1. 1

                                                        seems excessive, though

                                                  2. 2

                                                    Get the benefits of those languages plus maybe C’s efficiency, tooling, libraries, etc.

                                              2. 1

                                                languages that have a runtime are difficult to use as a system programming language

                                                I dislike that Go went full Garbage Collected. I guess it is to enable a different approach to programming involving concurrency with shared objects between [cg]oroutines rather than async I/O libraries.

                                                On that part, Rust has something I convey: Less of the C++ memory management mess, still “free while it’s over” behavior.

                                                1. 1

                                                  I haven’t seen a packt publishing link for ages. Are their books still awful? Are they still trying to get publishing deals with people, despite that they are in general worse than self-publishing?

                                                  1. 1

                                                    I haven’t seen a packt publishing link for ages. Are their books still awful? Are they still trying to get publishing deals with people that are in general worse than self-publishing?