5 ms·

That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control t

by jasmer 4y ago

That's definitely the elephant in the room. And the fact that it does not have clean and easy C integration. If you could do direct memory stuff and control the ARC stuff, and easily integrate with C ... ... and the docs were clean, and you could easily use something other than XCode ... Then Swift would be huge. It's a neat language but it's just not designed to go beyond Mac. The entire C++ world would move away in an instant to something clean and flexible. Rust is just too specific for most things, and Swift is just about outside. So sad.

myko 4y ago
Using VSCode instead of Xcode should work fairly well: https://www.swift.org/blog/vscode-extension/ https://www.swift.org/blog/vscode-extension/ https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...
sweetjuly 4y ago
I've found Swift->C to interop very well with Swift. Yes, you get absolutely buried in UnsafeXXX wrapped types but it does do exactly what you expected. Going the other way is somewhat "herebe dragons" since @_cdecl is technically non-standardized (though there is a movement to standardize it [1]) but it definitely works fine. [1] https://forums.swift.org/t/formalizing-cdecl/40677/7 https://forums.swift.org/t/formalizing-cdecl/40677/7
galangalalgol 4y ago
What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.
- xedrac 4y ago
  I think for Rust to truly replace C++, it needs a better dynamic linking story. I wish they would make their ABI stable within a given edition. That would make it much easier for people to rely on dynamic linking, similar to how C++ does it. Without it, Rust binaries are quite huge.
  - zozbot234 4y ago
    The stable ABI in Rust is called the C ABI. Which means you can write C compatible dylibs/.so in Rust that can be used by any language with a C FFI. This is used in the real world for seamless rewrites of existing dynamic libraries in Rust - librsvg being a well-known case. You don't need all the hacks OP is talking about.
    - xedrac 4y ago
      Sure, dropping down to a C interface is easy enough, but far from ideal. So much of Rust's expressive power is lost by doing so. What would be the downside of providing a stable ABI for an edition? It seems to me it resolves both sides of the argument on stable ABIs. By the way, I'm mostly thinking about Rust -> Rust dynamic linking.
    - int_19h 4y ago
      In C++ land, classes are a part of the stable ABI. Pretty much everything is, except for templates (but including explicit template specializations).
  - galangalalgol 4y ago
    I think that is a good idea, but dynamic linking seems to be reserved for system level stuff like glibc. When even embedded arm7 targets are shipping as comtainers, what difference does it make if we use dynamic or static linking within that container? The dynamic libraries aren't getting used by multiple executables anyway. The main case I see is to protect yourself from a copy-left license impacting all the bsd and mit stuff from crates.
- jasmer 4y ago
  Rust will not replace C++. Everything is thrown out the window, including developer productivity in order to provide the 'zero overhead runtime guarantee' feature. The code ends up quite laborious, and it's just not suitable for many things, and it doesn't play so easily with C. Most projects do not require what Rust provides at the cost it provides it at. C++ people really wants a C++ that is clean, modern, parsable, without all the legacy cruft. Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better.
  - pcwalton 4y ago
    > Most projects do not require what Rust provides at the cost it provides it at. If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023. > Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better. This is the literal definition of vaporware, without a specific plan for how "newer iterations" will do it better. People have been searching for silver bullets for years in this space and nobody has really found a way to improve on the balance Rust has found without introducing garbage collection of some kind. I personally don't believe a "better borrow checker" can exist without GC (which is not such a bad thing, by the way--in my experience, C++ and Rust developers tend to be unfairly dismissive of garbage collection).
    - lll-o-lll 4y ago
      Swift is memory safe. It’s the better C++ I want, just out of reach because Apple. There is at least one memory safe alternative to Rust that doesn’t require a GC. I’ve made this argument before but here we go again. GC is great and works better and faster than reference counting in most cases, but there are degenerate cases and they matter on phones. One degenerate case is memory pressure. A GC running out of memory will perform terribly. Another case is bounded latency. Most obvious with hard real-time, but also a problem for any system where a long GC pause will lead to failure modes or user dissatisfaction. RC allows for predictable (albeit slower) performance. So if we can agree that “no GC” is preferable in a constrained environment like a phone, but you still want memory safety, then you are left with “is Swift or Rust better for productivity?” It’s pretty obvious that the answer is resoundingly “Swift”.
saagarjha 4y ago
Swift has better C integration than Rust does.

by jasmer 4y ago

myko 4y ago

