Winding down the Swift 3 release | Hacker News Reader

Winding down the Swift 3 release

thread.gmane.org

70 pointsmilen63 comments

Now, with swift 3 around the corner, I will ask some most experience fellow developers the following question. There is golang, swift, rust, dlang. If you will put some energy, what language will be, and why? :)

The answer is obvious: Swift if you target iOS. Otherwise, use what is best for you.

Swift for GUIs on OSX / iOS. Go for everything else. Haven't had much reason to play with Rust or D, but also haven't seen nearly as much of them in the wild...

Go for everything else? Swift is moving for everything too, with the cross platform support, IBM adoption, etc...

Cross platform is not yet there Swift 3. I don't know what to make of IBM adoption of Swift, maybe Websphere Business Component are still a thing and a Swift version might enthrall enterprise users. IBM is already bringing Go on s and z series and writing software in Go like full blockchain implementation.

Cross platform isn't there yet though. I'll definitely give it more thought, especially if it does cross-platform GUIs (something Go does not have good libraries for).

That said, Go's tooling, documentation, and ecosystem are much friendlier than Swift's. And since most of us spend more time doing that stuff than actually typing code, it's an important point for me in the comparison.

Swift, most likely.

Go I don't like the design, but I will always suggest it to anyone wanting a simple safe C like language.

D, the community is great, but they still need to decide which direction the language is supposed to grow.

Rust community and language are great, but I think they need to get into an OS SDK to really accomplish the goal of replacing C++.

Swift is replacing C and Objective-C as the official systems language on Apple platforms. It has the necessary tooling for full stack applications, IBM is already pushing it on their cloud services and Microsoft will eventually support it on their iOS bridge.

So in what concerns OS vendor support I am betting on Swift.

For the use cases where that isn't relevant, I would say Rust is also a very good candidate.

Could you expand on an OS SDK in relation to Rust?

If you look at the history of computing, since the early 60's, there were tons of system programming languages.

But the ones that kept surviving between OS generations were the ones being sold by the OS / hardware vendors for their systems, not the ones being sold by third party software companies.

You just need to compare the tooling offered for the programming languages that are part of an OS SDK, with the platform support for other programming languages not part of the SDK.

Bringing an external systems programming language means additional development effort, spent in wrapping OS libraries, integration with debugging tools, compiler toolchains.

Hence why many companies are willing only to work with programming languages that have first class support on the platforms they are targeting.

However, there are also some companies for which such issues don't matter. So if there is a big number of such companies, eventually an OS vendor does pay attention and adds such a language into their offerings.

There are also rumors that Google may be looking at using Swift as an alternative interface to android, that sounds a bit nutty, given that they have golang. But....

1) go is not a suitable candidate for android, as most of the api's are object orientated and involve subclassing sdk classes, which would be awkward and painfull on golang, but not so hard on swift.

2) they would pick up a bunch of companies and devs that are currently building high quality apps for iOS, if swift does succeed in abstracting the foundation classes and provide a reasonable abstraction of the UI classes, it would open up the potential of a universal "app" language, for Mac, Linux, android and iOS.

This may be wishful thinking, but it's worth pushing a few Braincells in that direction.

Swift if you're targeting iOS or OS X and either need GUI or integration with system frameworks, Rust otherwise.

In the long run, Swift, IMO.

It has all the advantages of Go but with a more expressive language, much better C interop and a platform that will create a community around it very quickly, the other day I saw somewhere that there are already more Swift books and courses than Go. Swift will also let you do everything Rust can, very low level stuff.

> Swift will also let you do everything Rust can, very low level stuff.

Not quite. Swift requires a runtime, so you probably won't see people writing OS kernels in Swift.

Swift uses LLVM as backend, so as far as I understand it can generate standalone binaries. No ?

All languages add a bit of code to a binary to make the code you write runnable. Rust [1] and C add almost none, language like Swift and Go have to add their GC support code even if it's in the same binary, and jit+scripting languages generally come with an external runtime.

[1] https://www.rust-lang.org/faq.html#does-rust-have-a-runtime (also mentions what's in the C runtime)

Swift doesn't have a GC and you can use it to program like C with malloc and free via UnsafeMutablePointer<T>.

IIRC, Swift's runtime is like C++'s with v-table lookup for dispatch on functions that do not involve Objective-C objects.

