6 ms·

>Nobody would criticize assembly for letting you shoot yourself in the foot, C is much the same. But I bet they would criticize programs for being written in a

>Nobody would criticize assembly for letting you shoot yourself in the foot, C is much the same. But I bet they would criticize programs for being written in assembly, if they didn't need to be. If you could have a language with all the performance of C without the footguns, why wouldn't you want that?

chii 9y ago
> a language with all the performance of C without the footguns, why wouldn't you want that? I've yet to see a language that actually delivered on this claim.
- bluejekyll 9y ago
  Perhaps you aren’t looking? Rust delivers on all these claims. And there have been others before it. Rust hits all the sweet spots for me.
  - z3phyr 9y ago
    Rust is very sweet, but it lacks the simplicity of C. I get that ML style programming is all the rage today, and ML itself is a simple language, but programming languages today carry a lot of baggage and styles, maybe to cater to wide range of programmers. But in the end, it complicates the language. I have noticed that a lot of people find Rust or Scala to be very hard because of these reasons.
    - hsivonen 9y ago
      The simplicity of C relative to Rust is an illusion in the sense that the main thing that makes Rust feel difficult at first ("fighting the borrow checker") relates to a concern that's relevant to C (allocation lifetimes), but in the case of C the burden of dealing with the issue is on the programmer and not on the compiler.
    - Ygg2 9y ago
      > Rust is very sweet, but it lacks the simplicity of C. That's like saying a SawStop (http://www.sawstop.com/ http://www.sawstop.com/) lacks a simplicity of a sawblade. I mean - Yeah, sure, but sawblade also won't stop you from turning yourself into amputee. I understand Rust can be overly verbose, but main complexity comes from the borrow checker and the effect adding another kind of type, to track lifetimes. The lifetime system is the main selling point. There are other sources of complexity in Rust, but I am glad to say both Rust/Scala seem to be looking for a way to simplify things.
      - blub 9y ago
        Perhaps if the SawStop would complain about using certain types of wood after another, forced you to pick the wood from the pile in a certain order, etc. I bet woodworkers would be quite annoyed by that.
        junkcollector 9y ago
        This is in fact what the Sawstop does because if you use the wrong material it will engage and destroy your very expensive saw blades. This is one of the (many) reasons why SawStops aren't more popular and why they are in fact removable. So really, the sawstop is like Rust in that you can do what you want when it considers it dangerous by embedding c code, but it requires you to put in an annoying level of effort.
        deleted 9y ago
        [deleted]
  - zik 9y ago
    Rusty has a significantly higher cognitive load for programmers than C. I find it quicker to write reliable code in C than in Rust because I can write the C code and a comprehensive set of tests quicker than I could write just the Rust code with no tests.
    - steveklabnik 9y ago
      How much time have you spent with Rust? This kind of thing will obviously vary with the individual.
    - mannykannot 9y ago
      Testing does not perfectly substitute for verification, and vice-versa. In particular, comprehensive testing does not scale: at some point in the growth of your code, your testing will no longer be comprehensive, even if it started that way. On the other hand, no amount of static analysis will eliminate semantic errors (but neither will testing.)
    - naasking 9y ago
      > I find it quicker to write reliable code in C than in Rust because I can write the C code and a comprehensive set of tests quicker than I could write just the Rust code with no tests. Tests can't establish the absence of bugs the way Rust can. You only think your C code is reliable, you don't actually know that it's reliable. Rust only appears harder because of the latent bugs in your C program that you're not aware of.
    - dragonwriter 9y ago
      > Rusty has a significantly higher cognitive load for programmers than C. For simple cases, this may be true, for complex cases it but shifts the cognitive load up front. Which may be more frustrating, but also may prevent a large class of hard to identify, intermittent in manifestation, bugs from getting into production. Which also saves programmer frustration.
    - flukus 9y ago
      I've been doing the same lately, I don't know how it would scale to a bigger project but I've been enjoying it so far. I've been running the tests under valgrind as well which has found 1 or 2 issues a lot faster than debugging would. The best part of that is that valgrind shows me actual errors in actual running code whereas the rust compiler shows potential errors.
  - rbehrends 9y ago
    Rust sits in a really weird spot. It's too high-level for a lot of low-level work, and too low-level for a lot of high-level work. Example for the first case: Writing a garbage collector runtime in Rust has most of the same problems in Rust as in C, because you have to write most of it in unsafe code, where Rust inherits much of C's undefined behavior w.r.t. pointers via LLVM. In short, you have largely the same problems and have added a hard dependency on Rust. For high-level work, almost all [1] of what Rust gives you is memory safety and that comes at the price of dealing with a LOT of extra language complexity. But aside from dynamic memory management, memory safety isn't hard (we did that back in the 1970s and 1980s), and for dynamic memory management, we can get memory safety with a garbage collector and much less complexity. So Rust is primarily of interest for those use cases where garbage collection is not an option. While that still gives you plenty of interesting use cases for Rust, there are also plenty of programming niches that it serves poorly. [1] People will also mention "fearless concurrency", but guaranteeing the absence of data races is not hard. That more languages don't do it is partly because they simply neglected that aspect [2], but also because any mechanism – including Rust's – for doing so inherently constrains your options w.r.t. concurrency [3]. Plus, avoiding data races is the easy part of getting concurrency right. [3] Concurrent Pascal had guaranteed absence of data races in the absence of pointers in the 1970s, Eiffel had done it with pointers in the 1980s, and there was a plethora of research in the 1990s to do it in various other ways. [3] For example, there are plenty of use cases, such as certain idempotent operations, where data races are not only perfectly safe, but also desired for performance. There are also use cases where you can prove that no data races occur, but a type system cannot easily capture that.
    - nine_k 9y ago
      Your critique of Rust can be largely applied to C++. Maybe the latter is a niche language, but that niche was not served by many offerings up until recently, and C++ is still going strong, despite being less safe than Rust.
    - tdbgamer 9y ago
      It's too high-level for a lot of low-level work, and too low-level for a lot of high-level work. This is true in the very specific cases that you gave, but I believe that is the minority of use cases, not the majority. Even the example of writing a GC that requires tons of unsafe code, that is not a good argument for making all the code unsafe. All the unsafe GC code would be abstracted away into a module and would be more obvious to those looking at it that they will need to be watchful for undefined behavior. Now you can proceed writing the rest of the project in safe, simple Rust. People will also mention "fearless concurrency", but guaranteeing the absence of data races is not hard Maybe for developers that are very familiar with the race conditions of parallel code, but definitely not for most people. Even seasoned developers will make mistakes with simple multithreaded code. Also, the reasoning behind "x is easy so why do I need my language to check it for me" is questionable. The whole point is that you have a guarantee. Have you never had a compiler catch a stupid mistake before it happened and felt relieved? I doubt it. Now imagine if instead of debugging stupid data races in your parallel code you can spend that time optimizing and improving it. I fail to see how this can be viewed as negative. Sure Rust doesn't cover 100% of use cases, but it definitely covers more than you're implying. It's low-level enough that Redox OS can be written in Rust, but high-level enough that Firefox is now outpacing other browsers and parallelizing everything with Rust.
  - beefhash 9y ago
    Rust delivers on all these claims on a very limited set of platforms. The support for BSDs is abysmal, with only x86_64 NetBSD and i686/x86_64 FreeBSD even being "guaranteed to build", while OpenBSD, Windows XP and Solaris sit in some kind of state of hopelessness[1]. Rust is not a replacement for C in the sense of portability. People love simplifying the world into Windows/macOS/Linux, but that is not all you may want to target. [1] https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html
    - bluejekyll 9y ago
      What you point out can be fixed with time and resources. C has had 40 years to be ported to all of these other platforms. Rust has been realeased and stable for a little over 2.
    - staticassertion 9y ago
      "All of the performance of C without the footguns" Nowhere in this sentence do I see "for every platform C targets". Given no other requirement other than C without the footguns (memory unsafe) is there a good reason not to use the safe version? I'd say there are some, but they aren't crazy compelling (ie: developers have to learn rust, maybe harder to hire for, etc).
      - boomlinde 9y ago
        It's still a very realistic reason that someone would prefer C over Rust. Having to learn Rust, it being harder to hire for, etc. are really just as irrelevant to the named requirements, but important concerns nonetheless.
  - throwme211345 9y ago
    Rust is the ugliest, least palatable, alternative to C for me. Seems like they said "Let's chain function calls together like java(script) as the preferred expression and throw in lispy looking declarations and logic constructs. When people get frustrated with our safety paradigm there will always be unsafe..for experts."
    - luckydude 9y ago
      Yeah, I feel pretty much the same way. I get that there are a lot of sharp edges in C but I don't see why every attempt to do a new language wants to throw the baby out with the bathwater. Why not do a C dialect that fixes whatever it is that bugs people? There is value in the Rust language, why couldn't that value have been added to a C like language?
      - zurn 9y ago
        There have been attempts. Safe-C and Cyclone come to mind.
  - Const-me 9y ago
    > Rust delivers on all these claims No it doesn’t. One reason is rust doesn’t have SSE/AVX/Neon intrinsics. Without them, you can’t get anywhere near all the performance of C, nor anywhere near advertised performance of any modern CPU.
    - steveklabnik 9y ago
      Sometimes the compiler will autovectorize, but you're right that these are important. That's why it's actively being designed; it's a temporary limitation, not an inherent property.
