5 ms·
I think static languages are generally more disciplined and manageable in this regard. The only times I struggled with 3rd party Swift code was when a package i
by mojuba 4y ago
I think static languages are generally more disciplined and manageable in this regard. The only times I struggled with 3rd party Swift code was when a package included some C or C++ code alongside with Swift.
Specifically, I think Apple's philosophy of "everything comes with its own dependencies embedded" saved us a lot of trouble. Sure, it's more disk space and potentially lots of duplicates (just count the number of times various SSL libs are included in a single large and messy application), but it usually just works.
- astrange 4y agoMachO has some features that make this easier than ELF, namely matching libraries by full path and two-level namespaces (external symbols know which library they're found in). Though it's still not great if everyone uses their own SSL library, because then you can't update it if there's a bug.
- mojuba 4y agoYes it's a problem, but because you (as a library maintainer) are responsible for what you are embedding, you should keep an eye on the dependencies and test them with each update. This creates a hierarchy of responsibilities, as opposed to a flat mess that is Linux .so or Windows .dll approach.
- enlyth 4y agoI had a similar experience with Rust when I first tried it a couple years ago. Wanted to make a web server which returns Hello World, and then this crate doesn't compile, this official example from the README throws a compilation error, that crate is the wrong version, etc etc. I tried again today and got it done in 2 minutes, so it seems things have improved.