Swift's GC is in the form of pervasive reference counting for reference types with no automatic cycle detection. Though as we're demonstrating, calling this GC is contentious, it would be better if people weren't too lazy to type out "pervasive reference counting for reference types with no automatic cycle detection". :P

(For the record, I believe Chris Lattner is on the record as saying "yes, Swift has a runtime, let's not bother arguing that point" though I can't find the link, but I agree that Swift's runtime is less invasive than most other languages (e.g. Go).)

Does saying 'ARC' not work for you? :)

And the Swift runtime is pretty minimal, mostly used for storing dynamic type information, dispatching protocol methods, generating (unspecialised) generic types, checking conformances etc. It's mostly used by the compiler to add the dynamic features of the language; for example, the compiler observes the lifetimes of variables and inserts retain/release instructions, which are lowered down to a swift_retain or swift_release calls on the runtime instance. These functions are implemented in the runtime and do the manipulation of reference counts and deallocation.

I can see how you'd say that's minimal compared to languages with really huge runtimes — but do you really think it's minimal compared to C or Rust?

It is simpler than a full GC, but I would not call that "pretty minimal". In particular, weak and unowned references and the guarantee that referencing them after the object they referred to was deallocated crashes your program make swift_release nontrivial.

Yes, the swift runtime does stuff like heap allocation & reference counting for classes, type introspection (including `as` casts), error handling, as well as generating instances of unspecialised generic types, and dispatching (dynamic) protocol methods (and other witnesses, like computed properties).

https://github.com/apple/swift/tree/master/stdlib/public/run...

Generating standalone binaries is orthogonal to the presence of a runtime. Go also generates standalone binaries (even more standalone than Rust and Swift) though it indisputably has a runtime.

> Swift is a successor to both the C and Objective-C languages.

Source: https://developer.apple.com/swift/

Objective-C requires a runtime, and the Darwin kernel is not implemented in Objective-C.

Also, Swift, unlike Objective-C, is not a superset of C.

Interesting that you decided to ignore the fact that Apple also mentions C, which is what the Darwin kernel is implemented on, isn't so?

Which also happens to have a runtime, crt0.o.

C has a runtime, used in a "hosted" implementation (your typical *NIX user-space program) - but it's optional, and there is the alternative "freestanding" implementation that doesn't need to have a runtime or standard library, and this is generally used to implement kernels.

http://www.iso-9899.info/n1570.html#4.p6

Doesn't invalidate the fact that Swift could eventually be used in similar scenarios.

Usually in these scenarios I believe it just requires a company to bully developers to accept it and an eventual generation change.

If tomorrow Apple decides, for whatever reason, that new kext or IOKit modules are to be written in Swift, then whoever cares about their Apple OS customers will just comply with it.

What I think you're missing is that using a runtime is impossible in an OS kernel, unless the runtime doesn't use any OS features. You at least need to bootstrap enough of an OS before you can use the runtime. It's not the same thing as kexts or IOKit modules.

It is so impossible that history of computing is full of such examples, but the C community likes to re-write history so thay younger generations don't feel the need to dive into ACM papers about how the world was outside AT&T walls.

Sincerely: I would love to learn about one or more of these. Do you have any links to papers?

Could be, I wouldn't rule it out, but if so I've got serious doubts that it would be the full Swift language - the Objective-C style "dynamic" dispatch seems rather inappropriate for kernel space.

I agree that dynamic dispatch is not suitable for a kernel however if you compile Swift on a linux host then there is no ObjC runtime support anyway so its not an issue. However I would still see it as the full Swift language

It is possible but the Swift stdlib does rely on a minimal set of libc functions including malloc()/free() and the usual str* and mem* functions. Some of the other functionality can be removed eg the math and floating point but even implementing malloc() in Swift would be hard because any data structures that get used eg Arrays will themselves rely on malloc(), and even if you wrote it using UnsafeMutablePointer it would not be much different to a C implentation. Also the globalinit functions that get called at startup themselves rely on malloc() so it ends up being circular.

However if you are willing to accept some functionality will be written in C it is possible to run Swift directly on bare metal.

> However if you are willing to accept some functionality will be written in C it is possible to run Swift directly on bare metal.

I would rather use Assembly or compiler intrinsics instead, just like many C alternatives, some much older like NEWP, do.

Also many of the C library calls are impossible to implement in pure ANSI C without language extensions or Assembly, malloc() and free() being two of them.

Some key differences with Rust:

- Swift code can't be called from C code yet

- Swift has a runtime, Rust does not

