7 ms·

I get the feeling it's because it's impossible to get away without using c for low level high performance stuff

saagarjha 6y ago
As Rust shows, it’s not really impossible from a technical standpoint in many areas. The issues are more to do with convention and legacy and familiarity, for the most part. (Technically, C does have a couple of advantages: it’s stable, familiar, and extremely well supported in most places, and has basically had the world revolve around it for a couple decades at least. But there are a number of domains where these are surmountable.)
- CameronNemo 6y ago
  C is also much better at dynamically linking, and results in much smaller binaries. Still not good justification for flatpak. Or crun (the reimplementation of runc in C) for that matter. The Red Hat crew has a problem with their reliance on C, Python, and Go. They need something like Rust (or even Vala, which does ARC from what I can tell) in their arsenal.
  - boccko 6y ago
    It's rather easy to dynamically link something that's not polymorphic.
  - eptcyka 6y ago
    What exactly is the issue with Rust and dynamic linking? Is it that it can't dynamically load Rust interfaces? There's nothing wrong with linking plain old symbols from shared objects in Rust.
    - adev_ 6y ago
      Rust has no stable ABI contrary to C and also support much higher concept like polymorphism or high order functions which are much harder to represent in a simple ABI. Real dynamic linking on that (dlopen-style) can be a real nightmare, specially between compiler versions. You can also add that Rust do not have a runtime, which is in many cases an advantage, but also tend to make libraries bigger.
      - Groxx 6y ago
        Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. Other fancy languages have stable ABIs, it's not impossible, nor does it require that it's complex to use. Though the average one is probably harder, yes. I'd wager that it's mostly lack of care or motivation though, made a bit worse by common language features.
        adev_ 6y ago
        > Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. C++ has a stable ABI. Fragile, but stable. Or doing things like updating libQt on your Linux distribution without recompiling half of the world would be close to impossible :)
        amaranth 6y ago
        This is a relatively new feature and there have been one or two ABI breaks since they thought it was done that required recompiling half the world. I think it's been solid for at least most of the last decade though so... stable enough? I'm not sure if there is an actual spec somewhere though, certainly not a proper one from a standards body. It's just "whatever GCC or MSVC do on that OS/CPU combo" and those two happen to have stopped changing the ABI every compiling release at some point. They're both at least based on the relatively well specified Itanium C++ ABI though so that helps.
        Groxx 6y ago
        C++ is also older than Rust by, oh... a few years. I'm not aware of any plan to not stabilize Rust's ABI, it just hasn't happened yet. It's completely fair to label that a deal-breaker for using Rust, but trying to draw a hypothetical box around it with the label "its ABI will be difficult to create and/or use" seems a bit unwarranted.
      - devit 6y ago
        Rust can create dynamic libraries that import and export symbols using the C ABI, so it is not worse than C in such a comparisons, since it can do exactly the same thing as C.
    - deleted 6y ago
      [deleted]
lmm 6y ago
It's not, people are just incapable of making realistic assessments of what level of performance they require. If you're using C or C++ "for performance" and not using a profiler in day-to-day development, you don't need to be using C or C++ and should be using a memory-safe language instead.
- throwaway17_17 6y ago
  I will agree in part, if you aren’t using C or C++ in performance critical software you probably could use another language. I think your profiler-every-day requirement is, maybe, a tiny bit too restrictive, but not by much. There is certainly a need for the industry (and hobbyists) to take stock of both what is necessary and what is just desired. I just don’t want to see the bar for using a language that doesn’t handle all aspects of memory usage and performance to be restricted to soft real-time applications and infrastructure projects. Digging into low level programming can be fun and rewarding. My problem is essentially that even if I am not absolutely concerned with maximum performance across memory usage, binary size, CPU efficiency, bandwidth, etc. I still truly enjoy the options for control (or the illusion of it) that is provided by C. I enjoy memory layout design, allocator design, cache-efficiency considerations and the like; while at the same time, I don’t have a huge love of malloc and free or having to track down segfaults. I think ‘performance-by-default’ is a viable language design goal and want more of it in my tools. I keep posting comments mentioning my pet language project, mostly in hopes that when I see it on my threads display I can continue to shame myself into getting it released on time, and this is one of those. These kinds of concerns motivated me to design a language for personal use that gives me what I want, but doesn’t require (but can) allow me to deal with other things. I enjoy using Coq, Haskell, Idris, Lisp, ATS, and Clean. But those language deprive me of things I really do enjoy. So I’m going for a low level language (in the Perlis sense) that has an experimental type theory. This will certainly allow for a memory safe subset and is the kind of thing I want to see more of from others.
- danielscrubs 6y ago
  "Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster. The adage is named after Niklaus Wirth, who discussed it in his 1995 article "A Plea for Lean Software".[1][2]" We could do better languages. But it just takes insane resources to compete with the others ecosystem. IDE's, the Pandas, the format on save. I've been a professional C++-developer in the past and one of the great things is the tooling and the just sheer knowledge of my past C++ colleagues. They know what happens in the kernel, they know the performance optimisation tricks, they know a lot, because the knowledge they gather just have a longer lifespan. Ask a JS-developer and they will tell you all the web frameworks that came before React and their quirks...

