7 ms·

Why do you think Swift and Rust are competing on the same grounds or for the same objective? Genuinely curious, i don't know much about Rust.

msk-lywenn 4y ago
I used rust for a while. When I saw and read about swift, my immediate thought was: "hey, this looks like rust's easy mode"
nicoburns 4y ago
Aside from Swift having automatic reference counting, and Rust relying more heavily on its borrow checker, Swift and are super similar languages. If what you want is an ergonomic language that lets you combine the best of ML type systems with C family imperative programming then they’re the two obvious choices.
- kybernetyk 4y ago
  I would not describe Rust as being particularly ergonomic. While it is a suitable replacement for C++, that is not necessarily a high standard to meet.
  - yazaddaruvala 4y ago
    Reading the super majority of Rust code is equally easy or easier than reading Python, or Typescript, or even Ruby. Writing Rust applications is also very ergonomic. The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks. The only Rudy lacking ergonomics is writing net new frameworks or missing framework pieces, or when std is not available. 95%+ of all new Rust code will fall into the bucket of “ergonomic to write and read”.
    - sidlls 4y ago
      This isn't really the case. Rust code is almost as complex as C or C++ for any non-trivial application.
      - Ar-Curunir 4y ago
        That’s just not true. Just the fact that you can reuse libraries easily makes Rust much easier. That combined with memory safety means that the two biggest headaches of C and C++ are just gone.
        Aeolos 4y ago
        I don't know why you are being downvoted, but in my experience this is exactly right. The pain of adding third party C++ dependencies is undeniable, especially in a cross-platform manner. I've had the displeasure of maintaining three different C++ build systems in 3 different companies, and they were all a nightmare. Contrast that with cargo that just... works.
      - gary17the 4y ago
        > Rust code is almost as complex as C or C++ for any non-trivial application. This is also, if not more, true for Swift as well. I've been working with both Swift and Rust (in addition to C++) for some time now and I find real-world, advanced Rust SIGNIFICANTLY easier to read and comprehend than real-world, advanced Swift. This is, IMHO, due to the fact that where Rust chooses to be syntactically simple, explicit and consistent, Swift chooses to be syntactically complex, idiom-based and feature-bloated. Sure, Swift code can look very modern and attractive at times, but usually when it comes to superficial code samples in Apple promotional videos. Otherwise, if you, say, look at a large codebase written by someone else, Swift reads just as badly as C++ complexity-wise.
      - jen20 4y ago
        That doesn’t make it less straightforward to read than Python or Ruby, where you have a variety of dynamic ills to contend with.
      - yazaddaruvala 4y ago
        I’ve worked professionally with Java, Scala, C++, Python, Rust, JavaScript, Typescript, Ruby. None of them are ergonomic for non-trivial applications! The goal is to appropriately abstract away the super minority of code that deals with the non-trivial parts into a nice ergonomic interface. Rust is frankly better than most in the list above at allowing the writer to create an ergonomic interface. Yes it’ll take the writer 3x as long in the short term to create the ergonomic interface but: 1. Relative to everything else creating/maintaining these types of internal abstractions is a super minority of time spent reading and writing code. 2. Unlike other languages, you’ll end up with fewer iterations of the interface because it’ll push the author to really understand the complete interface, rather than shipping a buggy interface that needs iteration. Also refactoring is Rust is simpler than any other of the listed languages (because it self documents more assumptions). 3. The ergonomic interface likely has already been published as a crate. I.e. don’t need to write it at all. These internal abstractions are more likely to be written in their first pass as general purpose than in other languages because of the collaborative design working with the rustc compiler.
    - dataangel 4y ago
      I've been writing rust recently and trying to figure out how to write generic traits using higher ranked trait bounds with understanding variance sufficiently to know I'm not creating a soundness hole is much more difficult for me than writing C++. It's like all the template hackery madness you needed to resort to to do anything mildly interesting in C++98, except it's in the core idioms of the language.
      - yazaddaruvala 4y ago
        > trying to figure out how to write generic traits using higher ranked trait bounds with understanding variance sufficiently I agree! You’re currently dealing with writing non-ergonomic Rust. I’d argue your domain is missing a fundamental reusable library/framework or the framework is currently missing a piece. Once someone publishes the needed library (hopefully it’ll be you) then everyone consuming it can just Lego block multiple crates together. Lego blocking crates together (barring heavy macro crates) is very ergonomic. 95% of all new code written is Lego blocking other crates. 5% of new code written is to build new or improve/patch crates.
    - Zababa 4y ago
      > The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks. I don't think that's true at all, at least it wasn't for me. Async in Rust has always been hard for me, it seems that using it requires knowing about how exactly it works and how your runtime of choice works. This is a lot, and requires a lot of time. The documentation in Rust is above average, however the Rust ecosystem tends to be very unstable. Libraries often pull lots of depencies, many of which aren't even in 1.0, some that have switched to a new version but still have docs made for the old. The guideline from semantic versioning is to release 1.0 as soon as people start depending on it, since the idea is to version the public API. This is not always respected. And goes hand in hand with libraries that are 4 years old and on version 12 or something. I remember actix-web before the 4.0 being particularly hard to get into.
  - peterashford 4y ago
    I have to agree. I find writing Rust painful (probably my fault) and I'm used to writing C & C++.
    - julienfr112 4y ago
      There maybe a causality there ...
  - tialaramex 4y ago
    For me it seems to almost exactly fit my model of how things ought to work, and of course the diagnostics are so much better than most languages. We saw the other day where C and C++ just let you write what seems reasonable but then they do something insane, D says no, that's a syntax error, but Rust's diagnostic gives a name to what you intended, says you can't do that, and suggests how to write it instead. if (a < b < c) C and C++ think that's doing a comparison, coercing the boolean result to whatever type to compare it with the remaining variable, and then acting on the new boolean result. D says that's a syntax error because there should be a closing parenthesis after the variable "b". Rust says "comparison operators cannot be chained" and suggests a < b && b < c Edited to add: Swift says: adjacent operators are in non-associative precedence group 'ComparisonPrecedence' -- which is definitely better than D, but it doesn't offer the helpful suggestion.
