14 ms·

Why wouldn't they use Swift? Seems odd.

by 1over137 7y ago

saagarjha 7y ago
Swift’s performance isn’t really up for high-performance network processing, at least not yet.
- BubRoss 7y ago
  If it can't fill a network connection by now, I wouldn't hold my breathe.
- zerr 7y ago
  Swift is a LLVM front-end just like Rust.
  - hombre_fatal 7y ago
    You are saying that like it must then be as fast as Rust by this virtue.
    - zerr 7y ago
      No, semantics and idiomatic code matters but I don't think performance oriented Swift code would be significantly slower than Rust. I might be wrong though - feel free to share relevant benchmarks.
      - nicklauri 7y ago
        There are some benchmarks that I think you should give them a look: https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/swift-rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
        zerr 7y ago
        Interesting, thanks! Ref counting has an overhead, of course. I wonder about the performance of the "performance oriented Swift code" - i.e. it would be non-idiomatic, but to avoid ref-counting - something you would write in your inner loop or other similar hot points.
        nicklauri 7y ago
        Yes, they're programs from the benchmarks game that use a lot of UnsafeMutablePointer, which is: > provides no automated memory management or alignment guarantees. You are responsible for handling the life cycle of any memory you work with through unsafe pointers to avoid leaks or undefined behavior. [1] So I think they're "performance oriented Swift code". I'm not familiar with Swift, so sorry if I'm wrong. [1]: https://developer.apple.com/documentation/swift/unsafemutablepointer https://developer.apple.com/documentation/swift/unsafemutabl...
  - fooker 7y ago
    That doesn't magically make Swift and Rust equally performant.
greggman3 7y ago
Why is this downvoted? It's a valid question. Chris Lattner, the creator of Swift, has stated many times his goal of Swift being the best language for all uses.
- OJFord 7y ago
  Maybe one guy's goal isn't the same as 100% corporate buy-in.
- Dahoon 7y ago
  Either you misquote him or he has no idea what he is talking about. Maybe in a walled garden as Apple's it could come pretty close in many instances but One Language To Rule Them All is naive at best.
  - ksec 7y ago
    >Either you misquote him...... Not parent but no, I wish that was the case, he stated it numerous times and he compare it to scaling from Low Level C to Javascript. That was 3 - 4 years ago. I was extremely sceptical of it because it was unrealistic, that is of course very much against the silicon valley optimistic view so it wasn't a popular opinion. But in a recent interview he has definitely rephrase and said it doesn't need to be the best in everything. Now I have another problem, It is not the best at anything, what is it actually good at? That is why I still think Objective-c is going stay for at least a few more years.
- kungito 7y ago
  Ah yes, a creator of a language wanting his pet language to be the best language for everything. That's a first
gameswithgo 7y ago
Rust has more safety features and better runtime performance. So either or both of those reasons.
PudgePacket 7y ago
Why would they use Swift? It doesn't seem like the most fitting replacement for C level infrastructure.
- krzat 7y ago
  I don't see any obvious arguments why. It integrates very well with existing C code, a lot can be done with structs and static dispatch, there are pointers, etc. Not Rust level capabilities, but pretty good.
  - rumanator 7y ago
    > Not Rust level capabilities And you answered your own question. If you aim for performance, "pretty good" doesn't cut it.
    - lmm 7y ago
      > If you aim for performance, "pretty good" doesn't cut it. It does in the overwhelming majority of real cases.
      - malux85 7y ago
        But not at the trillion dollar company that is Apple, which is what we are talking about
        lmm 7y ago
        Even for Apple, if "pretty good" performance were the price of avoiding another "goto fail" then it should be more than worth it.
        malux85 7y ago
        Sure, for some hypothetical tradeoff you just made up then sure ¯\_(ツ)_/¯ But the reason companies as large as apple care so much about performance is because at their scale a 10% difference can easily mean 100,000 physical servers. So they do go to insane lengths to avoid "pretty good"
namelosw 7y ago
Swift is not yet a zero-abstraction-cost language like C or Rust which might be one of their concerns.
- pkolaczk 7y ago
  C is far from zero-abstraction-cost. For example you can't do a generic qsort supporting user defined types with zero overhead, other than with preprocessor macros (ugly, unsafe, unmaintainable).
  - klyrs 7y ago
    I think you've inverted the meaning of "zero abstraction cost" here. It's not that writing abstract code is well-supported and free; it's that the language basics aren't built upon a stack of expensive abstractions.
    - hedora 7y ago
      When I’ve seen “zero abstraction cost” used, it generally has meant that writing high-level abstract code is the idiomatic way to use the language, and that it comes with zero runtime overhead. (This is the main selling point of modern C++.)
  - anonymoushn 7y ago
    This sort of standard seems hard to meet for any language, if the bar is "all abstractions should be included and zero-cost." In practice, you probably write a specialized quicksort for a given type in C to work around the lack of generic quicksort. You do this in the same way you manually convert your suspendable forkable computations into a struct that has all your "local variables" and an "instruction counter" inside to work around the lack of copyable coroutines in almost every language. Depending on your choice of compiler, a more legitimate concern with C is maybe the lack of computed goto. See here about the nonzero cost of missing this feature: https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...
woadwarrior01 7y ago
Reference counting.

Why wouldn't they use Swift? Seems odd.

saagarjha 7y ago

