Hacker News Reader

Comment by melling | Hacker News Reader

You are simply offering an opinion with providing any supporting evidence. Where does Go fall short as a language for mobile? Why would it not work well?

People use JavaScript to develop mobile apps, for example. The rapid compile times would be great for iterative development and the fast performance might even be better than Dalvik.

View on HN

>Where does Go fall short as a language for mobile?

Go falls short as a language for mobile in the same ways it falls short as a language for most things. It's simply not a very well-designed language.

Let me give you a few examples:

Terrible support for generic programming. Read almost any production go code and you see many instances of the interface{} type. This is basically equivalent to up-casting to Object in java, or passing things around as null* in C++. In many cases, that's the best you can do. All the type-safety of Python with five times the verbosity.

Many features are built-in, non-extensible language directives. Take the `range` operator. `range` only supports built-in types like maps, slices, and chans. You want to range over a tree? Too bad. Want to range over a graph? Too bad. Want to range over a queue or a linked list? Hmm, well too bad, or maybe wrap the queue or LL with a chan, write a helper function, range over that, and watch your performance go to shit.

Go was built with one purpose in mind; building web services. It's good at that. But really, the only things Go has going for it are decent threading primitives and a solid standard library.

So the answer is this: Go is not a bad language, but it is certainly no better than existing languages for writing mobile applications. Go offers nothing that would make me, if I were a mobile app developer, want to switch from Java or Objective-C. In fact, it's missing a lot of things that I might consider important.

If you want to `range` over a non-rangeable thing, the idiomatic way to do this is to use an iterator approach:

  var e elem
  for nonrangeable.HasNext() {
    e = nonrangeable.Next()
    // do stuff with e
  }

Coincidentally, that's what the built-in io.Copy [0] does.

(I'm also very biased, but I think this approach fits better with the fact that Go is targeted towards stream processing)

[0] http://golang.org/src/pkg/io/io.go?s=11928:11988#L330

Objective-C doesn't have generics either. The id type is used just like interface{}

Also canonical is building QML support for golang, so they seem to think it's well suited to build apps for Ubuntu http://m.youtube.com/watch?v=HB-3o8Cysec

well if you need generics that badly, I think you could improvise with this github.com/leeview/godsl/. My feeling is that in time Go will become a more multipurpose language than it is today. Even Rob Pike said that he and other authors have a list on which add everything that they would like to change in Go and consider it for Go 2.0 or Go 3.0 which could be not backward compatible with Go1.* (this is similar to what D lang did, D2 is a nice improvement on the lessons learned from D1).

That's your opinion and it's valid, but Google obviously doesn't agree since they've created the language, use it internally and have added support for it in App Engine. So the question is, what makes Go unsuitable for Android but suitable for App Engine.

Grandparent said:

Go was built with one purpose in mind; building web services.

App Engine is a web service. Whether you agree with that statement or not, it replies your question.

I'm not the original poster and I have no evidence to share, but I'll point out that Go executables are often quite large due to static linking. Client-side apps have to worry about code size.

if I understood correctly, that problem is already being addressed in 1.3 and the size of the files will decrease with the work on the new compiler/linker.

Reply on news.ycombinator.com