5 ms·

I agree with the sentiment somewhat. Some rust libraries are dying, while some great new ones thrive (recently found iroh and wgpu to name a few). Everyone want

I agree with the sentiment somewhat. Some rust libraries are dying, while some great new ones thrive (recently found iroh and wgpu to name a few). Everyone wants to write a game engine or some fun project and then abandon it, but no one wants to write a game. No application software has really "cemented" itself in the global ecosystem. Except for maybe ripgrep? I would like to see support for more compilers (https://rust-gcc.github.io/ https://rust-gcc.github.io/), more interoperability with C/C++, better support for cross-compilation. Maybe less reliance on crates.io, static linking, and permissive licenses. Still, I see Rust as the natural progression from C++. It has enough momentum to flatten all competitors (Carbon, Zig, Nim, Go) except scripting languages

speed_spread 1y ago
Rust will not "flatten" Go. They have some overlap but generally don't serve the same purpose and don't appeal to the same crowd. Go's popularity is undeniable, both in open source and in the industry. Outside of major shops and the odd shady Fintech startup, there are still very little Rust jobs out there. It's not necessarily bad, it's just the nature of it. Rust adoption is a slow thing because it addresses problems faced by slow moving software.
- fpoling 1y ago
  Go jobs are not that popular either especially outside US. Java is way more popular and with recent improvements on JDK Go does not offer that match advantages over it. And compared with Go Java is fully memory-safe and have independent implementations.
  - speed_spread 1y ago
    I like modern Java and agree it's a much better language than Go and an excellent platform in general. But Java will not beat Go where small and fast native executables are required. The native story for Java will remain a sad one, builds being hyper slow (aot) or resulting in huge binaries (jlink).
    - krior 1y ago
      Small and fast native executables sounds more like a niche than a real market. Don't get me wrong: really nice to have, but a raison d'etre?
    - pjmlp 1y ago
      You mean like those 300MB that need to be compressed with upx for distribution, like some Go projects?
    - lenkite 1y ago
      Beyond a certain project size, GraalVM compiles to the same binary size as Go. Many k8s projects produce binary sizes of >100MB. I think this is because LOC in Go scales poorly. Go's real edge over Java is in memory consumption, not in performance or binary size. Yet, this is also mostly true at the small-scale level. The edge again disappears for large projects needing large heaps.
    - fpoling 1y ago
      If one needs a small and fast executable, then Rust should be used, not Go. I know a company that wished they would use Rust, not Go, for their services as poor Go performance and GC spikes made it a big headache.
  - melodyogonna 1y ago
    Then you've not tried to do any cloud-native development. Go in cloud is like Python in AI
    - pjmlp 1y ago
      I have, and Go over here is only relevant as the language Docker and Kubernetes are written on. Everything we do is written in JVM or CLR languages, JS/TS, and the occasional C++ for native libraries.
      - melodyogonna 1y ago
        You must be joking. Over 75% of software on CNCF is written in Go; these include tools ranging from CI/CD to metrics and monitoring. It may not be popular to write your enterprise applications but it is certainly very popular in cloud infrastructure
        pjmlp 1y ago
        Quite serious, CNCF products are basically Docker and Kubernetes related, that isn't what actual companies care about when moving their compute workloads from in-house into AWS, Azure, GCP, Vercel, Nelify, while paying big boys money to consulting agencies. Many of those products are startups looking for attention in podcasts interviews and the like, and barely part of any enterprise cloud projects.
TuxSH 1y ago
> Still, I see Rust as the natural progression from C++ I don't; Rust has its niche but currently can't replace C++ everywhere. From what I'm aware of, Rust has poor ergonomics for programs that have non-hierarchical ownership model (ie. not representable by trees), for example retained mode GUIs, game engines, intrusive lists in general, non-owning pointers of subobjects part of the same forever-lived singleton, etc. > Go To displace Go you must also displace Kubernetes and its ecosystem (unlikely, k8s is such a convenient tool), or have k8s move away from Go (not gonna happen considering who developed both)
- throwawaymaths 1y ago
  k8s was originally java, iirc
  - pjmlp 1y ago
    It was, then a couple of early Go advocates joined the team, and ....
- sunshowers 1y ago
  > intrusive lists in general Not quite an intrusive list, but a particular data structure that's often called "intrusive" is a map where keys borrow from values. This turns out to be a super useful pattern. https://www.boost.org/doc/libs/1_59_0/doc/html/boost/intrusive/key_of_value.html https://www.boost.org/doc/libs/1_59_0/doc/html/boost/intrusi... Note that the signature here is `const key_type & operator()(const value_type &)`, or in Rust terms `fn key(&self) -> &Self::Key`. This means that the key must exist in a concrete form inside the value -- it is impossible to have keys that borrow from multiple fields within the value, for example. At Oxide, I recently wrote and released https://docs.rs/iddqd https://docs.rs/iddqd, which provides similar maps. With iddqd, the signature is `fn key(&self) -> Self::Key<'_>`, which means that iddqd does allow you to borrow from multiple fields to form the key. See the ArtifactKey example under https://docs.rs/iddqd/latest/iddqd/#examples https://docs.rs/iddqd/latest/iddqd/#examples.
- tialaramex 1y ago
  Things that live forever can be immutably borrowed, no problem. So rather than a non-owning pointer, you'd just use a &'static here - the immutable borrow which (potentially) lives forever Years ago it was tricky to write the "forever, once initialized" type, you'd need a third party crate to do it stably. But today you can just use std::sync::LazyLock which lets you say OK, the first time somebody wants this thing we'll make it, and subsequently it just exists forever. [If you need to specify some runtime parameters later, but still only initialize once and re-use you want OnceLock not LazyLock, the OnceLock is allowed to say there isn't a value yet] Intrusive lists are one of those things where technically you might need them, but so often they're just because a C or C++ programmer knew how to write one. They're like the snorkel on the 4x4 I see parked in my street. I'd be surprised if they've ever driven it on a muddy field, much less anywhere the snorkel would help. A retained mode GUI looks like a hierarchy to me, how do you say it isn't?
eldenring 1y ago
I find a lot of Rust libraries "seem" dead, based on github activity, but looking into it, they are actively used in many projects. I think Rust projects just tend to have less open issues, and don't need to be maintained as often. This is also the case internally at my company.

speed_spread 1y ago

Rust will not "flatten" Go. They have some overlap but generally don't serve the same purpose and don't appeal to the same crowd. Go's popularity is undeniable, both in open source and in the industry. Outside of major shops and the odd shady Fintech startup, there are still very little Rust jobs out there. It's not necessarily bad, it's just the nature of it. Rust adoption is a slow thing because it addresses problems faced by slow moving software.

fpoling 1y ago
Go jobs are not that popular either especially outside US. Java is way more popular and with recent improvements on JDK Go does not offer that match advantages over it. And compared with Go Java is fully memory-safe and have independent implementations.
- speed_spread 1y ago
  I like modern Java and agree it's a much better language than Go and an excellent platform in general. But Java will not beat Go where small and fast native executables are required. The native story for Java will remain a sad one, builds being hyper slow (aot) or resulting in huge binaries (jlink).
  - krior 1y ago
    Small and fast native executables sounds more like a niche than a real market. Don't get me wrong: really nice to have, but a raison d'etre?
  - pjmlp 1y ago
    You mean like those 300MB that need to be compressed with upx for distribution, like some Go projects?
  - lenkite 1y ago
    Beyond a certain project size, GraalVM compiles to the same binary size as Go. Many k8s projects produce binary sizes of >100MB. I think this is because LOC in Go scales poorly. Go's real edge over Java is in memory consumption, not in performance or binary size. Yet, this is also mostly true at the small-scale level. The edge again disappears for large projects needing large heaps.
  - fpoling 1y ago
    If one needs a small and fast executable, then Rust should be used, not Go. I know a company that wished they would use Rust, not Go, for their services as poor Go performance and GC spikes made it a big headache.
- melodyogonna 1y ago
  Then you've not tried to do any cloud-native development. Go in cloud is like Python in AI
  - pjmlp 1y ago
    I have, and Go over here is only relevant as the language Docker and Kubernetes are written on. Everything we do is written in JVM or CLR languages, JS/TS, and the occasional C++ for native libraries.
    - melodyogonna 1y ago
      You must be joking. Over 75% of software on CNCF is written in Go; these include tools ranging from CI/CD to metrics and monitoring. It may not be popular to write your enterprise applications but it is certainly very popular in cloud infrastructure
      - pjmlp 1y ago
        Quite serious, CNCF products are basically Docker and Kubernetes related, that isn't what actual companies care about when moving their compute workloads from in-house into AWS, Azure, GCP, Vercel, Nelify, while paying big boys money to consulting agencies. Many of those products are startups looking for attention in podcasts interviews and the like, and barely part of any enterprise cloud projects.

TuxSH 1y ago

> Still, I see Rust as the natural progression from C++ I don't; Rust has its niche but currently can't replace C++ everywhere. From what I'm aware of, Rust has poor ergonomics for programs that have non-hierarchical ownership model (ie. not representable by trees), for example retained mode GUIs, game engines, intrusive lists in general, non-owning pointers of subobjects part of the same forever-lived singleton, etc. > Go To displace Go you must also displace Kubernetes and its ecosystem (unlikely, k8s is such a convenient tool), or have k8s move away from Go (not gonna happen considering who developed both)

throwawaymaths 1y ago
k8s was originally java, iirc
- pjmlp 1y ago
  It was, then a couple of early Go advocates joined the team, and ....
sunshowers 1y ago
> intrusive lists in general Not quite an intrusive list, but a particular data structure that's often called "intrusive" is a map where keys borrow from values. This turns out to be a super useful pattern. https://www.boost.org/doc/libs/1_59_0/doc/html/boost/intrusive/key_of_value.html https://www.boost.org/doc/libs/1_59_0/doc/html/boost/intrusi... Note that the signature here is `const key_type & operator()(const value_type &)`, or in Rust terms `fn key(&self) -> &Self::Key`. This means that the key must exist in a concrete form inside the value -- it is impossible to have keys that borrow from multiple fields within the value, for example. At Oxide, I recently wrote and released https://docs.rs/iddqd https://docs.rs/iddqd, which provides similar maps. With iddqd, the signature is `fn key(&self) -> Self::Key<'_>`, which means that iddqd does allow you to borrow from multiple fields to form the key. See the ArtifactKey example under https://docs.rs/iddqd/latest/iddqd/#examples https://docs.rs/iddqd/latest/iddqd/#examples.
tialaramex 1y ago
Things that live forever can be immutably borrowed, no problem. So rather than a non-owning pointer, you'd just use a &'static here - the immutable borrow which (potentially) lives forever Years ago it was tricky to write the "forever, once initialized" type, you'd need a third party crate to do it stably. But today you can just use std::sync::LazyLock which lets you say OK, the first time somebody wants this thing we'll make it, and subsequently it just exists forever. [If you need to specify some runtime parameters later, but still only initialize once and re-use you want OnceLock not LazyLock, the OnceLock is allowed to say there isn't a value yet] Intrusive lists are one of those things where technically you might need them, but so often they're just because a C or C++ programmer knew how to write one. They're like the snorkel on the 4x4 I see parked in my street. I'd be surprised if they've ever driven it on a muddy field, much less anywhere the snorkel would help. A retained mode GUI looks like a hierarchy to me, how do you say it isn't?

eldenring 1y ago

I find a lot of Rust libraries "seem" dead, based on github activity, but looking into it, they are actively used in many projects. I think Rust projects just tend to have less open issues, and don't need to be maintained as often. This is also the case internally at my company.