jakewins 4y ago
The segment in this interview where Chris talks about Rust and compares the design decisions they made in Swift tied the two languages closely in my head: https://atp.fm/371 https://atp.fm/371 the section on the future hopes for Swift similarly; it seems both Rust and Swift contend to replace C++ in many use cases
- tialaramex 4y ago
  Lattner had a vision for a lower-level Swift, which wouldn't need the support Swift needs today - it didn't end up happening and I suspect is not practical. He talked about it in several places, but obviously by 2018 or so what Chris Lattner thinks about the future of Swift doesn't matter very much. This "lower-level Swift" felt like a similar problem to what Carbon or Herb Sutter's Cpp2 have. They've got something that's unsafe, and they want to somehow build a safe abstraction, but that's a foundation layer, and you've already built a tower of stuff above that, so you need to build it underneath all the stuff you have, which will be way harder than what Rust did where they begin at the bottom. Is it impossible? No. But it might well be too expensive to be pulled off in practice, especially given that you need the result to pay back your expense over and above what exists today e.g. Rust.
manmal 4y ago
I watched a Rust intro video recently that provided a perspective I liked, so I’ll share that here: MS, Apple, Google (and more) all relied heavily on C for low level code that needed to be as performant as possible. It turned out though that C‘s memory management is so problematic that many/most security issues are caused by it. To address that, Google invented Go, Apple made Swift, Mozilla gave us Rust etc. MS is interesting - they tried to write memory safe C and invested heavily, but admitted defeat eventually - and started using Rust. And I think that’s what will happen at most companies eventually. Rust has a lot going for it (faster than C sometimes, excellent WASM support etc). Swift might have been another contender, but Apple kept things too close to their chest for too long IMO. As another poster wrote, Swift certainly won’t die at Apple (and their ecosystem), and Google will certainly keep Go alive. But I think Rust will eventually be used at many/most other companies for anything security or performance critical. Maybe it will replace C as the de facto low level language.
- moloch-hai 4y ago
  This assumes that no subsequent language comes along and steals away all the, um, seekers after novelty lately chasing Rust and Swift.
  - _448 4y ago
    Val[0] language? [0] https://www.val-lang.dev https://www.val-lang.dev
  - ChrisMarshallNY 4y ago
    > and Swift Can’t speak for Rust (but I hear that it is now quite mature -it predates Swift), but I’ve been programming Swift, since the day it was announced. In that time, the language, itself, has matured; possibly to the point that it’s starting to look a bit “Swiss army knife”-like. I’m not exactly your typical jargonaut. I’ve been writing software since 1983. Been through a lot of changes, paradigms, and just plain old bullshit, in that time. I don’t really go for “shiny,” just because all the kids are into it, these days.
    - 4y ago