Swift can't do everything Rust can, but I also don't expect it to be able to.

i think that as long as swift doesn't have a proper official concurrency model, we can't really know how good it will be as a go competitor on the server side.

Isn't that what libdispatch is though?

Is libdispatch part of the cross-platform Swift effort? AFAIK that's a Mac technology that isn't really used anywhere else.

Yes it is part of a the cross-platform base set of libraries that have been prioritized. You should probably Google before just commenting AFAIKs IMHO.

Don't be a dick. Have a conversation. Be kind.

I did. The top result for "libdispatch linux" is a third-party library, and the second one is a project from Apple with very little activity (looked like a couple dozen LOC changed since the beginning of April) that sounds very far from "winding down" and looked to be more in the mode of "hey, it's open source, so you could theoretically run it on Linux if you wanted" that libdispatch has been in for over half a decade now — so it seemed like a fair question.

I've only used Golang and Swift fairly extensively with a cursory use of Rust. I'm also extremely biased because I'm an iOS engineer, so I'm going to advocate Swift. I really love Golang's concurrency model and the way the dependency system is implemented. It just seems like the Swift team is making more progress at a faster pace right now. The tools surrounding swift like the REPL are also extremely useful for education, documentation and examples.

I've been putting time into Rust. There will always be a need for a C-level language and I think Rust has a strong long-term future. The language as it exists today isn't going to be my all-purpose default but it might be. There are a couple major ergonomic wins coming (trait-based exception handling, impl trait) and a set of first-party language services for IDE support. I think IDE-supported Rust has the potential to be a very productive language, particularly since it's okay without IDE support.

Since this is a Swift thread, I will say that I like Swift except for the parts that are clearly there to interact with Objective C. I have no interest in doing apple os interface development but I'll be seeing how it goes as a server development language when the 3.0 preview happens in June. If Rust for all things doesn't work, core Rust + Swift scripting is the planned fallback.

  > trait-based exception handling

I'm obligated to mention that Rust isn't growing an exceptions system, that RFC was just poorly named. :P

D isn't going to happen.

Go is a wonderfully boring language. That's its technical strength and social downfall.

Rust is the anti-Go. It's an adoption cult with a good language attached.

Swift is pleasantly surprising me with its evolution and cross-platform direction.

I'd recommend Rust, Swift or Go in that order. Personally I'm most interested in Go but I don't think it's the most useful intellectual exercise or career move to learn it at the moment.

can you give more details why dlang is not a good bet. I actually like the language and feature set :) I have the feeling that is to much noise on dlang, and they do not have a clear path, but still :)

Mostly because it's been going on for a decade, and while itself is not catching (much adoptions), other languages that have appeared since have already gotten much more traction, including Go and Swift -- and potentially Rust.

That could be a function of the marketing rather than the language.

I've been using D in production at work. I can't say that it'll never happen, but it's up against some very strong competition, and given its age, I'm not optimistic about it catching up.

D has been going for a long time, and still needs a decent more work before I'd call it mature. Its garbage collector still has global locks around every allocation and scan. On top of that, I've had memory leaks where it turned out that some anonymous closure just wasn't being released by the garbage collector. The fix for that memory leak was giving the anonymous closure a name to eliminate the environment capture.

For that matter, the tooling around things like taking heap snapshots and profiling is rather painful -- there are no good runtime tracing solutions, and the memory profiler built into the GC breaks down allocations by type, and not by allocation site, which is generally not all that useful. Valgrind dies when I try to debug invalid memory use in C code bound to D. Symbols in the local stack frame are spotty in gdb. And, in general, debugging support could stand to be much better.

