Hacker News Reader

Comment by krat0sprakhar | Hacker News Reader

> The most notable new feature in this release is official support for Android. Using the support in the core and the libraries in the golang.org/x/mobile repository, it is now possible to write simple Android apps using only Go code.

This is fantastic! Are there any example Android apps released by the Go team to help get started ?

View on HN

https://github.com/golang/mobile/tree/master/example

As far as I can tell these samples are immediately bailing out of the Java framework and calling Go using JNI. Which means you don't get the niceties of the UI Framework. You could make OpenGL calls from the Go code like for a game or something. Maybe someone will come up with a Go game engine for Android.

Is there any way to integrate the Java framework? Even something tedious could be crowdsourced with enough help.

That would be the JNI. I have a little bit of experience with making a Python interface to the Android API, and tedious is exactly the right word.

And now things just got interesting. I'll put my money on the availability of Go on Android being the catalyst for its future hockey stick growth.

I would be extremely surprised to see a language having no class, no inheritance and no good IDE become successfull in modern app development. Android devs are used to such a different type of programming, i don't expect them to accept banging their heads on so many walls for such little gains.

Ps : my stand is the opposite for server side dev.

Maybe this will help people (like me, for instance) who are disgusted by the overengineered OOP-heavy approach of most Java frameworks but enjoy the concise and elegant simplicity of languages like Go to finally move over and try out Android development.

Sure, the java bloated ecoystem is a real issue. Yet, imagine yourself building UI component without classes or inheritance ? Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden".

GUI is to me the field where inheritance actually makes a lot of things easier and natural. Now you may end up with something similar using struct inheritance and manually overriding function for the given type, but i doubt most devs will go past the first unsuccesfull attempts.

>imagine yourself building UI component without classes or inheritance

I see no problem at all. UI development in my opinion becomes much more elegant, concise and easy to follow/reason about in a functional language that does not implement classes or inheritance. As you said, Go has struct inheritance and interfaces, that's how you do things in Go and every Go developer is familiar with the concept, it's clean and elegant. I honestly see no problem whatsoever.

> easy to follow/reason about in a functional language

Go is explicitly not functional. Many builtin functions mutate (look at Sort for an example). There's no map.

https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC...

Functions are only almost first-class. For example... http://play.golang.org/p/WB133vrGKD

Go does have powerful constructs, but to call it "functional" is maligned.

I would also argue that it's not always easy to reason about and follow. The reason we build abstractions, which Java allows perfectly, is so that we can ignore the hidden complexity and reason about code more easily.

Go explicitly makes it difficult to hide underlying complexity. If I want to make, for example, a Bimap (which Java has many clean implementations of) I get to pick from two poisons in Go: Either I must force everyone who uses it to type-cast on every get (implement the bimap via taking and returning interface{}), or I must surface the implementation details (two maps) and have users directly manipulate those since the builtin uni-directional map is a type-safe generic data-structure which I can't replicate in the language itself. This might look appealing at first, but since I also need to do some Locking my interface for allowing people to manipulate those maps directly rapidly becomes troublesome.

Neither of those choices sound appealing to me.

Honestly, if you want to avoid java now you have a plethora of options. You can develop for android with Scala and get basically first-class support.

You can develop for android via webview+html+js and use something like http://ocsigen.org/js_of_ocaml/ to write OCaml and have a wonderful actually functional language.

You can wait for Rust to have some android bindings implemented and use a wonderful language that allows powerful features like macros that are excellent for interface-building.

I don't mean to bash on Go since it does have a place somewhere, I just feel that it is not the correct language for something UI heavy nor anywhere that suitably complex abstractions and complexity-hiding are a necessity.

I never claimed Go was a functional language. Sorry, maybe I shouldn't have placed those two statements on the same line but I was talking about two different things. After all, Go does implement inheritance and OOP constructs using structs (in a way), I thought it was obvious I was talking about a different thing when I said functional languages without inheritance or classes can work well with UI.

It's not about imagining what the best UI component would look like removed from any particular framework, but what the practical constraints are working within the already-existing android UI framework. Android APIs were simply designed for inheritance-oo style to work with them, and trying to avoid this will cause pain.

A similar situation has occured in ios development where the functional aspects of Swift do not complement the existing design of the coca framework.

Well, if what you are doing is inheritance-heavy, then OOP features will make your code cleaner. It's what OOP is made for. You can do it in Go, but it's not as elegant.

