Hacker News Reader

Comment by sjackso | Hacker News Reader

Supporting Linux is a surprise, but I think it's a great move on their part.

Think: How many iOS apps are frontends to a server API? And how many of those APIs are running on Linux servers? Swift on Linux means ~all the code for a client-server iOS app can be written in the same language.

View on HN

So here's the thing. They will release Apple Music for Android... and there's full stdlib of Swift support for Linux? Could it be that the Android app is partly Swift?

I wouldn't read too much into that.

Android ships with Bionic libc, which is different from the glibc that is usually shipped in a Linux distro. There are definitely some differences between the two.

Plus the average Android app is very far from the average Linux app. If they were aiming at supporting Android, I think they would have said that instead of Linux.

Possibly talking about different things when you say "stdlib"?

The key word here is "partly" Swift. I would not put it past Apple to use an intermediary framework that hosts a Swift runtime and calls into native Android APIs. That keeps the non-UI logic in one codebase.

That's more or less what they do with iTunes, isn't it? I recall there being an incomplete library packaged with iTunes once upon a time (with stuff like a stub implementation of Grand Central Dispatch that was neither grand nor dispatching).

> stub implementation of Grand Central Dispatch that was neither grand nor dispatching

Thanks for the chuckle, almost r/programminghumor worthy ;-)

iTunes (used to, at least) have a lot of Mac OS 9/Carbon stuff partially ported to Windows, in fact.

It's great news. Hopefully there will be a node-like ecosystem for writing small services on Linux soon. With F#, Swift and C# available, hopefully the proliferation of Javascript can be slowed on the server (without people running to Go).

Just curious, why do you say that (about Go)?

It feels much too pragmatic for my taste. Exactly the kind of thing to come out of Google, to solve their type of problem (scalability, deployment are much more important than the code itself). Personally I don't have googles problems (few of us do!) and I really like a good type system, with algebraic types/pattern matching/generics

I use Go a lot for backend stuff, and I agree with you. There is a lot of stuff you can do with interfaces to ameliorate the lack of generics--but you still end up missing generics and algebraic types.

> It feels much too pragmatic for my taste

It doesn't feels pragmatic at all. It relies on users to do the compiler's job(type assertions) , because "You dont need that with Go"TM ...

It feels "pragmatic" in that Go follows "YAGNI" almost to a fault. It makes the argument that repeating yourself can sometimes be a better choice than more abstraction to increase code clarity. Some disagree with that, which is why it's nice to see other languages taking on similar areas that Go tackles but with differing choices in that area.

If you write Go code, you will realize you will actually not hit that problem often at all.

Right now the annoyance I hit more often is the inability to map a []Foo on an attribute .Name (string) to get a []string. I do that in ruby all the time, and with Golang it really sucks to do a for loop to collect stuff appending to a new array.

  people.map(&:name) => ["Joe", "John"]

  a := make([]string, 0)
  for _, p := range people {
    a = append(a, p.Name)
  }

It feels much too pragmatic for my taste.

C was unprincipled and pragmatic too, it was created with the goal of making UNIX portable. Still, C became one of the most popular and influential languages.

While I prefer ADTs/generics too, let's not forget that many people are less principled and pragmatic factors influence language choice as much (toolchain, ecosystem, popularity, familiarity).

> Still, C became one of the most popular and influential languages.

That was a side effect of successful startups (Sun, SGI...) adopting UNIX as their OS.

The success of UNIX is inseparable from C and vice versa. C made UNIX one of the first portable operating systems and, by virtue of being low-level, provided performance.

The same could be said of OSes using Algol and Mesa. They just hadn't successful startups using them.

There are good reasons that these startups weren't using OSes using Algol and Mesa. You seem to imply that the success of C and Unix is some historical accident as a result of two startups picking Unix randomly, and their choice was bit a function of the technical properties of UNIX and C. Which, is of course, nonsense.

Sun used Unix because Sun was co-founded by Bill Joy. By that time, Joy was already deeply involved in Unix (per BSD). If he didn't find Unix and C likeable and up to the task, they would have made different choices.

SGI and Sun were just one of many catalyzers, like a lot of programming languages have catalyzers.

You just confirmed what I said.

The startups that have chosen UNIX, did so because the owners were part of the American UNIX university culture.

A different background would have mean a very different history in mainstream OSes and their respective system programming languages.

In Europe C had very little meaning until most enterprises started to replace their mainframes by UNIX servers from those companies.