Using VSCode instead of Xcode should work fairly well: https://www.swift.org/blog/vscode-extension/ https://www.swift.org/blog/vscode-extension/ https://marketplace.visualstudio.com/items?itemName=sswg.swift-lang https://marketplace.visualstudio.com/items?itemName=sswg.swi...

sweetjuly 4y ago

I've found Swift->C to interop very well with Swift. Yes, you get absolutely buried in UnsafeXXX wrapped types but it does do exactly what you expected. Going the other way is somewhat "herebe dragons" since @_cdecl is technically non-standardized (though there is a movement to standardize it [1]) but it definitely works fine. [1] https://forums.swift.org/t/formalizing-cdecl/40677/7 https://forums.swift.org/t/formalizing-cdecl/40677/7

galangalalgol 4y ago

What do you mean about rust being too specific for most things? It seems like a fairly obvious choic for c++ replacement in a new project, the issue is large c++ codebases already exist, and that migration is painful in my experience. Autocxx type support is still largely missing or in work, diplomat seems reasonable, but I haven't had an opportunity to use it for something real yet.

xedrac 4y ago
I think for Rust to truly replace C++, it needs a better dynamic linking story. I wish they would make their ABI stable within a given edition. That would make it much easier for people to rely on dynamic linking, similar to how C++ does it. Without it, Rust binaries are quite huge.
- zozbot234 4y ago
  The stable ABI in Rust is called the C ABI. Which means you can write C compatible dylibs/.so in Rust that can be used by any language with a C FFI. This is used in the real world for seamless rewrites of existing dynamic libraries in Rust - librsvg being a well-known case. You don't need all the hacks OP is talking about.
  - xedrac 4y ago
    Sure, dropping down to a C interface is easy enough, but far from ideal. So much of Rust's expressive power is lost by doing so. What would be the downside of providing a stable ABI for an edition? It seems to me it resolves both sides of the argument on stable ABIs. By the way, I'm mostly thinking about Rust -> Rust dynamic linking.
  - int_19h 4y ago
    In C++ land, classes are a part of the stable ABI. Pretty much everything is, except for templates (but including explicit template specializations).
- galangalalgol 4y ago
  I think that is a good idea, but dynamic linking seems to be reserved for system level stuff like glibc. When even embedded arm7 targets are shipping as comtainers, what difference does it make if we use dynamic or static linking within that container? The dynamic libraries aren't getting used by multiple executables anyway. The main case I see is to protect yourself from a copy-left license impacting all the bsd and mit stuff from crates.
jasmer 4y ago
Rust will not replace C++. Everything is thrown out the window, including developer productivity in order to provide the 'zero overhead runtime guarantee' feature. The code ends up quite laborious, and it's just not suitable for many things, and it doesn't play so easily with C. Most projects do not require what Rust provides at the cost it provides it at. C++ people really wants a C++ that is clean, modern, parsable, without all the legacy cruft. Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better.
- pcwalton 4y ago
  > Most projects do not require what Rust provides at the cost it provides it at. If this is true, it's because most projects should use a GC'd, memory safe language, not because most projects should use memory unsafe languages. There is little to no place for memory unsafe languages such as C++ for new projects in 2023. > Also I think that Rust is a 'V1' version of a borrow checker and I can't wait for newer iterations which I think will be better. This is the literal definition of vaporware, without a specific plan for how "newer iterations" will do it better. People have been searching for silver bullets for years in this space and nobody has really found a way to improve on the balance Rust has found without introducing garbage collection of some kind. I personally don't believe a "better borrow checker" can exist without GC (which is not such a bad thing, by the way--in my experience, C++ and Rust developers tend to be unfairly dismissive of garbage collection).
  - lll-o-lll 4y ago
    Swift is memory safe. It’s the better C++ I want, just out of reach because Apple. There is at least one memory safe alternative to Rust that doesn’t require a GC. I’ve made this argument before but here we go again. GC is great and works better and faster than reference counting in most cases, but there are degenerate cases and they matter on phones. One degenerate case is memory pressure. A GC running out of memory will perform terribly. Another case is bounded latency. Most obvious with hard real-time, but also a problem for any system where a long GC pause will lead to failure modes or user dissatisfaction. RC allows for predictable (albeit slower) performance. So if we can agree that “no GC” is preferable in a constrained environment like a phone, but you still want memory safety, then you are left with “is Swift or Rust better for productivity?” It’s pretty obvious that the answer is resoundingly “Swift”.

saagarjha 4y ago

Swift has better C integration than Rust does.