Inheritance as taught in OO courses (deep class hierarchies) is bad most of the time.

We can save 100 lines of code there by coupling 2 slightly related things forever (and arbitrarily choosing this criteria for division as the most important).

I've made game before I knew OO programming. I haven't knew it then, but I used Interpreter Pattern - there was data model, with a list of records, each record had some enums deciding how game logic should handle it. There was main loop updating the model using these enums to choose logic to run on this record.

It wasn't pretty but it worked, I was able to modify it however I wanted, to choose logic to run on some record basing on enums, other atributes of given record, attributes of parent records, or of colliding records, on whatever I wanted basicaly.

Then I rewrote the game to use OO design (I was enthusiastic- this is exactly what I need - I thought). It turns out that I had to choose arbitrary divisions. I can divide game objects into Solid and non-solid, Static and Movable, Visible and Invisible, and also Smart vs Dumb Objects. Which division should be first in class hierarchy? All the rest would need to be duplicated anyway. SmartMovableVisible, SmartMovableInvisible, SmartStaticVisible, etc... Ugly.

Inheritance solves part of the problem and leaves you with inconsistent solution.

The real solution is strategy pattern, and composition over inheritance. It can be done just as well in languages without inheritance (but with lambdas).

@vegedor you are hellbaned I think. I can't respond to you and your post is grey.

I wrote the OO game in C++, but I avoided multiple inheritance, because there were warnings everywhere: "don't use multiple inheritance". And I don't think it would be much help in the end.

Another thing inheritance doesn't solve - when you want to choose which logic should run on your "object" depending on dynamic conditions.

For example I had ParticleEffect abstract class, Smoke and Fire derived from it. Fire reacted differently to collisions with stuff, than smoke. Fire partices were smaller with each frame to simulate flames, smoke was getting bigger and more transparent with each frame to simulate, well, smoke.

Then I wanted to make fire that turns into smoke after a couple of frames.

Solution 1 - merge both classes, make enum field inside, switch it after a couple of frames [not OO design - behaviour depends on fields not on classes]

Solution 2 - destroy fire object after a couple of frames and create new smoke object in its place [unnessesary allocation and deallocation is bad in games, also this complicates identity - for fire and smoke it doesn't matter, but for player and bullets it's important - I need to ensure player isn't hit by bullets he shoot, that's achieved by keeping "parent" pointer in each object, when the player is recreated because he got new behaviour - all the pointers are wrong and need to be updated].

I can't change class of object dynamicaly, so all the OO divisions are static in time, I have to workaround class hierarchy to model my problem correctly.

Another thing - in collision detection, the logic to run should depend on both colliding objects types, and some of their fields. With OO I have to workaround this again (because most OO languages are single-dispatch).

Another thing - OO data is much harder to serialize. Structural data allows banal serialization. This is solved in some languages (like Python or Java) by providing serialization in the core language, but in C++ or javascript serializing arbitrary object graph correctly is nontrivial. Serializing list of records was trivial even in Turbo Pascal ;)

Inheritance is almost always an anti-pattern. It's encapsulation-breaking, dependency-creating, brittle and limited.

There is almost never code that requires inheritance.

Inheritance, in practice, is cut-n-paste for people that think they're too smart for cut-n-paste.

"Give me an object like Foo, but with this one little thing changed."

More than just "in practice", it might be worse than copy/paste. Richard Gabriel nailed it in the 90s when he identified inheritance as a form of compression, not reuse, forcing the programmer to have to understand every class under inheritance to understand any part of it:

Compression is a little dangerous because it requires the programmer to understand a fair amount about the context from which compressed code will take its meaning. Not only does this require available source code or excellent documentation, but the nature of inherited language also forces the programmer to understand the source or documentation. If a programmer needs a lot of context to understand a program he needs to extend, he may make mistake because of misunderstandings.

(from Patterns in Software, which is a really deep if long-winded book)

Sure, you can clone Foo into Bar and change one thing in Bar. But what happens when you need to change functionality common between Foo and Bar? Oh right, you have to change the same thing in two places now. Doesn't seem so smart anymore...

This is why Go has standalone functions and interfaces. You can easily share logic between types without having the types be the same thing.

The biggest problem with inheritance is that it's a lot like monkey patching (except in production)... the rest of the base class's code expects method X to do ABC, and you've just swapped out the implementation to do LMNO ... and if that never bites you in the ass, you're luckier than most OO programmers I know.