Swift’s performance isn’t really up for high-performance network processing, at least not yet.

BubRoss 7y ago
If it can't fill a network connection by now, I wouldn't hold my breathe.
zerr 7y ago
Swift is a LLVM front-end just like Rust.
- hombre_fatal 7y ago
  You are saying that like it must then be as fast as Rust by this virtue.
  - zerr 7y ago
    No, semantics and idiomatic code matters but I don't think performance oriented Swift code would be significantly slower than Rust. I might be wrong though - feel free to share relevant benchmarks.
    - nicklauri 7y ago
      There are some benchmarks that I think you should give them a look: https://github.com/ixy-languages/ixy-languages https://github.com/ixy-languages/ixy-languages https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/swift-rust.html https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
      - zerr 7y ago
        Interesting, thanks! Ref counting has an overhead, of course. I wonder about the performance of the "performance oriented Swift code" - i.e. it would be non-idiomatic, but to avoid ref-counting - something you would write in your inner loop or other similar hot points.
        nicklauri 7y ago
        Yes, they're programs from the benchmarks game that use a lot of UnsafeMutablePointer, which is: > provides no automated memory management or alignment guarantees. You are responsible for handling the life cycle of any memory you work with through unsafe pointers to avoid leaks or undefined behavior. [1] So I think they're "performance oriented Swift code". I'm not familiar with Swift, so sorry if I'm wrong. [1]: https://developer.apple.com/documentation/swift/unsafemutablepointer https://developer.apple.com/documentation/swift/unsafemutabl...
- fooker 7y ago
  That doesn't magically make Swift and Rust equally performant.

greggman3 7y ago

Why is this downvoted? It's a valid question. Chris Lattner, the creator of Swift, has stated many times his goal of Swift being the best language for all uses.

OJFord 7y ago
Maybe one guy's goal isn't the same as 100% corporate buy-in.
Dahoon 7y ago
Either you misquote him or he has no idea what he is talking about. Maybe in a walled garden as Apple's it could come pretty close in many instances but One Language To Rule Them All is naive at best.
- ksec 7y ago
  >Either you misquote him...... Not parent but no, I wish that was the case, he stated it numerous times and he compare it to scaling from Low Level C to Javascript. That was 3 - 4 years ago. I was extremely sceptical of it because it was unrealistic, that is of course very much against the silicon valley optimistic view so it wasn't a popular opinion. But in a recent interview he has definitely rephrase and said it doesn't need to be the best in everything. Now I have another problem, It is not the best at anything, what is it actually good at? That is why I still think Objective-c is going stay for at least a few more years.
kungito 7y ago
Ah yes, a creator of a language wanting his pet language to be the best language for everything. That's a first

gameswithgo 7y ago

Rust has more safety features and better runtime performance. So either or both of those reasons.

PudgePacket 7y ago

Why would they use Swift? It doesn't seem like the most fitting replacement for C level infrastructure.

krzat 7y ago
I don't see any obvious arguments why. It integrates very well with existing C code, a lot can be done with structs and static dispatch, there are pointers, etc. Not Rust level capabilities, but pretty good.
- rumanator 7y ago
  > Not Rust level capabilities And you answered your own question. If you aim for performance, "pretty good" doesn't cut it.
  - lmm 7y ago
    > If you aim for performance, "pretty good" doesn't cut it. It does in the overwhelming majority of real cases.
    - malux85 7y ago
      But not at the trillion dollar company that is Apple, which is what we are talking about
      - lmm 7y ago
        Even for Apple, if "pretty good" performance were the price of avoiding another "goto fail" then it should be more than worth it.
        malux85 7y ago
        Sure, for some hypothetical tradeoff you just made up then sure ¯\_(ツ)_/¯ But the reason companies as large as apple care so much about performance is because at their scale a 10% difference can easily mean 100,000 physical servers. So they do go to insane lengths to avoid "pretty good"

namelosw 7y ago

Swift is not yet a zero-abstraction-cost language like C or Rust which might be one of their concerns.

pkolaczk 7y ago
C is far from zero-abstraction-cost. For example you can't do a generic qsort supporting user defined types with zero overhead, other than with preprocessor macros (ugly, unsafe, unmaintainable).
- klyrs 7y ago
  I think you've inverted the meaning of "zero abstraction cost" here. It's not that writing abstract code is well-supported and free; it's that the language basics aren't built upon a stack of expensive abstractions.
  - hedora 7y ago
    When I’ve seen “zero abstraction cost” used, it generally has meant that writing high-level abstract code is the idiomatic way to use the language, and that it comes with zero runtime overhead. (This is the main selling point of modern C++.)
- anonymoushn 7y ago
  This sort of standard seems hard to meet for any language, if the bar is "all abstractions should be included and zero-cost." In practice, you probably write a specialized quicksort for a given type in C to work around the lack of generic quicksort. You do this in the same way you manually convert your suspendable forkable computations into a struct that has all your "local variables" and an "instruction counter" inside to work around the lack of copyable coroutines in almost every language. Depending on your choice of compiler, a more legitimate concern with C is maybe the lack of computed goto. See here about the nonzero cost of missing this feature: https://eli.thegreenplace.net/2012/07/12/computed-goto-for-efficient-dispatch-tables https://eli.thegreenplace.net/2012/07/12/computed-goto-for-e...

woadwarrior01 7y ago

Reference counting.