Live data from Hacker News

IBM says Swift is ready for the enterprise

computerworld.com

101–110 of 235 posts

Re: IBM says Swift is ready for the enterprise

#101
post #89

Earlier quoted context omitted.

Yeah but it can't replace C++. Swift was designed to make programming fun/nice not to replace C or C++.

"Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). " 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/

Swift can't do realtime. It has automatic memory management. How do you replace C or C++ with Swift for that? What they mean is that Swift replaces Objective-C on user facing apps(on Apple devices) but I doubt you will see the critical parts of the OS (kernel, drivers, etc) written in 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.

Re: IBM says Swift is ready for the enterprise

#102
post #86

Earlier quoted context omitted.

I thought Apple was not one to usually adopt technologies quickly. That's been a (fair?) criticism of theirs for some time.

On the contrary - they've usually raced headfirst into abandoning old technologies for the hot new thing (early to have only CD and no floppy, early to get rid of CD drive altogether, early to go to USB-C, early to go to 802.11ac, etc.) They've used their weight to create a one-company network effect for up-and-coming standards and technology.

Using their weight, huh. Apple hit 10% market share with the Mac for the first time in 2012. I think it's something like 15% now.

Re: IBM says Swift is ready for the enterprise

#103
post #96

Overall I like Swift and it's certainly a massive quality of life improvement for Mac/iOS devs. 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 un…

Can you elaborate on the cognitive overhead vs a GC language like golang or java? (With regards to memory) 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 appropri…

Speaking only for myself, avoiding or breaking retain cycles is a noticeable problem in Swift code that simply isn't there in languages with a proper garbage collector. Among newer iOS programmers, it's a big point of confusion to figure out when a callback closure should use [weak self] versus capturing self strongly, for example. I've seen a lot of people struggle to understand, completely fail, and end up dogmatically using [weak self] everywhere whether it's needed or not (and sometimes where it's actually harmful).

Re: IBM says Swift is ready for the enterprise

#104
post #86

Earlier quoted context omitted.

I thought Apple was not one to usually adopt technologies quickly. That's been a (fair?) criticism of theirs for some time.

On the contrary - they've usually raced headfirst into abandoning old technologies for the hot new thing (early to have only CD and no floppy, early to get rid of CD drive altogether, early to go to USB-C, early to go to 802.11ac, etc.) They've used their weight to create a one-company network effect for up-and-coming standards and technology.

Early? All of those changes were made after long using old technologies. I wouldn't consider it "raced headfirst into abandoning", more like "everyone wanted to abandon those old technologies but couldn't survive being the first to, so Apple made the move and everyone soon followed".

Re: IBM says Swift is ready for the enterprise

#105
post #92

Earlier quoted context omitted.

It's not really predictable enough for a systems language.

Can you predict what your C compiler with going to do with your code, taking into account UB and compiler specific implementation behaviors not specified by ANSI C?

More than with Swift. I routinely see 100x - 1000x and more performance difference between -O0 and -O in Swift. Considering that the optimiser doesn't give warnings or errors if it can't apply optimisations, that's out of bounds for me for a systems programming language. YMMV.

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.

Re: IBM says Swift is ready for the enterprise

#106
post #21

I cannot take this seriously. Even minor versions of Swift have breaking language changes and depredations. That tells me precisely it is too early for the enterprise.

This should be greatly reduced now that Swift 3 is out. A big part of Swift 3 was getting all of the breaking changes over with so that they can maintain source compatibility from here. There will likely be some small breaking changes over the next year or so as they nail down bits they missed, but it'll be a lot less chaotic than what we saw with Swifts 1 and 2. I realize that "greatly reduced" may not be good enough for you, though. Perhaps next year even that will be done.

Re: IBM says Swift is ready for the enterprise

#107

Earlier quoted context omitted.

I think the pitch is that despite static typing, it offers a lot of multi-paradigm high-level features while remaining elegant with fairly minimal syntax compared to other native static languages like Rust or C++. It automatically manages memory but without a stop-the-world garbage collector and goes a long way to opening a lot of flexible design options to any developer: it has great support for generic programming,…

> It automatically manages memory 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 tha…

Well, technically Swift's memory management is the same as what C++ offers via smart pointers, the only difference is that in C++ it is opt-in (and still very popular). Swift is quite unlike Go or Java's memory management; it is not a GC in the sense that they use it.

Re: IBM says Swift is ready for the enterprise

#108
post #89

Earlier quoted context omitted.

Yeah but it can't replace C++. Swift was designed to make programming fun/nice not to replace C or C++.

"Swift is intended as a replacement for C-based languages (C, C++, and Objective-C). " 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/

Those are the claims. The reality does not match those claims.

Re: IBM says Swift is ready for the enterprise

#109
post #86

Earlier quoted context omitted.

On the contrary - they've usually raced headfirst into abandoning old technologies for the hot new thing (early to have only CD and no floppy, early to get rid of CD drive altogether, early to go to USB-C, early to go to 802.11ac, etc.) They've used their weight to create a one-company network effect for up-and-coming standards and technology.

Using their weight, huh. Apple hit 10% market share with the Mac for the first time in 2012. I think it's something like 15% now.

Their "weight" extends beyond their market share. As an easy example: There are many people that don't own an iPhone 7, but who also know that the iPhone 7 tossed the headphone jack.

Re: IBM says Swift is ready for the enterprise

#110

Earlier quoted context omitted.

To be ready for the enterprise ecosystem basically means that you can sue someone if things go wrong, and you can buy support packages for enormous sums of money. IBM is saying that you can 1) buy bluemix swift from them, and 2) sue them if anything goes wrong - but since they have a great legal team, they probably got ironclad agreements ready to go.

It's not about having someone to sue it's about attracting blame. 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 choic…

This is probably the most important comment in this thread. Being able to delegate blame out to $common-choice on project failures is the difference between that CIO being able to say "hey, not my fault, I bought the Oracle platinum integration package!" to satisfy the board rather than "sorry guys, I really thought my node.js idea would work, it's all the rage with the kids! Haven't you ever heard of Slack?!"

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

Post reply on HN