Having had exposure to both C and Pascal at around the sane time, I vastly preferred working in C.

I do think there's something intrinsically good about it compared to other contemporary systems languages - I don't think it's just that it tagged along with Unix.

It is not pragmatic at all, it is a language for mine workers that are too stressed to think.

Hah, I precisely use Go when I have to think deeply, i.e. about a difficult to solve problem.

When the problem is boring, use a fun & challenging language. When the problem is fun and challenging, use a boring language.

javascript is awesome

With the .NET Framework actually declining, Swift still being far away from the server and frameworks like Meteor, JS seems to have a really good position.

With that said I will root for Clojure + ClojureScript. One could theoretically build a framework much more advanced than Meteor, on the same code-sharing principles.

How so is .NET declining? I haven't heard this.

This is purely based on numbers, but still might be a little subjective. Nevertheless here it is: https://onedrive.live.com/view.aspx?resid=1E5AA35A965D3234%2...

Be interesting to see if they support @objc on Linux, the Apple runtime is difficult to support because it requires the dynamic linker to notify libobjc when an image is loaded.

The Objective-C support on Linux is already great, the compiler handles it well. The problem is the Foundation library isn't ported so you're left using old, unsupported relics from the OpenSTEP project.

Is Apple's dialect supported, or only the NeXT version? (Which, TBF, has absolutely nothing wrong with it and is a great language; but it's not what people are writing these days.)

Objective-C 2.0 via Clang and the GNUStep ObjC2 runtime supports blocks, GCD, fast enumeration, declared properties, introspection.

It's always just a SMOP, but my hunch is that Swift is way too integrated with the Apple runtime to not use it. I wouldn't be surprised if they have limited support for ObjC in their Swift Linux port, but happy to be proven wrong. (I started porting the Apple runtime to Linux last year but ran into the aforementioned linker issue. A way around it is to change the Apple runtime ABI on Linux of course.)

