Hacker News new | ask | show | jobs
by danielrakh 4375 days ago
Apple releases a series of books with hundreds of pages and hours of video using Swift, and Google releases a one page Google Doc proposing to use Go. And then people wonder why Apple is able to attract so many developers to their platform...
8 comments

Swift has been in development since 2010 in secret. This is the price you pay for open source, you get to see things in an immature state which evolve over time.
And Go was started in 2007! http://golang.org/doc/faq#history

It's got nothing to do with open source. Instead it reflects the different approaches taken by Apple and Google.

Apple designs something new, tries hard to get it right the first time, and commits to it completely. Swift is the way to write for Apple's platforms, period. It's appropriate for a "social media application, all the way up to a high-performance 3D game." There's no doubt that Swift is meant to succeed Objective-C.

Google experiments more, sees what sticks. Go, Dart, Dalvik, v8, NaCl... You sure have lots of choices, but the relationships between these technologies is unclear, and has the character of uncoordinated teams working in isolation.

Go was also never made to be used in context of Android - even more it doesn't even have dynamic linking capability and was explicitly made to generate completely static binaries for server deployments. Which is not compatible (at least not without some serious hacking) with an OS which has full API written in Java an requires JNI interface and boxing of every interaction for every API call.

While Go is a feasible replacement for C/C++ for native parts of Android applications (which are just normal Linux .so libraries linked against bionic) it would be a terrible fit for main application language without a full rewrite of most of the operating system (note that ART is certainly NOT a magic bullet here!). Note here that native (NDK) code has practically NO access to Android OS APIs (only APIs available are bitmap manipulation, OpenGL, OpenAL and limited sensors access).

It's staggering just how many misconceptions and lack of understanding of Android structure is there in those "Go for Android" threads.

For us Android devs pretty much three points would improve the Android development experience:

1.) Add Java 8 language feature support to ART/Dalvik runtime. This would clean up code immensely, especially in so concurrency and callback heavy use-case as a mobile app is.

2.) Clean up Android APIs and fix broken implementations. Add modern block/callback based APIs to replace listener-heavy code. Perhaps look at RxJava design patterns for core Android APIs as well.

3.) Improve tooling. Not the code editors (IDEA/AS with Maven or Gradle are decent enough), but the profiling tools, hiearchy viewer, tracing tools and other tooling which wasn't touched in years and are SORELY needed for good app development. Figuring out why a certain animation stutters right now requires stitching together several partially working tools with poor documentation.

Note that NONE of those issues would be improved by adding Go as a language to interact with Android and would just cause additional issues on Go/Java boundaries.

I agree with your points. "Official", out of the box support for Scala or Groovy wouldn't hurt, either!

As for IDEs, personally I grew to prefer Android Studio to Visual Studio (well, no ReSharper), although I have much more working experience with the latter. Especially in terms of navigating around the project. VS native refactoring tools are very rudimentary, too, even in VS 2013 - not much seems to have changed in YEARS.

Are you proposing that Java 8 closure syntax is the solution to deeply nested callback code? Hopefully not---because that doesn't really follow IMO. A proper solution for concurrency is to use the Actor model or something similar.
It's a solution for tons of boilerplate code which appears when trying to do patterns. Compare for example Reactive Extensions (which are pretty popular in Android community for management of concurrency) and just how much more verbose is Java 6 code with it's piles of anonymous classes vs. lambdas of Java 8 or Scala. Even though IntelliJ IDEA can hide that boilerplate pretty well, it's still tons of needles code you have to pollute your codebase when you're implementing those modern patterns.

In short, what I'm saying is, that at the current state of Android, implementing Java 8 features would bring simillar benefits than switching to a whole other language without having to rewrite whole runtime and most of the operating system.

>Apple designs something new, tries hard to get it right the first time, and commits to it completely.

Oh really? That must be why they removed all of their USB and HDMI ports to replace them with Thunderbolt ports. Anyway, let me get back to writing my IOS apps in AppleScript and hosting my website on my Xserve. While I'm doing that I'll being sharing my music listening habits will all of my friends on Ping.

