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 ?

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.

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.

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.

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?

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.

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

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.

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

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.

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.

There is almost never code that requires inheritance.

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

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.

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.

no good IDE

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

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.

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

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

Can someone give me a compelling reason to start programming in Go? My default language at the moment is C, or C++.

You can also add numbers on an abacus. It _works_.

Put in a less snarky way, C is often way more low-level and tedious than you need.

The great thing about Go is that it lets you blend high-level and low-level programming in the same program, only getting low when you need to. It feels like a great mix of C and Pythonubyerlhphavascript.

I've given many talks on this, e.g. http://talks.golang.org/2014/gocon-tokyo.slide#1

You can also add numbers on an abacus. It _works_.

Well, I wouldn't go there (C is antiquated/under-equiped like an abacus) if I was advocating Go.

After all, Go, just like an abacus doesn't have generics, or, besides channels and goroutines, most other facilities modern languages offer for that matter (GC and some basic data structures built-in is so 1980).

The great thing about Go is that it lets you blend high-level and low-level programming in the same program

Where are map, reduce, select, filter, fold, zip ...?

I don't consider hand-rolling them in for/range as equivalent. Can I wind up with the same result? Yes. But I could do it with gotos too.

And I've seen "loops are the same as map/reduce etc" advanced as a serious argument by people who weren't, so far as I could tell, trying to tug on my leg.

Most of the questions about "how do I do X in Go?" are answered with "just write a loop". Yes, that means map/reduce, filter, fold, zip, etc. If writing simple loops gets your hackles up, Go is not the language for you. For me, I worry about the hard stuff, not easy loops.

If writing simple loops gets your hackles up, Go is not the language for you.

What gets my hackles up is claiming that "it's just the same".

The same argument works for any language that satisfies the structured programming theorem, including assembler.

"If writing simple BNE $reg gets your hackles up, Assembler is not the language for you."

For most people's uses, it's the same. Certainly, there can be performance benefits if your language's implementation uses lazy evaluation and you have a very large list and you only need to evaluate a small portion of the list... but in my experience, that is very rarely the case in real programs.

For most people's uses, it's the same.

I look forward to seeing how I can chain multiple operations on a set into a single line of Go.

Cramming a lot of logic into a single line of code is an anti-pattern and not a goal of the go language.

Also see the aforementioned "the answer is to write a loop".

Not having to use Java on Android. This is a major reason.

