4 ms·

D is in the same space, but it started off having a GC and that kind of caused it more problems that it was perhaps worth being in an almost system space. Rece

by Verdex 7y ago

D is in the same space, but it started off having a GC and that kind of caused it more problems that it was perhaps worth being in an almost system space. Recent work with different allocator patterns and adding the -betterC compiler flag, I think, may help D in the long run. However, I wouldn't be surprised if D never gets much more popular that it already is. The other major competitors to Rust is Zig and Jai. Of course Jai has the problem of being unreleased at the moment (and its fate is tightly bound to Jon Blow). There are also a few other languages attempting to make inroads in the space. For example, Odin and Kit. Here's my take on it though. C and C++ will always have some sort of systemic problem because they are able to do too much. In order to be a system language AND also do everything that people want a system language to do (games, embedded, high performance) you need (I assert) to have rough edges and dangerous pit falls. Rust will eventually beat C/C++ on making web browsers and similar technologies because that's what it was built to do. However, Rust probably won't be able to beat C/C++ in game development and total OS development (although it can probably be partially used for both). Enter Zig and Jai. D and Go both compete with C/C++ in a space that was temporarily taken over to Java/C#. But in the long run may end up being ceded to something that's less than a managed language but more than a system language. Ultimately I predict we'll see C/C++ slowly give way to a family of system languages that all hold different niches before finally becoming a relegated to legacy only. This could still take a few decades to complete. And if you look at newer versions of C++ it's possible that C and C++ may even evolve to hold a different niche than the wide series of domains that they used to hold onto so tightly.

bluejekyll 7y ago
I appreciate that you're trying to frame this as areas where all of these languages can be successful in these spaces, but for Rust in particular, this is an odd take: "In order to be a system language AND also do everything that people want a system language to do (games, embedded, high performance) you need (I assert) to have rough edges and dangerous pit falls. "Rust will eventually beat C/C++ on making web browsers and similar technologies because that's what it was built to do. However, Rust probably won't be able to beat C/C++ in game development and total OS development (although it can probably be partially used for both)." Rust has all the necessary escape hatches (through unsafe) required for these spaces. There are people working in these spaces with Rust successfully, today. So, while, the other languages you mention might find success here as well, there is no reason (from a technical perspective) that Rust will not.
- jandrewrogers 7y ago
  The caveat here is that some correct software architectures require littering so much "unsafe" in the code (due to incompatible safety models, not actual unsafe-ness) that it largely defeats the purpose, and a software architecture that lets you avoid most "unsafe" produces a worse product while requiring more lines of code to accomplish the same thing. Rust will always leave plenty of room for C++ to the extent that it tacitly encourages suboptimal software architecture for some types of applications, such as database engines, that commonly rely on safety models Rust was not designed to express. I do see Rust potentially replacing a lot of backend Java, eventually.
  - Verdex 7y ago
    I'm glad you commented because this is what I wanted to say, but couldn't think of a good way to lead into it. IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons. Uniqueness is really useful for most applications, but there are times that you want data structures that allow multiple pointers to the same data. Having to do this in Rust is going to be a bigger chore than doing it in a language that doesn't support uniqueness. It will be possible for Rust to still participate in these areas (especially because you can use Rust for only part of your project, so you can use it where you don't have allocation or nonuniqueness constraints in your problem space). However, other options are going to offer a better programmer experience.
    - steveklabnik 7y ago
      > IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons. So, sort of yes, and sort of no. Like, you can swap the global allocator, but there's no way to parameterize standard library stuff over anything but the given allocator. But for your own code, you can write and use allocators however you want. Arenas are often popular, for example.
Scarbutt 7y ago
Go also competes with Rust in many areas though.
- rapsey 7y ago
  The most prominent projects are in areas where Go is not relevant. Go established itself as a python/ruby/php competitor. Rust is a c/c++ competitor
  - Thaxll 7y ago
    Hmm not really, Go is close to Python / Java / C# / C++, not much for PHP / Ruby, people didn't build backend services outside of the web in those languages. Imagine one second Kubernetes, Docker or Prometheus those app have nothing to do with PHP / Ruby. It's related to C++ / Java. Prometheus is the equivalent of what's at Google and it was built in C++. Same for all the DBs outhere in Go: CockroachDB, NATS, etcd ect ... those are C++ applications related.
    - rapsey 7y ago
      By far the most usage of Go is web backends. But it is true I should have mentioned Java in the language list. Go is a popular Java replacement. However you are talking about projects that are not particularly language dependent as long as the runtime is reasonably performant. They could just as well have been implemented in Java. For many Rust would arguably be a better choice but that is not relevant. Go shines here, but Rust is barely emerging in these areas. Rust is a C++ competitor in areas where C++ has no competition because a GC is a no go. This is also where the most prominent use cases are.