msk-lywenn 4y ago

I used rust for a while. When I saw and read about swift, my immediate thought was: "hey, this looks like rust's easy mode"

nicoburns 4y ago

Aside from Swift having automatic reference counting, and Rust relying more heavily on its borrow checker, Swift and are super similar languages. If what you want is an ergonomic language that lets you combine the best of ML type systems with C family imperative programming then they’re the two obvious choices.

kybernetyk 4y ago
I would not describe Rust as being particularly ergonomic. While it is a suitable replacement for C++, that is not necessarily a high standard to meet.
- yazaddaruvala 4y ago
  Reading the super majority of Rust code is equally easy or easier than reading Python, or Typescript, or even Ruby. Writing Rust applications is also very ergonomic. The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks. The only Rudy lacking ergonomics is writing net new frameworks or missing framework pieces, or when std is not available. 95%+ of all new Rust code will fall into the bucket of “ergonomic to write and read”.
  - sidlls 4y ago
    This isn't really the case. Rust code is almost as complex as C or C++ for any non-trivial application.
    - Ar-Curunir 4y ago
      That’s just not true. Just the fact that you can reuse libraries easily makes Rust much easier. That combined with memory safety means that the two biggest headaches of C and C++ are just gone.
      - Aeolos 4y ago
        I don't know why you are being downvoted, but in my experience this is exactly right. The pain of adding third party C++ dependencies is undeniable, especially in a cross-platform manner. I've had the displeasure of maintaining three different C++ build systems in 3 different companies, and they were all a nightmare. Contrast that with cargo that just... works.
    - gary17the 4y ago
      > Rust code is almost as complex as C or C++ for any non-trivial application. This is also, if not more, true for Swift as well. I've been working with both Swift and Rust (in addition to C++) for some time now and I find real-world, advanced Rust SIGNIFICANTLY easier to read and comprehend than real-world, advanced Swift. This is, IMHO, due to the fact that where Rust chooses to be syntactically simple, explicit and consistent, Swift chooses to be syntactically complex, idiom-based and feature-bloated. Sure, Swift code can look very modern and attractive at times, but usually when it comes to superficial code samples in Apple promotional videos. Otherwise, if you, say, look at a large codebase written by someone else, Swift reads just as badly as C++ complexity-wise.
    - jen20 4y ago
      That doesn’t make it less straightforward to read than Python or Ruby, where you have a variety of dynamic ills to contend with.
    - yazaddaruvala 4y ago
      I’ve worked professionally with Java, Scala, C++, Python, Rust, JavaScript, Typescript, Ruby. None of them are ergonomic for non-trivial applications! The goal is to appropriately abstract away the super minority of code that deals with the non-trivial parts into a nice ergonomic interface. Rust is frankly better than most in the list above at allowing the writer to create an ergonomic interface. Yes it’ll take the writer 3x as long in the short term to create the ergonomic interface but: 1. Relative to everything else creating/maintaining these types of internal abstractions is a super minority of time spent reading and writing code. 2. Unlike other languages, you’ll end up with fewer iterations of the interface because it’ll push the author to really understand the complete interface, rather than shipping a buggy interface that needs iteration. Also refactoring is Rust is simpler than any other of the listed languages (because it self documents more assumptions). 3. The ergonomic interface likely has already been published as a crate. I.e. don’t need to write it at all. These internal abstractions are more likely to be written in their first pass as general purpose than in other languages because of the collaborative design working with the rustc compiler.
  - dataangel 4y ago
    I've been writing rust recently and trying to figure out how to write generic traits using higher ranked trait bounds with understanding variance sufficiently to know I'm not creating a soundness hole is much more difficult for me than writing C++. It's like all the template hackery madness you needed to resort to to do anything mildly interesting in C++98, except it's in the core idioms of the language.
    - yazaddaruvala 4y ago
      > trying to figure out how to write generic traits using higher ranked trait bounds with understanding variance sufficiently I agree! You’re currently dealing with writing non-ergonomic Rust. I’d argue your domain is missing a fundamental reusable library/framework or the framework is currently missing a piece. Once someone publishes the needed library (hopefully it’ll be you) then everyone consuming it can just Lego block multiple crates together. Lego blocking crates together (barring heavy macro crates) is very ergonomic. 95% of all new code written is Lego blocking other crates. 5% of new code written is to build new or improve/patch crates.
  - Zababa 4y ago
    > The Rust web server frameworks are approaching the ergonomics of Typescript web server frameworks. I don't think that's true at all, at least it wasn't for me. Async in Rust has always been hard for me, it seems that using it requires knowing about how exactly it works and how your runtime of choice works. This is a lot, and requires a lot of time. The documentation in Rust is above average, however the Rust ecosystem tends to be very unstable. Libraries often pull lots of depencies, many of which aren't even in 1.0, some that have switched to a new version but still have docs made for the old. The guideline from semantic versioning is to release 1.0 as soon as people start depending on it, since the idea is to version the public API. This is not always respected. And goes hand in hand with libraries that are 4 years old and on version 12 or something. I remember actix-web before the 4.0 being particularly hard to get into.