The point of that is that they hardly ever commit to things as 'completely' as you imply. They just have a conservative marketing strategy where they won't release anything until much later than most companies would.

>Oh really? That must be why they removed all of their USB and HDMI ports to replace them with Thunderbolt ports.

That doesn't even make sense. Thunderbolt and USB/HDMI cater to different needs. When they added thunderbolt they DID take out their Firewire ports. And when they added USB they did take out legacy mouse, keyboard etc ports.

>Anyway, let me get back to writing my IOS apps in AppleScript

Again, doesn't even make sense. Applescript is a legacy language they maintain. Designed pre-OS X. Not something they actively designed for iOS or anything.

>and hosting my website on my Xserve

They would, if enough people were interested. They weren't, so they killed the product. Same for ping.

True re Google's experiments. Given there's one guy in charge of Android and Chrome/OS developers could use a clearer direction. Preferably an alternative to Java (Kotlin?) which can also run on Chrome OS.
Agreed. And to add, Swift is designed and marketed as an osx and iOS language. Golang still mainly targets CLI tools or server programs. If you look at how Go progresses, some of the devs on the team seem to be able to choose the feature they will work on and move it forward. This seems to be the effort of one man getting this initially working. If it pans out, they may throw more resources at it.
> This is the price you pay for open source, you get to see things in an immature state which evolve over time.

Quite the opposite.

Wouldn't there be more people to write books and to work on SDKs when a language is openly developed?

You're comparing apples to automobiles. The documentation and video accompanying the Swift announcement was the official promotional materials and guides. The document linked here is a development proposal sent by a developer to the golang-dev mailing list outlining his intentions to work on a feature for the next release.
Go is more of a community driven technology.. more in the unix way style, i think google endorse it, but unlike Swift, i think they dont have a marketing department, official budget and the like.. so i think the comparison is pretty unfair
Go also has documentation. Also, Go has a spec. Swift doesn't. That's a pretty big deal, don't you think?

Android is fairly open. You can run whatever you want on that platform. If you want to use LuaJIT, no one can stop you.

Also, this isn't "Google". It's one guy working for Google. He's on the Go team. He wants to make Go a viable option for games on Android.

If you like Go, this is a good thing.

Swift has a spec. Just go to Apple developers documentation.
I can't find a language specification anywhere. Can you give me a link?

go language spec hit #1:

http://golang.org/ref/spec

dart language spec hit #1:

https://www.dartlang.org/docs/spec/

java language spec hit #1:

http://docs.oracle.com/javase/specs/

For Swift, I can only find guides and references.

At one click distance for any Mac developer:

https://developer.apple.com/library/prerelease/ios/documenta...

From the very first paragraph:

"The grammar described here is intended to help you understand the language in more detail, rather than to allow you to directly implement a parser or compiler."

A language specification is for people who want to implement a parser/compiler/VM/etc. It's something you need if you want to standardize it (e.g. TC39 [ECMAScript] and TC52 [Dart]).

A language specification is also generally clearly labeled as such.

http://en.wikipedia.org/wiki/Programming_language_specificat...

PHP, for example, doesn't have one.

Ah, so you mean a formal language spec, not an informal one.

Edit: I forgot to mention that both Go and Java lack ECMA and ISO specs.

It's pretty obvious they've just now considered adding Go to Android, and have just begun working on it. I'd like to think it's in part because of my constant pestering on HN about Google supporting Go in Android.
> And then people wonder why Apple is able to attract so many developers to their platform...

There are quite a few more Android developers than iOS ones, not sure what point you are trying to make.

Go will probably have zero impact on Android but Java has certainly been instrumental to Android's success.

> There are quite a few more Android developers than iOS ones

Do you have a source for this? My observation is that it's much easier to hire iOS developers than Android developers.

I have been dying to find an Android dev who has at least written a real app but I'm overflowing with iOS devs. Any advice where to find these guys?
May I ask where you are located?

Around here (Central Europe, Austria) it's the other way around. It's a little bit harder to find good Android jobs than iOS jobs.

