Hacker News new | comments | ask | show | jobs | submit login

I'm excited to see what happens in the Linux and BSD space when they finally open source Swift. I hope it finds an audience excited enough to help reimplement some of the functionality that will be missing from the lack of Apple APIs.

It would be great to see an open source ecosystem for Swift, written in Swift on all *nix platforms.




Honestly the desktop Linux (and BSD) world is rather better served by fun new language technologies than iOS or Android is. In an environment already targetted by Go and Rust and C++14 and Haskell and Erlang and Clojure and Scala and Perl6, what exactly does Swift (much less Java) really have to distinguish itself?


I also don't get it.

What makes Swift better than other ML like languages for the mainstream developer is the tooling. e.g. Playgrounds and IDE support, and Apple forcing developers to adopt it (Objective-C had only a few WWDC sessions).

For anything else, Haskell, OCaml, Rust and even F# are better options, as they are more mature, already portable and lots of libraries to choose from.


Honestly, I think Swift is a pretty good ML-like on its own merits. A lot of the other options have snags that might make Swift look appealing.

Haskell is really weird. Even for someone reasonably experienced in functional programming, there are tons of new concepts you need to master to be minimally productive in the language. Beyond that, it introduces a whole new problem class of space leaks that you need to reason about. It's not a bad language, but it is a much more radical leap from anything else you're likely to have tried than Swift is.

OCaml is fairly verbose, still doesn't have a great parallelism story AFAIK, and has a quirky type system (1.5 + 1.5 is a type error) and a not-very-well-loved standard library.

Rust can be pretty hard to use and not very ergonomic. If anybody's first Rust stab at a Rust program doesn't run into "such-and-such does not live long enough," that's pretty astonishing. You have to think about a lot more than with Swift.

F# is tied to .NET, which is sufficient to be unappealing for a lot of people.


> Even for someone reasonably experienced in functional programming, there are tons of new concepts you need to master to be minimally productive in the language.

Mostly agree, but it does depend on how you define minimally productive. I also believe this is more of a pedagogy problem. For instance, someone can tell me what their definition of being minimally productive is in Haskell and if it is within my skills I can get them there pretty quickly.

> Beyond that, it introduces a whole new problem class of space leaks that you need to reason about.

I feel like "whole new problem class" is unfair since other languages have memory leaks.

Also, there are techniques developing for dealing with space leaks just like other languages have techniques for memory leaks:

http://neilmitchell.blogspot.com/2015/09/detecting-space-lea...

> It's not a bad language, but it is a much more radical leap from anything else you're likely to have tried than Swift is.

Perhaps I've drunk the koolaid, but it doesn't seem that radical after having learned it.

> OCaml is fairly verbose

Agreed, it's the main thing that has put me off of learning what is probably an awesome language. To be honest I just can't get over all the let's :/

I find this a little hypocritical since I found it easy to get over lisps/schemes parenthesis.

> still doesn't have a great parallelism story AFAIK

Right, but they are apparently fixing that fairly quickly: https://news.ycombinator.com/item?id=9582980

To be fair that was posted 146 days ago though and I don't know what current progress is.

> and has a quirky type system (1.5 + 1.5 is a type error)

Interesting, that's because you need to use .+ right?

> and a not-very-well-loved standard library.

I'm always torn on whether or not this is a huge problem. Part of me loves being able to build everything as libraries since anyone can essentially build onto the language. With a good enough package manager this seems ideal. The part of me that wants things to be fast and minimal though craves a great standard library so I can have fewer dependencies and a more "standard" experience. A good standard library also has the advantage of giving you good or good enough options without having to do tons of research on the best libraries for a given task.

Haskell for instance can require some knowledge of the library ecosystem to have the best experience. I'm not sure I'd say the standard library (or Prelude as we call it) is horrible, but it's definitely not as performant as it could be since many (all?) things are based on strings being represented as a linked list. The library solution for this is use Text for anything with unicode or use bytestring for ascii only IIRC.


It is the other way around. Using Rust on iOS is pain. Using Swift is not pain because it is supported by Apple. So it is easier to bring my Swift code and knowledge that I use on iOS to other platforms because other platforms (Linux) don't require sophisticated tooling and support. So I can create apps in Swift for iOS but also backend in Swift for Linux and it is the major benefit.


So... what you say is practical, but it creeps me out. This is the same logic behind "just code for windows because that's what everyone runs and treat everything else as a port". We suffered through that for a decade already, let's not repeat the mistake.

Don't tie your ecosystem to a proprietary (yes, Swift is still a 100% proprietary environment!) toolchain. We've done that several times already in this industry and the results have never been good.


  > Using Rust on iOS is pain.
Is there something more specific than the general fact that cross-compilation is a bit involved at the moment? Just curious :)


You need to write your bridging yourself and it might not always be possible because you need to bridge Rust <-> Objective-C.

Swift with Objective-C is bridged automatically.


I use rust with ios, and my bridging header just includes a single C header file. I don't see how it's any more complicated than using a C library.


Yeah, it bridges to C so you need to build another bridge to have nice Objective-C API. Not mentioning, you will have hard times calling Objective-C API from Rust.

You don't have this problem with Swift.


You don't need to involve Objective-C to use a C API in Swift. You can call C functions directly in Swift and wrap them in a nice Swift API.


I know that but if I decide to use Rust instead of Swift, why would I be wrapping Rust in Swift through C? And still it doesn't solve a problem how Rust can call anything from Cocoa or my existing code.


> if I decide to use Rust instead of Swift, why would I be wrapping Rust in Swift through C?

To avoid the unnecessary overhead of dynamically dispatched Objective-C method calls.

To me, it seems more sensible to go

  Rust -> C -> Swift
vs

  Rust -> C -> Objective-C -> Swift


Rust can call anything that exposes a C-compatible ABI, and Rust code can expose a C-compatible ABI so any language that can call into C (i.e. all languages) can call into Rust.


There exist Rust crates that make it easy to call Objective-C APIs. See https://github.com/SSheldon/rust-objc/ .


Thanks :)


It's not better. No one said it was. The target audience is developers who are using it as their primary language.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: