IBM says Swift is ready for the enterprise
computerworld.com
computerworld.com
(I didn't get the job)
I guess every team is different, but this attitude to dog fooding isn't great.
Apple isn't telling people to go use Swift on the server, IBM is. Apple is telling people to write iOS apps in Swift, which they are also doing themselves.
I'm aware. This is the (humorous) point I'm attempting to make. IBM is adopting technologies faster then Apple. While Apple started it's life out as the Anti-IBM. Indeed it is still fulfilling this role. The (humorous) point being, their roles have in a way swapped.
IBM lost the consumer space and is dominant in F100, while Apple won the consumer space and abandoned the enterprise.
With both IBM & Apple behind Swift the language is being positioned for success in both enterprise and consumer markets. It will be interesting to see how things evolve.
If the share was calculated by individual PC models and not by company, even in the PC business, there would be a bunch of Apple stuff ranking quite high.
So they can scale on many aspects much better than their competition. (plus they still have margins)
And because they have a phone, they could totally ditch the cdrom, because, like, who wants to use a CD on their phone, right?
And the ethernet jack! Man, I felt stupid having to plug my phone into the wall for the internets.
But that headphone jack. Their phone totally blazed that trail, getting rid of that. Wait, what? The Macbook dropped it in 2015?
Surely though, most people that have an iphone use a mac right? That's the leverage point! Well no, only about 10% of iphone users had a mac in 2015. Even if it was 1-1, what difference would it make? There's no leverage to be had. iphones work with windows last I checked, and the growing trend is not bothering to "sync" your phone with a computer at all.
[1] https://9to5mac.com/2016/04/11/apple-mac-market-numbers-idc/
So,"early" not as in before expected, but during the beginning of that time (i.e. more akin to "first").
Most people rebuild their software entirely prior to release, and deliver the entire package. Having a stable ABI doesn't do much to help this scenario.
Linux doesn't have a stable ABI, hasn't hurt its success much.
Linux does have a stable ABI. And GNU'e libc tries to have one but it breaks often enough to be a concern (even with symbol versioning). You're conflating GNU and Linux here.
Well, not ready for their purposes, which (guessing from Java) would be some App/iTunes store backend, etc.
Other teams in Apple already use it for native app development from what I've read.
I'd speculate that "not production ready" is at least partly rationalization or cover for "we really can't afford to screw around with this codebase, even though this is the company's Big New Thing."
Swift is great for client-side work, but I wouldn't use it on the server. Each tool good for a certain job. Our current stack is Swift on the client, Elixir on the server, and I haven't been happier.
The Dock and a few other components of macOS Sierra are written in 100% Swift, according to this year's WWDC.
Choosing the Dock, it's probably one of the smaller end-to-end apps that makes use of many OS features.
So they may have done it purely to prove our Swift for core apps. Now if only they'd have actually updated the UI...
It's probably a reasonably small codebase with well specified requirements, it's a standalone app already, and it's not likely to cause underlying OS performance or stability problems if it lost a little bit of performance migrating to Swift. I'm guessing it could be an experiment to see what parts of the OS are reasonably replaced with Swift?
People have also complained for several yearly releases now that OSX isn't improving as an operating system. It's also been around in various incarnations for like 18 or more years and has likely accumulated some deficiencies that needed addressing. Maybe things need some rewriting now to be positioned to become better in the future and a Swift migration is a good excuse to do both. Enough people are also complaining Apple isn't dogfooding Swift enough internally, so there you go, macOS is starting to dogfood it.
I'd also guess Apple probably has a reasonably hard time hiring for Objective-C positions to work with OS-level code (e.g. they've probably hired all of the existing, interested and qualified people willing to work in the Bay Area already), and the up and coming labor pool of people coming from iOS development is likely to be more interesting in or previously experienced with Swift. Modernizing your codebase where possible now seems like a reasonably way to hedge for the future hiring needs. Apple's been around long enough they likely have people retiring out of some critical positions.
(I believe the Dock "app" also encompasses Mission Control, Spaces and all that sort of desktop interaction wizardry.)
It does. I think it also handles Cmd-Tab. I remember seeing a bug now and then in these things (task switching and desktop spaces etc.) which gets fixed by relaunching the Dock process.
(You can work around this bug by changing some of the defaults in the Mission Control pane of System Preferences... I think the "Displays have separate Spaces" setting.)
They specifically said I should have had more professional Swift experience when they rejected me. Of course all the companies I worked for were being more conservative and hadn't yet made the leap to Swift yet, so getting that professional experience was pretty much impossible. But I guess if anyone can afford to be picky, it's IBM on a project working directly with Apple.
So yeah, IBM is definitely gung-ho about Swift. Apple itself, possibly less so.
Another was something like "In Swift, what are higher-order functions?", which I somehow only heard that term a couple of times before and didn't have fresh in my head, despite using higher-order functions in plenty of programming languages (C#, Python, Ruby, even in Objective-C). That one was a case of knowing the concept but not the term.
I believe those two questions were the main ones that lead to the rejection, because I stumbled and didn't come across as confident there, but was otherwise pretty calm and answered the other questions well. I was in and out of there in 45 minutes, talked to one person who quizzed me on the names of UI objects on a given screen, and then the pop-quiz-style interview with two other people.
I also stupidly didn't show them the app I had partially built in Swift, even though I brought an iPad with me. I think I even mentioned it, and they're like "You have it here?" and I said "It's not finished..." and they just started asking me more questions. It was a working puzzle game, but some of the logic for clearing matches was wonky at the time and was visibly broken so I was hesitant to show it.
http://uk.businessinsider.com/hp-shutting-down-hp-helion-pub...
The last thing you'd want is to do a big migration then find the rug pulled from under you.
But I don't see as much upside for enterprise development. Server side tooling and deployment is still TBD, reference counting adds non-negligible cognitive overhead vs GC in an environment where the downsides of GC matter much less. They will have to build a complete ecosystem of server-side libraries from scratch. And unlike on iOS/OSX, there are already a lot of good and much more mature alternatives.
I wouldn't be unhappy if Swift became a real contender on the server but it seems unlikely to me that it will.
To me sure there is things you think about but generally memory performance is less of a mental burden.
Also, swift 4 is supposed to support a rust like memory model. Not sure if it's opt in or how it will work but my impression is that it's memory model is about to support some new use cases to make it appropriate for more memory critical tasks.
With Rust, while you can make use of the type system, it is harder for the compiler to provide such guidance, unless the types are somehow blessed.
My Swift experience is constrained to the GNU/Linux version, so I don't know if XCode is already doing something in this direction.
Sure one can have blessed library types that the compiler knows about, but then from language design point of view it creates a decision between those types and others written by developers, but with similar semantics.
There's nothing wrong with special treatment for stuff in the standard library. C and C++ already do this with many things (e.g. many compilers understand calls like memcpy and will emit optimized code based on the standard library semantics) and Swift gives special treatment to built-in types like Optional.
The distinction here is fairly blurred. The Swift implementation of weak pointers is mostly in the runtime library already, it's just that the compiler hides it a bit so you don't write the names of the calls directly.
Thanks for clarifying.
I only mentioned Rust, because of ergonomics, since the compiler cannot guide the user unless the types are known.
Or is already something in place to make use of intrisics for better error messages in such cases, instead of just giving a type error?
On the other hand reference counting is extremely slow. So slow that it puts a lot of restrictions on API design and that is definitely a mental burden. Swift's own collection interface changed massively between 2.x and 3 and I believe the main reason for the redesign was that the old design required too much reference counting. (I'm not completely sure this is an accurate reflection of their thinking though)
This is very wrong on both points. Reference counting has a lot less mental burden compared to GC, because it's predictable. You can rely on destructors to actually work and be useful. For example, you don't have to keep track of whether you closed your file descriptor or not, but in GCd languages you have to do that manually, sometimes even with the same reference counting, but hand-written and explicit. Reference counting is also very fast, with the exception of concurrent decades old implementations, that are irrelevant today.
But incrementing/decrementing an atomic value in a tight loop apparently creates a performance problem that is severe enough for the Swift team to redesign their API. That wasn't decades ago:
"Code that handles indices has to perform atomic reference counting, which has significant overhead and can prevent the optimizer from making other improvements."
https://github.com/apple/swift-evolution/blob/master/proposa...
This is a typical Apple product to me - they obsessed over their idea of correctness and ended up with something that is difficult to use and completely alien. Meanwhile every other language offers convenience without even stopping you from doing anything else that you might need to do with Unicode...
This is a perfectly valid analogy. Visible characters in a strings are to Unicode code points as high-level functions in high-level code are to assembly commands.
Furthermore, even without using an analogy I'm quite comfortable in saying, again, that I want Strings sugarcoated because 99.9% of the time I don't give a fuck about some bullshit ivory tower corrected view of things that makes the common scenario more difficult than it needs to be.
IBM's days of having a voice in that conversation are probably more limited than they realize.
Cool! https://www.theguardian.com/australia-news/2016/sep/23/austr...
Now that you enlightened me I can see the stock markets, hospitals, banks and all enterprise consumers embracing Swift and eager to upgrade once Swift 4 is released.
However, Smalltalk later suffered when Visual Age for Smalltalk became Eclipse and IBM switched focus to just Java.
They're still making money hand over fist in maintenance keeping the mainframes up (your state's DMV won't move off MVS/zOS as long as support for their old JCL/REXX stuff is still available, especially those 'cheap' z13s which come in at under 100k) but that's an entirely different tier of customer.
Blame assignment isn't really about who made good decisions, or who worked hard, or any of that, it's a combination of how bad it went and who made uncommon choices:
common choice + failure = external blame (who could have seen it coming?)
uncommon choice + failure = it's your fault for doing it weird
common choice + success = great job!
uncommon choice + success = I don't trust you, but you might be a genius
Since hierarchical relationships function using blame ("responsibility"), making predictable decisions becomes more important than making good decisions at some depth of hierarchy.
(If this sounds strange to you, just replace "node.js" with "Rails 2" and you'll see why ASP.NET and Java's still king in any company with a market cap > 100MM && age > 20 years. It's about continuity of support, and Windows 2016 servers can still run ASP Classic and .NET 2 WebForms apps just fine.)
"Responsibility" == risk mitigation for that purchasing authority.
"Nobody ever got fired for buying IBM"
It has anything interesting over Elixir or Go (well, go's feature is "lack of feature" but you know what I mean) or Scala or Kotlin?
I know that iOS and MacOS desperately needed a modern language, and great for them that they have it now, but does the rest of the world need it?
It appeals to me as a server-side language, and I've never done any iOS work. The reasons it appeals:
- Static types - Good type system - Lots of good support for immutability - Apple is heavily invested in Swift, and very responsive to the community
It has some downsides. I'd evaluate Swift against Clojure and Elixir (which both have good, though quite different, concurrency stories), and maybe Haskell (but that would be tough from a buy-in perspective). But evaluating it against Python (which my team currently uses), it's hard to see a downside; we chose Python for Django and DRF, but we're increasingly not in love with that choice.
The downsides? Well, I find some of its syntax choices a bit odd and inconsistent; I think the pursuit of elegance could have gone much further. And, while I celebrate its pervasive use of closures/lambdas and functional idioms in my many contexts, it lacks true functional data structures that would be necessary to really write in a proper functional style with confidence that the runtime wouldn't suffer.
Also, the implementation of its high-level features is somewhat magical and hidden. You can't depend on performance when using them until you really study them. So much so, that WWDC had a big talk about how to choose language features depending on the type of performance you need, and none of it was intuitive.
Additionally, at least on the Apple platforms, its Objective-C heritage can be a bit annoying. In particular, you can't mix and match closures with "selectors", which is a real shame and missed opportunity for flexibility and elegance.
In which language does optimal performance come for free without really studying it? You have to pay attention to your case and context and use features accordingly, no matter what language you're using..
RC is a stop-the-world garbage collector when the reference count reaches 0 in very complex data structures, which trigger a cascade of deletions.
Also it has issues with sharing data between threads leading to cache coherency contention and locks.
RC does otherwise have very bad interactions with threads of course.
edit: clarify
I have to stop you there. You shouldn't compare anything to C/C++ or Rust after that. You are better off comparing Swift with Go(i.e. both have automatic memory management, nice syntax, static typing, dynamic feeling etc) or Java(automatic memory management, well established in the enterprise world). If Apple was to design a language to respond to Go or Java it would be Swift and that's it. So the pitch is that you have a nice language which encourages productivity and you can share the knowledge/code between server and client.
I agree with the parent that Swift memory management is basically like Go or Java: everything is GC'd (reference counting being a form of GC).
The swift 2 to 3 migration was absolutely insane, I'd estimate Xcode did maybe 25% of the work automatically and left me with hundreds of different errors to convert manually (and often they were red herrings where the actual error was not where Xcode said it was). And you have to rebuild all dependency frameworks on swift 3 as well since the binaries are incompatible. If you use Swift make sure you have 2-3 whole developer days per year to devote to just migrating to the next version in a medium sized project.
Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a project.
I love going back to Ruby dev because VS Code is just such a joy to work in compared with Xcode. Xcode really struggles on my top of the line MBP with 16GB RAM.
I still love the language compared to ObjC but the tooling is abysmal. Every year we hold out hope that Xcode will magically get better but its the iTunes of IDEs at this point.
You can always use AppCode if you don't like Xcode.
On my computer, recent versions of AppCode constantly use at least 100% CPU, even when it's in the background doing nothing. I got this a few times in earlier versions as well, but an "Invalidate caches and restart" usually fixed the problem. No such luck with recent versions. It will always use at least 100% when it's running.
I often get 30 seconds of beachball when I switch back to AppCode from some other app, despite having 16GB of RAM and not running any other remotely heavy app. This will happen even if I just leave AppCode for half a minute in order to check something on a web page. It's gotten so bad that I've developed the habit of checking web pages on my iPad instead of on my Mac, in order to avoid temporarily leaving AppCode.
There is a particularly infuriating bug that will sometimes cause AppCode to freeze when I type the opening parenthesis of a function invocation. When this happens, killing, restarting and typing again won't work, AppCode will freeze at the same spot. The only workaround I have found when this happens is to type my function invocation in some other editor and copy and paste to AppCode (often after waiting the usual 30 seconds for AppCode to stop beachballing).
It is not just me – all my coworkers suffer from the same problems. AppCode is by far the most annoying app I use on a daily basis. I hate it nearly – but not quite – as much as Xcode.
2. 1st class support for Optionals
3. Support for Structs and Classes
4. Native binary & scripting mode
5. Automatic reference counting (instead of garbage collection)
6. Large standard library
7. Large corporate backer (Apple)
8. Open source
9. Good C, C++, & Obj-C interoperability
10. Decently fast (https://medium.com/@qutheory/server-side-swift-vs-the-other-...)
That's what they said about front-end web developers and now we have nodeJS.
You can also get it today with any commercial JDK like Excelsior JET.
Also, see the top comment here: https://news.ycombinator.com/item?id=11759762 for a JDK discussion against ref-counting, along with this [now incredibly old] paper https://www.cs.purdue.edu/homes/hosking/690M/urc-oopsla-2003...
(N.b. around the time that paper was published, I was in HFT. We used Azul C4 and it just fine to crush even with management taking their typical 30/3 fees. Though to be fair, this was when the easy pickin's were still there to be plucked. Don't underestimate how well good-ol' free Hotspot is now; we're not talking 1996 Jakarta days with Swing)
Modern hardware would be a dream to any of those researchers doing systems programming in GC enabled languages.
I only consider the biggest flaws of Java not adopting AOT from the beginning and the lack of value types. Now the JDK ecosystem needs to wait until Java 10, probably around 2020 or later, to get them.
Not sure about Kotlin (stable version of the language was only recently released; more likely a stable JS target is higher on the priority list), but Scala Native isn't production ready, will likely be at least a year from now; same goes for Scala Meta, and Dotty's even further out, minimum 2 years away.
Swift has a head start here, and a huge captive audience in legions of iOS developers -- unlikely that Scala will be able to compete on the native front directly. More likely Scala.js + React Native may draw some from the JS developer pool that want to take advantage of static types and seamless client-server interop that can be had via Scala/Scala.js today.
In fact, it appears that a Kotlin Native project exists in the sense that a blog post exists that announced a native target is something they're looking into implementing down the road -- hardly a project ;-) Scala Native's been under heavy development for over a year now[1], and even then it's a long way off.
[1] https://github.com/scala-native/scala-native/graphs/contribu...
Features don't matter much I'm afraid.
Compared to Go it's a whole other level of interesting...
Think of Highway 50 (NV) vs Highway 1 (CA).
1. It doesn't have a GC. While the JVM's GC is decent, it can definitely cause latency spikes.
2. It has value types. Go has this, but Scala and Kotlin mean running on the JVM which means leaving memory locality behind. In fact, Swift allows you to select whether you want an object that contains pointers to things or a struct. Go gives you structs and Scala and Kotlin give you pointer-based objects.
If all you care about is syntax, Swift might not be that interesting to you. However, you get options in terms of how the program runs that the other languages you've mentioned don't give you. You can't decide that you want to create an object in Scala or Kotlin that is contiguous in memory. You can't decide you'd rather not have GC pauses in Go.
In many ways, Swift brought together the kind of niceties that have been available before. Generics aren't something new, value types aren't new, objects aren't new, first-class functions aren't new, ARC isn't new, non-nullable variables aren't new, closures aren't new, type inference isn't new. . . But none of those languages have all of those. Go took a hard stance against generics (I'm not going to go into why). The JVM doesn't really do value types. GC has been the standard for most new languages for a while.
Swift definitely offers new things.
Which one?
Java is like C and C++, there are plenty of JDKs to chose from, each it is own set of implementation behaviors, for the different types of customer pocket sizes.
Additionally, you can also explicitly allocate things on the stack.
You can also allocate continuous memory.
It's not running on a VM that Oracle or Microsoft control, and not a language Google controls.
Yes, it is Apple's language, but IBM apparently thinks it will become more popular than one they would control on their own, and picking Apple's language then is, for them, the least risky, as Apple isn't a company focusing on servers.
I am a little sceptical of IBM's business plan, all in on Watson, etc., but I have used their Bluemix hosting services and it is fairly nice. BlueMix is has a great free tier level' you can run one or two small web services or apps for free. It is a good idea supporting Swift in the server.
Side-note: There was an article about the imminent demise of Oracle, but residual support contracts and the need for CIOs to keep renewing those contracts for a few hundred k a quarter is a cheap buy as insurance in the same way you go to PricewaterCooper and not JoeSchmo to get your books audited. (If/when PWC messes up, the board will overlook your failure.)
On the other hand Swift had quite a few breaking changes in 2016.
EDIT: I'm not attempting to discredit the greatness that can be had... Just wanted to describe a feeling which I had while using it is all!
The whole UB idiocy is a different matter, though related because it's perpetrated by roughly the same group of people, for similar nonsensical and non-validated reasons. See my post http://blog.metaobject.com/2014/04/cc-osmartass.html
See also: http://www.complang.tuwien.ac.at/kps2015/proceedings/KPS_201... and Proebsting's Law.
Improvements required for the toolchain in a young language, than Apple, IBM and others will certainly improve.
Taken from https://swift.org/about/
"Swift is a successor to both the C and Objective-C languages."
Taken from https://developer.apple.com/swift/
It's almost like saying javascript will replace C/C++. I want a nice language like Swift (or Go) to replace C but there is none. Rust was the best/latest failed attempt.
https://github.com/mikeash/memorydumper2
I also gave a talk on this subject a couple of years ago. It's out of date by now, but the basics are still more or less intact:
Or peruse the standard library documentation for UnsafePointer, UnsafeRawPointer, UnsafeMutablePointer, and UnsafeRawMutablePointer. These are built-in types that the compiler knows about, and code that uses them should compile down to essentially the same stuff as C pointer code would.
Of course it can, it is just a matter of OS vendors caring to push it down developers throats.
There are ways to manually manage memory if required to do so, but then you suffer the consequences of dealing with Unsafe*.
That is how systems programming languages get adopted, when OS vendors do "my way or the highway".
Would you rather it were dynamic so you could write less code or something?
Java seems to be leaving a gap for various technical reasons. Java also may be seen by some as having strategic challenges under the Oracle stewardship. Go, Swift, Node and others are currently trying to exploit it.
Java took off not the least due to IBM stepping into the SUN court. Now IBM steps into the Apple court...
For that, its often just easiest to use anything non-blocking to serve as the main handler that communicates to your other services. For me, I use node but there are other choices if you don't like javascript.
Most of the time it's not worthwhile to switch to a language just because IBM deems it suitable. I've picked up more than a few freelance gigs where IBM have botched the job and grossly overcharged for something that could be done simply. My clients appreciate my honesty, openness, and simplicity of work.
What they really mean when they say "Swift is ready for the enterprise" is that THEY are ready --- they have developed all the sales materials, support orgs, and hired the "correct" developers (in this case Swift ones) to run their gambit on as big of fish as they can.
I'm pretty sure Swift isn't ready on Windows, which is a shame because most "enterprises" standardized on Microsoft Windows and Active Directory.
Go (golang) has better support for a wider variety of platforms, but it has serious bugs on non-Linux platforms (as of go 1.7.1) that make it unsuitable for the enterprise. Basically, whatever customized Linux distro used at Google will likely get the most time from superstars on the go team. Also, calling C functions and callbacks from C can cause all sorts of issues, and the "cgo isn't go" mantra scares me when considering Windows desktops, etc. as a target platform.
C++ is making a comeback and I like C++14, but backwards compatibility and other factors make it too complex compared to other languages. But at least it supports all the major platforms and there's no worry it'll drop support for one due to vendor politics.
Rust looks promising from a cross-platform perspective like C++, but Rust is still way too new for the enterprise just like Swift. Perhaps in five years, it'll stand a chance in the enterprise (as much as C++) and without the complex baggage from inheriting decades of backward compatibility.
Who knows what'll happen by the time Swift or Rust is considered enterprise ready and truly cross platform -- maybe in 5 years, there will be a cross-platform native compiled F# that doesn't heavily favor one vendor's platform or nim might skyrocket out of obscurity -- who knows, but its fun to imagine and do some coding to make the future brighter.
The real sign would be one day Apple telling us they are writing iCloud service or at least some significant part of it in Swift for Linux.
https://developer.ibm.com/swift/kitura/
Has this one gained the most traction?
https://github.com/vapor/vapor: 6,300+
So I would say IBM is scattering their eggs across multiple baskets.
I think it is more of thing that Swift has more interesting Client/Server/Mobile story than Java. Given that I do not see why IBM would not cut investments in Java.
On Windows, some people reported about using Swift under the new Bash for Windows (Windows Subsystem for Linux).
The GCC ABI 5.0 breakage doesn't play well with Swift source code, when using their own binaries.
IBM seems to make a mess of everything they touch. I really wish Apple had taken a "Thanks but no thanks" stance when approached by IBM.
I also heard Swift 4 is likely to have breaking changes. (ABI) stability will start only on Swift 4 too.
But what do I know...? Swift is great and everyone should abandon whatever obsolete language/tools they have in favour of this shinning thing because it has a nicer syntax.
https://h4labs.wordpress.com/2016/09/17/my-ios-10-and-swift-...
Any breaking changes going forward should be much less. Of course, you might be in the camp that wants zero breaking changes, then Swift probably isn't for you.
However, it's probably best for devs who are already using it for apps (code reuse, experience, etc). For other dev, I might try Elixir, for example, for web dev. It is gaining a lot of momentum. A critical mass in adoption means better support, quicker answers to questions, etc. We all can't pay IBM to worry about the details.