1. 101
  1.  

  2. 88

    In light of all of these problems, I’ll take my segfaults and buffer overflows

    but I won’t take your buffer overflows. I have spent enough time with emergency security patching RCEs left by C programmers who were “good enough” not to need a memory-safe language.

    1. 8

      “I have the best taxi service in town because my car is so fast! Yeah, it has no seat belts, but don’t worry — I’m a very safe driver.”

      1. 1

        This is a beautiful way to put that.

      2. 7

        I was thinking about this actually. I was pretty sure that those were security issues rather than just annoying. Maybe he doesn’t mean for the finished product? I hope that’s what he means.

        1. 3

          I’m sure he meant that, but it is still very unlikely that he or anyone else will iron out all segfaults and buffer overflows.

        2. -9

          So since PHP is memory-safe, it’s a good C replacement?

          1. 23

            Yes, if you have to choose between C and PHP, and both can do the job, you definitely should choose PHP, no question. The problem is that PHP often can’t do the job.

            1. 17

              That’s a very uncharitable interpretation. Brainfuck is also memory safe and is obviously not a good C replacement - obviously the only requirement isn’t memory safety.

              1. 3

                Yes. I chose PHP because it’s an extreme case.

                The point is: yes, Rust is safe, but the article explains why (besides memory safety) Rust isn’t a good C replacement. In other words: there are other programming languages that are better suited than Rust to replace C.

                1. 5

                  I think everyone get’s your point, but it’s banal noise that pollutes the discussion, hence the downvotes, which are actually pretty rare here.

            2. [Comment removed by author]

              1. 23

                Yup, and there will be more, you can count on that. Especially as Rust adoption increases and its overall attack surface expands. I wouldn’t even be surprised if it came from me, since many of the libraries I write use some amount of unsafe, and I’ve written a lot of libraries.

                And then they will say, “but you promised no more seg faults or buffer overflows! See, Rust isn’t safe after all!”

                Nuance has been lost in our discussions of programming languages. Instead, it’s just one giant culture war.

            3. 60

              First of all, I respect Drew’s work a lot. I am an avid sr.ht user and I like Sway. But I think some of the criticism is misplaced, perhaps due to a lack of experience with Rust. My largest peeve is comparing Rust with C++, both for historical reasons and because it is used as a rhetoric device. A lot of people dislike C++ nowadays, so if Rust is like C++, it must be large, complex, and ugly.

              But Rust could be compared to Haskell or OCaml as well. Modern Haskell also has a lot of features. But in contrast to C++, it has a lot of useful orthogonal features, such as algebraic data types, pattern matching, parametric polymorphism. Not coincidentally, Rust has many of the same ideas. Historically, Rust is more of a descendant of OCaml than C++. Graydon Hoare, Rust’s creator was an OCaml user and the first versions of the Rust compiler were written in OCaml. For me, as someone who has used C++, Haskell, OCaml, and Rust, Rust is more an imperative version of OCaml than C++. Rust is an ‘imperative OCaml’ sounds a lot more positive than ‘Rust is like C++’.

              Both Rust and C++ are what I like to call “kitchen sink” programming languages

              The Rust project has shown a lot of restraint in adding new features. There is no inheritance (outside trait inheritance), let alone multiple inheritance, there are no higher-kinded types, no support for specialization in trait implementations, etc.

              Over time it rapidly becomes difficult for one to keep an up-to-date mental map of Rust and how to solve your problems idiomatically.

              Rust 2015 -> Rust 2018 largely consists of ergonomic changes. You can compile Rust 2015 with a current Rust compiler and what is idiomatic in Rust 2015 is still idiomatic in Rust 2018, except perhaps deprecation of the try! macro for the ? operator. That said, try! still works like it worked in 2015. Also, the rate of new features has slowed down quite a bit and most of the action happens in the ecosystem or standard library.


              Before someone says: Rust Evangelism Strike Force strikes again. I have my fair share of criticisms of Rust. But they are more detailed than this post.

              1. 22

                Well, I’d describe Rust as “OCaml with C++ features” (aka no GC), not “imperative OCaml”. OCaml is already imperative, so the adjective is redundant. (Source: I used OCaml at work.)

                1. 18

                  I have my fair share of criticisms of Rust. But they are more detailed than this post.

                  We’d be very happy to hear them! If you want your writing cross-checked for facts on your own terms, community@rust-lang.org even offers a review service for posts of any kind :).

                  1. 21

                    Well, I don’t think anyone is served by a long write-up of these, since they are well-known ;). Some random problems that I encounter periodically:

                    • The impl From<T> for T implementation makes it implement conversions between specific instantiations of a type parameter. E.g. impl Foo<Bar> for Foo<Baz> is rejected because of this implementation in the standard library.
                    • Vec does not provide a constructor that allows specification of alignment.
                    • impl coherency rules. They are hard to find and somewhat confusing.
                    • It can be difficult to choose between enum or trait + impls in libraries. This is especially the case when some methods have type parameters and thus the resulting trait is not object-safe. This typically results in a lot of type parameter juggling for library users, since they cannot simply box instances. enums on the other hand, are closed.
                    • No good and consistent error handling story. failure is nice, but should not be used in libraries. But as far as I understand, there is some ongoing work upstream.
                    • Literals can be annoying. Luckily there is lazy_static and maplit, but even with those crates it is somewhat painful.
                    • It would be very nice if enum variants could be used as types (I know that there is an RFC).

                    There are more, but I have to run out for groceries :).

                    Problems that I often encounter in other people’s code:

                    • Confusion when clone() or to_owned() should be used.
                    • Confusion when Borrow or AsRef should be used.
                    • Confusion whether arguments should be a plain reference, AsRef and/or when arguments should be an owned type or Into<OwnedType>
                    1. 11

                      I agree that all of them are well-known, but I appreciate the condensed writeup :). Some of them are even my pet peeves (e.g. clone vs to_owned). Thanks!

                      Vec alignment: isn’t that solved by being able to choose the struct alignment? https://github.com/rust-lang/rust/issues/33626

                      (Interestingly: we consider such small things “features”, which might lead to the OP see that as such wrt to stability…)

                      1. 3

                        I was thinking of SIMD intrinsics that require aligned memory. So e.g. alignment of an f32 array on a 16-byte boundary.

                        There are some workarounds (e.g. allocation a larger array and starting on a boundary and avoiding backing array growth). Still, it would be nicer if it was directly suported.

                        1. 2

                          Hm, I see where the things are missing, but is that really something that should be folded into the generic vector type instead of a specific type?

                      2. 2

                        It would be very nice if enum variants could be used as types (I know that there is an RFC).

                        Agree on this, it has caused me so much pain.

                        I guess it’s one of these things where people who have never used a language where each enum has a precise type say “Huh, what’s the deal? I never needed that!” and for people who used such a language, it’s a huge pain to work around it.

                      3. 3

                        In case you’re interested in others’ reports too, and haven’t read mine yet, I’ve tried to list here on lobste.rs some of the papercuts I stumbled upon when trying to write a project as a newbie. Unfortunately, they made me exhausted and frustrated enough that I eventually stopped trying to push through, and switched to experimenting with Nim for the time being.

                    2. 72

                      Cargo is mandatory. On a similar line of thought, Rust’s compiler flags are not stable

                      This is factually false. Everything in rustc that is not behind -Z (unstable flags) is considered public interface and is stable. Cargo uses only the non--Z interface, so it can be replaced.

                      I also don’t agree with the rest of the statement, integrating cargo into other build systems is a problem that would get worse if it were solved badly and it is terribly hard to find an interface that helps even “most” of the consumers of such a feature. Yes, it always looks like “not caring” from the side of consumers, but we have a ton of people to talk to about this, so please give that time? There’s the unstable build-plan feature which allows to export data from cargo, so please use it and add your feedback.

                      A lot of the arguments fall down to “not yet mature enough” (which I can easily live with, given that the 4th birthday of the 1.0 release is in 1.5 months) or - and I don’t say that easily - some bad faith. For example, Rust doesn’t have a (finalized!) spec, yes, but it should also be said that lots of time is poured into formally proving the stuff that is there. And yes, we’re writing a spec. Yet again, there is almost no practical language today that had a formalized and complete spec matching the implementation out of the door!

                      I also don’t agree with the statement that Rust code from last year looks old, code churn around the 2018 edition was rather low, except that you could now kill a lot of noisy lines, which a lot of projects just do on the go.

                      I’m completely good with accepting a lot of the points in the post and please have your rant, but can’t help but feeling like someone wanted to grind an axe instead and highlight their mastodon posts.

                      Finally, I’d like to highlight how much effort Federico from Meson has put into exploring exactly the build system space around Rust in a much better fashion. https://people.gnome.org/~federico/blog/index.html

                      1. 3

                        Yet again, there is almost no practical language today that had a formalized and complete spec matching the implementation out of the door!

                        This is factually false? JavaScript has a superb spec and also has a formalized spec. Practically speaking, formalized spec is not very useful yet, so if we restrict to complete spec, all of C, C++, Java, C#, JavaScript have complete spec supported by multiple independent implementations. Rust’s spec as it exists is considerably less complete and useful compared to those specs.

                        1. 16

                          My point is: Did all of those have it out of the door?

                          Yes, the current spec is not useful for reimplementing Rust and that has to change. My point is that it’s rare to see languages that have such a spec 3 years out of the door.

                          1. 25

                            Java was released in 1996 together with Java Language Specification written by Guy Steele and co (zero delay). C# was released in 2002 and ECMA-334 was standardized in 2003 (1 year delay). Compared to Java and C#, Rust very much neglected works on specification, primarily due to scarce resource. My point is that even after 3 years, unlike Java and C#, there is no useful spec of Rust.

                            1. 4

                              Why did Steele write the Java spec? Usually there is little value in writing a spec if there is only one implementation. Did they write the Java spec because Microsoft made its own Java?

                              Also, Python has no spec although it has multiple implementations and it is certainly a useful and successful language.

                              1. 2

                                I believe Python does have a spec. “don’t rely on dict ordering” was a consequence of saying “Python spec doesn’t specify this even if CPython in fact orders it”, though this has changed. Not closing files explicitly is considered incorrect from a spec perspective even though CPython files will close files on file object destruction

                                It’s not the C++ language spec but there are a good amount of declarations relative to “standard Python behavior”

                                1. 3

                                  By that logic, so does Rust. They both follow almost identical processes of accepting RFCs and documenting behavior.

                                  1. 1

                                    I’m agnostic to the “Rust having a spec” question. I have not thought about it more than today.

                                    Python has the reality of having multiple mature implementations (I’m not sure if this is true of Rust?) so there’s actually a good amount of space for a difference between spec and impl.

                                    I also think there’s actually an ongoing project to defining a Rust spec? It feels like “Rust spec” is pretty close to existing , at least in a diffuse form

                                2. 1

                                  Usually there is little value in writing a spec if there is only one implementation.

                                  There is a lot of value in writing down the conclusion of a discussion. When the conclusions are about formalization, it adds value to write it down as formally as reasonable. That enables other humans to check it for logical errors, functional problems, etc. and catch those before they are discovered while coding or even later.

                                3. 1

                                  You’re right. coming from a background of more dynamic languages (Ruby/Python/etc., I’m more used to their pace so speccing).

                                  1. 0

                                    hm - i was against you until this comment

                                    thats a good point - perhaps mozilla wants hegemony over the language and wants to prevent other rust implementations - i wonder if any other serious implementations even exist currently?

                                    1. 14

                                      I don’t think that’s the case. Spec writing is a very specific skill, and you pretty much need to hire spec writer to write specification. Mozilla didn’t invest in hiring Rust spec writer. (They did hire doc writer to produce the book.) Since Java and C# did invest in specification, it is right and proper to judge Rust on the point, but then Mozilla is not as rich as Sun and Microsoft were.

                                      1. 13

                                        Rust is independently governed from Mozilla; while there are Mozilla employees on the teams, there was a deliberate attempt to make Rust its own project a bit before 1.0.

                                        There are active attempts to specify parts of Rust: we have a group of people attempting to pin down the formal semantics of unsafe code so that that can be specified better (we need to figure this out before we specify the rest of it).

                                        Specifying a language is a huge endeavor, it’s going to take time, and Rust doesn’t have that many resources.

                                        1. 6

                                          Equally likely that Mozilla doesn’t want hegemony over Rust, and so doesn’t put a lot of effort into the things that don’t benefit them directly as much. Java and C# were both made by large companies that needed a standard written down so that a) they could coordinate large (bureaucratic) teams of people, and b) they could keep control over what the language included.

                                          There’s already one alternative Rust implementation: https://github.com/thepowersgang/mrustc . Afaik it’s partial, but complete enough to bootstrap rustc.

                                          1. 19

                                            (Yes, and…) Having worked not on but nearby the Microsoft JavaScript and C# teams I can tell you that in both cases the push for rapid standardization was to a significant degree a result of large-corporation politics. For JavaScript, Netscape wanted to control the language and Microsoft put on a crash effort to participate so it wouldn’t be a rubber stamp of whatever Netscape had. For C#, Microsoft wanted to avoid the appearance of a proprietary language, so introduced it with an open standards process to start with. In both cases somebody had to write a spec for a standards process to happen.

                                            BTW, the MS developers had some “hilarious” times trying to write the JavaScript spec. The only available definition was “what does Netscape do”, and pretty often when they tried to test the edge cases to refine the spec, Netscape crashed! Not helpful.

                                          2. 3

                                            i wonder if any other serious implementations even exist currently?

                                            There is mrustc, although I haven’t followed development of it lately, so I’m unsure of the exact roadmap.

                                            1. 2

                                              mrustc doesn’t do lifetime checking at all, which is notoriously unspecified how it exactly works (like: what must be accepted, what not?)

                                      2. 14

                                        This debate is Rust vs C. Rust had good design imitating strengths of various languages with a spec to come later. C was a slightly extended variant of B and BCPL, which was bare minimum of what compiled on an EDSAC. Unlike Wirth’s, it wasn’t designed for safety, fast compiles, or easy spec. Pascal/P was also more portable with folks putting it on 80 architectures in a few years. Even amateurs.

                                        Far as spec, we got a C semantics with undefined behavior decades after C since the “design” was so rough. I can’t recall if it covers absolutely everything yet. People started on safety and language specs on Rust within a few years of its release. So, Rust is literally moving decades faster than C on these issues. Im not sure it matters to most programmers since they’ll just use Rust compiler.

                                        C is still ahead, though, if combined with strict coding style and every tool we can throw at it. Most C coders don’t do that. Im sure the author isn’t given what he stated in article.

                                        EDIT: Post was a hurried one on my phone. Fixed organization a bit. Same content.

                                        1. 2

                                          C is still ahead, though, if combined with strict coding style and every tool we can throw at it. Most C coders don’t do that. Im sure the author isn’t given what he stated in article.

                                          This is something I’m always quite surprised by. I can’t get why some don’t even use the minimum of valgrind/the sanitizers that come with the compiler they use, also cppcheck, scan-build, and a bunch of other other free C++ tools work wonders with C as well.

                                    2. 26

                                      I’ll take entirely unsafe Rust over C any day, and that won’t change until C gets sum types and real modules. Maybe even actual arrays, as long as we’re wishing.

                                      1. 25

                                        I mostly agree with specifics, which boil down to “Rust is immature”. I disagree overall, because I believe Rust will be mature in the future. Rust will be portable, will have a spec, will have competing implementations, will have stable ABI (which will be better than C ABI), etc.

                                        I specifically object to “attempts to integrate Cargo with other build systems have been met with hostility from the Rust & Cargo teams”. I (and I believe other Rust & Cargo contributors) am painfully aware of the problem and we are trying hard to integrate with external build systems. Cargo’s so called “build plan” mode is already implemented, and I believe this problem will be solved by 2020.

                                        1. 3

                                          The point Drew is trying to make I think is still fair. You are using the future tense when you say Rust will have those things; the point is that it doesn’t have them now. Who knows maybe when they do Drew will change his mind.

                                        2. 56

                                          Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

                                          The pronouns in this sentence are wrong. It should read: “You’ll take my segfaults and buffer overflows.”

                                          1. 16

                                            I’m personally rooting for Zig. The goals of Zig seem more aligned with how I tend to approach programming languages. But that’s just a personal opinion.

                                            1. 7

                                              I am as well, and this part of the article seemed to stick out for me, when thinking about Zig:

                                              C is far from the perfect language - it has many flaws. However, its replacement will be simpler - not more complex.

                                              It stuck out to me, because @andrewrk had talked about this in one if his videos about comptime. He explicitly mentioned about how when thinking about Zig, he “removed the pre-processor from C” and instead used zig itself to handle comptime logic, and how it was actually a /simpler/ model than what C had, and by simplifying it, other nice things just kind of fell into place (generics? I think that was one he mentioned?). Very cool stuff.

                                            2. 13

                                              I disagree with most of this post, that said I think he brings up some good points, and I suspect that there’s a certain amount of truth in the statement that “Rust is not a language most people who are still C programmers will like”, because most of those developers who would like it have already moved to C++ or other languages.

                                              I’ll start with a few things I agree with - then a long list of things I disagree with. I’ve tried to avoid duplicating arguments already made in other comments.

                                              C is the most portable programming language.

                                              This is true, and is a deciding feature for the few people it applies to. It’s can also be a significant factor to people who it might apply to in the future, in terms of return on time invested in learning and building up a library of code.

                                              more importantly [the number of features added per year] speaks to their complexity. Over time it rapidly becomes difficult for one to keep an up-to-date mental map of Rust and how to solve your problems idiomatically.

                                              This is definitely a concern I have for Rust’s future, and C’s lack of features over even Rust’s current complexity is definitely a substantial upside.

                                              [The number of features added per year] speaks volumes to the stability of these languages

                                              I don’t think I agree, you could add a million features per year and as long as nothing broke it would be perfectly stable. In particular, the source looking outdated is not an “issue” that means it broke. It would be interesting to see a comparison of breaking changes per year in each - I suspect Rust beats C++ and is on par with C.

                                              No spec means there’s nothing keeping rustc honest. Any behavior it exhibits could change tomorrow.

                                              They have made some rather strong backwards compatibility guarantees, and while there is not an official spec there is documentation of every public API. This greatly exaggerates the degree to which rustc could change without breaking promises.

                                              C and C++ on the other hand have no problem with changing the spec with new versions. If anything rustc has more promises about backwards compatibility than C (or C++).

                                              Edit: By the same logic there would be nothing keeping the Linux userspace honest - but obviously there is.

                                              Serial programs have X problems, and parallel programs have X^Y problems, where Y is the amount of parallelism you introduce.

                                              Certainly the case in C, I think Rust challenges this assumption. In my experience parallelism in idiomatic rust introduces few problems, and it doesn’t scale much with the amount of parallelism you introduce past 0.

                                              However, nearly all programs needn’t be parallel.

                                              Depends on how you define both “nearly all” and “needn’t”. I posit that most programs weighted by time spent on development benefit substantially from some degree of parallelism (speeding up computation, running IO simultaneously to a user provided script, etc).

                                              rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would.

                                              This is a ridiculously high goalpost, Rust doesn’t have to replace C in existing programs to be a C replacement.

                                              1. 8

                                                “Rust is not a language most people who are still C programmers will like”, because most of those developers who would like it have already moved to C++ or other languages.

                                                I think this is not as true as you think it might be? C devs who did not already move to another language may very well like Rust.

                                                My personal experience is that many C devs I know seem generally keen on Rust because it solves real problems they have in C while still being usable in the spaces they care about (bare metal, embedded) and without much of the uncertainty and opacity that comes with C++ (virtual overloads, unexpected copy constructor calls, template shenanigans).

                                                Bryan Cantrill also gave a talk last year on this very topic - how he likes Rust as a long time C dev.

                                                1. 3

                                                  I think you are confusing stability and maturity. Rust is stable, but Rust is not mature (yet).

                                                  1. 3

                                                    Assuming you’re replying to the part of my comment in reply to

                                                    [The number of features added per year] speaks volumes to the stability of these languages

                                                    I think if you want to make that argument it’s sircmpwn who is confusing the two.

                                                    I’d add that I think “lack of maturity” isn’t a particularly good argument for “X is not a Y replacement”. To the extent maturity is required it can only happen with time. I don’t think the thesis being argued includes a “yet”.

                                                    1. 2

                                                      As you said, Rust didn’t have time to mature, so it is pretty much impossible for Rust to have maturity now. sircmpwn’s argument is different. According to sircmpwn, C++ had enough time to mature, but decided to remain forever immature, and in this respect, Rust is like C++. Since C is mature, Rust is not a good C replacement for those who value maturity.

                                                      My opinion is that Rust is unlike C++ in this respect and Rust will have maturity once enough time passes.

                                                2. 11

                                                  oof, hot takes time I guess…

                                                  C++ is a good C replacement :P

                                                  It’s the second most portable language, it has a spec, many implementations, a consistent ABI (if SysV counts, Itanium counts too :P), integrates with any build system, doesn’t encourage concurrency, and is a lot safer than C. (Yes, of course there are footguns, but just using std::string is a MASSIVE upgrade over just passing around raw pointers and hoping there’s a \0 somewhere close after that location lol.)

                                                  More seriously though, I am a big fan of Rust, but I picked C++ for a recent project because of

                                                  • portability (relatively recently there was a thread-local storage related bug in FreeBSD/aarch64 that prevented Rust from working — that’s been fixed, and Rust is absolutely not to blame here, but that episode contributed to the feeling that Rust is a bit less reliable when you want to run on less popular unix platforms)
                                                  • effortless C interop (calling bindgen’d bindings with unsafe everywhere doesn’t feel effortless even though there’s nothing hard or bad about it… also, like, trying to integrate e.g. gtk-rs and wayland-rs is just a bit less fun than doing the same with gtkmm and waylandpp)
                                                  • the usage of shared libraries (builds and executables feel a lot lighter when instead of cargo building your deps, your deps are already built and installed into the system globally)

                                                  and honestly, C++ doesn’t deserve the hate it’s been getting. Modern C++ is actually really really good and underrated. Come on, it’s the only language that both 1) has RAII and 2) is ubiquitous in the Unix world!

                                                  1. 10

                                                    honestly, what i took away from this is that rust has some language complexity so that your code can be simpler, and c has a (mostly) simple language that pushes a bunch of complexity into your code instead. i prefer the rust way, but there are certainly things to be said for both sides.

                                                    1. 9

                                                      I don’t think there are substantially more C compilers than rust ones. If you are not GCC, you are playing catch-up. Recently, clang seems to have caught up and overcome, and that brings us to two real contenders for building larger projects.

                                                      But toy compilers that build subsets of C well? Sure.

                                                      1. 4

                                                        There’s also MSVC.

                                                        1. 12

                                                          MSVC does not support the latest standards. In fact, it does not even fully support C99 yet:

                                                          https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance?view=vs-2017

                                                          1. 4

                                                            That’s most of why I ignore it. No big project needs to support being built by MSVC, though there are troopers like libgit2 that refuse to break C89 compatibility.

                                                            1. 4

                                                              I’d like to suggest that if your definition of a non-toy C compiler excludes MSVC then your definition is probably wrong.

                                                              This thread is an interesting comment on the “standardization” part of the article.

                                                              1. 3

                                                                I accept your critique, but argue that some compilers have fallen by the wayside. For example, whatever compiler Codewarrior used.

                                                            2. 2

                                                              And this is a problem for the C language.

                                                              MSVC is a pain to work with (especially for cross-platform projects), but due to Windows’ and Visual Studio’s popularity it’s hard to ignore.

                                                              Microsoft thinks the C language is dead, and won’t touch MSVC beyond the minimum required by C++ standards. Because of MSVC the C99 (20 years old!) is still a new, unproven novelty version.

                                                            3. 3

                                                              I don’t agree, there are lots of private C compilers in companies and elsewhere.

                                                              1. 3

                                                                This point is interesting from another perspective – a large number of C compilers would suggest it is not that hard to write a C compiler. True, some of them might be lacking recent features, but they do implement older standards (adhere to a spec). Could one say the same for Rust? Could this be a metric to judge a complexity of the language?

                                                                1. 2

                                                                  Yes, C is simple. Rust is very much not simple. In fact, Rust places very low value on simplicity as a design goal. Rust believes good solutions are often not simple. This is against somewhat common position that if the solution is not simple, it is not good.

                                                                  1. 5

                                                                    Standard C with implementation and undefined behaviors is not simple. There’s a lot to learn versus something like Pascal, Modula-2, or Simpl. That even experts slip corroborates it’s hard to keep in one’s head.

                                                                    1. 5

                                                                      I’m so glad someone else feels this way. C isn’t even close to simple when you count the literally hundreds of inplementation defined and undefined behaviors.

                                                                      1. 1

                                                                        Not just feel. I’m sure we could quantify it by comparing the semantics. Especially using something like K Framework since it’s (a) executable and (b) potentially concise by using rewriting approach. The C semantics paper said this:

                                                                        “Our C semantics defines 150 C syntactic operators. The defini-tions of these operators are given by 1,163 semantic rules spreadover 5,884 source lines of code (SLOC). However, it takes only77 of those rules (536SLOC) to cover the behavior of statements,and another 163 for expressions (748 SLOC). There are 505 rulesfor dealing with declarations and types, 115 rules for memory, and189 technical rules defining helper operators. Finally, there are 114rules for the core of our standard library. “

                                                                        I didn’t see numbers for the others at a quick glance. Just descriptions of the rules and such. Be interesting to do models of the languages I mentioned, Forth, SPARK Ada, PreScheme (C alternative), and Haskell. Maybe do Modula-3 instead of 2 since Pascal is already in there. I have a feeling Forth and PreScheme will come out simpler than C despite being able to do more with less code. SPARK Ada and Haskell results being interesting if nothing else. :)

                                                                        1. 1

                                                                          C is simple. I have seen a single person implement the whole standard in a few months of effort, and I’m not even talking about all the ‘mostly’ implemented toy compilers that also exist.

                                                                          1. 1

                                                                            I wonder what level of expertise they had as a programmer or compiler writer. In some languages I called simple, college students have been doing in limited time for a single course or one part of a course. Time usually goes up with what optimizations they want. Your example would further confirm how complex C was versus Forth, Oberon, and so on. Well, that plus the book worth of pages the standard takes to describe C versus 17 pages or so of Oberon-07 report. I imagine Forth or PreScheme wouldn’t take a lot either.

                                                              2. 8

                                                                The points marked in bold are mostly technically true, but the conclusions drawn from them are exaggerated, misleading or straight up trolling.

                                                                The author knows that “undefined behavior” in this context has a very specific meaning, which is not related to lack of a formal spec. Rust greatly limits scope where UB can happen. The compiler is remarkably stable and predictable, and there’s MIRI tool that can flag known UB in unsafe Rust code. That’s practically much more useful than memorizing edge cases from a 550-page-long C spec.

                                                                To use Rust 2018 you need to know less than to use Rust 2015. Just counting number of “feature” announcements ignores quality of the changes and the context they are in. It tries to sell stagnation as stability, and lack of simplifications as simplicity.

                                                                Rust doesn’t have a complex legacy that C++ has. It started with a simpler, more modern base, and has stronger checks that prevent misuse of features. The Rust team learns from C++‘s past (and OCaml’s and Haskell’s), and goes to great lengths to ensure language features are sound and orthogonal. “How do we teach this?” is part of every proposal, and most recent changes have been removals and simplifications.

                                                                The author also entirely misses the point of “fearless concurrency”. It projects real problems of shared mutable state, in languages that don’t control it, onto Rust, which from the ground up is designed to prevent this.

                                                                1. 7

                                                                  The first half of this article is the important bit. This really is a question of language design: philosophy, design goals, affordances, etc.

                                                                  Programming in Go feels like programming in a better C. Programming in Rust feels like programming in a better C++.

                                                                  The rest of the article seems like an attempt to rationalize this feeling, which is a sensible thing to do but - as others have pointed out - not all the rationalizations are really fair.

                                                                  The initial point remains though: we might want a memory-safe C but Rust is not it. Rust - in design and feel - is a memory-safe C++. Whether that bothers you or not depends on your view of C++.

                                                                  1. 13

                                                                    The initial point remains though: we might want a memory-safe C but Rust is not it. Rust - in design and feel - is a memory-safe C++. Whether that bothers you or not depends on your view of C++.

                                                                    I think Rust and C have more in common than Rust and C++.

                                                                    • Fundamentally, Rust is a struct oriented language where you define functions that take the struct as an argument - just like C. C++ is an object oriented language with inheritance trees, function overriding (runtime dispatch tables), etc. Traits in Rust make working with structs feel superficially like OO, but in reality it’s more like defining interface implementations for structures so you can use them interchangeably, which is actually very different from OO.
                                                                    • Neither Rust nor C have exceptions, where C++ does.
                                                                    • Reasoning about when structures are deallocated in Rust is more like C than C++ (both C and Rust have trivial memory management rules for developers, where C++ has relatively complex rules and norms about how and where to define destructors, and it is easy to screw up deallocation in C++).

                                                                    As someone who writes mostly C for a living the Rust model looks fairly straightforward, where the C++ model looks relatively complex. Rust is just structures and functions, where C++ is objects and templates and exceptions and abstract virtual base classes and other stuff that makes it non-obvious what’s actually happening when your code runs. To me, Rust feels like a memory and thread safe C (with interfaces), and less like a memory and thread safe C++.

                                                                    1. 2

                                                                      Rust is definitely preferable to C++. I haven’t programmed in Rust much but what I have done I have enjoyed. Sadly, I have programmed in C++ for a couple of decades, none of which I particularly enjoyed (although C++11 did make some things less painful).

                                                                      C++ programmers rarely use the whole language, not least because it is impossible for any one person to remember the whole language at once. People tend to find a subset of the language that they think they understand and stick to that. These days, I see mostly functional-style C++. I don’t see much use of inheritance or exceptions. The C++ that I have written and code reviewed in the last five years or so looks quite a lot like Rust.

                                                                      Rust does it better. It’s like a nice subset of C++ with better ergonomics. Its type system is more pleasant to use than C++ templates. Its support for functional programming is better. And, of course, it has RAII that really works because the compiler ensures that it is safe.

                                                                      I don’t know what the right term is: aesthetics? style? feel? mindset? Whatever it is, Rust shares it with C++. I don’t think it is an insult to say that it is C++ done right.

                                                                      I would contrast that with C. Some people may use C because they have to: they need something with manual memory management for example. But manual memory management is not a design goal for C. The core ethos of C, perhaps now diluted by standards bodies and compiler writers, is simplicity. It’s about having a small number of orthogonal building blocks from which bigger things can be made. I think that ethos has been passed on to Go.

                                                                    2. 11

                                                                      wat. How is golang in any way like a “better C”? I remember when it came out some touting it that way and I got excited… and then it just isn’t that at all IME. The GC alone disqualifies

                                                                      1. 2

                                                                        I agree. I’d express it as: C and Go value simplicity. C++ and Rust, they do not sacrifice simplicity for nothing, but they are eager to trade off simplicity with almost anything.

                                                                      2. 10

                                                                        Go is the result of C programmers designing a new programming language…

                                                                        Sure, Go is designed by some of the same people who initially created C. And in a naïve sense, they did mature to be similar-looking languages. But Go is so spartan in its design that there are certain classes of fundamental problems it’s just not remotely suitable for. This is even less excusable than it already was for C, considering how recent Go’s development was.

                                                                        Go really doesn’t solve many problems that weren’t already solved by C; it mainly simplifies the syntax and adds features for concurrency, which is nice but not quite worth the several decades that passed in between. It might be more accurate to say that Go is the result of C nostalgists designing a new programming language.

                                                                        Here, I’ll throw my hat into the ring. I made a pithy yet misdirected saying of my own:

                                                                        Haskell is better suited to imperative programming than Go is to generic programming.

                                                                        End of entirely tangential rant. Moving on…

                                                                        C is the most portable programming language.

                                                                        Have you tried compiling for different architectures? Hell, even JavaScript is more stable across platforms. Who knows when a given target was last verified to work with the latest GCC? Sure, it may compile to them, but it won’t be easy. Which brings me to the next point…

                                                                        C has a spec.

                                                                        More important than the language spec is the compiler spec. And the sheer complexity of C’s compiler virtually demolishes any advantage C had of being a simple language to use. This isn’t something that Rust’s free from either—it hasn’t learned the lesson it should’ve, and neither have most languages—but the blame for this goes directly to C. Go is more stable in this respect, although a cursory look at go tool compile’s manpage isn’t very promising compared to that for rustc.

                                                                        Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams.

                                                                        This situation is entirely new to me. Would anybody care to enlighten?

                                                                        Concurrency is generally a bad thing.

                                                                        Cry me a river. I’d take a kitchen sink language that actually lets me breathe over C any day of the week.

                                                                        Yes, Rust is more safe. I don’t really care. In light of all of these problems, I’ll take my segfaults and buffer overflows.

                                                                        That’s a luxury the rest of the world doesn’t have, my friend. I must agree that it’s upsetting to see performance thrown under the bus, but there are bigger fish to fry.

                                                                        1. 10

                                                                          Attempts to integrate it with other build systems have been met with hostility from the Rust & Cargo teams.

                                                                          This was proven false in the HN thread and @SirCmpwn recognized that it was false but refused to amend the article.

                                                                          1. 2

                                                                            I must say I find @SirCmpwn’s own hostility in the thread you linked rather ironic.

                                                                        2. 13

                                                                          Standard Forth is far more portable than standard C

                                                                          1. 1

                                                                            “Forth is far more portable”? That’s a big claim and I think it’s easily refuted. For instance Forth can’t target really tiny microcontrollers, but C can and regularly does. However I can’t think of any platform Forth can target that C can’t.

                                                                            For example you can’t run Forth on a PIC16F84A microcontroller - which has 68 bytes of RAM and 1.75KB of flash. C does. No Forth exists which works on a device this small (although there is one which can target the larger PIC16C series and the much larger PIC18+s).

                                                                            While it’s pretty old now the PIC16F84A was an incredibly popular microcontroller with many millions of them being sold over the years, so it’s not exactly an obscure device.

                                                                            1. 1

                                                                              I did regret adding “far” in what I said but for ANS core in general I think it holds.

                                                                              Sure you can’t run “a Forth” on the PIC, but you don’t really run “a ‘C’” on the PIC, you cross-compile for the PIC. You can write Forth-to-assembler cross-compilers relatively simply (see: avr, cmForth), I don’t see why writing one for the PIC16F84A would be harder than the equivalent C compiler… (in fact, there appears to be one for the PIC12/16 family PicoForth)

                                                                          2. 6

                                                                            One problem for C is that the terrible work of the Standards committee appears to have blocked anyone from advocating acual improvements. Some obvious improvements: optional type promotion, constants & inline plus anon function to replace macros, clear “volatile” semantics, optional checked arrays, clear type pun and effective type change semantics, limited UB options, improved file semantics (walled off). Trend of WG14 is to follow C++ rather than to simplify.

                                                                            1. 3

                                                                              Now that’s what I like to read: C experts telling us what they’d adopt in a replacement. Im bookmarking this. Anything else? And from anyone else that wants to join in who codes in C regularly?

                                                                              1. 4

                                                                                So some of the whole “why does nothing really happen with the standard” is that it is an ISO standard with all which that entails, and some very conflicting opinions on direction. Either de-facto fork it at this point (which is what practically happens with -std=gnu11 etc.) or grab the bull by its horn: get people from a bunch of small countries on board in the WG, 1 country 1 vote, and use that to deal with the brits..

                                                                                Personal wishlist:

                                                                                • controls for packing / unpacking structs between “for size/interoperability (no padding, endianness control)” vs. “for speed”
                                                                                • controlled weak-symbol like runtime allocator for VLAs
                                                                                • better allocator interface: force caller to specify alignment, terms of initialisation (bzero, …), terms of use (static data, user input, disallow in memory snapshots/core dumps, force clear on free, …), behaviour on OOM (fatal / non-fatal).
                                                                                • enum to string
                                                                                • get rid of locale defined behaviours (%f + LC_LANG is a harsh lesson in RADIX_POINT)
                                                                                • constexpr
                                                                                1. 3

                                                                                  I’d like the above. I’d also be happy if the C committee would drop support for non-2’s complement machines and allow signed integer overflow (remove it from UB). If you are concerned about overflow, then add new type qualifiers (say, __NoOverflow or __Trap or something) to catch overflow at runtime. Have a way to declare enums type distinct (enum foo decays to an int so it’s easy to mix enumerated values and cause bugs). Have a way to declare typedefed types distinct as well (such that passing an int to something expecting a typedef int foo will generate an error). And change a bare char declaration to be unsigned, instead of “implementation defined”—we are, after all, in a UTF-8 world these days.

                                                                                  On the standard library side of things: make a malloc() and realloc() that take an element size and number (like calloc() does) to avoid potential overflow with multiplication of unsigned values. Maybe include some optional directory like operations in addition to the standard file operations.

                                                                                  1. 3

                                                                                    that typedef chnsge is part of what I meant by optional type promotion: typedef int cm; typedef int inch; cm x; inch y; then x+y should be a syntax error. programmers should need to be specific x + 2.5*(int )y; or something. Enums should be distinct and not mixable as you suggest for the same reason.

                                                                                    1. 2

                                                                                      I might not have made myself clear, but I don’t think enums should be mixable either—I was describing their current behavior.

                                                                              2. 8

                                                                                I think a lot of this goes back to “Worse Is Better.”

                                                                                One question I imagine is “Would it be better if Emacs depended on Rust rather than C?” and I basically think the answer is “no.” The C compiler always works and it’s always there, and it’s usually really fast too.

                                                                                The framing of “Worse Is Better” is clever because it avoids claiming that C is actually good in some Platonic sense, indeed it was written by a kind of C opponent. C doesn’t win because it’s of such high quality—it wins because it’s a cockroach.

                                                                                1. 9

                                                                                  FWIW, there is a rewrite emacs in rust project. It’s taking an incrementalist approach: replacing C code piece-by-piece with equivalent Rust, using libraries where available, and being buildable (and usable) at all stages. The author is also committing fixes upstream when he finds errors in the C code (he keeps finding bugs).

                                                                                  That doesn’t answer your question, of course, but I’ll say: I use an emacs that requires Rust.

                                                                                  1. 5

                                                                                    he keeps finding bugs

                                                                                    As much as I’m rooting for Rust (Zig and Jai don’t offer a strict UB-free subset, so they’re not interesting to me), that’s not really an argument in favor of Rust. Any close reading of the source code will result in people finding such bugs, even if it was rewriting a Rust app into C, or, like in the case of Microsoft reverse-engineering Netscape, doing a black-box rewrite of a C++ app into another C++ app.

                                                                                    1. 3

                                                                                      I’d say that’s true unless we’re talking errors from the type system or borrow checker. Finding those would be a Rust benefit. I don’t know anything about that case study, though.

                                                                                      1. 2

                                                                                        Ah, sorry, I didn’t communicate that well. I was responding largely to the OP’s assertion:

                                                                                        rewriting an entire program from scratch is always going to introduce more bugs than maintaining the C program ever would

                                                                                        The process of maintaining emacs didn’t find those bugs. The process of rewriting has done so. Yes, I agree, that’s because the rewrite demands close audit of the code.

                                                                                    2. 5

                                                                                      One question I imagine is “Would it be better if Emacs depended on Rust rather than C?” and I basically think the answer is “no.” The C compiler always works and it’s always there, and it’s usually really fast too.

                                                                                      If Emacs was rewritten to truly use Rust rather than C, the Rust compiler would become ubiquitous very rapidly.

                                                                                      1. 2

                                                                                        I somehow think people would rather go back to the C Emacs!

                                                                                        1. 5

                                                                                          This is kind of a silly hypothetical anyway, but to play it out: if the Emacs project re-wrote the whole thing in Rust, you’re saying that people would rather fork the project than include rustc and cargo in their operating system distributions?

                                                                                          That seems… really far-fetched, to be honest. I mean, there’s already Rust packages in Debian…

                                                                                          1. 1

                                                                                            I really don’t know and I guess I don’t want to be the pessimist…

                                                                                            1. 1

                                                                                              That seems… really far-fetched, to be honest.

                                                                                              Not really. People made a hell of a lot of noise and forked distros just to prevent systemd.

                                                                                              1. 4

                                                                                                And yet calling systemd anything other than widespread would be foolish.

                                                                                      2. 6

                                                                                        I think talking about Rust immaturity is a bad faith argument. C early on was similarly lacking a spec and stability. The first C compilers were many and what would become the standard was only the most common practices. This gave a few of the C mistakes (some bad libc APIs, some incoherencies). This was mostly ironed out after 10-15 years.

                                                                                        However, the main criticism, and I think it is right and very important, is about the language philosophy. Yes, to experienced C programmers, Rust is like C++. It is feature-heavy, and it trades simplicity not for safety, but for syntax-sugar that no one maintaining a big codebase will care about, or even, will forbid for serious work.

                                                                                        The borrow-checker and lifetimes are core contributions that should definitely be a part of a C-like system language. However rust lost itself when so, so, so many features were added without having a clear scope.

                                                                                        It’s really disheartening, because Rust is such a beautiful attempt: the tooling is very good, the test front and center is right, a few core points are very well executed (Some/None, sum types, traits). Drop is really the only implicit things that should be allowed to happen behind the programmer’s eye. Every other eye-candy (that is mostly line-noise) should just be dropped, in favor of having more code implementing it, properly and safely.

                                                                                        Rust is well-positioned to take a good chunk of C++ problem-space, but not C.

                                                                                        1. 9

                                                                                          However rust lost itself when so, so, so many features were added without having a clear scope.

                                                                                          Could you give examples for features without a clear scope? Not that I necessarily disagree, but I think discussing in the abstract is not very useful.

                                                                                          1. 5

                                                                                            However, the main criticism, and I think it is right and very important, is about the language philosophy. Yes, to experienced C programmers, Rust is like C++. It is feature-heavy, and it trades simplicity not for safety, but for syntax-sugar that no one maintaining a big codebase will care about, or even, will forbid for serious work.

                                                                                            Hm, I’m not sure I agree. Syntactically (ignoring the syntax cleanup in 2018), the language does not gain anything without being usecase-driven. Syntax changes with no semantic gain are the cause of the biggest fights in our community (and usually don’t get through). But for example things lime impl Trait are sorely needed for efficient type erasure at compile time.

                                                                                            When talking about features, a lot of the work last year was around clarifying a lot of the life around main (e.g. the exact interface of the panic handler, etc.). While these are certainly language features, IMHO, its the fate of systems languages that want to handle all the details.

                                                                                            Every other eye-candy (that is mostly line-noise) should just be dropped, in favor of having more code implementing it, properly and safely.

                                                                                            As someone who writes async code using futures on a daily basis, I don’t agree with this. Especially as async/await for example is strictly more then syntactic sugar. It allows borrows across yield points and similar.

                                                                                            Finally, Rust was always been a language for constructing largeish systems, so I can certainly see that it puts people that just want to write 500 lines of code off.

                                                                                            1. 3

                                                                                              I really want C with ownership to be honest.

                                                                                              1. 1

                                                                                                What do you think about Clay (pdf)? It was a safe, C-like language that used linear and singleton types for temporal safety. I’d say next version should use whatever Rust is using since it works well enough. Anything good or bad about it jump out at you from a design point?

                                                                                            2. 3

                                                                                              Seems like the biggest (and only legitimate?) complaint is the lack of back-ends, but this can be fixed over time. Would the author come around if more were added?

                                                                                              1. 4

                                                                                                C: 0.73 new features per year, measured by the number of bullet points in the C11 article on Wikipedia which summarizes the changes from C99, adjusted to account for the fact that C18 introduced no new features.

                                                                                                adjusted to account for the fact that C18 introduced no new features.

                                                                                                And that is why I love C. Yes, it has its problems (of which there are many), but it’s a much smaller, bounded set of problems. The devil I know. Many other languages are so large, I couldn’t even know all of the devils if I tried.

                                                                                                1. 25

                                                                                                  The devil I know

                                                                                                  if the devil you know is an omnipotent being of unlimited power that generations of warriors have tried to fight and never succeeded because it’s just too powerful, then I would argue that it might be worth trying to chose a different evil to fight.

                                                                                                  Even in 2019 70% of security vulnerabilities are caused by memory-safety issues that would just not happen if the world wasn’t running on languages without memory-safety.

                                                                                                  1. 1

                                                                                                    I don’t think being memory safe is enough for a programming language to be a good C replacement.

                                                                                                    1. 18

                                                                                                      No. It’s not enough. But IMHO it’s required.

                                                                                                      1. 4

                                                                                                        … a requirement that C, incidentally, does not fulfil. Now that memory-safe low-level languages have swum into our ken, C is no longer a good C replacement. ;-)


                                                                                                        Edited to add a wink. I meant this no more seriously than pub talk – though I believe it has a kernel of truth, I phrased it that way mainly because it was fun to phrase it that way. There are many good reasons to use C, and and I also appreciate those. (And acknowledge that the joke does not acknowledge them.)

                                                                                                        1. 3

                                                                                                          that is my point.

                                                                                                          1. 2

                                                                                                            Hi, sorry, I spent a lot of time on my edit – everything below the line plus the smiley above it wasn’t there when you replied. Sorry to readers for making this look confusing.

                                                                                                            It is indeed your point, and I agree with it.

                                                                                                      2. 6

                                                                                                        Nobody is arguing that it’s sufficient, but it is necessary.

                                                                                                        If I were to develop a new language today, a language that was as unsafe as C but had lots of shiny new features like ADTs and a nice package manager and stuff, I’d never get traction. It would be ridiculous.

                                                                                                        1. 1

                                                                                                          I don’t know. PHP and C are still pretty popular. You just target those markets with selective enhancements of a language that fits their style closely. ;)

                                                                                                      3. 1

                                                                                                        Doesn’t web assembly allow unchanged C to be memory safe?

                                                                                                        1. 2

                                                                                                          Sort of, but not really. Unmanaged C isn’t allowed to escape the sandbox it’s assigned but there is still plenty of opportunities for undefined behavior. Process-level isolation in OSes provide similar guarantees. In the context of WebAssembly, even if the TLS stack were segregated into its own module it would do nothing to mitigate a Heartbleed-style vulnerability.

                                                                                                          1. 2

                                                                                                            There are other environments where the C standard is vague enough to allow for C to compile to a managed and safe environment. As the local AS/400 expert, C there compiles to managed bytecode, which is then compiled again by a trusted translator.

                                                                                                            1. 1

                                                                                                              I try to keep up with folks’ skills in case opportunities arise. Do you know both AS/400 and z/OS? Or just AS/400?

                                                                                                              Also interested in you elaborating on it making C safer.

                                                                                                              1. 3

                                                                                                                No, z is a separate thing I don’t know much about.

                                                                                                                Because C on AS/400 (or i, whatever IBM marketing calls it this week) is managed code, it does things like checking the validity of pointers to prevent things like buffer overflows. It does that by injecting hardware-enforced tagging. To prevent you from cheating it, the trusted translator is the only program allowed to generate native code. (AIX programs in the syscall emulator, however, can generate native code, but are then subject to normal Unix process boundaries and a kernel very paranoid about code running in a sandbox.) The tags are also used as capabilities to objects in the same address space, which it uses in place of a traditional filesystem.

                                                                                                                1. 1

                                                                                                                  Thanks. That makes sense except for one thing: hardware-enforced tagging. I thought System/38’s hardware enforcement was taken out with things just type- or runtime-checked or something at firmware/software level. That’s at least how some folks were talking. Do you have any references that show what hardware checking the current systems use?

                                                                                                                  1. 1

                                                                                                                    No, tags and capabilities are still there, contrary to rumours otherwise.

                                                                                                                    The tagging apparatus on modern systems are undocumented and as a result I know little about them, but it’s definitely in the CPU, from what I’ve heard.

                                                                                                                    1. 1

                                                                                                                      Ok. So, I guess I gotta press POWER CPU experts at some point to figure it out or just look at the ISA references. Least I know there wasn’t something obvious I overlooked.

                                                                                                                      EDIT: Just downloaded and searched the POWER ISA 3 PDF for capabilities and pointer to see what showed up. Nothing about this. They’re either wrong or it’s undocumented as they told you. If it’s still there, that’s a solid reason for building critical services on top of IBM i’s even if commodity stuff had same reliability. Security be higher. Still gotta harden them, of course.

                                                                                                        2. 1

                                                                                                          Sort of. It had a much larger set of problems than safe, system languages that compete with it. There’s less to know with them unless you choose to dance with the devil in a specific module. Some were more productive with faster debugging, too. So, it seems like C programmers force themselves to know and do more unnecessarily at least on language level.

                                                                                                          Now, pragmatically, the ecosystem is so large and mature that using or at least outputing C might make sense in a lot of projects.

                                                                                                        3. 4

                                                                                                          Well, our famous polemicist is at it again… Catchy title, too.

                                                                                                          the term “C/C++” infuriates me. They are completely different languages. Idiomatic C++ looks nothing like idiomatic C.

                                                                                                          A man after my own heart…

                                                                                                          1. 8

                                                                                                            Agreed. Remembering his last intellectual gem “Generics aren’t ready for Go” still makes me cringe.

                                                                                                          2. 2

                                                                                                            Except for the “Safety” section, which is devoid of rational thought, these are all important and valid criticisms of rust. The current limitations around Cargo and unstable compiler flags is particularly unfortunate, and I hope they will be resolved in the next few years, but rushing to stabilization is not the way to get there.

                                                                                                            Also, I’m amazed he left out “Compile Times”, which, in my personal opinion, is the biggest drawback of Rust vs C. I think that Rusts strengths more than make up for it, though. Especially algebraic data types, exhaustive pattern matching, ad-hoc polymorphism (traits), and the borrow checker. I do hope the compile times can be dramatically improved over the coming years, though. Introducing MIR optimizations has the potential to make a significant dent, as does adding a backend based on cranelift.

                                                                                                            1. 2

                                                                                                              Yes, Rust is more safe. I don’t really care.

                                                                                                              Close tab.

                                                                                                              1. 2

                                                                                                                Well, Rust is a much better C replacement than C++!

                                                                                                                It does not lure you into nonzero overhead abstractons all the time.

                                                                                                                1. 2

                                                                                                                  try #![no_std]

                                                                                                                  1. 2

                                                                                                                    After reading the article and all the comments I think I’ve realized why Drew maybe wrote this: other than hating Rust, that is. I have a feeling a ton of people have been asking him if he is going to start rewriting things in Rust and he’s getting really tired of it.

                                                                                                                    1. 1

                                                                                                                      I do think the Rust/C++ analogy is good. I don’t have massive hate for C++ (I think it makes a lot of sense as a language choice for those who want to do large systems programming and need strong abstraction tool), but using Rust reminds me a looooot or doing operations on C++ vectors with iterators and having a lot of method calls for stuff.

                                                                                                                      Rust has a lot more reasons for it and offers a lot of ways out. But yeah it’s pretty hard to write Rust as C without just dropping into unsafe mode. Rust is pretty performative

                                                                                                                      1. 1

                                                                                                                        No spec means there’s nothing keeping rustc honest.

                                                                                                                        On this topic, I found this to be interesting and informative: https://users.rust-lang.org/t/is-there-a-plan-to-get-a-formal-rust-language-specification-at-some-point/21622/8