6 ms·

Off topic. Asking seriously, will there be any point learning some language other than rust in coming days? Will rust be ubiquitous in future?

AnonC 6y ago
Just an opinion. Rust will never be ubiquitous in the future. It could aim to be as ubiquitous as C++ is, but I think those systems will be split among Rust and other languages whenever they’re rewritten and someone decides C++ should be eliminated. It requires some additional upfront effort that many practical projects may not have the luxury for (people/management types think it’s ok to fight random bugs in the future). Rust may not have the rich and mature library ecosystem like certain other languages either. But learning Rust will likely help in being a better programmer.
jfkebwjsbx 6y ago
Rust (and others like D, Ada, Zig...) won't be ubiquitous because it is a systems programming language intended to replace C and C++. This kind of languages are specialized and more costly to develop in them. Everything else (the world of Java, C#, Go, Python, JavaScript, Swift, etc.), which is the majority of the programming done nowadays, will stay the same.
- bhaak 6y ago
  I'm surprised that you put Go in the latter group and not in the same group as Rust and C/C++. What features of Go disqualify it as a systems programming language?
  - _hl_ 6y ago
    It’s not that fantastic for low level systems programming due to garbage collection and the runtime. If you’re working with C et al, you’re generally doing something that requires extreme control, and Go is too high level to do that nicely - you can use it of course, but it’s just... weird. C++ is not really a low level systems language because, very broadly speaking, low level stuff doesn’t benefit as much from the extreme flexibility and abstraction capabilities of C++. It’s used more as a high-performance application programming language for large, complex stuff. Go doesn’t fit that niche because it’s just not a very powerful language. The niche where a simple language like Go is applicable for systems stuff without being too slow or high-level is extremely small. It’s a fantastic language for working on business-logic type stuff, web backends, etc, and excels when working with less experienced developers or larger teams. It’s as easy as python et al but actually has reasonable performance. But it’s not really a systems language for serious systems stuff.
  - oconnor663 6y ago
    Automatic heap allocation and garbage collection are big ones. People debate this endlessly, and it's true that undeniably-systems-ish software projects like Docker and CockroachDB are written in Go. But at the end of the day there will always be some systems that cannot be written in Go because of how it manages memory, which is not the case with C, C++, or Rust.
    - shim__ 6y ago
      Well thats just like how one might say numpy is written in python, so portion of it certainly is but all the heavy lifing is done by C, the same goes for Docker. Docker is "just" an cli around cgroups which is a kernel feature written in again C.
      - oconnor663 6y ago
        That's a good point. Maybe you could argue that most of the heavy lifting in CockroachDB is actually done by RocksDB.
        irfansharif 6y ago
        It's not, not at all. We've actually gone as far as replacing RocksDB with https://github.com/cockroachdb/pebble/ https://github.com/cockroachdb/pebble/ by default now (and it's written in Go).
        oconnor663 6y ago
        Oh very cool. What was the main motivation for moving away from RocksDB?
  - shmerl 6y ago
    Go is not systems programming language because it has mandatory garbage collector.
- oconnor663 6y ago
  I don't think "more costly" is true across the board. I think it might be more a matter of taste, in terms of which costs you prefer. Rust is often higher-cost in terms of up front design and development time to get something working. But the resulting program might have lower costs in terms of debugging and downtime afterwards. This distinction is especially strong when the program is multithreaded.
  - jfkebwjsbx 6y ago
    Not really. Many other mainstream languages give you memory safety, strict type systems and overall robustness without having to deal with memory management or low-level details. Even for parallelism this holds true. I would say it is even more pronounced there, in fact. Some high-level languages even come with simple, effective ways of doing parallelism without multithreading, which simplifies problems a lot. Of course, they may not reach the top performance that C++ or Rust might, but that is the trade off. Performance vs. development cost.