This is the big insight. Instead of trying to inherit code, figure out what that code does that interesting, and allow that code to do the interesting things without being inside the class. For example, imagine your class has a "WriteToFile" method. Instead of that, it should just have a method to return its representation, delegating the responsibility of writing to a file to something else. (Of course, the fact that a file can be written to should also be one of those "interesting things", and the thing that writes shouldn't care that it's backed by a file.)

Instead of

foo.WriteToFile("/tmp/foo")

You might write:

file.Write(foo.Representation()).

I promise that most inheritance in the real world is attempting to reuse something like "WriteToFile". "I wouldn't want to copy-paste the file-writing code, so I'll inherit from something that can write itself to the file." No. Don't do that.

Inheritance isn't a property of what code does, but how the programmer chooses to do it. There is no problem that is inherently inheritance-heavy.

> Can't even say something like "my custom button is a special kind of android button, with just those two methods being overriden".

Of course you can do that in Golang. You don't need inheritance. It has composition with type embedding. You can even "override" methods.

http://play.golang.org/p/UV55gQj7t0

I know you can, i've explicitly talked about struct inheritance in my comment, as well as manually defining functions for the new type. Yet, this is a weird construct if all you want to do is class inheritance. You have to deal with questions like "do i want to define the func on my type, or on a pointer to that type", or "how do i call "super"", how do i extend the constructor for that new type, etc..

All those questions do have answers in golang. But you have to learn new patterns in order to do an extremely basic and common thing in OOP, once again, without much immediate apparent benefit.

> i've explicitly talked about struct inheritance in my comment

It's not struct inheritance[1], so I wasn't sure what you were talking about.

[1] - http://golang.org/ref/spec#Struct_types

> You can even "override" methods.

That's not the same thing as overriding a virtual method in an OO language. If B() calls A(), it gets the general A: http://play.golang.org/p/nu7kY168E9

... hence the scare quotes ...

GUI is to me the field where inheritance actually makes a lot of things easier and natural.

I would invert that and say GUI frameworks are why bad OO/excessive inheritance is so ubiquitous. I have no idea why all the major frameworks have these horrible inheritance hierarchies, there's really no excuse for it.

In my UI days, I would avoid this by having a Window or Component class extend nothing, housing the necessary component as a field. I'd extend it only if I had to (rarely, and even then usually just one or two methods), and expose it with a getter. Cleaned things up a LOT.

Embedded types are king.

> Android devs

there are plenty of non-Android devs, like me, that just don't want to go with Java and are not fussed about IDEs. I know full well there are plenty like me in the Go community.

Got has inheritance, or at least the same idea, just done a bit differently:

http://golangtutorials.blogspot.com/2011/06/inheritance-and-...

I'd also argue that by being designed to be machine refactored and parsed (unlike some dynamically typed languages), go is easier to wrap with an IDE for refactoring stuff.

The main use of go for android, is to write native apps (games) in go, using a simple draw loop, that calls into OpenGL. In this way you can have one codebase for your game on android and ios (go will support ios too in the future).

I think it was never meant todo UI android development, because that requires calling into java a lot. Since most of android IS java.

It nay not become popular among existing, heavily invested mobile devs, but they aren't the only devs who might target mobile. And the fashion of class-based OO and languages that require heavy IDEs seems to be increasingly less accepted as the one true way.

Not sure where you got that feeling :

Android studio was just released a few weeks ago and became the official IDE for android. Xcode advocates building GUI using Wysiwyg tool. Swift has all the OOP features, and it also has an embedded "playground" mode, inside the IDE itself.

I don't think the trend is toward slim environments. There will always be people to say that doing things manually is better than having the computer do it, but it always surprises me when this thought comes from programmers themselves.