- peterashford 4y ago
  I have to agree. I find writing Rust painful (probably my fault) and I'm used to writing C & C++.
  - julienfr112 4y ago
    There maybe a causality there ...
- tialaramex 4y ago
  For me it seems to almost exactly fit my model of how things ought to work, and of course the diagnostics are so much better than most languages. We saw the other day where C and C++ just let you write what seems reasonable but then they do something insane, D says no, that's a syntax error, but Rust's diagnostic gives a name to what you intended, says you can't do that, and suggests how to write it instead. if (a < b < c) C and C++ think that's doing a comparison, coercing the boolean result to whatever type to compare it with the remaining variable, and then acting on the new boolean result. D says that's a syntax error because there should be a closing parenthesis after the variable "b". Rust says "comparison operators cannot be chained" and suggests a < b && b < c Edited to add: Swift says: adjacent operators are in non-associative precedence group 'ComparisonPrecedence' -- which is definitely better than D, but it doesn't offer the helpful suggestion.

jakewins 4y ago

The segment in this interview where Chris talks about Rust and compares the design decisions they made in Swift tied the two languages closely in my head: https://atp.fm/371 https://atp.fm/371 the section on the future hopes for Swift similarly; it seems both Rust and Swift contend to replace C++ in many use cases

tialaramex 4y ago
Lattner had a vision for a lower-level Swift, which wouldn't need the support Swift needs today - it didn't end up happening and I suspect is not practical. He talked about it in several places, but obviously by 2018 or so what Chris Lattner thinks about the future of Swift doesn't matter very much. This "lower-level Swift" felt like a similar problem to what Carbon or Herb Sutter's Cpp2 have. They've got something that's unsafe, and they want to somehow build a safe abstraction, but that's a foundation layer, and you've already built a tower of stuff above that, so you need to build it underneath all the stuff you have, which will be way harder than what Rust did where they begin at the bottom. Is it impossible? No. But it might well be too expensive to be pulled off in practice, especially given that you need the result to pay back your expense over and above what exists today e.g. Rust.

manmal 4y ago

I watched a Rust intro video recently that provided a perspective I liked, so I’ll share that here: MS, Apple, Google (and more) all relied heavily on C for low level code that needed to be as performant as possible. It turned out though that C‘s memory management is so problematic that many/most security issues are caused by it. To address that, Google invented Go, Apple made Swift, Mozilla gave us Rust etc. MS is interesting - they tried to write memory safe C and invested heavily, but admitted defeat eventually - and started using Rust. And I think that’s what will happen at most companies eventually. Rust has a lot going for it (faster than C sometimes, excellent WASM support etc). Swift might have been another contender, but Apple kept things too close to their chest for too long IMO. As another poster wrote, Swift certainly won’t die at Apple (and their ecosystem), and Google will certainly keep Go alive. But I think Rust will eventually be used at many/most other companies for anything security or performance critical. Maybe it will replace C as the de facto low level language.

moloch-hai 4y ago
This assumes that no subsequent language comes along and steals away all the, um, seekers after novelty lately chasing Rust and Swift.
- _448 4y ago
  Val[0] language? [0] https://www.val-lang.dev https://www.val-lang.dev
- ChrisMarshallNY 4y ago
  > and Swift Can’t speak for Rust (but I hear that it is now quite mature -it predates Swift), but I’ve been programming Swift, since the day it was announced. In that time, the language, itself, has matured; possibly to the point that it’s starting to look a bit “Swiss army knife”-like. I’m not exactly your typical jargonaut. I’ve been writing software since 1983. Been through a lot of changes, paradigms, and just plain old bullshit, in that time. I don’t really go for “shiny,” just because all the kids are into it, these days.
  - 4y ago