6 ms·

As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix syst

As a systems programmer, Rust has won. It will take decades before there is substantial Rust replacing the absurd amounts of C that runs on any modern Unix system, but I do believe that our of all the replacements for C/C++, Rust has finally gained the traction most of them have lacked at the large companies that put resources behind these types of rewrites and exploratory projects. I do not think Zig will see wide adoption, but obviously if you enjoy writing it and can make a popular project, more power to you.

chrisco255 2y ago
Rust has very real limitations and trade-offs. It compiles slow and the binaries are large. The compiler also makes performance sacrifices that makes it generally slower than C. I'm sure the language will continue to be successful, but it hasn't "won".
- pkulak 2y ago
  Why do you say slower than C? I’ve never seen a reason to believe they’re anything but roughly equivalent.
  - Defletter 2y ago
    The last I heard, Rust had issues with freeing memory when it wouldn't need to, particularly with short-lived processes (like terminal programs) where the the Rust program would be freeing everything while the C version would just exit out and let the operating system do cleanup.
    - asa400 2y ago
      Rust has ManuallyDrop, which is exactly the functionality you’re describing. It works just fine for those types of programs. The speed of the two is going to be largely dependent on the amount of effort that has gone into optimizing either one, not on some theoretical performance bound. They’re both basically the same there. There are tons of examples of this in the wild at this point.
      - zozbot234 2y ago
        ManuallyDrop seems overkill when you have Box::leak().
        edflsafoiewq 2y ago
        You may also be able to simply exit() before your allocations get dropped.
  - Narew 2y ago
    From my experience on C++ vs Rust on test algorithm. For a naive algorithm implementation rust is usually slightly faster than C++. But when you try to optimise stuff, it's the opposite. It's really hard to optimise Rust code, you need to put lots of unsafe and unsafe is not user-friendly. Rust also force you on some design that are not always good for performance.
- jicea 2y ago
  I maintain a Rust project that is ~50,000 loc [1]. I've never felt that compiling is slow, in the contrary it's always a pleasure to see how fast the project compiles (at least in debug). In release, build time is longer but in this case, it's in the CI/CD so it doesn't bother me. We try to be very conservative with adding dependencies so it may help compilation time. Also I'm coming from a Java/Kotlin world so a lot of things appear like fresh air in comparison... [1]: https://github.com/Orange-OpenSource/hurl https://github.com/Orange-OpenSource/hurl
tapirl 2y ago
Zig might not become very popular, but IMO, it will become more popular than Rust. Zig is good at all the areas Rust is good at. Zig is also good at game development which Rust is not good at. And Zig is better when integrating with C/C++ libraries.
- Defletter 2y ago
  > but IMO, it will become more popular than Rust While I wish this were true, I very much doubt it, at least not until Zig has proper interfaces and gives up its weird hangup on anonymous functions. It's also extremely easy to effectively lose access to Zig features without cluttering your code. For example, say you want to use libevent in Zig: your event callbacks must use C calling conventions, meaning you lose access to try and errdefer, which are two of the most defining features of Zig. And while you can remedy this by having the callback invoke a Zig function, doing that just doubles every interaction between your Zig code and libevent, which is already cluttered because of the lack of anonymous functions. These things aren't as important as compile times, but they are annoyances that will drive a non-zero amount of people away.
  - tapirl 2y ago
    It seems you are proving Zig will not become very popular, but not Zig will not become more popular than Rust. I agree that Zig will not become very popular. It needs certain programming experiences to master it. But I'm quite sure it will become more popular than Rust.
    - littlestymaar 2y ago
      There's a contradiction though, as Rust is already popular…
- pcwalton 2y ago
  > Zig is good at all the areas Rust is good at. Not memory safety. > Zig is also good at game development which Rust is not good at. Let's see. Over just the past year in Bevy I've implemented GPU driven rendering, two-phase GPU occlusion culling, specular tints and maps, clustered decals, multi-draw, bindless textures, mixed lighting, bindless lightmaps, glXF support, skinned mesh batching, light probe clustering, visibility ranges with dithering, percentage-closer soft shadows, additive animation blending, generalized animation, animation masks, offset allocation, volumetric fog, the postprocessing infrastructure, chromatic aberration, SMAA, PBR anisotropy, skinned motion vectors, screen-space reflections, depth of field, clearcoat, filmic color grading, GPU frustum culling, alpha-to-coverage, percentage-closer filtering, animation graphs, and irradiance volumes. In addition to extremely rapid general engine progress, there have also successful titles, such as Tiny Glade. Whether Rust can be a productive language for game development was an interesting question a few years ago. At this point the answer is fairly clear.
