Windows having multiple C libraries has its own pain points, in particular it's difficult to ship binary libraries that return allocated memory to their consumer (you either need to have the library consumer allocate the memory, which probably explains why so many Win32 APIs have this behaviour, or allow alloc/free functions to be registered). Not to mention different C libraries having their own file handle, TLS, etc state. Unsurprisingly Microsoft now ships the Universal CRT (UCRT) as part of Windows.
Having consumer allocate the memory where possible has other benefits in that the consumer can use more efficient allocation techniques (stack, arenas etc), and given that Win32 API design goes all the way back to the earliest version of Windows running on very resource-limited PCs, that would be the main reason why.
However, in cases where this wasn't consistently feasible - e.g. COM - Windows instead mandates the use of a common API to manage memory: CoGetMalloc etc.
Things I like about Swift: works great on Linux, fun to write in, excellent interoperability with C, C++ and even Java.
Thinks I like less: compile times, binary size, runtime type introspection overhead (Codable performance was killing our application), getting async/await right (still that's always going to be hard whichever way you slice it).
Are they great price points? Their open timecard starts at £2,999 or £5,495 with an atomic oscillator. Those prices are far outside the home hobbyist budget.
They're newer, but they aren't at all similar to what ships on Apple's OSes anymore. These days, the layers have flipped, and CoreFoundation is becoming a wrapper around swift-foundation.
CF functions toll-free bridge the CF types to their Foundation counterparts and invoke the corresponding Objective-C API, which is either implemented directly in Swift, or is a wrapper around the Swift function.
I'm sure it's still a work-in-progress, but their definitive goal is for the OSS swift-foundation codebase to be the same as what ships in their OSes, which was never the case with swift-corelibs-foundation.
swift-foundation will never be the code that ships on the OS, mostly because they always have some private bits they won't expose. Come back when URL bookmarks are part of the open source dump.
Of course the entire binary will never be the same, but the implementation of (for example) DateComponents.swift in OSS swift-foundation will be the same implementation that is used to build the OS library.
Going forward, the bedrock of both the OSS package and the platform [Core]Foundation.framework will be swift-foundation. This is distinct from SCF, which was a novel Swift wrapper around CoreFoundation.
Swift can be just as fast as C or C++. The danger, in my experience, is that it's not always clear what the performance implications of the language's many convenient abstractions are. (A random example, I recently improved one code path by over an order of magnitude by replacing some serialisation that used Codable with hand-rolled code. Still 100% Swift, just paid a lot of attention to avoiding RTTI and allocations.)
reply