- pjmlp 9y ago
  Pascal compilers up to the mid 90's, were as fast as C compilers.
- deleted 9y ago
  [deleted]
colechristensen 9y ago
I have serious doubts that anybody would actually create such a language. The basic problem with C is the ease in which you're allowed to shoot yourself in the foot or in other words the great pedantic lengths you have to go to in order to not do so. A language that avoided it would have to be very close to C while making it only mildly more difficult to foot shoot. Everyone who is trying is overshooting and therefore not really writing an adequate replacement low level systems language. Even if they did, it would be so close to C that adoption pickup would be low, awkward, and the language would fail outright. (Think Python 3 but worse) >But I bet they would criticize programs for being written in assembly, if they didn't need to be. Certainly. If you're writing your web app in assembly you are very likely a crazy person unless your goal is to do something ridiculous. If you're writing some assembly in a critical path in a web server to precisely control the network stack, you might not be a crazy person (see Netflix tech blogs).
- edmccard 9y ago
  >A language that avoided it would have to be very close to C while making it only mildly more difficult to foot shoot. Says who? A language where every single memory access did NOT have the potential to be a buffer overflow would be much more difficult to foot-shoot with, even if it allowed you to sometimes access memory with raw pointers. Just having the ability, as in Rust, to mark code as either safe or unsafe goes a long way towards preventing footguns. >Everyone who is trying is overshooting and therefore not really writing an adequate replacement low level systems language. Using Rust as an example again, I don't think there's anything about being able to say "this code right here cannot cause memory unsafety" that precludes "low-level systems" programming.
