4 ms·

What are some program that Rust is not always a reasonable choice to write in? Frankly, there may be some areas where another language is slightly easier to pro

What are some program that Rust is not always a reasonable choice to write in? Frankly, there may be some areas where another language is slightly easier to program in than Rust, but I see the value in trying to promote a lingua franca for programming. Different languages causes huge interoperability problems

aaron-lebo 9y ago
I would argue almost anything. Nim writes like Python. The average programmer never worries about lifetimes because there's a GC, which the vast majority of programmers (especially application programmers) have gotten used to over the last 40 years. Rust is a big sidestep in usability, which makes sense if you want to replace C and C++, but not much sense elsewhere. Humans are really, really good at juggling multile languages, it's why we make a new one whenever we can.
- webkike 9y ago
  So you're saying that for almost everything Rust is not a reasonable choice. You then state that a reason for this is because people don't have to worry about lifetimes because it has a GC. There are applications where a garbage collector is simply unnecessary and possibly extremely detrimental. And if you get down to it you'll find an amazing truth: once you learn how writing programs is about as easy without a garbage collector than it is with one and your programs run a lot faster. Using an automatic transmission is a lot easier but manual is not hard and you save a lot of gas.
- sgift 9y ago
  If I can actually use a GC for my problem there is zero reason for me to switch away from Java/Kotlin/JVM language: Great tooling, great ecosystem, very mature. So, the reason to use one of these languages is to get away from the "you can use a GC"-space and then the count of interesting languages gets very small very fast. But sure, if your problem is in the "GC can be used" space, but you like to use new languages .. go for it. It's certainly fun to use a new language to tackle a problem. Just not the most efficient use of someones time in my experience. (But: Fun!)
  - danieldk 9y ago
    If I can actually use a GC for my problem there is zero reason for me to switch away from Java/Kotlin/JVM language: Great tooling, great ecosystem, very mature. Unless you have a language with immutable data structures, ownership is still a problem with a GC. E.g. Consider the case where you have some class with some member variable. You want to provide a getter to obtain the member. Now you have an ownership problem: you could return a reference, but now the caller could mutate the data structure in such a way that it breaks invariants of the wrapping class. So, instead you return a copy, but this can be prohibitively expensive.
chrismatheson 9y ago
Why not solve the interoperability problem instead, then who's gives a flying, about the choice of language :)
- webkike 9y ago
  The interoperability is entirely connected to the choices a programming language makes in order to execute a program. A programming language that has a GC will immediately have somewhat of a challenge in calling native C code. And then there's the identifier problem. Some languages allow different characters than others in identifiers. There are so many issues that interoperability is literally impossible to solve generally or by any single individual.
- bluejekyll 9y ago
  We did, remember Corba? I mean XML-RPC, er SOAP... wait no, REST+XML... REST+JSON, er, Swagger (I should really call it Open-API). Omg, what are gRPC, avro, thrift, and cap'n proto meant to do? I bet if we could all just agree to pick one of those then the interoperability problem will be solved. I know you were referring to C ABI etc, but as others have pointed out, having two GC languages communicating with each other over a C ABI is tough, which is why IPC/RPC exist. Oh, and once we settle this single ABI/Interoperability problem, let's come back to this one-true-language idea... I think there's something there ;)
wolco 9y ago
I think there are many good reasons to use rust. But trying to promote it so everyone uses it everywhere to replace everything is overkill and can kill any chance of widespread adoption. If you only need an spa use react or bue. If you only need a website use php or ruby. If you only need a webservice use node or go. If you only need an operating system use rust or c. Using rust for client side validation is probably not going to work.
- webkike 9y ago
  I'm not arguing that Rust should be used for everything but that Rust is a reasonable choice of language for pretty much everything. It may not be _preferred_, but just like C or C++ can be used pretty much anywhere to great effect.