The threading library (std.concurrency) can't send objects between threads without lots of lying to the type system to make things happy: You can't send shared references by default (we've hacked around this at work, still need to upstream the patch), and you can't send unshared references unless they're immutable. Sounds ok from a safety perspective until you realize that D is built around mutable objects, and there's no way to declare a value class.

There are lots of things to like about D, but I would be very antsy about using D for a system that I had to rely on in any critical capacity, as things stand. At least, not without a willingness to commit to changing the libraries and runtime.

I haven't used Go, Swift, or Rust in production enough to have an opinion on them and their production readiness.

I think I largely agree with your assessment, though I learned Go first and am probably going to pick up Swift or Elixir next.

I work mostly with networked services though, and Rust seems to have a bit of a comparatively (vs Go, Elixir) poor concurrency/async-io story so far -- though I am sure the libraries will come eventually.

Neither one of them is worth putting your energy into. But Go and after that Swift are important for better employment opportunities somewhere down the road.

Might be worth considering C# here too. The open-source cross platform tooling is new and still immature, but it's getting serious resources lately, with new language features (including more null safety) coming, cross platform IDE from Jetbrains in development, Mac / Windows / Linux / Android / iOS support, good concurrency features for server side development, JIT and AOT compilers + runtime, development mostly on github etc. They seem to be serious about making a first class cross platform language, I wouldn't be surprised if it displaces Java some in a few years.

And F#/other .NET languages.

As for displacing Java - this is never going to happen - I prefer .NET but soo many companies have invested man-milenias probably in to Java deveopment - it might losr popularity, especially with Oracle at the helm.

Sure, I agree Java isn't going anywhere, I just meant it might grow some at Java's expense since it has some of the same strengths (and while the ecosystem might not be up there with Java it's surely competitive with some of the other languages used for backend development).

Looking at it, and who is backing it and what support they have, I think Swift has a pretty good shot at being an "it" language for a while. Let's face it, Swift is the iOS programming language and it looks like IBM is putting some effort into porting it. Now, historically IBM and Apple are a bit hit and miss (with a lot more misses), but I think they will succeed with this one. I do wonder if IBM is getting a bit nervous about Java these days. If Swift had its own Rails or meant for a container deployment framework then things would be a lot clearer.

This does not come from a Swift fanatic as I view Swift as my next Transact-SQL. A language I will do work in and become very proficient, but I'm not loving it.

I like Go. The language is sane and small, the standard library is great, and the tooling is nice, the community is getting quite large. It's a bit too high level for me to call it a C successor, but I get similar joy from coding in it as I do with C. It's just so clean and neat, and I still get native code, and with no dependencies either. Pretty great. Go is so good thanks to the sum of all its properties. I think it will be around for a long time.

I'm not too much into Rust, but sure, if you absolutely cannot have even a low latency garbage collector involved or do very low level work like drivers, I guess it is useful. As soon as I don't, I feel like the pragmatic nature of Go is very appealing. I wonder about Rust's future, where it will be in 5-10 years.

I'd prefer Swift more if stuff started happening here as for cross-platform support. I hear the Linux support isn't even quite there yet, and as for Windows, it just recently saw _any_ kind of progress. I feel like it will take a long time until Swift feels like a natural general purpose choice across the largest three operating systems, rather than an iOS / OS X development platform ported to said platforms. But sure, Swift as a language feels modern and just great. Sometimes like a merge of Rust and Go, with the similar focus on safe code of Rust from guards, optionals, seeing the good in immutability, pattern matching. I wish Swift was much more popular and with much better cross-platform support.

I have played just very little with D and it has a bit much feature creep and bad traction for my taste (community _does_ matter). It had a chance of becoming more popular before, but I can't really see it anymore with these new languages. They already seem to have overtaken it in popularity, leaving D as a used but very niche language.

I wonder what the implications for Linux of the removal of "Portability" from the Swift 3 evolution/Readme.md [1] are?

[1] https://github.com/apple/swift-evolution/commit/06b69a6e51a7...

It looks like Portability is not a core focus of the core team. It looks like IBM is doing a ton of the Linux compatibility work and has offloaded the core team.

(BTW, shameless plug, I send a weekly Swift newsletter here: http://SwiftNews.co)

Also, defining portability as "porting to UNIX-like OSes that LLVM supports", I don't think portability is a big problem to solve given the current state of Swift (no multi-threading support in the language).

For example, Swift was just added to the FreeBSD ports collection (http://www.freshports.org/lang/swift)

I hope they suprise us during WWDC.

Most of the time im writing simple and small programms (on a windows machine) that manipulate data, interact with the web, or work with files.

I really liked Swift from the start. It has all the language features that I like. Sadly, with no Windows support, and Linux being only a second class citizen, I'm not motivated enough to spend a huge amount of time with Swift.

I also hope that they provide a documentation like Go. The Swift book is fine but the examples of the Go documentation in addition to the text, the easy navigation between packages/structs, and the aility to jump to the implementation helps a lot while learning the language.

Portability is still a strong goal for Swift 3. I'll revise the page, thanks!

Well a whole lot of Swift 2 tutorials probably just go broken (correct me if I'm wrong).

Why?

Reply on news.ycombinator.com