- cyphar 9y ago
  Rust delivers on many of the use-cases, so much so that there is a full operating system (kernel and userland) implemented in Rust called Redox[1]. I understand being critical of hype, but Rust is legitimately a very interesting and exciting language. [1]: https://www.redox-os.org/ https://www.redox-os.org/
- pjmlp 9y ago
  Ada, Modula-2, Mesa, PL/8, ESPOL, Object Pascal and many others come to mind.
mokus 9y ago
> a language with all the performance of C without the footguns IMO, this isn't even the right goal. The problem is that in many cases using C is itself a premature optimization. Consider two languages: * C, which gives you performance by default at the cost of an entire arsenal of footguns with esoteric nonlocal trigger conditions * Hypothetical language X, which has all the same footguns but engineered for safer triggering and locked up in a safe that you have to choose to open when you want C-like performance I'd rather have hypothetical language X (which is an accurate portrayal of many real existing languages), because it's got better failure modes. Performance issues are less impactful, in general, and more importantly they are more obvious. It is usually easy to tell when code is not fast enough. The endless parade of CVEs ultimately deriving from memory safety issues, often decades old, is living proof that misuse of the footguns is frequently far from obvious.

chii 9y ago

> a language with all the performance of C without the footguns, why wouldn't you want that? I've yet to see a language that actually delivered on this claim.