goatlover 9y ago
But why make Rust The One and not Common Lisp, C++, Java, Go, Haskell, etc? Back in the 90s, people were thinking Java would be The One. Didn't happen. Good luck with convincing everyone that it should be Rust and not their preferred language.
millstone 9y ago
One short answer is anything that needs dynamic linking. Rust has no stable ABI. But that can be fixed. More fundamentally Rust is poorly suited to programs that don't have a hierarchical ownership model. UI programming is a good example. UI elements tend to have lots of cross-references to each other: think event handlers, etc. Of course Rust can support non-hierarchical ownership, but only by applying constraints that don't make sense in UI programming. Imagine if JavaScript's `getElementById()` threw exceptions if the referenced element was already on the stack. That would be silly! In this context, Rust's borrow checking is not a seatbelt but a footgun.
- dbaupp 9y ago
  > One short answer is anything that needs dynamic linking. Rust has no stable ABI. In theory this is problematic, but I'm not sure how often it comes up in practice: a lot of systems-y use cases for dynamic linking are writing low-level libraries that many other languages can use, which currently means exposing a C interface. This is supported and stable in Rust. Of course, this doesn't cover every thing, e.g. pure Rust plugins for pure Rust programs. Although one still can dynamically link, as long as all pieces are compiled with the same version (annoying, but, depending on circumstances, not a complete roadblock due to tooling like rustup). > Imagine if JavaScript's `getElementById()` threw exceptions if the referenced element was already on the stack I'm sure you realise it, but Rust does offer a wide variety of functionality for working with shared data. It is definitely syntactically more verbose than in languages that don't try to tame mutation, but it's essentially equivalent functionality (at least, to languages that use reference counting).
  - millstone 9y ago
    > a lot of systems-y use cases for dynamic linking are writing low-level libraries that many other languages can use, which currently means exposing a C interface. This is supported and stable in Rust UIKit is an example of a high-level dynamically linked library. Rust isn't ready for that category of use case - but to be fair neither is C++ :) > Rust does offer a wide variety of functionality for working with shared data. It is definitely syntactically more verbose than in languages that don't try to tame mutation, but it's essentially equivalent functionality My point regarding shared data is not about Rust's verbose syntax, but about its unwanted runtime checks which no other languages perform. Here's what I have in mind (doing my best pseudo-Rust): struct CounterWidget { count: u32, limit: u32, didClick: fn(), }; impl CounterWidget { fn clicked(&mut self) { if self.count < self.limit { self.count+=1; didClick(); } } fn setLimit(&mut self, limit:u32) { self.limit = limit; } } The Counter widget has a count and a limit, and a callback for when it's clicked. It also has a landmine: if the click callback attempts to call setLimit on the same Counter, it will crash at runtime. This crash is hard to test for and doesn't add any value: why shouldn't the callback be able to adjust its limit?

aaron-lebo 9y ago

I would argue almost anything. Nim writes like Python. The average programmer never worries about lifetimes because there's a GC, which the vast majority of programmers (especially application programmers) have gotten used to over the last 40 years. Rust is a big sidestep in usability, which makes sense if you want to replace C and C++, but not much sense elsewhere. Humans are really, really good at juggling multile languages, it's why we make a new one whenever we can.

webkike 9y ago
So you're saying that for almost everything Rust is not a reasonable choice. You then state that a reason for this is because people don't have to worry about lifetimes because it has a GC. There are applications where a garbage collector is simply unnecessary and possibly extremely detrimental. And if you get down to it you'll find an amazing truth: once you learn how writing programs is about as easy without a garbage collector than it is with one and your programs run a lot faster. Using an automatic transmission is a lot easier but manual is not hard and you save a lot of gas.
sgift 9y ago
If I can actually use a GC for my problem there is zero reason for me to switch away from Java/Kotlin/JVM language: Great tooling, great ecosystem, very mature. So, the reason to use one of these languages is to get away from the "you can use a GC"-space and then the count of interesting languages gets very small very fast. But sure, if your problem is in the "GC can be used" space, but you like to use new languages .. go for it. It's certainly fun to use a new language to tackle a problem. Just not the most efficient use of someones time in my experience. (But: Fun!)
- danieldk 9y ago
  If I can actually use a GC for my problem there is zero reason for me to switch away from Java/Kotlin/JVM language: Great tooling, great ecosystem, very mature. Unless you have a language with immutable data structures, ownership is still a problem with a GC. E.g. Consider the case where you have some class with some member variable. You want to provide a getter to obtain the member. Now you have an ownership problem: you could return a reference, but now the caller could mutate the data structure in such a way that it breaks invariants of the wrapping class. So, instead you return a copy, but this can be prohibitively expensive.

chrismatheson 9y ago

Why not solve the interoperability problem instead, then who's gives a flying, about the choice of language :)