anacrolix 2y ago
I agree. It's not ideal but Rust is a genuine improvement across the board on C and C++. It has the inertia and will slowly infiltrate and replace those 2. It also has the rare capacity to add some new areas without detracting from the mainstay: It's actually good as an embedded language for the web and as a DSL. C/C++ definitely didn't have that.
- zozbot234 2y ago
  Safe C++ could still be a genuine improvement on Rust - if only because the community would be larger by at least one order of magnitude compared to present-day Rust. Though you would also need a viable C++ epochs proposal to keep the complexity from becoming totally unmanageable.
  - pcwalton 2y ago
    I'm not convinced, actually. The problem is that every proposal for safe C++ that I've seen sacrifices compatibility with the broader C++ ecosystem. Yes, you could graft borrow checking onto a C++-like semantics, but what you would end up creating is an incompatible dialect of C++--essentially a new language. So the resulting ecosystem would actually be smaller than that of Rust.
    - zozbot234 2y ago
      I think this issue is a bit overstated. What people want is not to have interop with existing C++ code, but to just keep writing C++ in the same idiomatic style. And this just isn't feasible if you want to automatically ensure memory safety. It's especially problematic in larger codebases that can't be comprehensively surveyed, which is what people mostly want to use C++ for. So, something has to give. Rust is a bit of a different story, because the clunkiness of Pin<> actually makes interop with C++ (and, to a lesser extent, C) surprisingly difficult in a way that might be amenable to improvement.
hitekker 2y ago
A big company I worked at actually deprecated the last of its Rust code last year. Maintaining Rust was much more expensive than predicted, and hiring and/or mentoring Rust Engineers proved even more expensive. A simpler performant language like Zig, or a boring language + a different architecture would have been the better choice.
- tasuki 2y ago
  > A big company I worked at actually deprecated the last of its Rust code last year. What replaced Rust?
  - hitekker 2y ago
    A newer JVM language, which admittedly came with its own share of problems.
- __float 2y ago
  Is Zig really a simpler language? It has a ton of features!
  - scubbo 2y ago
    "Simple language" is often used as shorthand for "a language in which it is simple to express ideas", rather than "a language with few features". A language can, in fact, have many features and still be simple(-to-write-in); or, like Go, it can have so few features that it is complex-to-write-in.
baranul 2y ago
Many, after doing a review of Rust, say they don't like or will stop using it. It's very premature to declare it has "won", whatever that can be said to mean. Example, ThePrimeTime[1] (famous YouTube programmer) is another stating he does not like Rust anymore, and rather use some other language. It appears part of the controversy surrounding Rust, is that many are of the opinion that it's not worth it because of the limited use case, poor readability, complexity, long compile times, etc... and that appears to be what certain advocates of Rust are not understanding or appreciating the difference in opinions. Rust is fine for them, specifically, but not for everyone. [1]: https://www.youtube.com/watch?v=1Di8X2vRNRE https://www.youtube.com/watch?v=1Di8X2vRNRE

chrisco255 2y ago

Rust has very real limitations and trade-offs. It compiles slow and the binaries are large. The compiler also makes performance sacrifices that makes it generally slower than C. I'm sure the language will continue to be successful, but it hasn't "won".

pkulak 2y ago
Why do you say slower than C? I’ve never seen a reason to believe they’re anything but roughly equivalent.
- Defletter 2y ago
  The last I heard, Rust had issues with freeing memory when it wouldn't need to, particularly with short-lived processes (like terminal programs) where the the Rust program would be freeing everything while the C version would just exit out and let the operating system do cleanup.
  - asa400 2y ago
    Rust has ManuallyDrop, which is exactly the functionality you’re describing. It works just fine for those types of programs. The speed of the two is going to be largely dependent on the amount of effort that has gone into optimizing either one, not on some theoretical performance bound. They’re both basically the same there. There are tons of examples of this in the wild at this point.
    - zozbot234 2y ago
      ManuallyDrop seems overkill when you have Box::leak().
      - edflsafoiewq 2y ago
        You may also be able to simply exit() before your allocations get dropped.
- Narew 2y ago
  From my experience on C++ vs Rust on test algorithm. For a naive algorithm implementation rust is usually slightly faster than C++. But when you try to optimise stuff, it's the opposite. It's really hard to optimise Rust code, you need to put lots of unsafe and unsafe is not user-friendly. Rust also force you on some design that are not always good for performance.
jicea 2y ago
I maintain a Rust project that is ~50,000 loc [1]. I've never felt that compiling is slow, in the contrary it's always a pleasure to see how fast the project compiles (at least in debug). In release, build time is longer but in this case, it's in the CI/CD so it doesn't bother me. We try to be very conservative with adding dependencies so it may help compilation time. Also I'm coming from a Java/Kotlin world so a lot of things appear like fresh air in comparison... [1]: https://github.com/Orange-OpenSource/hurl https://github.com/Orange-OpenSource/hurl

tapirl 2y ago

Zig might not become very popular, but IMO, it will become more popular than Rust. Zig is good at all the areas Rust is good at. Zig is also good at game development which Rust is not good at. And Zig is better when integrating with C/C++ libraries.

