5 ms·

I think describing Rust as a "systems language" in this context is pigeonholing it, and limiting your options. Rust can be used as a Python replacement despite

I think describing Rust as a "systems language" in this context is pigeonholing it, and limiting your options. Rust can be used as a Python replacement despite not sharing some of its properties. It's a matter of choosing the tradeoffs the author is comfortable with: the familiarity with and availability of libraries, the ability to run unfinished code versus being informed about mistakes at compilation, etc. There's nothing inherent about Rust that makes it unsuitable for high level projects.

amelius 5y ago
> There's nothing inherent about Rust that makes it unsuitable for high level projects. Dealing with garbage is a waste of intellectual effort, and is not something you want to be doing in high level projects.
- rhn_mk1 5y ago
  Dealing with typos at runtime is a waste of intellectual effort, and yet no one claims Python is unsuitable for high level projects because of that. There's a big gap between "not perfect" and "unsuitable".
  - amelius 5y ago
    This is true. In the end all programming languages are Turing complete, so you can't really argue about the power of one language over another in terms of what projects you can do with them. This is about ergonomics, and my point is that there are better alternatives with a lower cognitive load, freeing your brain to think about high level architecture, or other important things such as security, or reducing time to market, improving maintainability, etc. I have nothing against Rust. I'm sure it is a great language for systems work. I would love to see a language combining the power of Rust with that of e.g. Haskell, so Rust code could be used in the inner loops and Haskell code could orchestrate the high-level parts of the application. But let's not fool ourselves that Rust is the best choice of language for just about any project, which is the impression you get from all of these Rust-oriented blogposts on HN lately.
    - rhn_mk1 5y ago
      I think the big deal here is that Rust is the best language choice for many tasks among the languages an average coder might know. For me, it's taken over a whole bunch of tasks for which I'd have whipped out Python before, which really surprised me. But it's absolutely not perfect at those tasks. Worse, now I see how Python was never perfect at them. I wish I knew which language combines their advantages for prototyping high level things.
amelius 5y ago
> There's nothing inherent about Rust that makes it unsuitable for high level projects. I don't agree. A garbage collector is very useful for high level projects. The problem with Rust is that you might run out of options once your project grows bigger. So in fact, choosing Rust is limiting your options. Garbage collected closures are very powerful, and missing in Rust. It's probably one of the reasons why Rust has no stable GUI yet.
- detaro 5y ago
  Lots of very large GUI applications and libraries are written in C++, and do just fine without language-level GC. And Rust gives you tools to manage a lot of the issues you have there.
  - pjmlp 5y ago
    There is a reason why many of such frameworks have been moving into a managed layer, including Qt.
- jeffparsons 5y ago
  I think this may be more of a problem for people who are, because of the language(s) they are coming from, used to throwing everything at the garbage collector to sort out. I've been writing Rust for years now, and the number of times I think "jeez, I wish I had a garbage collector right now" are so very few and far between that I can't come up with a single example right now. That is to say, I really think it has more to do with what you're familiar with. > It's probably one of the reasons why Rust has no stable GUI yet. I don't think there's much to this hypothesis. It's more likely that for people who really want something right now, there are plenty of bindings to GTK etc. that work quite well. People who are interested in a novel, idiomatic Rust GUI framework tend to be more interested in thoroughly exploring lots of different ideas than committing to one of them. That is to say, there's not actually any great urgency to slap together something that works that you could call "a Rust GUI", because in practice plenty of those options already exist!
- tlamponi 5y ago
  > A garbage collector is very useful for high level projects. Rust solves most (or even more) of the problems GC does already with the borrow checker, I'd argue that one does not want to spent time thinking about stutters/latency spikes due to micro pauses or stop-the-world events from a GC in a very complex code base — granted GC's got a lot better, but there are still issues out there. At work, we may not be the big, huge enterprise project, but Proxmox Backup Server is not small either and packs a lot of features (REST API, content addressable storage layer, backup management, system (network, time, update) management, ...) together spanning from low to high level. So, I'd figure it has at least a medium complexity. The thought that a GC would help us never entered my mind, nor did any of our devs mention it — most of them explicitly expressed at some time that they are glad there's no GC. Besides that, Rust makes refactoring a bliss, which is a major plus point in big, complex projects with multiple teams working on a (partially) shared code base. > It's probably one of the reasons why Rust has no stable GUI yet. I think that is rather a reason of why a rust GUI could be superior to use, even from another language (GC or not) — I mean, it allows memory management without GC (slightly better performance, faster memory reclaim and no micro-pauses or the like) but also avoids lots of memory (mis)management bug classes. But yes, you're right in that there's no good plain-rust GUI framework with a stability guarantee, druid may be pretty close and has some project showing that it can work OK and look good already, e.g.: https://github.com/jpochyla/psst https://github.com/jpochyla/psst https://github.com/lapce/lapce https://github.com/lapce/lapce