- swiftcoder 7y ago
  Go folks seem pretty persistent in espousing this belief, but I've yet to see many examples of it in action. Most of the fields where rust is making headway, it is making headway for precisely the things that Go is not known for - lack of a garbage collector, strict and expressive type system, robust generics, etc.

by Verdex 7y ago

bluejekyll 7y ago

I appreciate that you're trying to frame this as areas where all of these languages can be successful in these spaces, but for Rust in particular, this is an odd take: "In order to be a system language AND also do everything that people want a system language to do (games, embedded, high performance) you need (I assert) to have rough edges and dangerous pit falls. "Rust will eventually beat C/C++ on making web browsers and similar technologies because that's what it was built to do. However, Rust probably won't be able to beat C/C++ in game development and total OS development (although it can probably be partially used for both)." Rust has all the necessary escape hatches (through unsafe) required for these spaces. There are people working in these spaces with Rust successfully, today. So, while, the other languages you mention might find success here as well, there is no reason (from a technical perspective) that Rust will not.

jandrewrogers 7y ago
The caveat here is that some correct software architectures require littering so much "unsafe" in the code (due to incompatible safety models, not actual unsafe-ness) that it largely defeats the purpose, and a software architecture that lets you avoid most "unsafe" produces a worse product while requiring more lines of code to accomplish the same thing. Rust will always leave plenty of room for C++ to the extent that it tacitly encourages suboptimal software architecture for some types of applications, such as database engines, that commonly rely on safety models Rust was not designed to express. I do see Rust potentially replacing a lot of backend Java, eventually.
- Verdex 7y ago
  I'm glad you commented because this is what I wanted to say, but couldn't think of a good way to lead into it. IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons. Uniqueness is really useful for most applications, but there are times that you want data structures that allow multiple pointers to the same data. Having to do this in Rust is going to be a bigger chore than doing it in a language that doesn't support uniqueness. It will be possible for Rust to still participate in these areas (especially because you can use Rust for only part of your project, so you can use it where you don't have allocation or nonuniqueness constraints in your problem space). However, other options are going to offer a better programmer experience.
  - steveklabnik 7y ago
    > IIRC while Rust does allow you to switch up allocators, it doesn't let you mix and match your runtime with multiple allocators. (Each artifact can be linked with at most one allocator at a time.) There are applications where you want to have multiple allocation strategies for performance reasons. So, sort of yes, and sort of no. Like, you can swap the global allocator, but there's no way to parameterize standard library stuff over anything but the given allocator. But for your own code, you can write and use allocators however you want. Arenas are often popular, for example.

Scarbutt 7y ago

Go also competes with Rust in many areas though.

rapsey 7y ago
The most prominent projects are in areas where Go is not relevant. Go established itself as a python/ruby/php competitor. Rust is a c/c++ competitor
- Thaxll 7y ago
  Hmm not really, Go is close to Python / Java / C# / C++, not much for PHP / Ruby, people didn't build backend services outside of the web in those languages. Imagine one second Kubernetes, Docker or Prometheus those app have nothing to do with PHP / Ruby. It's related to C++ / Java. Prometheus is the equivalent of what's at Google and it was built in C++. Same for all the DBs outhere in Go: CockroachDB, NATS, etcd ect ... those are C++ applications related.
  - rapsey 7y ago
    By far the most usage of Go is web backends. But it is true I should have mentioned Java in the language list. Go is a popular Java replacement. However you are talking about projects that are not particularly language dependent as long as the runtime is reasonably performant. They could just as well have been implemented in Java. For many Rust would arguably be a better choice but that is not relevant. Go shines here, but Rust is barely emerging in these areas. Rust is a C++ competitor in areas where C++ has no competition because a GC is a no go. This is also where the most prominent use cases are.
swiftcoder 7y ago
Go folks seem pretty persistent in espousing this belief, but I've yet to see many examples of it in action. Most of the fields where rust is making headway, it is making headway for precisely the things that Go is not known for - lack of a garbage collector, strict and expressive type system, robust generics, etc.