8 ms·

This'll be a fun comment section. Maybe Go isn't so simply the answer, but the spread of "write everything in Rust" or "Rust is the salvation of software" is c

This'll be a fun comment section. Maybe Go isn't so simply the answer, but the spread of "write everything in Rust" or "Rust is the salvation of software" is crazy. It's got huge advantages but it's really a very difficult language for what it does. 80% of software (nonsense percentage) that gets targeted to Rust would actually be better in another language. Rust's focus is on (for most devs and software) the wrong things. It's too bad something like a better OCaml or Nim weren't what people were going nuts rewriting stuff in but they don't have the mindshare. Rust evangelism is like using a very advanced hammer to do everything. We've got screwdrivers, chisels, and multitools, yall, use them! Is Rust actually the right tool for the job? As programmers we do tend to seek the one true language which doesn't really exist.

webkike 9y ago
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?
urschrei 9y ago
> but the spread of "write everything in Rust" or "Rust is the salvation of software" is crazy. Sorry to burn down your straw man, but the overwhelming majority of "Rust evangelism" points out that Rust is not always the right tool for the job. The intersection between people who write both Rust and Go (for instance) is substantial, and people in the Rust community (more precisely: communities) go to great lengths to point out that it's not an either / or proposition. Most of the RIIR! hyperbole is something that happens to the Rust community, not on its behalf. > As programmers we do tend to seek the one true language which doesn't really exist. This seems somewhat at odds with your denunciation, mere sentences ago.
- aaron-lebo 9y ago
  If we're talking about strawmen, not sure how you differentiate the one true community from the false community. stevekalabnik and pcwalton show up in every Rust discussion for a reason (no knock on them), the Rust evangelism strike force meme is real, for a reason, this post called "Rust is Software's Salvation" got 172 upvotes and 176 comments for a reason: https://news.ycombinator.com/item?id=13280150 https://news.ycombinator.com/item?id=13280150 The marketing is real, nuance is good.
  - urschrei 9y ago
    > If we're talking about strawmen, not sure how you differentiate the one true community from the false community. I pointed out that there were multiple communities before you did. > stevekalabnik and pcwalton show up in every Rust discussion for a reason I agree completely; their calm, constructive engagement with the HN community has been a tremendous help to Rust's adoption.
  - sgift 9y ago
    > the Rust evangelism strike force meme is real The meme is more real than the strike force itself. For every once I've seen it appear I've hundred times seen that tired meme appear.
mamcx 9y ago
Something must be used against "Everything is done in C/C++/JS. Why change that, ever?".
andreasgonewild 9y ago
One true language, one true paradigm, one true database, one true encoding, one true editor; the list goes on and on and on, that's where forum flame wars and hate mobs are born. The problem is lacking experience; you need to earn enough scars to knock you out of the loop, bump your head against enough walls to realize that the one true way will always fail. As usual; the people who make all the noise don't really know which way is up or down yet, that's what they are so busy trying to figure out.

webkike 9y ago

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?

urschrei 9y ago

> but the spread of "write everything in Rust" or "Rust is the salvation of software" is crazy. Sorry to burn down your straw man, but the overwhelming majority of "Rust evangelism" points out that Rust is not always the right tool for the job. The intersection between people who write both Rust and Go (for instance) is substantial, and people in the Rust community (more precisely: communities) go to great lengths to point out that it's not an either / or proposition. Most of the RIIR! hyperbole is something that happens to the Rust community, not on its behalf. > As programmers we do tend to seek the one true language which doesn't really exist. This seems somewhat at odds with your denunciation, mere sentences ago.

aaron-lebo 9y ago
If we're talking about strawmen, not sure how you differentiate the one true community from the false community. stevekalabnik and pcwalton show up in every Rust discussion for a reason (no knock on them), the Rust evangelism strike force meme is real, for a reason, this post called "Rust is Software's Salvation" got 172 upvotes and 176 comments for a reason: https://news.ycombinator.com/item?id=13280150 https://news.ycombinator.com/item?id=13280150 The marketing is real, nuance is good.
- urschrei 9y ago
  > If we're talking about strawmen, not sure how you differentiate the one true community from the false community. I pointed out that there were multiple communities before you did. > stevekalabnik and pcwalton show up in every Rust discussion for a reason I agree completely; their calm, constructive engagement with the HN community has been a tremendous help to Rust's adoption.
- sgift 9y ago
  > the Rust evangelism strike force meme is real The meme is more real than the strike force itself. For every once I've seen it appear I've hundred times seen that tired meme appear.

mamcx 9y ago

Something must be used against "Everything is done in C/C++/JS. Why change that, ever?".

andreasgonewild 9y ago

One true language, one true paradigm, one true database, one true encoding, one true editor; the list goes on and on and on, that's where forum flame wars and hate mobs are born. The problem is lacking experience; you need to earn enough scars to knock you out of the loop, bump your head against enough walls to realize that the one true way will always fail. As usual; the people who make all the noise don't really know which way is up or down yet, that's what they are so busy trying to figure out.