4 ms·

I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.

by skohan 7y ago

zozbot234 7y ago
Rust can be quite usable and productive if you know the right shortcuts. The tradeoff is somewhat lowered performance (and Rust makes sure that you're aware of where you're choosing that tradeoff) but that's just the way it goes. It's not like Swift is any different.
- skohan 7y ago
  I think Rust is a fine language, but it's undeniable that it involves more tedium than other languages to use. If there is some tradeoff between safety, performance, and usability, Rust has prioritized safety and performance, where swift has chosen safety and usability. And that's perfectly fine. I am glad that Rust exists for those use-cases where the performance is important, but there are also cases where it's more important to be able to write a lot of code quickly with less friction. It doesn't devalue Rust to admit that there are places where it is not the optimal choice.
  - zozbot234 7y ago
    > more tedium than other languages Perhaps you haven't programmed in Java. Or even C++, for that matter (modern "Core C++" programming can be quite tedious at times). I'd say the jury is still out when it comes to Rust vs. "higher level languages", yes, even Swift. The point of my comment is that the "friction" you're pointing to need not be an inherent property of something like Rust, any more than it is in C++. It remains to be seen if the 'tradeoff' you mention is a binding one.
    - skohan 7y ago
      > Perhaps you haven't programmed in Java. Or even C++, for that matter I never said Rust was the most tedious language, and I would hope it has learned something from those decades old languages. I agree that Rust has some usability issues which can be improved upon without sacrificing safety and performance, but I think that trade off will always be there at some level. For example, Swift’s copy-on-write makes it very easy to reason about value types, but comes at the cost of performance since there will be a lot of copies which aren’t strictly necessary. You can get essentially the same behavior in Rust by cloning everything, but it takes a lot more typing and adds visual noise to your code, because Rust has made the default to be more parsimonious with memory usage. At some level trade offs have to be made. No one language can be all thing a to all people.
      - pjmlp 7y ago
        Thing is, yes it might cost performance, but does it matter? It all boils down to, does it deliver what the customer of an application written in Swift is asking for?
        skohan 7y ago
        Yeah that is exactly my point. In many cases all the extra work you put into writing Rust code for the additional performance is just that: extra. It doesn’t add any meaningful value to the final product, and it comes at the opportunity cost of that time you could have spent adding or improving features in a more productive language.
        pjmlp 7y ago
        Yeah, while Rust is paving the way for affine type systems among mainstream languages, and it already influenced design decisions on other system programming languages, including Swift (memory ownership manifest), it isn't the first on my list for UI or distributed computing applications.
        skohan 7y ago
        Yeah to me Rust almost feels like the prototype for the next great programming language. There are a lot of great ideas there, but there are also a lot of awkward edges. Like what it accomplishes from a technical perspective is super impressive, but it would be great if somebody could synthesize all of those concepts behind a cleaner front-end which really nails the ergonomics.
        steveklabnik 7y ago
        A few people have tossed around the idea of “what if Rust but drop the commitment to zero cost abstractions.” That’s probably our principle that causes the most ergonomic hit. Of course, Rust won’t start taking that path, but if I were to start a new language today, that’s what it would look like.
panpanna 7y ago
Go? Kotlin?
- skohan 7y ago
  Go is a nice language for some use-cases, but a bit too light on abstractions for my needs. When I tried Kotlin a couple years ago, it seemed to be marginally behind Swift in terms of the power of the type system and some of the cool things you can do in Swift, and I'm not wild about targeting JVM, but I understand that situation has been evolving so maybe I should give it a second look at some point.
- lokedhs 7y ago
  Kotlin Native is nice, but its compile times are absolutely horrible. I guess some of this comes from Gradle, which is another mess in itself, but when it takes over half a minute to compile Hello World, there is a problem.

I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.

by skohan 7y ago

I would kill for a language with Swift's productivity and usibility and Rust's tooling and ecosystem.

Rust can be quite usable and productive if you know the right shortcuts. The tradeoff is somewhat lowered performance (and Rust makes sure that you're aware of where you're choosing that tradeoff) but that's just the way it goes. It's not like Swift is any different.

skohan 7y ago
I think Rust is a fine language, but it's undeniable that it involves more tedium than other languages to use. If there is some tradeoff between safety, performance, and usability, Rust has prioritized safety and performance, where swift has chosen safety and usability. And that's perfectly fine. I am glad that Rust exists for those use-cases where the performance is important, but there are also cases where it's more important to be able to write a lot of code quickly with less friction. It doesn't devalue Rust to admit that there are places where it is not the optimal choice.
- zozbot234 7y ago
  > more tedium than other languages Perhaps you haven't programmed in Java. Or even C++, for that matter (modern "Core C++" programming can be quite tedious at times). I'd say the jury is still out when it comes to Rust vs. "higher level languages", yes, even Swift. The point of my comment is that the "friction" you're pointing to need not be an inherent property of something like Rust, any more than it is in C++. It remains to be seen if the 'tradeoff' you mention is a binding one.
  - skohan 7y ago
    > Perhaps you haven't programmed in Java. Or even C++, for that matter I never said Rust was the most tedious language, and I would hope it has learned something from those decades old languages. I agree that Rust has some usability issues which can be improved upon without sacrificing safety and performance, but I think that trade off will always be there at some level. For example, Swift’s copy-on-write makes it very easy to reason about value types, but comes at the cost of performance since there will be a lot of copies which aren’t strictly necessary. You can get essentially the same behavior in Rust by cloning everything, but it takes a lot more typing and adds visual noise to your code, because Rust has made the default to be more parsimonious with memory usage. At some level trade offs have to be made. No one language can be all thing a to all people.
    - pjmlp 7y ago
      Thing is, yes it might cost performance, but does it matter? It all boils down to, does it deliver what the customer of an application written in Swift is asking for?
      - skohan 7y ago
        Yeah that is exactly my point. In many cases all the extra work you put into writing Rust code for the additional performance is just that: extra. It doesn’t add any meaningful value to the final product, and it comes at the opportunity cost of that time you could have spent adding or improving features in a more productive language.
        pjmlp 7y ago
        Yeah, while Rust is paving the way for affine type systems among mainstream languages, and it already influenced design decisions on other system programming languages, including Swift (memory ownership manifest), it isn't the first on my list for UI or distributed computing applications.
        skohan 7y ago
        Yeah to me Rust almost feels like the prototype for the next great programming language. There are a lot of great ideas there, but there are also a lot of awkward edges. Like what it accomplishes from a technical perspective is super impressive, but it would be great if somebody could synthesize all of those concepts behind a cleaner front-end which really nails the ergonomics.
        steveklabnik 7y ago
        A few people have tossed around the idea of “what if Rust but drop the commitment to zero cost abstractions.” That’s probably our principle that causes the most ergonomic hit. Of course, Rust won’t start taking that path, but if I were to start a new language today, that’s what it would look like.

panpanna 7y ago

Go? Kotlin?

skohan 7y ago
Go is a nice language for some use-cases, but a bit too light on abstractions for my needs. When I tried Kotlin a couple years ago, it seemed to be marginally behind Swift in terms of the power of the type system and some of the cool things you can do in Swift, and I'm not wild about targeting JVM, but I understand that situation has been evolving so maybe I should give it a second look at some point.
lokedhs 7y ago
Kotlin Native is nice, but its compile times are absolutely horrible. I guess some of this comes from Gradle, which is another mess in itself, but when it takes over half a minute to compile Hello World, there is a problem.