First, there's nothing "toy: about Swift. It's a full featured language on par with Rust, Go, etc.
Second, whether some random web dev or embedded C dev or Java dev wants Swift or not is irrelevant to its intended audience and utility. It's not for "professional developers" in general, it's for Mac/iOS application developers, and thus, for Mac/iOS users (that benefit as a side-effect from developers having a modern/better language to implement stuff).
>I'm buying a powerful laptop, I don't want cloud storage.
So? Millions of users do want it, judging from the huge popularity of Dropbox, Google Drive, MS implementation of the same, etc.
>I want the possibility to dual boot or share drives with other operating systems, I don't need a new proprietary filesystem.
Again, irrelevant. Lots of Mac users, and tons of pundits HAVE asked for a "new proprietary filesystem" to replace HFS+ and Apple obliged.
And whether you can "dual boot" or "share drives" is orthogonal to whatever OS X has a new native filesystem. You can still format the rest of the hard disk on another fs to dual boot, and you can still share drives with other systems in NTFS, xFAT, etc.
>I don't want compressed memory, I want 32GB of RAM.
And I want a pony unicorn. But until Intel delivers boards that accept 32GB low-power RAM of the kind that goes into Apple laptops, we're not gonna get it. And Intel gives late 2017 / early 2018 as the date for those. (Existing PC laptops with 32 GB ram merely sacrifice battery life using regular high power drawing RAM -- and even those are far and few between).
(And of course compressed memory helps whether you have 16 or eventually 32GB of ram)
>In short, Apple is spending a lot of effort making features that I, as a professional developer and 20 year Mac user, don't want.
Well, as a 15 year Mac user and 20 years professional developer, I do want those things.
I don't particularly care for the touch strip though -- I'd prefer it to be OLED physical buttons giving both tactile feel AND changeable inscriptions.
Yet just about everyone uses local FS with cloud for backup or sharing of a small subset. Giving us an odd cloud first strategy seems more suited for a phone or severely storage constrained devices.
> Again, irrelevant. Lots of Mac users, and tons of pundits HAVE asked for a "new proprietary filesystem" to replace HFS+
Seem to remember that most of that conversation was of ZFS. They even got a long way into the ZFS port before abandoning. HFS+ has been getting long in the tooth for years, so a better FS is long overdue! So now we're getting APFS that explicitly doesn't checksum user data[0]! With current storage size, that's disappointing to understate it hugely.
> until Intel delivers boards that accept 32GB low-power RAM
It's funny, if Apple had not significantly reduced the Wh of MBP batteries in the latest generation we could easily have had both. Probably a longer overall life. Teardowns show a lot of empty space around current batteries.
[0] http://dtrace.org/blogs/ahl/2016/06/19/apfs-part5/#apfs-data
What "odd cloud first strategy"? Cloud is just ANOTHER option, not a "first" or privileged one. To the point that Apple also includes a whole new local filesystem (in beta) with Sierra.
>Seem to remember that most of that conversation was of ZFS. They even got a long way into the ZFS port before abandoning.
Oracle bought Sun and poisoned the area with patents and threats.
>It's funny, if Apple had not significantly reduced the Wh of MBP batteries in the latest generation we could easily have had both.
No, we really couldn't. At best we'd have a 10% or so larger battery space. The impact of RAM (there whether you use 32GB or fewer for a task or not) is much larger.
In most cases, not because they want to, but because that's how current software works. Both Dropbox and Google Drive focus on having their own special folder that gets synced; syncing the OS desktop and documents folders is possible but only with special configuration (on both Windows and macOS).
Cloud first makes perfect sense no matter how much or how little storage you have. It prevents you from losing data if your device is lost or damaged, and if you have multiple devices it allows accessing all your data from any device. If anything, its usefulness depends more on internet connection speed.
I do think Apple's specific cloud storage offerings could be improved for large devices. Currently the highest tier of iCloud storage is 2TB, which costs $20/mo; that's only twice as large as my MacBook Pro's SSD, and fairly expensive. But it's the same price/GB as both Google Drive and Dropbox, so it can't be that much of a ripoff...
Until that other OS has support for the new proprietary filesystem, it won't be able to read it. Since Apple and Microsoft categorically refuse to implement any of the many featureful existing filesystems, one is stuck with archaic NTFS (with no file permissions) or FAT (with less than 4gb files) to keep data.
In NTFS, each file or directory can have arbitrary access control list specifying granted and denied permissions for users and groups.
Those lists are typically inherited down the directory hierarchy, but that inheritance can be stopped.
xFAT which I already mentioned is supported and doesn't have a 4GB limitation. You can have up to 128 pebibytes (which should be enough for everybody: that's ~144 petabytes).
I've heard these words so often that they've lost any meaning to me. :)
A language with no promises of stability counts as a "toy" in my mind (I understand that this can be subjective, just providing my opinion).
Say what you want about Objective-C, but at least Apple stuck with basic syntax decisions.
Migrating is a pain, but I'll take the Swift migration pain over the maintenance of old Objective-C code any day. Even on large projects.
As a Linux/Windows developer you are not the target audience (which I already addressed).
Besides, just because you can't use it, it doesn't make it a toy language, just a language that doesn't have support (or full support) for Linux.
A toy language has a specific meaning, it's not a generic work for "language I can't use professionally on my platform/industry".
I can't use Forth to make web apps either, which is were I make all of my money, but it's not a toy language by any means.
As a developer for Apple platforms, am I right to consider C# or Java toy languages, too?
C# that he mentioned wouldn't be toy languages even if there were 0 Apple and Android C# apps. It would just be a totally professional Windows language with no Android/iOS support.
C# was professional even when it only supported Windows (and partially FreeBSD), before Mono came along...
As well as the decade-plus when Mono existed but wasn't owned by Microsoft, making cross-platform support merely incidental or even a negative from Microsoft's perspective.
That's some amazing CoolAid you've got there. But I'll grant you that it's on the same level with a bunch of other new languages that also aren't in general use for serious long term products yet.
But until Intel delivers boards that accept 32GB low-power RAM of the kind that goes into Apple laptops, we're not gonna get it.
Yeah, wouldn't it be great if Apple made this happen? That's the kind of innovation I want to see.
As for the bulk of the rest of your points, developers and common Mac users have different priorities, and your opinions are not mine. Who better represents professional developers will take time to find out.
Adding something with marginal utility for the majority of their users (since even pros can do just fine with 16GB) just because some insignificant minority runs multiple VMs on their Macs?
That's not the kind of innovation Apple was ever, ever, interested in.
Then you're in luck. APFS isn't proprietary, as Apple's website claims that "Apple plans to document and publish the APFS volume format specification when Apple File System is released for macOS in 2017." So there will be nothing preventing drivers from being written for other operating systems, though of course it will require someone to actually do the work. In return you get a FS that improves on HFS+ in reliability, performance, and features (volumes). If there is enough interest I imagine it might even compete with btrfs for use as a root volume for Linux installations… though there probably won't be.
You may criticize Apple for not open sourcing their implementation of APFS, though I'm holding out hope they will do so eventually. An open source implementation would definitely be useful as a starting point for drivers for other operating systems, but to be fair, it would still require someone to spend the time to port it. Apple's HFS+ driver is open source as part of xnu, but Linux hfsplus doesn't support journaling which was added in 2002. That's not Apple's fault.
Great. ... anyone else still waiting for the open FaceTime API announced in public on stage by Steve Jobs?
Only people who missed the part that some other company took them to court over a BS patent on it and won, so they couldn't finally do it.
Meanwhile, they HAVE opensourced other stuff, including Swift, in the meanwhile, so it's not like they have some big history of backtracking on open sourcing promises...
The rumor is that Apple changed its mind due to the VirnetX patent lawsuit, which forced it to switch FaceTime from P2P to relaying all calls through a central server. But who knows if that's the whole story. I'd still like to see an open FaceTime.
In short, Apple is spending a lot of effort making features that I, as a professional developer and 20 year Mac user, don't want.