IBM says Swift is ready for the enterprise • Hacker News Board

Re: IBM says Swift is ready for the enterprise

#171

Post by emdowling » Mon, Sep 26, 2016, 4:15 PM UTC

dcosson wrote: post #126

hellofunk wrote: post #34

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

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

Re: IBM says Swift is ready for the enterprise

#172

Post by fauigerzigerk » Mon, Sep 26, 2016, 4:18 PM UTC

pcwalton wrote: post #164

fauigerzigerk wrote: post #150

Earlier quoted context omitted.

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

I have never seen unnecessary reference counting be a problem in Rust. That's because not manipulating the reference count requires an explicit action—.clone()—and borrowing is so expressive that you rarely need to manipulate the counts.

I guess that's because in Rust you never need defensive reference counting thanks to the borrow checker.

Re: IBM says Swift is ready for the enterprise

#173

Post by pjmlp » Mon, Sep 26, 2016, 4:21 PM UTC

mikeash wrote: post #141

pjmlp wrote: post #137

Earlier quoted context omitted.

Yes, but they are library calls without any help from the compiler.

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.

Re: IBM says Swift is ready for the enterprise

#174

Post by nicky0 » Mon, Sep 26, 2016, 4:24 PM UTC

misterdata wrote: post #140

Razengan wrote: post #99

Earlier quoted context omitted.

> this attitude to dog fooding isn't great. The Dock and a few other components of macOS Sierra are written in 100% Swift, according to this year's WWDC.

The Dock? Why would they completely rewrite the Dock?

Apparently the Dock team just really liked Swift and wanted to go all-in on it. (According to Federighi.)

(I believe the Dock "app" also encompasses Mission Control, Spaces and all that sort of desktop interaction wizardry.)

Re: IBM says Swift is ready for the enterprise

#175

Post by pjmlp » Mon, Sep 26, 2016, 4:24 PM UTC

pcwalton wrote: post #165

pjmlp wrote: post #129

Earlier quoted context omitted.

It is much easier than in either C++ or Rust.

Technically true, but very misleading in Rust's case. In Rust you rarely have to break retain cycles in the first place, simply because you don't use reference counting much. Things like "weak self" are not a problem, because closures aren't reference counted unless you explicitly make them so (and in fact I don't think I've ever seen a reference counted closure in practice).

I agree.

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?

Re: IBM says Swift is ready for the enterprise

#176

Post by pjmlp » Mon, Sep 26, 2016, 4:26 PM UTC

gpderetta wrote: post #157

pjmlp wrote: post #83

Earlier quoted context omitted.

> but without a stop-the-world garbage collector a 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.

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.

Re: IBM says Swift is ready for the enterprise

#177

Post by fauigerzigerk » Mon, Sep 26, 2016, 4:26 PM UTC

zzzcpan wrote: post #166

fauigerzigerk wrote: post #145

Earlier quoted context omitted.

Reference counting has upsides and downsides. If you look at the lengths that some Java based projects like Spark have to go to in order tame the GC, then you have to question whether tracing GC is the right choice in the age of hundereds of GBs of memory. 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 ow…

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

I don't disagree on the benefits of RAII at all. I love it. It's a much cleaner and more general resource management idea than a tracing GC.

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

Re: IBM says Swift is ready for the enterprise

#178

Post by premium-concern » Mon, Sep 26, 2016, 4:31 PM UTC

mdasen wrote: post #100

nnq wrote: 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 does have some interesting bits. 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 poin…

Scala has value types, and on native all the current restrictions from the JVM are dropped.

Additionally, you can also explicitly allocate things on the stack.

You can also allocate continuous memory.

Re: IBM says Swift is ready for the enterprise

#179

Post by montyedwards » Mon, Sep 26, 2016, 4:33 PM UTC

Swift is good for enterprises that standardized on Macs and ios devices, but there aren't many of those (yet).

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.

Re: IBM says Swift is ready for the enterprise

#180

Post by themihai » Mon, Sep 26, 2016, 4:34 PM UTC

hellofunk wrote: post #107

themihai wrote: post #98

Earlier quoted context omitted.

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

Swift does have a runtime though. In its current form I can't see it replacing C or C++. It may provide more deterministic performance than Go but it's not C. If it were to be designed as C replacement I would expect a roadmap for embedded environments, praise about its mapping to the hardware, how it trashes or at least matches C/C++ on its application domain(i.e. low level/ hardware interface or performance) etc but it's clear that is not the case and its focus is on "apps" first, servers second and maybe a bit of low level.