3 ms·
But the framework dependency is exactly why I mention the C++ interop and Foundation rewrites. Swift prior to the interop didn’t interest me as much for cross
by dagmx 3y ago
But the framework dependency is exactly why I mention the C++ interop and Foundation rewrites.
Swift prior to the interop didn’t interest me as much for cross platform use, primarily due to ecosystem .
That has changed significantly because the ecosystem just magically expanded. I can use most C++ libraries I throw at it. Foundations rewrite means I can use a more comprehensive stdlib everywhere.
IDE tooling is definitely a weak point but I think that’s easier to rectify than ecosystem. The biggest loss has really been the Swift plugin for CLion and the entirety of AppCode for me. But when they were around, they worked very well and so the foundation for it is already there along with the Swift LSP to improve on.
- pjmlp 3y agoFrom my experience dual language approach always adds some atriction across the board, in tooling, building infrastructure and debugging layers. Hence why while I could use C++/CLI on my hobby coding to stay on the confort of .NET, with a couple of bindings being used from C#/F#, I end up using straight C++ instead.
- dagmx 3y agoIn my experience, it’s the opposite. Most people tend towards the easier language unless they need to be maintaining the bindings or something on the other end. Perhaps you’re considering mixed language projects. I’m talking about primarily Swift where I can just import C++ libs over. The fact that it’s C++ is easily hidden, especially with the use of SPM. I think Python is a big example. So many people stay on the Python side for things like Qt.