5 ms·

What are the chances of Rust or another language coming to the fore for cloud infra?

jpgvm 6y ago
Reasonably high. There is a good deal of frustration with Go from experienced programmers that worked with it for several years and grew tired of the tedium involved. Rust has some obstacles to overcome to supplant Go on a wider scale though. Namely compile time and learning curve - especially in relation to concurrency and async which are key features to replacing Go as it's main draw is it's green runtime.
- bfrog 6y ago
  Go has no expressiveness to it. You end up either with a large pile of copy pasted code, code generators, or massively error prone runtime introspection. Go blows up the entire idea of Don't Repeat Yourself. The language actively encourages it.
  - greyman 6y ago
    > Go blows up the entire idea of Don't Repeat Yourself. Yes, this is true. I programm in Go professionally, about 50% of my work time (other half is python). But in many cases, I have found that copying the same code to other places doesn't have that much negative consequences as one would believe.
    - CameronNemo 6y ago
      Refactoring becomes intensely burdensome, often to the point that it is avoided at all costs. Not a great situation when you need to iterate on a design.
    - jack_h 6y ago
      So I'm almost certainly in a different industry (embedded) where EEs tend to prolifically copy+paste code. In the end this always makes it so that a change that should take very little time consumes an entire workweek or more. So I have a seething hatred of this practice from past experiences. I suppose I should say that there's a lot of different types of duplicate code, some of which really don't matter per se. Sometimes two bits of code are basically the same but are completely unrelated and as things change they will diverge, i.e. it was just incidental. Code that is duplicated with a strong functional relationship make changes a nightmare though.
- throwaway894345 6y ago
  I'm not seeing that. It seems like there's lots of enthusiasm to use Rust, but that people can't justify choosing it over Go probably because Rust is quite a lot more tedious than Go and its strong performance and correctness guarantees aren't worth the tradeoff for very many applications. I'm hopeful that things like rust-analyzer will help close that gap, but I don't think it will ever completely close much less reverse.
  - jpgvm 6y ago
    This is true. It's worth remembering why Go got it's shot though which is at the time of Docker being written it was originally written in Python. A few members of the container/orchestration community pushed to try writing it in Golang as Golang was also new and combining the enthusiasm of 2 communities was likely to result in greater success (turned out to be correct). On the other hand Rust hasn't had an oportunity for a killer app, in fact it's main sponsor project Servo/Firefox is pretty much the opposite. It's a browser, the definition of a complex and slow moving behemoth of a project. I attribute Rust's slow takeoff compared to Go mostly to this phenomenon. After Docker was written in Go and started popularising containers outside of the lxc/openvz/other hardcore guys doing their own stuff directly on top of the kernel APIs then it was only natural that stuff would want to integrate with Docker and using the same language was a way to capture some of that enthusiasm. This resulted in software like Flynn, Deis and Kubernetes all picking Golang. The resulting network effect is very strong. To some degree this is also down to the strength of the Go standard library. It has an excellent HTTP and TLS stack, encoding/decoding etc. All of this made it a good fit to write software that is fundamentally fairly "dumb" quite quickly. i.e software the mostly shuffles bytes from one socket to another. Rust will most likely not find such a killer app so I think people need to be realistic about how long it will take Rust to find a marketshare. The big difference though is one can actually make good arguments to use Rust over C/C++ where you can't in most cases for Go. C is the largest software ecosystem right now and Rust is best positioned to take some of this market share away.
    - pjmlp 6y ago
      Rust's killer app will come from OS vendors support, like Microsoft and ironically Google (Fuschia and Crostini). However while I like Rust, it seems that it will become more of a C++ companion than a replacement, as it will take quite some time to get a foothold on systems where C++ is finally replacing C as of the last decade.
- zozbot234 6y ago
  Concurrency and async in Rust has improved a lot as of late. See https://areweasyncyet.rs https://areweasyncyet.rs for an overview of this space.
q3k 6y ago
Not great as is. Rust does not have a comprehensive story for CSP concurrency like Go has. It does have a fair share of libraries/ecosystems (like Tokio), but not having something built in means that you have to hunt for the right set of libraries to work together. Meanwhile, in Go, every single library will just work with its concurrency model out of the box.
- asimpletune 6y ago
  Rust has channels though, unless I misunderstand what you mean.