Defletter 2y ago
> but IMO, it will become more popular than Rust While I wish this were true, I very much doubt it, at least not until Zig has proper interfaces and gives up its weird hangup on anonymous functions. It's also extremely easy to effectively lose access to Zig features without cluttering your code. For example, say you want to use libevent in Zig: your event callbacks must use C calling conventions, meaning you lose access to try and errdefer, which are two of the most defining features of Zig. And while you can remedy this by having the callback invoke a Zig function, doing that just doubles every interaction between your Zig code and libevent, which is already cluttered because of the lack of anonymous functions. These things aren't as important as compile times, but they are annoyances that will drive a non-zero amount of people away.
- tapirl 2y ago
  It seems you are proving Zig will not become very popular, but not Zig will not become more popular than Rust. I agree that Zig will not become very popular. It needs certain programming experiences to master it. But I'm quite sure it will become more popular than Rust.
  - littlestymaar 2y ago
    There's a contradiction though, as Rust is already popular…
pcwalton 2y ago
> Zig is good at all the areas Rust is good at. Not memory safety. > Zig is also good at game development which Rust is not good at. Let's see. Over just the past year in Bevy I've implemented GPU driven rendering, two-phase GPU occlusion culling, specular tints and maps, clustered decals, multi-draw, bindless textures, mixed lighting, bindless lightmaps, glXF support, skinned mesh batching, light probe clustering, visibility ranges with dithering, percentage-closer soft shadows, additive animation blending, generalized animation, animation masks, offset allocation, volumetric fog, the postprocessing infrastructure, chromatic aberration, SMAA, PBR anisotropy, skinned motion vectors, screen-space reflections, depth of field, clearcoat, filmic color grading, GPU frustum culling, alpha-to-coverage, percentage-closer filtering, animation graphs, and irradiance volumes. In addition to extremely rapid general engine progress, there have also successful titles, such as Tiny Glade. Whether Rust can be a productive language for game development was an interesting question a few years ago. At this point the answer is fairly clear.

anacrolix 2y ago

I agree. It's not ideal but Rust is a genuine improvement across the board on C and C++. It has the inertia and will slowly infiltrate and replace those 2. It also has the rare capacity to add some new areas without detracting from the mainstay: It's actually good as an embedded language for the web and as a DSL. C/C++ definitely didn't have that.

zozbot234 2y ago
Safe C++ could still be a genuine improvement on Rust - if only because the community would be larger by at least one order of magnitude compared to present-day Rust. Though you would also need a viable C++ epochs proposal to keep the complexity from becoming totally unmanageable.
- pcwalton 2y ago
  I'm not convinced, actually. The problem is that every proposal for safe C++ that I've seen sacrifices compatibility with the broader C++ ecosystem. Yes, you could graft borrow checking onto a C++-like semantics, but what you would end up creating is an incompatible dialect of C++--essentially a new language. So the resulting ecosystem would actually be smaller than that of Rust.
  - zozbot234 2y ago
    I think this issue is a bit overstated. What people want is not to have interop with existing C++ code, but to just keep writing C++ in the same idiomatic style. And this just isn't feasible if you want to automatically ensure memory safety. It's especially problematic in larger codebases that can't be comprehensively surveyed, which is what people mostly want to use C++ for. So, something has to give. Rust is a bit of a different story, because the clunkiness of Pin<> actually makes interop with C++ (and, to a lesser extent, C) surprisingly difficult in a way that might be amenable to improvement.

hitekker 2y ago

A big company I worked at actually deprecated the last of its Rust code last year. Maintaining Rust was much more expensive than predicted, and hiring and/or mentoring Rust Engineers proved even more expensive. A simpler performant language like Zig, or a boring language + a different architecture would have been the better choice.

tasuki 2y ago
> A big company I worked at actually deprecated the last of its Rust code last year. What replaced Rust?
- hitekker 2y ago
  A newer JVM language, which admittedly came with its own share of problems.
__float 2y ago
Is Zig really a simpler language? It has a ton of features!
- scubbo 2y ago
  "Simple language" is often used as shorthand for "a language in which it is simple to express ideas", rather than "a language with few features". A language can, in fact, have many features and still be simple(-to-write-in); or, like Go, it can have so few features that it is complex-to-write-in.

baranul 2y ago

Many, after doing a review of Rust, say they don't like or will stop using it. It's very premature to declare it has "won", whatever that can be said to mean. Example, ThePrimeTime[1] (famous YouTube programmer) is another stating he does not like Rust anymore, and rather use some other language. It appears part of the controversy surrounding Rust, is that many are of the opinion that it's not worth it because of the limited use case, poor readability, complexity, long compile times, etc... and that appears to be what certain advocates of Rust are not understanding or appreciating the difference in opinions. Rust is fine for them, specifically, but not for everyone. [1]: https://www.youtube.com/watch?v=1Di8X2vRNRE https://www.youtube.com/watch?v=1Di8X2vRNRE