webkike 9y ago
The interoperability is entirely connected to the choices a programming language makes in order to execute a program. A programming language that has a GC will immediately have somewhat of a challenge in calling native C code. And then there's the identifier problem. Some languages allow different characters than others in identifiers. There are so many issues that interoperability is literally impossible to solve generally or by any single individual.
bluejekyll 9y ago
We did, remember Corba? I mean XML-RPC, er SOAP... wait no, REST+XML... REST+JSON, er, Swagger (I should really call it Open-API). Omg, what are gRPC, avro, thrift, and cap'n proto meant to do? I bet if we could all just agree to pick one of those then the interoperability problem will be solved. I know you were referring to C ABI etc, but as others have pointed out, having two GC languages communicating with each other over a C ABI is tough, which is why IPC/RPC exist. Oh, and once we settle this single ABI/Interoperability problem, let's come back to this one-true-language idea... I think there's something there ;)

wolco 9y ago

I think there are many good reasons to use rust. But trying to promote it so everyone uses it everywhere to replace everything is overkill and can kill any chance of widespread adoption. If you only need an spa use react or bue. If you only need a website use php or ruby. If you only need a webservice use node or go. If you only need an operating system use rust or c. Using rust for client side validation is probably not going to work.

webkike 9y ago
I'm not arguing that Rust should be used for everything but that Rust is a reasonable choice of language for pretty much everything. It may not be _preferred_, but just like C or C++ can be used pretty much anywhere to great effect.

goatlover 9y ago

But why make Rust The One and not Common Lisp, C++, Java, Go, Haskell, etc? Back in the 90s, people were thinking Java would be The One. Didn't happen. Good luck with convincing everyone that it should be Rust and not their preferred language.

millstone 9y ago

One short answer is anything that needs dynamic linking. Rust has no stable ABI. But that can be fixed. More fundamentally Rust is poorly suited to programs that don't have a hierarchical ownership model. UI programming is a good example. UI elements tend to have lots of cross-references to each other: think event handlers, etc. Of course Rust can support non-hierarchical ownership, but only by applying constraints that don't make sense in UI programming. Imagine if JavaScript's `getElementById()` threw exceptions if the referenced element was already on the stack. That would be silly! In this context, Rust's borrow checking is not a seatbelt but a footgun.

dbaupp 9y ago
> One short answer is anything that needs dynamic linking. Rust has no stable ABI. In theory this is problematic, but I'm not sure how often it comes up in practice: a lot of systems-y use cases for dynamic linking are writing low-level libraries that many other languages can use, which currently means exposing a C interface. This is supported and stable in Rust. Of course, this doesn't cover every thing, e.g. pure Rust plugins for pure Rust programs. Although one still can dynamically link, as long as all pieces are compiled with the same version (annoying, but, depending on circumstances, not a complete roadblock due to tooling like rustup). > Imagine if JavaScript's `getElementById()` threw exceptions if the referenced element was already on the stack I'm sure you realise it, but Rust does offer a wide variety of functionality for working with shared data. It is definitely syntactically more verbose than in languages that don't try to tame mutation, but it's essentially equivalent functionality (at least, to languages that use reference counting).
- millstone 9y ago
  > a lot of systems-y use cases for dynamic linking are writing low-level libraries that many other languages can use, which currently means exposing a C interface. This is supported and stable in Rust UIKit is an example of a high-level dynamically linked library. Rust isn't ready for that category of use case - but to be fair neither is C++ :) > Rust does offer a wide variety of functionality for working with shared data. It is definitely syntactically more verbose than in languages that don't try to tame mutation, but it's essentially equivalent functionality My point regarding shared data is not about Rust's verbose syntax, but about its unwanted runtime checks which no other languages perform. Here's what I have in mind (doing my best pseudo-Rust): struct CounterWidget { count: u32, limit: u32, didClick: fn(), }; impl CounterWidget { fn clicked(&mut self) { if self.count < self.limit { self.count+=1; didClick(); } } fn setLimit(&mut self, limit:u32) { self.limit = limit; } } The Counter widget has a count and a limit, and a callback for when it's clicked. It also has a landmine: if the click callback attempts to call setLimit on the same Counter, it will crash at runtime. This crash is hard to test for and doesn't add any value: why shouldn't the callback be able to adjust its limit?