- alexeldeib 6y ago
  I write in Go daily and I've been ramping up on Rust. While CSP isn't built into the language, Crossbeam, Flume, and others are more than enough to fill the gap. If anything, I find Rust returns flexibility to me in programming choice that Go made me forget I had. There are places where library support in Go is still richer, but language support has been stellar across the board in Rust.
  - throwaway894345 6y ago
    I write Go daily, and I don't think CSP really panned out. For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP. That might be an artifact of how channels are implemented and their many hidden error cases--perhaps a better channel implementation could change the calculus. There are lots of reasons to prefer Go to Rust IMO, but I don't think CSP is among them.
    - dnautics 6y ago
      > For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP It's easier to write code with standard threading tooling but I think CSP is much, much easier to debug and avoid deadlocks.
      - 6y ago
cfors 6y ago
For platform stuff that has speed and correctness as the highest priority? Absolutely. Things like http proxies, message queues, shared infrastructure makes sense to be done in Rust. For writing a normal networked http/rpc/event stream service Go is probably more than good enough. It’s not a winner-take-all market. A great example imo is Buoyant’s Linkerd. Rust dataplane proxy as well as a control plane written in Go. Two different requirements for each of those services drove the language requirements
streetcat1 6y ago
The fight is not technical but political / business-oriented. Each language is a much more than its syntax. It is a complete ecosystem with network effects. Rust can overcome go, if it would provide a lot of open source libraries, as well as growing number of programmers. To do that, it would need the backing of big tech (e.g. MS), that have a big budget to evangelize it. In any rate, the choice of language today is completely meaningless, since you can wrap anything in a container, and put a GRPC interface on top of it. So the choice of lang should be based on the libraries for the task at hand and not on the lang itself.
- pjmlp 6y ago
  Speaking of MS, https://msrc-blog.microsoft.com/2020/04/29/the-safety-boat-kubernetes-and-rust/ https://msrc-blog.microsoft.com/2020/04/29/the-safety-boat-k... https://msrc-blog.microsoft.com/2019/09/30/building-the-azure-iot-edge-security-daemon-in-rust/ https://msrc-blog.microsoft.com/2019/09/30/building-the-azur... https://blogs.windows.com/windowsdeveloper/2020/04/30/rust-winrt-public-preview/ https://blogs.windows.com/windowsdeveloper/2020/04/30/rust-w...
deleted 6y ago
[deleted]

Reasonably high. There is a good deal of frustration with Go from experienced programmers that worked with it for several years and grew tired of the tedium involved. Rust has some obstacles to overcome to supplant Go on a wider scale though. Namely compile time and learning curve - especially in relation to concurrency and async which are key features to replacing Go as it's main draw is it's green runtime.

bfrog 6y ago
Go has no expressiveness to it. You end up either with a large pile of copy pasted code, code generators, or massively error prone runtime introspection. Go blows up the entire idea of Don't Repeat Yourself. The language actively encourages it.
- greyman 6y ago
  > Go blows up the entire idea of Don't Repeat Yourself. Yes, this is true. I programm in Go professionally, about 50% of my work time (other half is python). But in many cases, I have found that copying the same code to other places doesn't have that much negative consequences as one would believe.
  - CameronNemo 6y ago
    Refactoring becomes intensely burdensome, often to the point that it is avoided at all costs. Not a great situation when you need to iterate on a design.
  - jack_h 6y ago
    So I'm almost certainly in a different industry (embedded) where EEs tend to prolifically copy+paste code. In the end this always makes it so that a change that should take very little time consumes an entire workweek or more. So I have a seething hatred of this practice from past experiences. I suppose I should say that there's a lot of different types of duplicate code, some of which really don't matter per se. Sometimes two bits of code are basically the same but are completely unrelated and as things change they will diverge, i.e. it was just incidental. Code that is duplicated with a strong functional relationship make changes a nightmare though.
throwaway894345 6y ago
I'm not seeing that. It seems like there's lots of enthusiasm to use Rust, but that people can't justify choosing it over Go probably because Rust is quite a lot more tedious than Go and its strong performance and correctness guarantees aren't worth the tradeoff for very many applications. I'm hopeful that things like rust-analyzer will help close that gap, but I don't think it will ever completely close much less reverse.
- jpgvm 6y ago
  This is true. It's worth remembering why Go got it's shot though which is at the time of Docker being written it was originally written in Python. A few members of the container/orchestration community pushed to try writing it in Golang as Golang was also new and combining the enthusiasm of 2 communities was likely to result in greater success (turned out to be correct). On the other hand Rust hasn't had an oportunity for a killer app, in fact it's main sponsor project Servo/Firefox is pretty much the opposite. It's a browser, the definition of a complex and slow moving behemoth of a project. I attribute Rust's slow takeoff compared to Go mostly to this phenomenon. After Docker was written in Go and started popularising containers outside of the lxc/openvz/other hardcore guys doing their own stuff directly on top of the kernel APIs then it was only natural that stuff would want to integrate with Docker and using the same language was a way to capture some of that enthusiasm. This resulted in software like Flynn, Deis and Kubernetes all picking Golang. The resulting network effect is very strong. To some degree this is also down to the strength of the Go standard library. It has an excellent HTTP and TLS stack, encoding/decoding etc. All of this made it a good fit to write software that is fundamentally fairly "dumb" quite quickly. i.e software the mostly shuffles bytes from one socket to another. Rust will most likely not find such a killer app so I think people need to be realistic about how long it will take Rust to find a marketshare. The big difference though is one can actually make good arguments to use Rust over C/C++ where you can't in most cases for Go. C is the largest software ecosystem right now and Rust is best positioned to take some of this market share away.
  - pjmlp 6y ago
    Rust's killer app will come from OS vendors support, like Microsoft and ironically Google (Fuschia and Crostini). However while I like Rust, it seems that it will become more of a C++ companion than a replacement, as it will take quite some time to get a foothold on systems where C++ is finally replacing C as of the last decade.
zozbot234 6y ago
Concurrency and async in Rust has improved a lot as of late. See https://areweasyncyet.rs https://areweasyncyet.rs for an overview of this space.

q3k 6y ago

Not great as is. Rust does not have a comprehensive story for CSP concurrency like Go has. It does have a fair share of libraries/ecosystems (like Tokio), but not having something built in means that you have to hunt for the right set of libraries to work together. Meanwhile, in Go, every single library will just work with its concurrency model out of the box.

asimpletune 6y ago
Rust has channels though, unless I misunderstand what you mean.
alexeldeib 6y ago
I write in Go daily and I've been ramping up on Rust. While CSP isn't built into the language, Crossbeam, Flume, and others are more than enough to fill the gap. If anything, I find Rust returns flexibility to me in programming choice that Go made me forget I had. There are places where library support in Go is still richer, but language support has been stellar across the board in Rust.
- throwaway894345 6y ago
  I write Go daily, and I don't think CSP really panned out. For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP. That might be an artifact of how channels are implemented and their many hidden error cases--perhaps a better channel implementation could change the calculus. There are lots of reasons to prefer Go to Rust IMO, but I don't think CSP is among them.
  - dnautics 6y ago
    > For most applications, I find it's much easier to use a mutex and standard threading tooling than channels/CSP It's easier to write code with standard threading tooling but I think CSP is much, much easier to debug and avoid deadlocks.
    - 6y ago

cfors 6y ago

For platform stuff that has speed and correctness as the highest priority? Absolutely. Things like http proxies, message queues, shared infrastructure makes sense to be done in Rust. For writing a normal networked http/rpc/event stream service Go is probably more than good enough. It’s not a winner-take-all market. A great example imo is Buoyant’s Linkerd. Rust dataplane proxy as well as a control plane written in Go. Two different requirements for each of those services drove the language requirements

streetcat1 6y ago

The fight is not technical but political / business-oriented. Each language is a much more than its syntax. It is a complete ecosystem with network effects. Rust can overcome go, if it would provide a lot of open source libraries, as well as growing number of programmers. To do that, it would need the backing of big tech (e.g. MS), that have a big budget to evangelize it. In any rate, the choice of language today is completely meaningless, since you can wrap anything in a container, and put a GRPC interface on top of it. So the choice of lang should be based on the libraries for the task at hand and not on the lang itself.

pjmlp 6y ago
Speaking of MS, https://msrc-blog.microsoft.com/2020/04/29/the-safety-boat-kubernetes-and-rust/ https://msrc-blog.microsoft.com/2020/04/29/the-safety-boat-k... https://msrc-blog.microsoft.com/2019/09/30/building-the-azure-iot-edge-security-daemon-in-rust/ https://msrc-blog.microsoft.com/2019/09/30/building-the-azur... https://blogs.windows.com/windowsdeveloper/2020/04/30/rust-winrt-public-preview/ https://blogs.windows.com/windowsdeveloper/2020/04/30/rust-w...

deleted 6y ago

[deleted]