Live data from Hacker News

IBM says Swift is ready for the enterprise

computerworld.com

181–190 of 235 posts

Re: IBM says Swift is ready for the enterprise

#181
post #173

Earlier quoted context omitted.

How does that make them any more difficult to use?

The compiler can provide better error messages and guide the user, whereas with library types, at least on C++'s case it requires help from external tooling. 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.

What sort of guidance does Swift provide here? And nothing prevents Rust or C++ compilers from becoming aware of these types and providing specialized diagnostics for them.

Re: IBM says Swift is ready for the enterprise

#182
In '95 I remember going to an excellent Smalltalk course. A year later that lecturer was working for IBM on Java. IBM '96 also bought and then shifted an excellent Software Configuration Management System by OTI towards Java (aka. Eclipse). IBM contributed a huge part of Java networking code too.

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

Re: IBM says Swift is ready for the enterprise

#183

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…

I wouldn't use Swift anywhere that I didn't have to until the terribly klunky and overly verbose Strings API is fixed - https://news.ycombinator.com/item?id=10519711 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 anythin…

To me, the Strings API is one of the best things about Swift. Strings are complicated and as Mike Ash says in that very article, "Swift doesn't sugar-coat it, but instead shows you the reality of what's going on. This can be difficult, but it's no more difficult than it needs to be."

Re: IBM says Swift is ready for the enterprise

#184

Earlier quoted context omitted.

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 th…

Slack is PHP and Jquery, no nodejs AFAIK.

Re: IBM says Swift is ready for the enterprise

#185
Well, that's just not true IMHO. They need the ABI stability or I wouldn't do anything for enterprise. Also, Foundation getting open sourced is a huge part of this to avoid using third party libs for a huge amount of things (HTTP requests for example).

Re: IBM says Swift is ready for the enterprise

#186

Earlier quoted context omitted.

One other downside is XCode. No refactoring support, and lots of errors that give you little help. For instance, if you're trying to implement a protocol which is itself a few layers of nested protocols, XCode will just tell you it doesn't conform and not what method you're missing, so you have to dig through and check every signature of every method carefully. The swift 2 to 3 migration was absolutely insane, I'd es…

I would agree with this. The biggest issue with Swift right now is Xcode. Multiple times each day, syntax highlighting and code completion will break, even though the code is perfectly valid. The lack of refactor support after three Xcode releases and major versions of Swift is inexcusable. Using storyboards is super frustrating due to the load times. It seems no one at Apple tests with more than one storyboard in a…

Well I don't know any experienced developer that would put more than three populated scenes in a Storyboard. I would only add more if it was something like a navigation setup (navcontroller, menu, etc) where I would simply nest a lot of empty screens and link to the real screens with storyboard references.

You can always use AppCode if you don't like Xcode.

Re: IBM says Swift is ready for the enterprise

#187

In '95 I remember going to an excellent Smalltalk course. A year later that lecturer was working for IBM on Java. IBM '96 also bought and then shifted an excellent Software Configuration Management System by OTI towards Java (aka. Eclipse). IBM contributed a huge part of Java networking code too. Java seems to be leaving a gap for various technical reasons. Java also may be seen by some as having strategic challenges…

That's a good point, but do you think that things have a chance of playing out similarly this time around? I get the feeling that web tech was more of an open question at that point, so people would look to a group like IBM to set the standard. I'm not so sure that that's the case anymore (and I make my living building within the IBM ecosystem, so I wish it were so).

Re: IBM says Swift is ready for the enterprise

#188
post #176

Earlier quoted context omitted.

That's not stop the world. Under RC, when a thread is destroying a complex data structure, other threads are free to keep doing useful work. RC does otherwise have very bad interactions with threads of course. edit: clarify

Just like a parallel GC.

parallel != stop-the-world

Re: IBM says Swift is ready for the enterprise

#189
post #73
post #20

So... what's the "elevator pitch" for Swift? 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 has anything interesting over Elixir or Go Compared to Go it's a whole other level of interesting... Think of Highway 50 (NV) vs Highway 1 (CA).

70 mph vs. 15 mph?

Re: IBM says Swift is ready for the enterprise

#190

Earlier quoted context omitted.

How does that make them any more difficult to use?

You have to manually optimize away unnecessary reference counting without help from the compiler.

Rust's borrow checker actually helps with this a lot- you can hand out references to the Rc-ed data without modifying the count, and the compiler will enforce that the count is not decremented until the references are dead. Combined with the fact that plain references are more idiomatic than Rc/Arc, this leads to pretty similar results.
Post reply on HN