bluejekyll 9y ago
Perhaps you aren’t looking? Rust delivers on all these claims. And there have been others before it. Rust hits all the sweet spots for me.
- z3phyr 9y ago
  Rust is very sweet, but it lacks the simplicity of C. I get that ML style programming is all the rage today, and ML itself is a simple language, but programming languages today carry a lot of baggage and styles, maybe to cater to wide range of programmers. But in the end, it complicates the language. I have noticed that a lot of people find Rust or Scala to be very hard because of these reasons.
  - hsivonen 9y ago
    The simplicity of C relative to Rust is an illusion in the sense that the main thing that makes Rust feel difficult at first ("fighting the borrow checker") relates to a concern that's relevant to C (allocation lifetimes), but in the case of C the burden of dealing with the issue is on the programmer and not on the compiler.
  - Ygg2 9y ago
    > Rust is very sweet, but it lacks the simplicity of C. That's like saying a SawStop (http://www.sawstop.com/ http://www.sawstop.com/) lacks a simplicity of a sawblade. I mean - Yeah, sure, but sawblade also won't stop you from turning yourself into amputee. I understand Rust can be overly verbose, but main complexity comes from the borrow checker and the effect adding another kind of type, to track lifetimes. The lifetime system is the main selling point. There are other sources of complexity in Rust, but I am glad to say both Rust/Scala seem to be looking for a way to simplify things.
    - blub 9y ago
      Perhaps if the SawStop would complain about using certain types of wood after another, forced you to pick the wood from the pile in a certain order, etc. I bet woodworkers would be quite annoyed by that.
      - junkcollector 9y ago
        This is in fact what the Sawstop does because if you use the wrong material it will engage and destroy your very expensive saw blades. This is one of the (many) reasons why SawStops aren't more popular and why they are in fact removable. So really, the sawstop is like Rust in that you can do what you want when it considers it dangerous by embedding c code, but it requires you to put in an annoying level of effort.
      - deleted 9y ago
        [deleted]
- zik 9y ago
  Rusty has a significantly higher cognitive load for programmers than C. I find it quicker to write reliable code in C than in Rust because I can write the C code and a comprehensive set of tests quicker than I could write just the Rust code with no tests.
  - steveklabnik 9y ago
    How much time have you spent with Rust? This kind of thing will obviously vary with the individual.
  - mannykannot 9y ago
    Testing does not perfectly substitute for verification, and vice-versa. In particular, comprehensive testing does not scale: at some point in the growth of your code, your testing will no longer be comprehensive, even if it started that way. On the other hand, no amount of static analysis will eliminate semantic errors (but neither will testing.)
  - naasking 9y ago
    > I find it quicker to write reliable code in C than in Rust because I can write the C code and a comprehensive set of tests quicker than I could write just the Rust code with no tests. Tests can't establish the absence of bugs the way Rust can. You only think your C code is reliable, you don't actually know that it's reliable. Rust only appears harder because of the latent bugs in your C program that you're not aware of.
  - dragonwriter 9y ago
    > Rusty has a significantly higher cognitive load for programmers than C. For simple cases, this may be true, for complex cases it but shifts the cognitive load up front. Which may be more frustrating, but also may prevent a large class of hard to identify, intermittent in manifestation, bugs from getting into production. Which also saves programmer frustration.
  - flukus 9y ago
    I've been doing the same lately, I don't know how it would scale to a bigger project but I've been enjoying it so far. I've been running the tests under valgrind as well which has found 1 or 2 issues a lot faster than debugging would. The best part of that is that valgrind shows me actual errors in actual running code whereas the rust compiler shows potential errors.
