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.

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

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.

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

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

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.

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.

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

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)
  }

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

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

  target: dependencies
      command

  all: hello world
      echo "!"

  hello:
      echo "Hello"

  world:
      echo "World"

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

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

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

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.

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/

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.

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

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

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

http://skylineosx.com

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

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

...I'll show myself out.

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

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

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.

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.

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.

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.

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

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

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.

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.