(it's going to interesting to see battery life of not running an interpreted language on small devices like Android Wear).

Once Go is installed, I can make a simple web app from scratch that displays parameters from the URL or request body in just over 95 seconds with Go, using only the standard library. I can cross-compile it for another OS and architecture, then deploy a single binary file without worrying about dependencies, dynamic linking, or segfaults.

Try doing that in C/C++.

Maybe a better comparison is to more systems-level applications like you might code up in C. The same benefits carry over to those, without a significant performance hit (usually).

(And to be fair, sometimes C/C++ is the better tool for the job. But give it a shot; Go is pretty handy when you don't need to drop down to lots of unsafe memory and CPU operations.)

By the way, your existing C skills will be very useful in Go. For example, struct fields will still be padded unless you pack them carefully. Your experience with buffers, streams, memory allocation, and data structures will definitely not be wasted in Go.

Once Go is installed, I can make a simple web app from scratch that displays parameters from the URL or request body in just over 95 seconds with Go, using only the standard library. I can cross-compile it for another OS and architecture, then deploy a single binary file without worrying about dependencies, dynamic linking, or segfaults. Try doing that in C/C++.

NodeJS runs on top of C++ :P

Yeah, he meant do it WITHOUT implementing an app server and a JIT for another language first.

With std.

You can still get segfaults in Go.

"panic: runtime error: invalid memory address or nil pointer dereference"

But you also get a stack trace without needing an IDE and debugger.

I've been working with Go daily for a few months now at my job and I'd like to point out that Go stack traces have a really big signal to noise ratio. There is a lot of cruft that mostly nobody cares about and sometimes it can be hard to pinpoint exactly where something crashed (at which line) with a panic.

Just saying, they should probably improve it to be less verbose and more concise.

In that case you would say it has a really low signal-to-noise ratio.

You can get static linking in C/C++ with `gcc -static`.

Sort of. On Linux, libstdc++ depends on the NSS system which dynamically loads libraries to implement things like getpwent(). Last time I had to actually make a portable static executable (admittedly some years ago) this was a real problem, and it was easier to statically link everything except libstdc++, then ship a copy which was loaded using RPATH in the linker settings.

This is however a tooling issue, not a programming language one.

A really crisp way to model concurrency. Most real world performance problems stem from the inability to model concurrency correctly.

I also found it's faster to read the library code than the docs. A lot of thought has gone into making the language and library clean and easy to understand.

Doesn't that mean that the docs are lacking?

No. Docs are very complete, readable and helpful.

You should be able to get up and running with Go extremely quickly if your default language is C.

If there's a reason you must be using C rather than another language (require manual memory management, require code to be as fast as possible, etc.), then Go might not be applicable. Otherwise, Go feels like an updated C and I don't see a compelling reason not to invest a little time in checking it out for yourself.

require code to be as fast as possible

It's also pretty easy to write the performance critical parts of the code in C and call them from Go.

If you're using C/C++ and need the performance, look at Rust. Fairly expressive, good type system (and they figured out generics), and C++ like or better performance. All the power of manual memory control, with none of the downsides.

It's too complex, we're already have C++.

I was at a lecture about security in C/++ code a couple of weeks ago. His conclusion was basically:

There are no silver bullets with regards to safety in C/++ code; in order to achieve security, the programmer has to pay the price of being forever vigilant.

A lot of the complexity of Rust is for eliminating security pitfalls which are inherent in C/++.

It is common to use ARC and unsafe shared memory access in Rust. This defeats the purpose of this complexity. You can't isolate unsafe memory access. You rather write only memory safe code or end up with fully unsafe codebase where some nasty things (buffer overruns or segfaults) are possible. If somebody needs memory safety - managed languages with GC is the only real option.

It is common to use ARC

What is unsafe about using atomic reference counting?

and unsafe shared memory access in Rust.

That should be provided with a safe interface, or an unsafe interface if calling that code is not safe.

As for it being common: I think they are working on minimizing the need for unsafe code.

This defeats the purpose of this complexity.

Like having a VM implemented in C defeats the purpose of the VM for that language being safe. No, not really - that C code has to be really vetted, just like unsafe code in Rust has to be really vetted.

I guess we might - eventually - be able to formally verify a language implementation, thus really proving that a language is safe (that goes for those managed languages, too). Maybe that will be feasible in a few decades, if ever. Alternatively, you can use the ATS language, where you can prove that unsafe usage of pointers etc. really is being used in a safe way.

You can't isolate unsafe memory access.

Sure you can - owned and borrowed pointers in Rust are represented as raw pointers at runtime. It's a safe abstraction. And if there turns out to be a bug in that interface, and they aren't really safe, then that will have to be fixed promptly - unlike in C/++, where one would be forced to say "Well, that's your fault for not being careful".

What is unsafe about using atomic reference counting?

Nothing at all. But sharing objects between threads is unsafe.

Like having a VM implemented in C defeats the purpose of the VM for that language being safe.

You can prove that VM code is memory safe? Good for you.

Sure you can - owned and borrowed pointers in Rust are represented as raw pointers at runtime. It's a safe abstraction. And if there turns out to be a bug in that interface, and they aren't really safe, then that will have to be fixed promptly - unlike in C/++, where one would be forced to say "Well, that's your fault for not being careful".

And in C++ we have value and move semantics. Nobody uses pointer arithmetic to implement arrays and strings anymore. std::unique_ptr is a standard way to implement the same semantics as borrowed pointers in rust. Array access can be range checked if you want. So being careful in C++ is easy today, can I say that C++ is safe? :)

  > It is common to use ARC and unsafe shared memory access 
  > in Rust

This is false. `Arc` is not common, and when it is used, it is to enable safe shared memory access.

  > You can't isolate unsafe memory access

This is also false. If you get memory unsafety outside of an `unsafe` block, it is a by definition a bug in the compiler.

This is also false. If you get memory unsafety outside of an `unsafe` block, it is a by definition a bug in the compiler.

All `unsafe` memory access in Rust performed in separate address space? I'm asking because if it isn't - this can't be called `isolated`.

"or better performance"?

I'd like to see some evidence if you have any.

Rust has great performance in general - and I also agree that it is an appealing language - but I haven't heard anyone claim better than C++ performance before. I'd be very dubious of anyone making that claim...

As with all performance, it really, really, really depends on what you're doing. I _hate_ the Benchmarks Game, but there are some that we are faster: http://benchmarksgame.alioth.debian.org/u32/rust.php

You _hate_ the Benchmarks Game because … ?

Because it's arbitrary, most of the benchmarks aren't useful or interesting, and it encourages a mentality that I find to be a net negative.

Many of the tests boil down to "Does your language have GMP bindings" or "Can you write non-idiomatic code to theoretically make this as fast as something else?"

In other words, I don't find it to be useful, except in the absolute broadest sense.

"arbitrary" is just name-calling. What about benchmarks game is arbitrary in your opinion?

Exactly one task might be described as boil down to "Does your language have GMP bindings" and that shows:

1) differences with the same language implementation and same GMP binding