Note : i would actually love to have a great IDE for golang, with all kinds of refactoring, code analysis and autocompletion features ( lightIDE isn't one of them yet). I dont't think big IDEs are incompatible with elegant language, as swift+xcode or visual studio+C# show. To me the problem with Java is that there isn't a single framework that you could actually use if your only editor is emacs.

> There will always be people to say that doing things manually is better than having the computer do it

Languages that don't require a heavy IDE (particularly one including lots of tools for writing and rewriting code -- static analysis tools are a different issue) aren't "doing things manually instead of having the computer do it" -- interacting with the language itself is no more "manual" than interacting directly with the IDE. Its just aligning the write-language with the read-language. If I need a separate visual language to use to write code from the language I'm nominally working in, that both increases the overall mental complexity and indicates that there are weaknesses in the abstractions available in the nominal working language.

I understand your point, although i don't think OOP has anything to do with ( as C# and swift demonstrate).

I disagree on your "read language" vs "write language" analogy. Take for example SQL and Database model designer. Both are useful, and the fact that the second makes things easier doesn't diminish the merits of the first.

> no good IDE

LiteIDE is open source, cross-platform and pretty enjoyable. https://code.google.com/p/liteide/

It's the one i'm currently using, but calling it enjoyable is really excessiv. You can't compile or get any kind of completion while running your program, you can't define a script to be called when hitting "run" ( it always tries to launch your current file). It doesn't have any kind of macro or refactoring features, etc..

Coming from xcode and pycharm, it still feels a decade younger.

For that really to happen, the Android team needs to give some love to alternative languages.

From their Fireside talk I won't expect any change.

> From their Fireside talk I won't expect any change.

Why?

They stated that Java is the language platform, laught at the idea someone would like to try to use Scala instead and mentioned you are pretty much on your own if you feel like using the NDK.

Search for Google IO 2014 Android Fireside, video is available.

They'll change their tune when Android starts losing market share.

I'm not sure how much more 'hockey stick' it can get. Android already has 85% market share.

alfiedotwtf was referring to the potential for hockey stick growth for go, not Android.

They'd have to make Dalvik a compiler target. Could work, though.

They are targeting (1) helper libraries compiled natively (2) full screen games compiled natively. Not Dalvik.

So, not a first class citizen on Android then.

It's now exactly as much a second class citizen as C/C++

I don't really see it - a language made for systems programming (read: non-application development) being used for developing Android apps? Or is there some other kind of Android development in mind, here?

I think it was Rob Pike who later said he regretted using the term "systems programming" to describe Go. They never meant the phrase to mean purely operating system tools and programs (ie. not web applications or interactive end-user applications), which would be rather limiting. Instead, he said he said they meant it as a language for composing systems, as for example a typical SOA web site may be, or even for application development as you've alluded to.

Edit: Rob mentions it here at 06:50: http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Pan...

Real systems programming would be possible with a little more help.

Meaning a few more operations exposed in unsafe.

The problem is that the average developers never saw Oberon line of languages or are unaware how much of libc is actually written in Assembly.

Maybe with Go 1.5 fully re-written in Go, it will be easier to sell this scenario.

According to Github 8.4% of glibc is written in assembly. You would actually expect that to be an over estimate, since assembly is guaranteed to be machine dependent.

I suspect this is a significant underestimate: glibc heavily relies on generated assembly (they have a set of scripts to generate boilerplate asm functions for system calls) and inline assembly (which gets defined once, probably counted as C by github, and used many times.)

With that in mind, I tried to use the phrase in a more wide sense than some other language communities would. But you're right that that phrase might as well be disassociated with the language at this point, to avoid confusion. Better to find a new word for it.

Pretty much any language can be used to program pretty much anything these days. After all, a decade or so ago people would have sniffed at the idea of Javascript running on the server side, Python being used in physics labs and anything other than C++ or Perl for UNIX systems programming (a touch of an exaggeration, but you get my point :))

These days the limitation of a programming language is the programmer him or herself.

Well, provided a strong implementation of your language exists for the platform/environment you are developing for.

Sure. For the internet to be fully realized, all endpoints need to provide services just as easily as consume services. The whole thing is a system.

An app isn't only about the ui -- maybe you'll need some background operations, and you'll need to coordinate between multiple inputs. Go sounds more suited than Java for that.

There has been some work by the community. A user created an app with a button and a webview using go 1.4beta[0]. I modified it to only be a webview with a Go web server[1]. I also wrote an app for myself in the same manner here[2].

I found the whole android developer ecosystem a bit of a pain to setup, but it works now. The amount of java I have to worry about is quite low, so that's a win for me.

---

[0] https://github.com/MarinX/godroid [1] https://github.com/howeyc/godroid [2] https://github.com/howeyc/spipedmobile

If go code can now run on android, the go compiler can run on it...? Allowing go coding on-the-unit.

Not necessarily, this could still be cross-compilation. On the other hand, why wouldn't it?

Reply on news.ycombinator.com