CoreFoundation has a MakefileLinux[1] for versions since 635 (corresponding to 10.7, if I'm not mistaken) — anybody know the status of that? It obviously relies on Clang (as it uses various extensions), but does it build, is it useful?

[1]: http://www.opensource.apple.com/source/CF/CF-1151.16/Makefil...

It's not all of CF and some of the ObjC glue is missing, particularly in the last few drops. Apportable put most of if back in though.

What language is that link written in? It looks like bash sort of but not really?

It's a Makefile.. for.. Make.

I feel like this reply could have been much more helpful and less snarky. Some people are still learning - we all were, at one point.

everyone is always learning (hopefully) ;D

Some people aren't learning to be helpful or less snarky though.... :-)

It's a Makefile[1]. They are quite simple really. They're defined like this:

  target: dependencies
      command

The command is run by a shell (e.g. bash!) when the target is called to be run. For example...

  all: hello world
      echo "!"

  hello:
      echo "Hello"

  world:
      echo "World"

Now if you run "make", you will see each command being run. By default, if you call "make" with no arguments, the "all" target will be run. You can also call "make world" for example, to have it only run the "world" target. As you can see, first the dependencies of the target are called, then the command of the target is run.

It's often used by C/C++ projects in order to manage dependencies, but can be used for anything really.

Here's a short tutorial you can walk through if you're interested in how it works and why it's useful: http://mrbook.org/blog/tutorials/make/

1. https://en.wikipedia.org/wiki/Makefile

wow thanks for breaking that down. years of playing and prodding on linux and this helped me a lot. funny and funky what slips through the cracks. kudos friend

I've been wondering for a while now why no one builds an Obj C backend for their apps:

https://news.ycombinator.com/item?id=9500855

Being able to deploy on Linux might be what it takes!

It's exactly because of server support. I'd LOVE to write obj-c on the backend - libgcd and the dispatch syntax alone makes it worthy, not to mention ARC, the ability to write pure C inline (not in an unsafe block or the like).

I long dreamed of using Objective C to build server apps. The compiler support has been there for years (GCC, later Clang), but there's no standard library. All the stuff you would want from Foundation is missing; strings, sockets, file I/O, encoding support, threads, etc., it turns out you'd have to reimplement a lot from scratch. There's GNUstep, but last I looked it, it was stagnant, and also very much geared towards GUI apps.

Swift on the backend would be even better, I think. Between all the languages that have evolved lately (including Go and Rust), Swift has struck me as the one that feels the most like my ideal language.

Agree. Feels like a reasonable language to get things done and still readable. Much cleaner in design than Go, and let's not even discuss JS.

The best Web development framework of all time was WebObjects, which started at NeXT. It was basically Cocoa for the web. It was wonderful. When Apple bought NeXT they continued it for awhile and ported it to Java to try and make it more cross platform. That didn't really take, as it was a commercial product and despite lowering the price dramatically many times and loosening the licensing restrictions this was the point at which open source solutions like Ruby on Rails, despite being terrible in comparison really started to take off because they were free.

There was a great community around WebObjects and it's a shame that Apple didn't open source it in a timely fashion-- they could have changed things quite a bit.

It is still used in heavy production- for instance the iTunes store is a WebObjects Application as is, I believe, the App Store.

At the time Sun was working together with NeXT for having Objective-C in Solaris (before Oak became Java) and got their base ideas for J2EE from WebObjects.

The Étoile OS folks have been working on top of GNUStep for a while: http://etoileos.com/

Here's a recent thing that came out of that group, which I'm interested to see in a server-side project: http://coreobject.org/

The fact that I don't use OSX has been a barrier to getting better at iOS development. Hackintoshing has proven to be quite elusive and the vmware and vbox USB layers in Linux don't convince virtualized OSX enough to transfer over apps to my iDevices. I'm not convinced you can get to high quality by testing strictly on emulators.

If anyone has an old mac that can run modern xCode (you probably know what this constitutes more than me) and wants to donate it to a dedicated open-source developer for completely unspecified future projects, feel free to email me at (my handle on hn)@(googles email service). thanks

Xcode is written Xcode, not xCode. Thank you and good night. ps. if you have any friends who work in Apple retail, twice a year or so they have a big clear out of some of the internal use machines. You can pick up fairly good machines for very very cheap. They had 2009 white MacBooks for 170 bucks or so the last time.

This is a great tip. My main laptop is a 2009 white MacBook with an SSD I cannibalised from another old laptop. The only thing I miss is Civilization V, everything else is fine.

Doesn't Civ V run on Mac as well ?

Yes, but probobably not on a 2009 MacBook.

The cheapest official retail option is the Mac Mini for $499. It's not a laptop but it will run the latest Xcode. Might be just the thing you need for that first app that makes you a bazillionaire.

I have an old white Macbook running SL, but it won't run modern XCode. It's great for doing things like Python dev, though.

> Hackintoshing has proven to be quite elusive

I've been using a hackintosh since 2008. It's literally never been easier to get one up and running.

So many people report success but a half dozen attempts with 20 years of computing to back me up has been nothing but abysmal failure.

I don't know what kind of magical book of voodoo spells these people are using.

I wonder if the web is just biased towards success because generally the people who haven't succeeded have nothing to say.

If so, it would be nice to get insight on the whole picture here somehow

Skyline OS X is a great resource for getting a solid And simple Hackintosh install. I'd recommend trying the guides there.

http://skylineosx.com

If you have the right hardware it can work as good as a real Mac.

But some hardware is just not compatible and that's it, nothing you can do about it.

It's not hard. Apple computers are still using commodity hardware - that is, you can buy very similar parts off the shelf to build your own system. The closer you get, the easier it is, but there are forums revolving around tweaks and updates to make just about anything work. Even AMD CPUs, which Apple has never used.

It _does_ take some tinkering, though, and if you aren't comfortable with that (or if your time is valuable enough), you should invest in the real deal. :)

So we can start writing articles about isomorphic Swift!

...I'll show myself out.

Apple needs to get the rest of OS X onto the server. They could build their own servers again (unlikely), or at least license OS X Server to Dell/HP/IBM/VMWare/etc..

I think Apple who did do servers at one time have found the consumer side of things more profitable. That said, they by not doing servers are seemed less hostile in server providing vender partnerships and this I believe would be more profitable for Apple than going into servers.

Now with the move of things into just the app bare bones style docker VM's in which the app is a service upon a server then maybe some form of runtime that enables some applications would be useful, maybe.

But if they went into the server market, then the trust of doing partnerships with server focused vendors would diminish. Though VMWare would probably be just as happy, if not more and that would be about it. IBM, for the arrangements they have now, work for both of them too well to upset I feel.

Back when they did servers they did it for two things, render farms and studio networking.

Render farms have largely been supplanted by Linux, and studio networking can either be handled by a Mini on the shelf or a Windows server in the closet.

Very true and probably more so when Job was somewhat into computer render animation. That and attention to a good working audio driver setup and API's have helped keep Apple still in the audio DAW industry. AS you say much has changed and can see why they shifted focus. Though I do as many wish they at least had a server flavour, more so given would not be much to change I feel as to what is already there. But exposure to a consumer messing up and a sever messing up can be vastly different in support/costs to make sure 100% right and less customers.

Still they do like consumerising things and who knows, personal home iCloud that sits in your home would perhaps be a likely server offering if any they may take as targeting consumers. That if any route is maybe the one that could happen.

Don't they already offer that via their Airport range of routers? I seem to recall they offer file storage/backup, perhaps even with a iCloud link.

I knwo you can add discs via the USB port and with hub can have a fair few and can network share and backup to them. But not apple user fully and did look but found nothing to enable sync with iCloud beyond a desktop option, though may of missed something. Though did find this: https://support.apple.com/en-us/HT204618 which pertains to remote desktop and related functionality done via your iCloud account, so maybe, though still need to access via iCloud, which if just athorisation would be ok if you had a fallback option.

I really wish that the airport extreme routers would expose an itunes home sharing service, so that those of us with laptops and way too much music/videos could stream to airport express/appletv/itunes home sharing without having to have a machine dedicated to the task.

Why when the aftermarket will do it for them?

http://photos.imgix.com/racking-mac-pros

OS X Server is really a shell of the former product. It used to be a great small business / design studio server, but it has lost most of its use-case and I really question its use outside of a few Apple Device Management scenarios.

Almost all the documentation and best case expects Macs to be tied to an Active Directory / MS environment for management.

As a typical Web / LAMP host, OS X really is not that performant. Unix tools execute faster on a RHEL/CentOS box then an OS X (even if the OS X box has higher specs). MySQL is particularly bad if it hasn't been tuned, and most of the literature seems to indicate that OS X (or more specifically MACH) doesn't have the level of optimisation for server workloads.

That being said, if your using the OS X frameworks, there can be some great value with exceptional performance (just look at the startup using Mac Pros as image manipulation servers).

I agree, with the type of growth Swift has shown in the past, there is going to be a big demand for Swift developers now. Swift could possibly rule the mobile/web. I have already added it on my #TODO list :)

I doubt Swift will rule the web. Javascript has yet to be dethroned by any other language coming before it, after all.

If you ask me, no chance to rule the web. JavaScript has been the standard for a very long time now. Because JS is not a flawless language dozens of js precompilers have been created till now, so the competition is pretty rough. Swift tries to be functional and provides you a way to use immutable data structures, but it is neither functional nor opinionated enough to force immutablity. With that said I personally don't think that it brings something new to the already existing web ecosystem. It sure is a nicer alternative to obj-c though.

When I was referring to web, I mainly considered the web-backend on web-servers. JavaScript is the standard for frontend, no doubt.

I'm going to double down on my bet that Apple will position Swift as the lingua franca to replace javascript. Front end and backend.

Good luck with that. One of the reasons JS is the lingua franca is that every browser comes with a JS runtime, all you need to get started is a plaintext text editor and all you need to publish an "app" is cheap/free web space.

Mark my words: Swift won't replace JS, not even PHP.

EDIT: Also, what's the point of writing Swift code in Linux if you aren't developing for iOS? As a non-iOS developer nothing at all compels me to learn Swift. It doesn't bring anything to the table that JS, Python, Ruby etc don't already do better. Except iOS support. HN tends to forget that just because iOS is the default in the US it's not internationally. Apple is a luxury brand, not a commodity one.

The point on having Swift on other platforms means you can write software for things other than iOS/OSX. It's a fun, modern language that brings A LOT to the table that js/py/rb don't (type checking and the ability to distribute binaries, for starters).

But programmers don't want better languages[0]. Programmers mostly just want what they already have. You can't overcome that kind of resistance just by saying "look, here's a language that's more fun and modern".

Programmers say they want better languages, but good luck trying to convince them to switch to a new language just by its merit. The only tangible benefit of Swift is that it can be used instead of Objective-C for iOS -- which is important for iOS because Objective-C poses an even bigger hurdle by virtue of its unfamiliar syntax. Swift wins on iOS because it competes with a language nobody wanted to learn to begin with.

Even as far as familiarity goes, the only thing Swift looks familiar to (based on first impressions) is Ruby, except it uses a more familiar C-like syntax (i.e. braces). While Ruby programmers are extremely visible (especially in startup/valley crowds) there aren't that many of them -- not to mention that some have already moved on to Rust or JS.

0: https://www.youtube.com/watch?v=JxAXlJEmNMg

I'd counter this

> But programmers don't want better languages

With TypeScript and/or ES6(7)+Babel. These have a pretty healthy userbase between them and there's a lot of excitement around ES6 which leads me to think that developers do want better languages.

Also... I want a better language. I'm not sure how you'll convince me otherwise and I don't think I'm alone in this sentiment.

Do they want a "different" language... maybe, maybe not. I suppose my comment about Apple "positioning" (and I'm careful to use that word) Swift as a replacement to Javascript can make a lot of sense to Apple and people who develop for iOS and OS X.

Firstly, Apple doesn't need buy in from other browser vendors. They can supply a Swift runtime with Safari (desktop and mobile) and I think it would be no more difficult to write a Swift to ES5 transpiler than it is to write an ES6/7 to ES5 transpiler, meaning that web devs can be agnostic about what browser their web app is running on and make demote Javascript to simply being a build task.

Secondly - Swift is going to have a lot of developer support. Because native apps are are increasingly dependent on a corresponding Web API - I think it's reasonable to expect people to be happy about sharing code between the front and back ends of their apps. I think nodes biggest advantage over any other server-side languages is that I can use node packages in both place.

Thirdly - I don't think Apple really cares wether "web developers" have an issue with this. They care about providing tools and solutions for people who develop for and use their platforms. If they can make the case that Swift is going to be "better" than Javascript by some metric we don't know right now, then that's what they'll do. Everyone else can go cry in a corner.

Also, Down-votes? Really? It's not the most radical idea in the world and I fail to see how someone could take offence from it.

PS: Apologies but I don't have time to watch that video right so I hope I haven't got the wrong end of the stick.

I agree, in part.

Programmers do want better languages, but they are extremely allergic to friction.

Parts of ES6/7 are relatively low friction thanks to Babel. But even so moving the majority of JS devs to modern JS is a very slow and long process.

Swift may make a dent if Swift-to-JS becomes a thing, but compile-to-JS languages are mostly a failed experiment (see the lack of success of "serious" languages like Dart or the decline of CoffeeScript). The advantage of Babel over other to-JS compilers is that you're just compiling JS to JS and it carries the promise that one day you won't need the compilation step at all.

The "JavaScript is the ASM of the Web" idea, while enticing, has time and again failed to come true. I don't think Swift can succeed where others have failed, even if it would allow iOS developers to write web apps.

At the risk of having to swallow my words, I don't think Swift-in-the-browser poses any risk to JS. I also don't think Swift-on-the-server will have a major impact, although I can imagine iOS-heavy shops wanting to use Swift when developing server APIs for their apps.

I agree that Apple will carry on regardless. Apple is all about controlling their ecosystems, so I wouldn't be surprised if they try to pose Swift as an alternative to JS (much like their unilateral CSS extensions back in the day).

About the video: basically Douglas Crockford (of JSON fame and JSLint infamy) argues that history has proven that developers (as a whole) favour similarity over "betterness" when it comes to the success of programming languages. They're more likely to pick something that is nearly exactly like what they already know than something that requires them to adjust their mental model, even if it is superior in nearly every way. The entire series is worth a watch IMO, and helps appreciating why and how JS got to the point where it is today.

Following your logic, Javascript just started growing on the server-side due to a number of frontend devs "just wanting what they already have". There's a huge number of mobile devs out there that have to, one way or another, write server-side code. Guess what'd be their language of choice then (when the Apple-backed open-source Swift is out)?

There's vastly more people who write JavaScript than people who write iOS apps in Swift.

I agree that server-side Swift may become a thing for iOS developers writing their own server APIs, but I'm only inclined to believe that it will at best become yet another alternative alongside Node, Ruby, Python and PHP. After all, Swift will only be a logical choice if you're already using Swift as the primary language -- i.e. only if you're writing native iOS apps.

For the "Swift in the browser" narrative it's also important to remember that the web is not just JavaScript. Even if you can abstract away DOM manipulations as in React, you still have to be aware of HTML and CSS and how everything comes together. Replacing JS with Swift only provides another layer of indirection, you still have to be a web developer to write web apps.

Considering how previous attempts to pretend you're not actually writing JS worked out (Ruby developers using CoffeeScript, Java developers using Dart or GWT, Python developers using PyJS, etc) I don't think JS in the browser is going anywhere, no matter how much some people would wish it.

Reply on news.ycombinator.com