8589934591 5y ago
Would Rust be the most suitable language as a drop in replacement for Python? I have always thought it would be Go.
pjmlp 5y ago
Other than messing with explicit ownership, instead of the friendliness of automatic memory management.

amelius 5y ago

> There's nothing inherent about Rust that makes it unsuitable for high level projects. Dealing with garbage is a waste of intellectual effort, and is not something you want to be doing in high level projects.

rhn_mk1 5y ago
Dealing with typos at runtime is a waste of intellectual effort, and yet no one claims Python is unsuitable for high level projects because of that. There's a big gap between "not perfect" and "unsuitable".
- amelius 5y ago
  This is true. In the end all programming languages are Turing complete, so you can't really argue about the power of one language over another in terms of what projects you can do with them. This is about ergonomics, and my point is that there are better alternatives with a lower cognitive load, freeing your brain to think about high level architecture, or other important things such as security, or reducing time to market, improving maintainability, etc. I have nothing against Rust. I'm sure it is a great language for systems work. I would love to see a language combining the power of Rust with that of e.g. Haskell, so Rust code could be used in the inner loops and Haskell code could orchestrate the high-level parts of the application. But let's not fool ourselves that Rust is the best choice of language for just about any project, which is the impression you get from all of these Rust-oriented blogposts on HN lately.
  - rhn_mk1 5y ago
    I think the big deal here is that Rust is the best language choice for many tasks among the languages an average coder might know. For me, it's taken over a whole bunch of tasks for which I'd have whipped out Python before, which really surprised me. But it's absolutely not perfect at those tasks. Worse, now I see how Python was never perfect at them. I wish I knew which language combines their advantages for prototyping high level things.

amelius 5y ago

> There's nothing inherent about Rust that makes it unsuitable for high level projects. I don't agree. A garbage collector is very useful for high level projects. The problem with Rust is that you might run out of options once your project grows bigger. So in fact, choosing Rust is limiting your options. Garbage collected closures are very powerful, and missing in Rust. It's probably one of the reasons why Rust has no stable GUI yet.

detaro 5y ago
Lots of very large GUI applications and libraries are written in C++, and do just fine without language-level GC. And Rust gives you tools to manage a lot of the issues you have there.
- pjmlp 5y ago
  There is a reason why many of such frameworks have been moving into a managed layer, including Qt.
jeffparsons 5y ago
I think this may be more of a problem for people who are, because of the language(s) they are coming from, used to throwing everything at the garbage collector to sort out. I've been writing Rust for years now, and the number of times I think "jeez, I wish I had a garbage collector right now" are so very few and far between that I can't come up with a single example right now. That is to say, I really think it has more to do with what you're familiar with. > It's probably one of the reasons why Rust has no stable GUI yet. I don't think there's much to this hypothesis. It's more likely that for people who really want something right now, there are plenty of bindings to GTK etc. that work quite well. People who are interested in a novel, idiomatic Rust GUI framework tend to be more interested in thoroughly exploring lots of different ideas than committing to one of them. That is to say, there's not actually any great urgency to slap together something that works that you could call "a Rust GUI", because in practice plenty of those options already exist!
tlamponi 5y ago
> A garbage collector is very useful for high level projects. Rust solves most (or even more) of the problems GC does already with the borrow checker, I'd argue that one does not want to spent time thinking about stutters/latency spikes due to micro pauses or stop-the-world events from a GC in a very complex code base — granted GC's got a lot better, but there are still issues out there. At work, we may not be the big, huge enterprise project, but Proxmox Backup Server is not small either and packs a lot of features (REST API, content addressable storage layer, backup management, system (network, time, update) management, ...) together spanning from low to high level. So, I'd figure it has at least a medium complexity. The thought that a GC would help us never entered my mind, nor did any of our devs mention it — most of them explicitly expressed at some time that they are glad there's no GC. Besides that, Rust makes refactoring a bliss, which is a major plus point in big, complex projects with multiple teams working on a (partially) shared code base. > It's probably one of the reasons why Rust has no stable GUI yet. I think that is rather a reason of why a rust GUI could be superior to use, even from another language (GC or not) — I mean, it allows memory management without GC (slightly better performance, faster memory reclaim and no micro-pauses or the like) but also avoids lots of memory (mis)management bug classes. But yes, you're right in that there's no good plain-rust GUI framework with a stability guarantee, druid may be pretty close and has some project showing that it can work OK and look good already, e.g.: https://github.com/jpochyla/psst https://github.com/jpochyla/psst https://github.com/lapce/lapce https://github.com/lapce/lapce

8589934591 5y ago

Would Rust be the most suitable language as a drop in replacement for Python? I have always thought it would be Go.

pjmlp 5y ago

Other than messing with explicit ownership, instead of the friendliness of automatic memory management.