4 ms·
Why would they use Swift? It doesn't seem like the most fitting replacement for C level infrastructure.
by PudgePacket 7y ago
Why would they use Swift? It doesn't seem like the most fitting replacement for C level infrastructure.
- krzat 7y agoI 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 agoBut not at the trillion dollar company that is Apple, which is what we are talking about
- lmm 7y agoEven for Apple, if "pretty good" performance were the price of avoiding another "goto fail" then it should be more than worth it.
- malux85 7y agoSure, 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"
- dep_b 7y agoSad but true, performance is possible in swift but it’s not very idiomatic and usually not safe. Rust still looks like Rust and it’s still safe when you have performant code.
- rumanator 7y ago> Sad but true, performance is possible in swift but it’s not very idiomatic and usually not safe. There's nothing sad about it. You pick the right tool for the job. Swift is not designed to be a reference tool in performance-sensitive applications, thus you pick the tools that are. There is no need to shoe-horn the wrong tool just because it's popular of fancy. A tool is just a way for technicians to express their skills, and just because someone is skilled at developing front-ends that doesn't mean he is a competent at developing performant systems-level application. Specialization matters, not only in tools.
- dep_b 7y ago> There's nothing sad about it. Why? It's a drop-in replacement for Objective-C that allowed you to dip into C and C++ code in the same code file, even in one function. Now Swift is faster for most higher level scenarios a front-end developer deals with but it's slower than the C performance Objective-C allowed.
- abjKT26nO8 7y agoI.e. it isn't a drop-in replacement. There is nothing wrong about a language not being good at something. When you want to have everything, you get C++. And working with C++ is just sad.
- rumanator 7y ago> you want to have everything, you get C++. C++ is an excellent example on the perils of developing a tool that's good at everything, because the cognitive load to do anything with it is simply not manageable. Picking the right tool for the job is always the solution.
- msla 7y ago> If you aim for performance, "pretty good" doesn't cut it. "Performance" isn't an absolute, and, going by the fact C++ is apparently acceptable in some "performance" codebases, there's more to it than directly controlling every single RAM allocation and making every single use of memory take maximal advantage of cache. You can't even get that in C without deep knowledge of internal compiler details. Rust gives no finer control than C does, overall, but it installs some guard rails to make the language less accidentally unsafe. That's proof that "performance" isn't the primary goal with this codebase; if it were, it would be re-written in assembly, and the guard rails be damned. So Swift isn't immediately out, unless profiling deems it so.