Hacker News Reader

Comment by ynniv | Hacker News Reader

I'm a professional developer, I don't want a new toy language. I'm buying a powerful laptop, I don't want cloud storage. I want the possibility to dual boot or share drives with other operating systems, I don't need a new proprietary filesystem. I don't want compressed memory, I want 32GB of RAM. And while I'm at it, I want a laptop with a real keyboard, not keys that have so little travel they feel like a touchscreen.

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.

View on HN

>I'm a professional developer, I don't want a new toy language.

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.

> So? Millions of users do want it, judging from the huge popularity of Dropbox

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

>Giving us an odd cloud first strategy seems more suited for a phone or severely storage constrained devices.

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.

To comment on Apple's "cloud first" strategy, while they do provide local file storage in their APIs, their guideline suggests avoiding creating an option for storing local files since users "expect all of their files to be available on all of their devices." (https://developer.apple.com/ios/human-interface-guidelines/i...)

> Yet just about everyone uses local FS with cloud for backup or sharing of a small subset.

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...

> 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.

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.

Why do you think there’s no file permissions in NTFS?

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.

>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.

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).

> which should be enough for everybody

I've heard these words so often that they've lost any meaning to me. :)

Glad you agree the keyboard sucks

> First, there's nothing "toy: about Swift. It's a full featured language on par with Rust, Go, etc.

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.

That kind of oversimplifies things. From my reading of the Swift mailing list, many things you would consider "basic syntax decisions" will have a profound impact on the stabilisation of the ABI.

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, Swift remains a toy language as it cannot be used to do develop useful applications for Linux and Windows, where I make all of my money.

>As a Linux/Windows developer

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.

Yes, it's wrong to be dismissive like that. But no, "toy language" does not have a specific meaning. It is a slang insult, not a proper technical term.

As a Linux/Windows developer, you probably are not the primary target audience of Swift.

As a developer for Apple platforms, am I right to consider C# or Java toy languages, too?

There are many Java apps for Mac and Apple used to provide its own implementation of the JRE.

There are thousands of Apple and Android C# apps (see Xamarin).

Which, again, is besides the point. The parent was mocking the idea that just because a language doesn't support a platform it can be called a "toy language".

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...

> 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.

Seems like a bit much to say that it's a toy language because it can't (currently) be used to write Linux or Windows applications. There's probably tens of thousands of developers at least making a living developing Swift applications. I bet there's more people making money writing Swift than Haskell and Lisp combined.

First, there's nothing "toy: about Swift. It's a full featured language on par with Rust, Go, etc.

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.

>Yeah, wouldn't it be great if Apple made this happen? That's the kind of innovation I want to see.

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.

You want Apple to make their own CPUs?

No, I want Apple to do what they've done in the past and get Intel to do something for them. http://mrob.com/pub/comp/mac-models.html#intel_special

> I want the possibility to dual boot or share drives with other operating systems, I don't need a new proprietary filesystem.

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.

APFS isn't proprietary, as Apple's website claims that "Apple plans to document and publish the APFS volume format specification

Great. ... anyone else still waiting for the open FaceTime API announced in public on stage by Steve Jobs?

>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...

That was six years ago :)

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.

What about patents?

I haven't heard any statements suggesting that APFS is patented or that Apple wants to charge for licensing it, but it's possible. We'll see what happens when 10.13 is released...

> I'm a professional developer, I don't want a new toy language

Why do you think Swift is a toy language?

Reply on news.ycombinator.com