5 ms·

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 pro

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.

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.