Maybe because Java has always been one of the more popular languages here and the amount of Android devs is just higher than the number of iOS devs.

It's the same here in SE Asia. I suspect that's because most people don't have the money to buy a Mac for iOS development but already have a PC of some kind and often a cheaper Android phone. Also, most university graduates here already know Java so they can start writing apps without having to first learn an exotic new language.
In Germany it's a PITA to find good Android developers... Good iOS developers on every corner but even average Android developers are hard to find. We also overall experienced a much slower development workflow with Android.
Interesting, since at our teams we haven't found significantly slower dev times on Android in comparison to iOS. Usually Android devs lose time on compatibility issues, while iOS devs take more time with UI/UX design.

But I agree, finding a good Android developer here in central europe is rather hard. Also finding a good Android job is rather hard - payment offers are usually atrociously bad.

Apple had a 3 or 4 year lead time, Go was a project to make better servers.
As someone else already said, this should not be Go it should be Dart.

Go in this case is seen sort of an in-between C and Java. But Go is not really as fast as C as much as we want it to be. So I don't know. Maybe it will be useful for something already written in Go to be ported. But I would rather see Dart succeed as a higher level-than java development language (both on Android and on the Web).

Years back I hoped Python would do that (being Guido was at Google and all). But as he confessed there was a minor political struggle internally over it and Guido lost. Not too long after he left Google.

I used to think like you too.. but after Jobs/Apple launched the iPhone the trend for jitted languages, as popularized by Java in the nineties is going down..

Because of the phones and batteries, AOT languages are more valued and even ordinary jitted languages are getting a AOT compiler.. ART for Java and even .Net

So Dart would need to have a AOT compiler first to make it more appealing to mobile phones.. also i think a lot of apps would not like to be distributed in source code form..

So langs like Go now are on the rise.. its funny how technology trends change over the decades... not while ago it was all about dinamic languages..

It has always been about language features, abstraction power, and maximized interactivity. Exactly how one achieves these isn't the main point.
Its all about influential people in tech, managing popular platforms deciding what technology to use for their platforms..

Eg. Basic, Javascript, Objetive-C

As i dont think people actually conciously choose to write in those languages because of its features.. thats why we have so many people grumpy about those technologies..

Languages that we choose because of better features, pretty often loose in popularity and adoption..

Sometimes those languages have some heroic comunity efforts and a vibrant community that can make it stand.. but this is pretty rare.. Python, Ruby(because of Rails)

It has almost the same mechanics of the fashion industry.. Some influential people decide what we gonna wear on the next 5 years..

We can use our "hobby language" of choice, because its our own decision.. but in the end of the day.. we have to mantain and work in code on those languages missing the "features, abstraction power and maximized interactivity" we love so much

As i dont think people actually conciously choose to write in those languages because of its features

Incorrect, or at least badly lacking historical context and perspective.

Basic: interactive. (Primitive REPL.)

Javascript: it was there. If it wasn't there, everywhere but influential people just wrote about it then it would have languished. Also, it is interactive.

Objective-C: has a lot of very good OO which was heavily influenced by Smalltalk. It is precisely the OO excellence that it was known for and which engendered fierce love for it in certain circles.

Remember also that these languages have been around for a long time, on hardware far less powerful than what we have today or even had a decade ago. The youngest of these languages is Javascript by far, and it is almost 20 tears old! For their day, they were advanced with respect to the programming mainstream by at least one measure. (In the Apple II days, BASIC was there, and it was interactive, and that was enough.)

I'm not saying these were the best available. But there is more to it than just fashion and influence/hype. (Otherwise we'd all just be using Java in the browser and for app servers.)

Also: Ruby was a hobby language once upon a time.

I never understood why everyone whines about Go's speed. The language, although stable, has a lot of potential into becoming much faster and performant. In every new version you can find speed-ups into different parts of it. I really don't worry about performance in Go. The Go team are very conscious about it and i am glad the bulk of development has been focused on things under the hood rather than adding features.
Hint: it's not due to the documentation.