IBM tailors Swift relationship after 'review of open source priorities' An announcement to the Swift forums indicates IBM is discontinuing its work on server-side Swift. IBM team leader Ian Partridge and technical architect Chris Bailey are leaving the Swift server workgroup. Apple's Swift language was released in late 2014 and soon became popular as a modern programming language for iOS and Mac …
I recently moved a Swift project from Kitura to Embassy/Ambassador (by Envoy) for two reasons:
1) Smaller footprint (Kitura pulls in a bunch of dependencies)
2) Support for HTTP long polling
I was impressed by Kitura though. It is solid and the most professional Swift library I have worked with so far.
Experienced with open source software but new to Swift I find it difficult to navigate the range of open source Swift libraries. Take for instance the main SwiftyJSON project with more than 19k stars on github, why would one choose the IBM fork with only 116 stars? Well, spending hours on fixing bugs in the main fork and later realizing that those bugs had already been fixed in the IBM fork was motivating. Looking closer at the latest string of commits to the non-IBM fork was the deciding factor. The IBM-fork is of higher quality and one can only hope that it replaces the main fork some day.
Thanks to IBM for contributing to the open source Swift community.
Not if you're stuck with cocks hiring other cocks to carry on the cockness. A place I worked at used to have cocks but luckily for them they hired a CEO who isn't a cock and they began to remove all the old cocks to replace them with ones that weren't cocks. So the culture changed for the better. There were actual non cocks over the years before that and they stayed, they were just drowned out over the previous years by the main cocks so couldn't steer the company away from that attitude until the new CEO arrived.
I suspect IBM has clearly, never managed to get rid of all the main cockness.
I did get to gloat to a very Apple obsessed coworker today.
He was under the opinion that Swift was going to take over the world (including server space) because Apple told him so.
I did predict this dropping of Swift by IBM because after the initial hype, it turns out that there is so much legacy code written in C/C++ that is too much of a pain to create binding layers against. Most, if not *all* of IBMs products are for maintaining legacy business systems and so Swift just brought in an endless and pointless layer of binding requirements.
For my next prediction, Apple will drop Swift and re-focus on Objective-C (similar to how Microsoft is falling back on C++/winrt and is diverting away from C#).
Again, this prediction is due to the binding issue with Swift. More effort than its worth.
Binding can be done using Protocol Oriented Programming without the need for classes.
With Swift UI and Combine there will be less reliance on Classes going forward, Structures will be used instead.
Classes and objects are not good in multithreaded programming as threads share memory (unlike processes) and instances of Classes are referenced. Structures copy on write so are thread safe.
I mean binding as in: https://developer.apple.com/documentation/swift/imported_c_and_objective-c_apis/using_imported_c_functions_in_swift
There is nothing you can do to avoid the need to wrap every C function you use (i.e from middleware or the OS) with a Swift alternative.
The example in the Apple docs used printf -> swiftprintf.
In a typical project we use about 200+ external calls. I am not binding them just to use a "cool" language ;)
Until Apple introduces a better mechanism to perform cross-talk between C and especially C++ with Swift, ports or non iOS usage will be fairly low I would assume. The truth is that it would be awesome if that part alone was better. It is already bad enough simply trying to work with Objective-C and that was a foregone requirement.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