- rbehrends 9y ago
  Rust sits in a really weird spot. It's too high-level for a lot of low-level work, and too low-level for a lot of high-level work. Example for the first case: Writing a garbage collector runtime in Rust has most of the same problems in Rust as in C, because you have to write most of it in unsafe code, where Rust inherits much of C's undefined behavior w.r.t. pointers via LLVM. In short, you have largely the same problems and have added a hard dependency on Rust. For high-level work, almost all [1] of what Rust gives you is memory safety and that comes at the price of dealing with a LOT of extra language complexity. But aside from dynamic memory management, memory safety isn't hard (we did that back in the 1970s and 1980s), and for dynamic memory management, we can get memory safety with a garbage collector and much less complexity. So Rust is primarily of interest for those use cases where garbage collection is not an option. While that still gives you plenty of interesting use cases for Rust, there are also plenty of programming niches that it serves poorly. [1] People will also mention "fearless concurrency", but guaranteeing the absence of data races is not hard. That more languages don't do it is partly because they simply neglected that aspect [2], but also because any mechanism – including Rust's – for doing so inherently constrains your options w.r.t. concurrency [3]. Plus, avoiding data races is the easy part of getting concurrency right. [3] Concurrent Pascal had guaranteed absence of data races in the absence of pointers in the 1970s, Eiffel had done it with pointers in the 1980s, and there was a plethora of research in the 1990s to do it in various other ways. [3] For example, there are plenty of use cases, such as certain idempotent operations, where data races are not only perfectly safe, but also desired for performance. There are also use cases where you can prove that no data races occur, but a type system cannot easily capture that.
  - nine_k 9y ago
    Your critique of Rust can be largely applied to C++. Maybe the latter is a niche language, but that niche was not served by many offerings up until recently, and C++ is still going strong, despite being less safe than Rust.
  - tdbgamer 9y ago
    It's too high-level for a lot of low-level work, and too low-level for a lot of high-level work. This is true in the very specific cases that you gave, but I believe that is the minority of use cases, not the majority. Even the example of writing a GC that requires tons of unsafe code, that is not a good argument for making all the code unsafe. All the unsafe GC code would be abstracted away into a module and would be more obvious to those looking at it that they will need to be watchful for undefined behavior. Now you can proceed writing the rest of the project in safe, simple Rust. People will also mention "fearless concurrency", but guaranteeing the absence of data races is not hard Maybe for developers that are very familiar with the race conditions of parallel code, but definitely not for most people. Even seasoned developers will make mistakes with simple multithreaded code. Also, the reasoning behind "x is easy so why do I need my language to check it for me" is questionable. The whole point is that you have a guarantee. Have you never had a compiler catch a stupid mistake before it happened and felt relieved? I doubt it. Now imagine if instead of debugging stupid data races in your parallel code you can spend that time optimizing and improving it. I fail to see how this can be viewed as negative. Sure Rust doesn't cover 100% of use cases, but it definitely covers more than you're implying. It's low-level enough that Redox OS can be written in Rust, but high-level enough that Firefox is now outpacing other browsers and parallelizing everything with Rust.
- beefhash 9y ago
  Rust delivers on all these claims on a very limited set of platforms. The support for BSDs is abysmal, with only x86_64 NetBSD and i686/x86_64 FreeBSD even being "guaranteed to build", while OpenBSD, Windows XP and Solaris sit in some kind of state of hopelessness[1]. Rust is not a replacement for C in the sense of portability. People love simplifying the world into Windows/macOS/Linux, but that is not all you may want to target. [1] https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html
  - bluejekyll 9y ago
    What you point out can be fixed with time and resources. C has had 40 years to be ported to all of these other platforms. Rust has been realeased and stable for a little over 2.
  - staticassertion 9y ago
    "All of the performance of C without the footguns" Nowhere in this sentence do I see "for every platform C targets". Given no other requirement other than C without the footguns (memory unsafe) is there a good reason not to use the safe version? I'd say there are some, but they aren't crazy compelling (ie: developers have to learn rust, maybe harder to hire for, etc).
    - boomlinde 9y ago
      It's still a very realistic reason that someone would prefer C over Rust. Having to learn Rust, it being harder to hire for, etc. are really just as irrelevant to the named requirements, but important concerns nonetheless.