2) differences with the same language implementation with/without GMP (for example, Rust #2 and Rust #1)

3) differences with different language implementations' use of GMP.

None of the tasks boil down to "Can you write non-idiomatic code to theoretically make this as fast as something else?" -- if you don't want them to!

If the Rust programs shown on the benchmarks game are "non-idiomatic" it's because so-far that's been the choice of the Rust community.

You know what you mean by "in the absolute broadest sense" but we don't.

What about benchmarks game is arbitrary in your opinion?

For example, look at the history of D being in the game vs. not. Generally speaking, all of http://benchmarksgame.alioth.debian.org/play.html#languagex is incredibly arbitrary. I don't think that the maintainers of the game have some sort of moral obligation to support things they don't want to, but it is an arbitrary line which influences what kind of benchmark it is.

As another, the domain of the examples, which are largely related to numeric computing and/or memory usage. Which is fine, but isn't going to give me information about other use cases.

None of the tasks boil down to "Can you write non-idiomatic code to theoretically make this as fast as something else?" -- if you don't want them to!

Yes, they do. Because one man is not an island: people use the raw numbers of the Benchmark Game to claim "X is faster than Y", even if the implementation of X and Y are totally different than what their implementation would be.

that's been the choice of the Rust community.

I'm actually not thinking of Rust here. I'm thinking more of languages like Haskell, who have implementations that look significantly more like C than like Haskell.

But regardless of if the implementations are idiomatic or not, it means that The Benchmark Game is useless for evaluating if a program I write in a language is going to generally be faster or not than if I did it in another. Because this isn't the code that I'd write: it's code that takes advantage of every little last corner to get as small a number as possible.

It's Go's simplicity that really struck a nerve with me. I've been coding for over 30 years now (Basic, ASM, C/C++, Java, Python, PHP, JS, Clojure) and with Go, I just love how everything is laid out for you: idiomatic Go, formatting, commenting, unit testing, concurrence, standard libraries etc. I don't have to research the basic tools. It keeps me focused on the task at hand. I'm very productive with Go. We have it in production and I'm super happy with it. (Btw, I never missed generics. If you pick a language based on its number of features, Go may not be for you.)