csomar 6y ago
I think yes. But than I am a Rust fanboy so take this as you wish. The way I see it is: In the future, we'll have 64-128 cores per processors (maybe in a few years) and parallel programming will be the norm rather than the exception. The second point, Rust abstractions are very powerful, and they can allow for higher-level programming that you are used to in Python/JavaScript. Also if you think Wasm is the future for front-end programming, it suddenly makes sense to jump all-in in Rust.
- verdagon 6y ago
  Do you think Swift has a future for WASM? Rust is faster and Swift is easier, and I genuinely wonder how that particular tradeoff will shake out for web.
  - csomar 6y ago
    Are you talking about the memory management model or the syntax. For the syntax, it's a matter of getting used to. For memory management, Rust has alloc::rc, so Rust gives you Swift + more options. Swift is backed by Apple, but whether they are willing to invest in a Swift WASM platform is another deal. The bull case for Rust is getting capital (whether money or dev time) from Microsoft and Facebook as both these companies don't have an equivalent and have use cases for Rust.
amelius 6y ago
There will be a point when you type: "./configure; make" and the system you are trying to build turns out to be partially written in Rust. At that point, it can be useful to have at least some Rust under your belt.
- Svenstaro 6y ago
  This exact thing happened to me with 389-ds.
- umanwizard 6y ago
  This is already the case if the system you’re trying to build is Firefox.
detaro 6y ago
For any other language in the past few decades, the answer to that would have been "of course there is a point in learning other languages" (since none single language has taken over). I don't see why Rust that much more special.
JJ4334 6y ago
It's important to understand that hackernews, reddit or stackoverflow are very small parts of the software universe. At my workplace less then 10% of the devs are hanging around at hackernews or reddit. Some don't even visit stackoverflow but just read the Java docs! Rust is extremly popular here at hackernews and at reddit. It's a brilliant language. I learned it and actually wanted to use it for some services at work, but the team chose Go. The impression of the spread of Rust one might get following hackenews or reddit is far off. In the industry Rust is not even at 0.1%. Probably less. The amount of Java, C and C++ projects is immense. That's at least what I can tell from my almost 20 years of experience as dev. Rust is 10 years old. It's not new. There must be reasons why it's not already ubiquitous. And it's not the lack of language features or the lack of promotion :-). The reason is simple: The choice of the programming language itself is not that important. How else can the world be full of extremly successful projects written in PHP, Python, Ruby, Java, C#, C, C++, Go, JS, ... I don't like to write code without algebraic types and pattern matching. I don't want to check for null. But with Java or Go I have to and to be honest: It doesn't matter. A good development process is essential for successful projects. Language and tools ergonomics, matureness and stability come second. That's why so many large projects are still on Java 8. They get the job done. The same can be said from C++ and C. If C++ was so harmful, why did Mozilla not port all of Firefox to Rust? Rust could be a greater success in the industry. They just have to look at Go. Go gets a lot right: Standard lib and stability. Generics don't really matter if you want to build a successful product. I want it but I don't need it. A large and stable standard lib does matter. The xml package in Go's standard lib is embarrassing slow. But you can rely on it. Rust needs a large company as patreon. It needs a more comprehensive standard lib. It needs one async runtime in the standard lib and a http server and client, crypto, etc.
- deleted 6y ago
  [deleted]
- estebank 6y ago
  > Rust is 10 years old. Rust didn't have any pick up in adoption (understandably) until 1.0 in May 2015, as a consequence of breakneck speed changes before then as the developers understandably wanted freedom to break things until then. Also, 1.0 wasn't a "feature complete" release, it was a "we promise not to break your current code" release. It was an MVP. I would say it took a few releases before it was useful enough without having to rely on nightly features. All this to say is that saying that it is 10 years old, when code from 6 years ago would be completely alien and not compilable today, is misleading by omission. > It needs a more comprehensive standard lib. Reasonable people can disagree. There's a difference between having a fat stdlib that has the same cadence as the compiler, and having a "blessed" crate ecosystem that can evolve on its own. Doing it that way can let people update either their compiler or their dependencies independently of each other (modulo minimum version bumps on libraries) and opens the door to more aggressive deprecation schedules that the stdlib can never consider. Your points about the actual popularity of the language are very true: Rust is niche now and will likely continue to be so for a while, but I don't think it will remain niche.
ulisesrmzroche 6y ago
Seriously? Ok, well the day when it starts making web apps. The day when you can't find a job unless you know how to write Rust. A better question: how is it ever going to topple JS? I haven't written any other language in the last 8 years.