As Rust shows, it’s not really impossible from a technical standpoint in many areas. The issues are more to do with convention and legacy and familiarity, for the most part. (Technically, C does have a couple of advantages: it’s stable, familiar, and extremely well supported in most places, and has basically had the world revolve around it for a couple decades at least. But there are a number of domains where these are surmountable.)

CameronNemo 6y ago
C is also much better at dynamically linking, and results in much smaller binaries. Still not good justification for flatpak. Or crun (the reimplementation of runc in C) for that matter. The Red Hat crew has a problem with their reliance on C, Python, and Go. They need something like Rust (or even Vala, which does ARC from what I can tell) in their arsenal.
- boccko 6y ago
  It's rather easy to dynamically link something that's not polymorphic.
- eptcyka 6y ago
  What exactly is the issue with Rust and dynamic linking? Is it that it can't dynamically load Rust interfaces? There's nothing wrong with linking plain old symbols from shared objects in Rust.
  - adev_ 6y ago
    Rust has no stable ABI contrary to C and also support much higher concept like polymorphism or high order functions which are much harder to represent in a simple ABI. Real dynamic linking on that (dlopen-style) can be a real nightmare, specially between compiler versions. You can also add that Rust do not have a runtime, which is in many cases an advantage, but also tend to make libraries bigger.
    - Groxx 6y ago
      Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. Other fancy languages have stable ABIs, it's not impossible, nor does it require that it's complex to use. Though the average one is probably harder, yes. I'd wager that it's mostly lack of care or motivation though, made a bit worse by common language features.
      - adev_ 6y ago
        > Similar to C++ though, e.g. explosions of template expansions, you don't have to use those higher-level and harder-to-keep-concise features. C++ has a stable ABI. Fragile, but stable. Or doing things like updating libQt on your Linux distribution without recompiling half of the world would be close to impossible :)
        amaranth 6y ago
        This is a relatively new feature and there have been one or two ABI breaks since they thought it was done that required recompiling half the world. I think it's been solid for at least most of the last decade though so... stable enough? I'm not sure if there is an actual spec somewhere though, certainly not a proper one from a standards body. It's just "whatever GCC or MSVC do on that OS/CPU combo" and those two happen to have stopped changing the ABI every compiling release at some point. They're both at least based on the relatively well specified Itanium C++ ABI though so that helps.
        Groxx 6y ago
        C++ is also older than Rust by, oh... a few years. I'm not aware of any plan to not stabilize Rust's ABI, it just hasn't happened yet. It's completely fair to label that a deal-breaker for using Rust, but trying to draw a hypothetical box around it with the label "its ABI will be difficult to create and/or use" seems a bit unwarranted.
    - devit 6y ago
      Rust can create dynamic libraries that import and export symbols using the C ABI, so it is not worse than C in such a comparisons, since it can do exactly the same thing as C.
  - deleted 6y ago
    [deleted]

lmm 6y ago

It's not, people are just incapable of making realistic assessments of what level of performance they require. If you're using C or C++ "for performance" and not using a profiler in day-to-day development, you don't need to be using C or C++ and should be using a memory-safe language instead.

throwaway17_17 6y ago
I will agree in part, if you aren’t using C or C++ in performance critical software you probably could use another language. I think your profiler-every-day requirement is, maybe, a tiny bit too restrictive, but not by much. There is certainly a need for the industry (and hobbyists) to take stock of both what is necessary and what is just desired. I just don’t want to see the bar for using a language that doesn’t handle all aspects of memory usage and performance to be restricted to soft real-time applications and infrastructure projects. Digging into low level programming can be fun and rewarding. My problem is essentially that even if I am not absolutely concerned with maximum performance across memory usage, binary size, CPU efficiency, bandwidth, etc. I still truly enjoy the options for control (or the illusion of it) that is provided by C. I enjoy memory layout design, allocator design, cache-efficiency considerations and the like; while at the same time, I don’t have a huge love of malloc and free or having to track down segfaults. I think ‘performance-by-default’ is a viable language design goal and want more of it in my tools. I keep posting comments mentioning my pet language project, mostly in hopes that when I see it on my threads display I can continue to shame myself into getting it released on time, and this is one of those. These kinds of concerns motivated me to design a language for personal use that gives me what I want, but doesn’t require (but can) allow me to deal with other things. I enjoy using Coq, Haskell, Idris, Lisp, ATS, and Clean. But those language deprive me of things I really do enjoy. So I’m going for a low level language (in the Perlis sense) that has an experimental type theory. This will certainly allow for a memory safe subset and is the kind of thing I want to see more of from others.
danielscrubs 6y ago
"Wirth's law is an adage on computer performance which states that software is getting slower more rapidly than hardware is becoming faster. The adage is named after Niklaus Wirth, who discussed it in his 1995 article "A Plea for Lean Software".[1][2]" We could do better languages. But it just takes insane resources to compete with the others ecosystem. IDE's, the Pandas, the format on save. I've been a professional C++-developer in the past and one of the great things is the tooling and the just sheer knowledge of my past C++ colleagues. They know what happens in the kernel, they know the performance optimisation tricks, they know a lot, because the knowledge they gather just have a longer lifespan. Ask a JS-developer and they will tell you all the web frameworks that came before React and their quirks...