Since you know Python, do you find Gonas expresive an clear as Python? Is there anything like list comprehensions and generators in Go? And anything simple like the Flask web framework? How does it compare to deploying a python app using uwsgi+nginx in terms of performance / reliability?

No need for header files.

If garbage collection is acceptable, you'd learn more from trying OCaml - or even Haskell, if you want to really expand your comfort zone. I'm not saying don't learn Go eventually, but for the "second language" you should try something more different from C/C++ so you get more of an idea of the range of stuff out there.

Doesn't OCaml have bad support for concurrency, though? Concurrency is one of the features that people who look into Go are often after.

OCaml is been around for almost 2 decades. Something must be holding back its adoption. Microsoft's version F# seems to be doing better but developers aren't adopting it en masse.

- garbage collection

- safe and easy programming (really!)

- no more shooting yourself in the knee with hard to debug problems

- lean but quite complete standard library

- native strings (proper unicode/utf-8 handling)

- very little boilerplate, sane defaults

- concurrency primitives (no tacked-on libraries)

- high performance - not far behind C/C++

- extremely easy and practical documentation features (via comments)

Except Java and C# are significantly better at all of these points except for boilerplate, which I would even dispute whether that is a bad thing overall.

Really, things like concurrency primitives as a point in Go's favor? Running code on several processors at once is where it's good to have a library because there are tons of knobs like priority and scheduling policy for instance; it's been trivial to deadlock or arbitrarily delay an entire Go program just by having GOMAXPROCS busy loops and there's no scheduling control at all last time I checked. Meanwhile shared data locking isn't even in the language despite being at a very fine level where using libraries can be cumbersome.

And Go comments as good documentation is another mind-boggling claim. It's a mostly free-format with few machine-readable parts. Most functions don't even explain what types of errors can be returned, just "err Error". It's so bad it isn't even comparable to JavaDoc or C#. How can you have "safe" programming when you have to dig through sources to even find out what the error conditions are?

There is a good reason to use Go and that's to feel like a pioneer. But few technical reasons.

Except Java and C# are significantly better at all of these points except for boilerplate, which I would even dispute whether that is a bad thing overall.

C# on Mono certainly isn't significantly better performing than Go from my experience, which is substantiated by Go winning all but one of the 'Benchmark Game' benches, typically by quite a wide margin:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

And Go is not doing that bad against Java either:

http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...

Can you build Android UI using Go? I have not found a good UI library in Go.

Also can someone please give a brief description of whole process to write a simple Android app in Go? What are the bare bone setup(Go, JDK, Android SDK??, etc.), so I can develop and compile? Is the final result an apk file? Thanks.

I'm not an Android developer, but have you seen the examples yet?

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

You can access OpenGL, but the full Android framework isn't directly exposed. It's similar to developing in C++ using the Android NDK.

From the documentation (https://godoc.org/golang.org/x/mobile/app):

  An app can be written entirely in Go. This results in a significantly
  simpler programming environment (and eventually, portability to iOS),
  however only a very restricted set of Android APIs are available.
  
  The provided interfaces are focused on games. It is expected that the
  app will draw to the entire screen (via OpenGL, see the go.mobile/gl
  package), and that none of the platform's screen management
  infrastructure is exposed. On Android, this means a native app is
  equivalent to a single Activity (in particular a NativeActivity) and on
  iOS, a single UIWindow. Touch events will be accessible via this
  package. When Android support is out of preview, all APIs supported by
  the Android NDK will be exposed via a Go package.

Alternatively, you could write your UI code in Java and call into a Go shared library via JNI methods, if you aren't worried about graphics and just need code portability. Again, this is similar to working in the NDK.

Just to make sure I'm not missing it: fsnotify didn't make it into Go 1.4, right? 1.5 maybe? :)

It didn't make it in, but there's no real strong moves for it to be in the standard library anyway. It works well enough in a go-gettable package.