AnonC 6y ago

Just an opinion. Rust will never be ubiquitous in the future. It could aim to be as ubiquitous as C++ is, but I think those systems will be split among Rust and other languages whenever they’re rewritten and someone decides C++ should be eliminated. It requires some additional upfront effort that many practical projects may not have the luxury for (people/management types think it’s ok to fight random bugs in the future). Rust may not have the rich and mature library ecosystem like certain other languages either. But learning Rust will likely help in being a better programmer.

jfkebwjsbx 6y ago

Rust (and others like D, Ada, Zig...) won't be ubiquitous because it is a systems programming language intended to replace C and C++. This kind of languages are specialized and more costly to develop in them. Everything else (the world of Java, C#, Go, Python, JavaScript, Swift, etc.), which is the majority of the programming done nowadays, will stay the same.

bhaak 6y ago
I'm surprised that you put Go in the latter group and not in the same group as Rust and C/C++. What features of Go disqualify it as a systems programming language?
- _hl_ 6y ago
  It’s not that fantastic for low level systems programming due to garbage collection and the runtime. If you’re working with C et al, you’re generally doing something that requires extreme control, and Go is too high level to do that nicely - you can use it of course, but it’s just... weird. C++ is not really a low level systems language because, very broadly speaking, low level stuff doesn’t benefit as much from the extreme flexibility and abstraction capabilities of C++. It’s used more as a high-performance application programming language for large, complex stuff. Go doesn’t fit that niche because it’s just not a very powerful language. The niche where a simple language like Go is applicable for systems stuff without being too slow or high-level is extremely small. It’s a fantastic language for working on business-logic type stuff, web backends, etc, and excels when working with less experienced developers or larger teams. It’s as easy as python et al but actually has reasonable performance. But it’s not really a systems language for serious systems stuff.
- oconnor663 6y ago
  Automatic heap allocation and garbage collection are big ones. People debate this endlessly, and it's true that undeniably-systems-ish software projects like Docker and CockroachDB are written in Go. But at the end of the day there will always be some systems that cannot be written in Go because of how it manages memory, which is not the case with C, C++, or Rust.
  - shim__ 6y ago
    Well thats just like how one might say numpy is written in python, so portion of it certainly is but all the heavy lifing is done by C, the same goes for Docker. Docker is "just" an cli around cgroups which is a kernel feature written in again C.
    - oconnor663 6y ago
      That's a good point. Maybe you could argue that most of the heavy lifting in CockroachDB is actually done by RocksDB.
      - irfansharif 6y ago
        It's not, not at all. We've actually gone as far as replacing RocksDB with https://github.com/cockroachdb/pebble/ https://github.com/cockroachdb/pebble/ by default now (and it's written in Go).
        oconnor663 6y ago
        Oh very cool. What was the main motivation for moving away from RocksDB?
- shmerl 6y ago
  Go is not systems programming language because it has mandatory garbage collector.
oconnor663 6y ago
I don't think "more costly" is true across the board. I think it might be more a matter of taste, in terms of which costs you prefer. Rust is often higher-cost in terms of up front design and development time to get something working. But the resulting program might have lower costs in terms of debugging and downtime afterwards. This distinction is especially strong when the program is multithreaded.
- jfkebwjsbx 6y ago
  Not really. Many other mainstream languages give you memory safety, strict type systems and overall robustness without having to deal with memory management or low-level details. Even for parallelism this holds true. I would say it is even more pronounced there, in fact. Some high-level languages even come with simple, effective ways of doing parallelism without multithreading, which simplifies problems a lot. Of course, they may not reach the top performance that C++ or Rust might, but that is the trade off. Performance vs. development cost.

csomar 6y ago

I think yes. But than I am a Rust fanboy so take this as you wish. The way I see it is: In the future, we'll have 64-128 cores per processors (maybe in a few years) and parallel programming will be the norm rather than the exception. The second point, Rust abstractions are very powerful, and they can allow for higher-level programming that you are used to in Python/JavaScript. Also if you think Wasm is the future for front-end programming, it suddenly makes sense to jump all-in in Rust.