- throwme211345 9y ago
  Rust is the ugliest, least palatable, alternative to C for me. Seems like they said "Let's chain function calls together like java(script) as the preferred expression and throw in lispy looking declarations and logic constructs. When people get frustrated with our safety paradigm there will always be unsafe..for experts."
  - luckydude 9y ago
    Yeah, I feel pretty much the same way. I get that there are a lot of sharp edges in C but I don't see why every attempt to do a new language wants to throw the baby out with the bathwater. Why not do a C dialect that fixes whatever it is that bugs people? There is value in the Rust language, why couldn't that value have been added to a C like language?
    - zurn 9y ago
      There have been attempts. Safe-C and Cyclone come to mind.
- Const-me 9y ago
  > Rust delivers on all these claims No it doesn’t. One reason is rust doesn’t have SSE/AVX/Neon intrinsics. Without them, you can’t get anywhere near all the performance of C, nor anywhere near advertised performance of any modern CPU.
  - steveklabnik 9y ago
    Sometimes the compiler will autovectorize, but you're right that these are important. That's why it's actively being designed; it's a temporary limitation, not an inherent property.
pjmlp 9y ago
Pascal compilers up to the mid 90's, were as fast as C compilers.
deleted 9y ago
[deleted]

colechristensen 9y ago

I have serious doubts that anybody would actually create such a language. The basic problem with C is the ease in which you're allowed to shoot yourself in the foot or in other words the great pedantic lengths you have to go to in order to not do so. A language that avoided it would have to be very close to C while making it only mildly more difficult to foot shoot. Everyone who is trying is overshooting and therefore not really writing an adequate replacement low level systems language. Even if they did, it would be so close to C that adoption pickup would be low, awkward, and the language would fail outright. (Think Python 3 but worse) >But I bet they would criticize programs for being written in assembly, if they didn't need to be. Certainly. If you're writing your web app in assembly you are very likely a crazy person unless your goal is to do something ridiculous. If you're writing some assembly in a critical path in a web server to precisely control the network stack, you might not be a crazy person (see Netflix tech blogs).

edmccard 9y ago
>A language that avoided it would have to be very close to C while making it only mildly more difficult to foot shoot. Says who? A language where every single memory access did NOT have the potential to be a buffer overflow would be much more difficult to foot-shoot with, even if it allowed you to sometimes access memory with raw pointers. Just having the ability, as in Rust, to mark code as either safe or unsafe goes a long way towards preventing footguns. >Everyone who is trying is overshooting and therefore not really writing an adequate replacement low level systems language. Using Rust as an example again, I don't think there's anything about being able to say "this code right here cannot cause memory unsafety" that precludes "low-level systems" programming.
cyphar 9y ago
Rust delivers on many of the use-cases, so much so that there is a full operating system (kernel and userland) implemented in Rust called Redox[1]. I understand being critical of hype, but Rust is legitimately a very interesting and exciting language. [1]: https://www.redox-os.org/ https://www.redox-os.org/
pjmlp 9y ago
Ada, Modula-2, Mesa, PL/8, ESPOL, Object Pascal and many others come to mind.

mokus 9y ago

> a language with all the performance of C without the footguns IMO, this isn't even the right goal. The problem is that in many cases using C is itself a premature optimization. Consider two languages: * C, which gives you performance by default at the cost of an entire arsenal of footguns with esoteric nonlocal trigger conditions * Hypothetical language X, which has all the same footguns but engineered for safer triggering and locked up in a safe that you have to choose to open when you want C-like performance I'd rather have hypothetical language X (which is an accurate portrayal of many real existing languages), because it's got better failure modes. Performance issues are less impactful, in general, and more importantly they are more obvious. It is usually easy to tell when code is not fast enough. The endless parade of CVEs ultimately deriving from memory safety issues, often decades old, is living proof that misuse of the footguns is frequently far from obvious.