Pardon my ignorance but if fsnotify is not available how is Hugo (static site generator) listening for events in the filesystem (to reload the server)

By using platform-specific cgo calls.

Doesn't look like it's been pushed to the canonical git repo or Github just yet: https://go.googlesource.com/go https://github.com/golang/go/releases

Aside from that, this is yet another great release! :)

It will be soon. I'm working on it.

And they actually stuck with their go generate design? What an unfortunate mis-step.

Let the makefile's continue.

I've seriously thought about moving to gccgo just to try and get a build system where I can actually inject dependencies on .go files builds again.

You seem to be confusing compilers and build systems. You can use whatever build system you'd like and with whichever compiler.

Is it possible to do away with the typical Go project directory structure? I thought all that was enforced by the tools, but it's possible that I didn't dig deep enough to uncover greater flexibility.

Now you can write Android application and eventually iOS ( I don't know if I need that ), this is quite interesting. Congrats go team !

Did I miss something? I didn't see anything about iOS.

https://groups.google.com/forum/#!searchin/golang-nuts/ios/g...

Quote:

gophers,

I'm happy to announce that the iOS port of Go recently gained full cgo and external linking support.

I've also got a simple C based application working on a real iPad.

The port lives in ios3 branch of https://bitbucket.org/minux/goios. Read misc/ios/README for some rudimentary documentation.

The port is Go 1.4+, and it's based on upstream dev.cc branch. I intend to propose for inclusion into Go 1.5 after finding a way to test it (either build each test as an App, or use the open source xnu/arm port). Brad mentioned that inclusion of iOS support might happen in Go 1.5 in his talk the state of the gopher (http://talks.golang.org/2014/state-of-the-gopher.slide#40), now I believe it really will happen.

The iOS port is my first Go OS port, but it's the only one that takes almost 3 years to complete. :)

Go build iOS Apps. Let's see when can we see a Go based App in the store.

Minux

I wonder why they didn't move the main code repo to GitHub as well. https://go.googlesource.com/ is somewhat poor compared to GitHub.

Because we want a good code review system, and GitHub doesn't have that.

More discussion: https://news.ycombinator.com/item?id=8715529 https://news.ycombinator.com/item?id=8605204

Gerrit looks pretty horrid to use to be honest.

What is google source? Is it a successor/alternative to google code?

This relatively recent trend of company-specific languages annoys and disturbs me.

I don’t ever want to be tied to a language and library ecosystem under the thumb of a single (large) corporation. Not Visual Basic, not .NET, not C#, not Objective C, not Go (It’s even named after the company, for crying out loud! Yes it is. Don’t try to claim otherwise).

I’ve used Basic, I’ve used Pascal, I’ve used C, I’ve used Python, I’ve used Lisp, and so on and so on. Those were open platforms, with different companies in the “lead” position in any one time (Microsoft Basic, Turbo Pascal, Borland C, GNU C Compiler, CPython, PyPy, etc.), but the language was not “owned” by a single company which would loom in everyone’s mind, always the unspoken fear being “what if <company> doesn’t like it?”.

I will not use tools which make me afraid. I will not live a life in fear.

It's open source.

While technically true, this has almost nothing to do with what I wrote. Huge code bases thrown over the wall, while technically “open source” does not a community make. A language named after a company with the overwhelming majority of development sponsored by that same company is not something you realistically envision someone forking, so the fear I spoke of is still there.

Now, if the language was, say, maintained by 80% or more by submissions and monetary contributions from outside the company (and if the name was changed), then it would approach being a neutral platform to the benefit of all.

As it is, we’re all being invited into Google’s yard to play, but we don’t own the house.

How would communities around anything come to exist if everyone had the same attitude?

Look at how the communities around languages like Basic, Pascal, C, Lisp and Python have developed.

They were, from the beginning, open with development, releasing early and often, and were explicit about readily accepting large contributions from outsiders (and really did so). The creators were always open to the possibility that they themselves might not be the eternal keepers of the language, which allowed competition when others developed the language further.

Contrast this with the development of the languages I mentioned. They have done the opposite of these things.

I think you should do what you ask to be done. You fork Go under a new name, create a community with the same objectives as yours around it, be competitive and develop the language further and then reap the satisfaction. If there is a significant need for your ideas I'm sure the developers will join you (otherwise you will have the best proof that your idea is just not good enough for many others). Personally I'm very glad and grateful for the product of a tremendous amount of man hours I receive for free even if I too have ideas (that don't overlap perfectly with Go) about how a better language should be.

You misunderstand me, please re-read what I wrote. Nowhere did I call for the forking of Go. On the contrary, I specifically wrote that it was unrealistic to even envision it, since it would not work as long as Google sponsored more into its development that I could do with the fork, and as long as Google was perceived as a more stable future sponsor of said development.

What I wrote was that I, personally, would not use Go as long as its development was perceived to be controlled and paid by Google. Forking Go would not ameliorate this in any way, unless it was successful, which would be extremely unlikely.

Your assertions are at odds with everything observable with regards to development of the Go language.

I freely admit that I do not know the intimate details of Go development, but my point is that they are almost irrelevant. Go is still perceived to be controlled by (and therefore is controlled by) Google. How much that is actually true is almost irrelevant until the perception changes. And with a name like “Go”, Google likely has no intention or wish for that perception to change.

I mean, can anyone claim that an internal developer at, say, Microsoft or Apple could develop programs in Go and have them become used for large parts of the internal company infrastructure without it becoming politically sensitive, just as if they had chosen, say, C? Until that happens, Go is not an obviously-neutral platform, and I therefore have no desire to use it.

I don't think this is true of C. The original compilers were AT&T proprietary, surely? Hence the need for multiple competing implementations.

Have you actually observed the Go community and how Go has been developed over the last five years? What you are saying are fair concerns in the abstract, but I cannot reconcile them with the reality of how the Go project operates.

You also seem unusually hung up on its name. It's not like it's called Google Programming Language All Access.

I see from another comment that this release first happened, and then, afterward, the release was pushed to its “official” Git repository. This is not the way real open projects do releases, and instead indicates that the real development is done in-house and the code thrown over the wall.

A name is important, as it is a symbol. As long as the language is called “Go”, Google will always have power over it, no matter who actually does most of the work, and thus the fear will still be there. (Yes, “Go” is symbolically the same as “Google Programming Language All Access”. It’s as if Microsoft released something called “MSCode”.)

I see from another comment that this release first happened, and then, afterward, the release was pushed to its “official” Git repository.

You misunderstand. The release was made from the official open source Mercurial repository, and later pushed to the official Git repository, because this release coincides with the project's migration from Mercurial to Git.

Every single change of this release was written in public, reviewed on public mailing lists, and committed to a public version control system. You are misinformed and spreading FUD. Please stop.

I'm generally in agreement, but it's hard to say what languages will be considered "company-specific" in the future.

Go back in time 35 years and C could have been called that "AT&T specific language" Or the opposite: Objective C looked like a hopeful contender to be a widely-used language but it just never caught much traction outside the NeXT/Apple (and NeXT ended up buying the developer) and today it's almost completely associated with a single company's ecosystem.

Maybe in 4 years we'll be talking about the new features coming in "ISO Go19" and complaining that VisualGo still doesn't support all of Go18 yet. Who knows?

If the non-company-specfic languages cannot keep up with the evolution company-specific languages show they will have a problem getting or keeping their users. I know it takes a lot of investment to build great tools, do marketing, evolve a language etc and currently some large companies seems to think that they get more of what they want by funding their own languages. If someone fund the free languages they same way they will probably evolve faster and get more users. There is also a problem of getting large groups of people and organizations to agree on something. This also slows down progress in some open/free projects. Sometimes it is easier to just decide for yourself.

But look at other examples.

JavaScript became ECMAScript, where ECMA is there to define standards, but still there are a couple of big players from certain companies and still they do Dart, which is mostly a Google thing and is a direct competitor to ECMAScript.. well, ECMAScript 6 at least. Even though it's not a bad language one can see a lot of company interest there.

And when you look at Go you see that it is controlled by people who work for Google, but don't exactly depend on them. I think it's more a language of Ken Thompson or Rob Pike than Google.

What do you think about Rust? It's affiliated with Mozilla, but Mozilla is (also) a Foundation and Rust is not a Mozilla Product like Firefox, where it often is really hard to get your changes in. There are a lot of people who got interested, even outside of Mozilla and at least to me it appears that they have influence.

And the last thing is what matters. Microsoft has huge interest on controlling C#, Visual Basic .Net, etc., because their income is related to data. They create the major platform for it, get income via selling the OS, the IDEs, etc.

If you look at Go then that doesn't seem to be the case. Google's main benefit (tell me if I am wrong!) appears to be being able to replace C++ and Python where neither seems to fit for one reason or another. If you look at the state of both the Android version now and Google App Engine then Google doesn't show huge interest into using it for money.

Of course that is only now and maybe this changes, but it doesn't look like it for now.

My personal opinion is that Dart was more to worry, also because of the approach being similar to Microsoft, when they create a standard (be it for documents or a language) and then create their incompatible extension or are always ahead of the others, because of their strong involvement. I really don't see that with Go.

Another thing that is slightly related to go is NaCl (Native Client, not the crypto library), being Google's version of ActiveX. But that's more because it of course is a target platform for Go, not a thing that's wrong with the language. Else you'd also have to worry about C.

Nice. Now all I need is for someone to turn https://github.com/jcla1/gisp into a slightly more complete LISP and I'll have a nice environment for all kinds of ARM systems.

Edit: typo/autocorrect

this your project? i'm down to do this

There is a new range syntax[1]. The release notes say it's rarely used, but makes code cleaner. In which cases would the syntax be useful?

[1] https://golang.org/doc/go1.4#forrange

If they added support for `range 10` to iterate 0-9 this would be useful for doing things a certain number of times. Now it's probably mostly useful for emptying iterators.

Why do they need to add support for this?

it already exists...

https://github.com/bradfitz/iter/blob/master/iter.go

I don't think that would be considered good Go code. It's no shorter than writing out the 3-part for loop, and it is probably slower.

Damn, another project giving up on Mercurial and switching to Git. :-/ A few more major ones and basically nobody is using Mercurial anymore. How sad.

I am you there.

Mercurial was more friendly to us Windows developers.

But with Microsoft embracing Git this isn't any longer the case.

Git is equally hostile to everyone! Long live Git.

(Maybe the way to advance the poor Gui user interaction experience is to write frontends for it?)

If they're smart, Perforce will integrate their UI tools with Git. They have by far the best UI for a Git-style SCM.

Perforce is not Git-style, it's got a single central repository.

Speaking of which, of all the shops moving to Git, prolly only a handful exercise the full value of dvcs.

I've favored hg over git for a long time but I gave up that fight a few months back: I mostly use git for all my new code now. I think the DVCS "war" is nearing an end and git pretty clearly won it, for better or worse.

Still, it's great we've had all this DVCS craze in the past years, we ended up with great open source tools that improved a lot over the CVS/SVN of yore.

I have never use hg. I don't really see much difference. What do you like about it?

"Package glsprite blah blah blah TODO". Okay then :-D

I was going to suggest that you report this as an issue at https://github.com/golang/mobile, but issues are disabled on that repo.

Good god. Seriously, another language. I'm just starting out learning how to program, and I find it irritating that there are so many languages and it's not that easy figuring out which ones you should learn and which ones you shouldn't.