verdagon 6y ago
Do you think Swift has a future for WASM? Rust is faster and Swift is easier, and I genuinely wonder how that particular tradeoff will shake out for web.
- csomar 6y ago
  Are you talking about the memory management model or the syntax. For the syntax, it's a matter of getting used to. For memory management, Rust has alloc::rc, so Rust gives you Swift + more options. Swift is backed by Apple, but whether they are willing to invest in a Swift WASM platform is another deal. The bull case for Rust is getting capital (whether money or dev time) from Microsoft and Facebook as both these companies don't have an equivalent and have use cases for Rust.

amelius 6y ago

There will be a point when you type: "./configure; make" and the system you are trying to build turns out to be partially written in Rust. At that point, it can be useful to have at least some Rust under your belt.

Svenstaro 6y ago
This exact thing happened to me with 389-ds.
umanwizard 6y ago
This is already the case if the system you’re trying to build is Firefox.

detaro 6y ago

For any other language in the past few decades, the answer to that would have been "of course there is a point in learning other languages" (since none single language has taken over). I don't see why Rust that much more special.

JJ4334 6y ago

It's important to understand that hackernews, reddit or stackoverflow are very small parts of the software universe. At my workplace less then 10% of the devs are hanging around at hackernews or reddit. Some don't even visit stackoverflow but just read the Java docs! Rust is extremly popular here at hackernews and at reddit. It's a brilliant language. I learned it and actually wanted to use it for some services at work, but the team chose Go. The impression of the spread of Rust one might get following hackenews or reddit is far off. In the industry Rust is not even at 0.1%. Probably less. The amount of Java, C and C++ projects is immense. That's at least what I can tell from my almost 20 years of experience as dev. Rust is 10 years old. It's not new. There must be reasons why it's not already ubiquitous. And it's not the lack of language features or the lack of promotion :-). The reason is simple: The choice of the programming language itself is not that important. How else can the world be full of extremly successful projects written in PHP, Python, Ruby, Java, C#, C, C++, Go, JS, ... I don't like to write code without algebraic types and pattern matching. I don't want to check for null. But with Java or Go I have to and to be honest: It doesn't matter. A good development process is essential for successful projects. Language and tools ergonomics, matureness and stability come second. That's why so many large projects are still on Java 8. They get the job done. The same can be said from C++ and C. If C++ was so harmful, why did Mozilla not port all of Firefox to Rust? Rust could be a greater success in the industry. They just have to look at Go. Go gets a lot right: Standard lib and stability. Generics don't really matter if you want to build a successful product. I want it but I don't need it. A large and stable standard lib does matter. The xml package in Go's standard lib is embarrassing slow. But you can rely on it. Rust needs a large company as patreon. It needs a more comprehensive standard lib. It needs one async runtime in the standard lib and a http server and client, crypto, etc.

deleted 6y ago
[deleted]
estebank 6y ago
> Rust is 10 years old. Rust didn't have any pick up in adoption (understandably) until 1.0 in May 2015, as a consequence of breakneck speed changes before then as the developers understandably wanted freedom to break things until then. Also, 1.0 wasn't a "feature complete" release, it was a "we promise not to break your current code" release. It was an MVP. I would say it took a few releases before it was useful enough without having to rely on nightly features. All this to say is that saying that it is 10 years old, when code from 6 years ago would be completely alien and not compilable today, is misleading by omission. > It needs a more comprehensive standard lib. Reasonable people can disagree. There's a difference between having a fat stdlib that has the same cadence as the compiler, and having a "blessed" crate ecosystem that can evolve on its own. Doing it that way can let people update either their compiler or their dependencies independently of each other (modulo minimum version bumps on libraries) and opens the door to more aggressive deprecation schedules that the stdlib can never consider. Your points about the actual popularity of the language are very true: Rust is niche now and will likely continue to be so for a while, but I don't think it will remain niche.

ulisesrmzroche 6y ago

Seriously? Ok, well the day when it starts making web apps. The day when you can't find a job unless you know how to write Rust. A better question: how is it ever going to topple JS? I haven't written any other language in the last 8 years.