But Go's not my goto language. I'm a staunch believer in the productivity of dynamic languages. In my opinion, Go's less than stellar type system and weak reflection capabilities exasperate this gap, even moreso for most websites / apis (which deal with impedance mismatch at two boundaries).

But, to answer your question. Consider first that Go's very simple to pick up. So the investment is small. Second, where I differ from you is on your second point: Java. I dislike it. It's complicated and verbose and gets in my way. Rust and Go are both proof that we know how to build better languages now. So, when I need to share memory across multiple cores and performance is a concern, I switch to Go because it's fast and simple.

> their goals, design philosophy and levels of abstraction are nearly identical

I think it could not be more different. Java APIs (including libs by Sun/IBM/Oracle) is a manifestation of more is less which is exactly opposite of Go.

> Java for more serious server-side software

The seriousness part is only because serious folks (the one who fund projects) prefer Java. I too think this is very important if not the most important part.

> unparalleled monitoring and tooling and more,

I too would need lot of monitoring and tooling if Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us.

For example?

> The seriousness part is only because serious folks (the one who fund projects) prefer Java.

I disagree. There are plenty of design decisions in Go that make it less optimal for very large projects (e.g. dependencies, error handling, generics), but most of all lack of hackability. Go is one of the least hackable languages I've ever encountered, i.e. the only escape-hatch you have when you realize, 5 years into the project, that you need to circumvent some runtime semantics are either source-code instrumentation or hacking on the runtime itself.

> Oracle/OpenJDK GC keeps crapping out for just 10-20GB heaps which is currently the case for us.

There is no way Go's GC wouldn't crap out on you sooner (except maybe in the circumstances that are now addressed as part of Valhalla).

Having said that, I think Go is great, and is a natural fit for anyone who likes the Java philosophy (which is also the Go philosophy)[1]. Some design decisions and some implementation circumstances just make it less suitable for really big stuff.

[1]: Namely, reading comes before writing, no too-clever tricks, and no cutting-edge PL ideas; a "blue collar" language, as Gosling referred to it.

I'm curious. Is there empirical evidence proving that Go is better than Java for small command-line apps, or did you just use your personal judgement to reach this conclusion?

Sure. It doesn't require warmup, it's a little easier to deploy as a standalone executable, and performance is comparable to compiled Java code in programs of this size (you can easily confirm all three claims); those are pretty much the relevant requirements from many command line programs. It's not a property of the language but of its implementation choices (AOT compilation, statically linked runtime), which match the requirements of those kinds of applications better.

Furthermore I think most people reach for Golang in the beginning because they want performance. However I've found it incredibly easy to write unperformant Go.

I think Golang will ultimately be a very important stepping stone in language development in terms of concurrency, type systems, standard libraries, deployability, and many other categories. I think a lot of important programs will be written in it. And ultimately I look forward to how future languages draw from it.

Some may argue that Go's simplicity is a strength. Adding moving parts doesn't always help.

"stepping stone" usually implies progress and Golang was a regression on both fronts, and while its deployment story is ok that's in no small part because it just opts to statically link everything by default, which the field has been going back and forth on basically since the beginning.

Plenty of JSON libraries in plenty of languages have both a function to decode JSON and an object that allows you to decode JSON with some settings. That's not really a Go-specific issue.

If you have time to spare read this: http://blog.paralleluniverse.co/2014/05/01/modern-java/

https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

One just can't write this shit in Go. The language itself precludes it.

It really doesn't, and you could write the exact same thing. Java code doesn't look like that, either (certainly not modern code).

Lack of very basic functions (map, filter, reduce) against slices.

map[string]interface{} is pain to work with (one of the moderately popular libraries I mentioned helps: https://github.com/karlseguin/typed)

Lack of immutability.

I don't want to get into errors vs exceptions, but I've never heard a pro-errors argument that wasn't hand waving. I think the decision makes sense given Go's genesis (system programming), but given how Go's actually being used, it's a step backwards.

Many of the points you mention are fairly low hanging fruit for inclusion if you are willing to accept the tradeoffs that official Go maintainers are not willing to.

What we have here is people who are already heavily invested in Go to the point where its type system is a real problem for them, yet they do not want to fix the problems, even in light of the relative ease at which at least some the problems can be solved (again, if you are willing to accept the tradeoffs).

You could fork Go and add generics support, but you'd be maintaining that fork forever. The Go core team would never allow it to go back upstream.

The group of people who are able to fork, change and maintain their own Go variant are usually not the people who would ever consider using Go in the first place.

Have a look how long it took PHP to get an AST (instead of the broken mess of reading&executing). Those who are able aren't those who would ever deal with PHP.

I think some of the best parts of Go is the central model: "go get", "go fmt" along with the standard library - if you fork, the burden falls on the fork keep all that stuff working in a sensible way too.

- OCaml is great but parallelism is still limited by its "Global Interpreter Lock" (like Python or Ruby).

- Rust is great but ownership/borrowing is not for everyone and people sometimes prefer relying on a good garbage collector.

- Nim is great but it's a "small" project compared to Go and most people prefer relying on a large ecosystem like the one offered by Go.

- Ada was a major milestone in the history of programming languages, but it's considered by most as an "old" language, compared to Go/Rust/OCaml/Haskell/Scala/etc.

"Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++"

Maybe Python and Ruby programmers are adopting Go to do system programming, but that isn't my impression.

Any non-trivial Go project will have interface{} sprinkled all over [1], which effectively gives you the guarantees of a dynamic language with the syntactic overhead of a typed language. Truly the worst of both worlds. While I realize it's a tired argument, Go desperately needs generics in some form or another. It would remove most criticism from the language while substantially improving the correctness of programs.

[1] Here's an example with an LRU cache. Just search for interface{} : https://github.com/hashicorp/golang-lru/blob/master/simplelr...

You seem to assume that people who do not like generics complexity will not complain then.

Go's compiler is very fast, which saves a lot of time in aggregate.

Go exhibits good design in many areas, including the core language, the compiler toolchain, and the standard library. You can write a complete server-side web application using only the standard library, and it won't be terrible.

Go is generally easier to learn than C++ or Java, and requires fewer concepts and fewer steps to produce a working program. A person who has written programs in Java or C can probably learn Go in about a day. Go's spec can be read in one or two sittings. The way to write "good" code in Go is usually obvious.

I've spoken to some detractors of Go and can understand where they're coming from. Erlang and Elixir users tend to not find Go's concurrency features compelling. Functional programmers will not find that Go provides much in the way of expressive power. Java programmers have expressed concerns about the Go garbage collector, although I think a lot of those concerns are now at rest.

For those that enjoy the set of tradeoffs that Go makes, it's a nice way to engineer software.

edit: typo

I really wish people would stop saying this. There is more to Go than just the syntax. I'm a Go dev on a team of php and Java devs, and just the opinionated philosophy of Go is hard to get across to them. They bypass the Go interview only to create the mess interviews intend to prevent. They are junior/mid devs again, except that because everyone keeps saying Go can be learnt in a day they think they've already mastered it. Go is easy to get started, but there is somewhat more than a day's worth of learning, I see this daily.

If they have the fundamentals down and are creating a "mess" that sounds like a failure of the existing project leads. A little code review and direction goes a long way.. It doesn't take long to run lint, vet, -race by someone. Establishing best practices and engineering principles for the project/team can help tremendously with on-boarding too.

The python program is web backend for JQuery+html Single page web app for front end. It built its own database in the backend on top of SQlite.

It is not that hard to part a few features over, ~1-2 weeks including learning time. There are lot of examples on how to do most of typical web programs with REST/AJAX for golang.

The REST/JSON in golang is a lot of verbose than python. Go need to define all JSON fields via marshalling which is none-trivial amount of boiler place template code code. It does very strict type check on all incoming JSON structures. I have full functional regression test coverage from my frontend code to the all the python REST APIs /JSON structures. The more stricter type check in REST/JSON in the Golang requires a lot of work while provide little value for me.

The error handling the go compare to pyhon is an "acquire taste". (I have to acquire that taste yet.)

I was used to the code style of raise/catch exceptions. Python provides extremely good stack trace feedbacks on those error cases. Recover from exceptions in python are trivial.

My python code needs to build/handle 10-25 GBytes database. I spent non-trivial amount of time in the low level API of python/C code to optimized/debug memory related issue at that scale. All the issues in python backend were worked out already. The backend python all used very little memory in building and using 20+GB of DB.

For Golang, I can not get pass that barrier. Building a DB of about 2-4GB cause the golang app to completely slow down. (Most likely GC kick in, memory hogs on system level.) I spent a few more weeks on golang and can't get enough info to fixed that issue and put that porting from python->Golang project on the shelf. In python I can force a GC operations in certain point of my app to see the memory usage clearly drop down. I can't find a way to do that in golang. There were documented API in golang that supposes to do that. But it just doesn't works for me.

That's > 1 years ago.

The only thing Go concurrency has over them is that it is easier to start with, but it isn't easier to use any other pattern, because Go doesn't allow library code to be first class in the type system.

The same thing goes for value types. In Go, everything uses value types. The standard library is littered with them. Will it be the same for Java? It seems unlikely, given that they have to keep backwards compatibility.

Granted, this is all from the point of view of an outsider who only dabbled in Java, so I may be way off base.

And there were alternatives available before for Java 1.4.

Which means most Java libraries had lots of time to adapt to it.

Also threads and concurrent queues are there since the early days.

Java already has a kind of pseudo-value types, but it is JVM specific. Some JIT and AOT compilers do convert final classes with only accessors (think Point) to value types.

But yeah, it is a JDK vendor specific optimization that one cannot control.

Likewise you cannot control if a value type in Go gets stack or heap allocated, if I remember correctly. Hence why the compiler options to debug how the compiler decided to do it.

Java value types will take time to get adopted surely, but in many type of applications it doesn't really matter that much.

The use cases driving value type's adoption are related to HPC and HPT, many of which are trying to move away from C++ into Java, but still find themselves have to make use of com.sun.unsafe for that last mile.

At least as presented by IBM and Azul on their talks about their approaches to value types in Java.

Also Go's advantage in using value types will vanish when Java finally gets to have them, although we still need to wait for Java 10 for them, while Go is available now. So Go does have a few more years to gain developer mindshare.

Still Java isn't the only game in town, and there are other alternatives with GC, value types, more expressive type systems and battle tested concurrency frameworks.

How the mighty have fallen. A language with more than decade over Go and billions in investment by top tech companies and literal monopoly over enterprise usage need to even think of user share of a marginal language.

What is driving value types in Java is HPC and HPT companies in places like stock exchanges and biology research that want to move away from C++ into JVM land, but still need to keep some C++ around due to value types or make use of com.sun.unsafe tricks.

Nothing to do with Go.

But mostly, you may find you just enjoy writing Go more than Java. It writes a lot like python... I switched from mainly writing C# to almost exclusively writing Go, and whoo boy, I'm not going back. No more huge class hierarchies, no more "everything has to be in a class"... no more "anything I call may throw and jump me out of my function in the middle and I have no idea if it will or not".

There's just a lot of niceties of writing Go that don't exist in Java. Sure, there's a ton you can do in Java that you can't do in Go, but once you stop focusing on what Go can't do, you realize, it still can do pretty much whatever you want.

Dropbox just rewrote parts of their Go infra into Rust explicitly because of the memory savings they needed.

Of course, if you have checked exceptions (which are for some unfathomable reason considered bad nowadays), nothing just throws an exception. Moreover, you don't know for sure whether a Go library correctly handles errors, because it's so easy to ignore them.

At my last job, very few methods in the application ended up throwing a specific list of exceptions, except the most leaf-ward modules. Anything anywhere near the application logic just threw our top level generic exception, because there was too much below them that could throw a variety of exceptions, and there generally was nothing the middle-tier code could do about it if they failed.

It's really not that easy to ignore errors in Go in practice... and you might as well worry that a library correctly handles the result of string.Split() incorrectly. Either one is a bug. Hopefully your tests would find either one, and there are tools to detect errors you didn't handle.

You don't do that in API-stable code, period. If you are working with API-unstable code - that's the point of static typing. The code won't compile because the intention is exactly to signal that something has changed.

If you change the return type of a low-level Go function, you will have to modify its callers as well.

Anything anywhere near the application logic just threw our top level generic exception,

Bad codebase = bad. Sure. I never encountered that problem in the Java codebases I worked on at various employers. (And I'd be quite happy to complain about Java, I don't like it.)

It's really not that easy to ignore errors in Go in practice...

It is. The compiler will not emit a warning when you ignore the return value of a function/method. Here:

    fmt.Println("Hello world")

Any library that panics for reasons other than a programmer bug would never be used by the community. I read a lot of Go code and look at a lot of Go libraries, and I've never seen one that said it purposely panics in my 3.5 years of writing Go.

Compared to Java, C#, Python, C++ etc... where declaring your code panics is a perfectly normal and expected way to report errors.

it's considered bad practice in go library code to panic(), while it is considered normal error handling to throw an exception in java.

also note that you can catch a panic in go, and use it as some kind of exceptions if you really must.

https://github.com/golang/go/wiki/PanicAndRecover#usage-in-a...

For the most part, it seems to have gained traction in the Ruby/Python/PHP world as a backend optimization language. IMHO that's where it currently fits best for most people.

I see it being used for system tools, to some degree, because it requires no runtime at all (static binary). It also seems to be pretty popular for different newer data stores. Again, if it's pure Go it'll run anywhere... so it makes development (and portability) much easier.

I like its concurrency model, to a point. That said, I hope they really improve some things about in Go 2 (like working with channels and goroutines). I'm not sure when that will be.

I use Go for a lot of things, most of which are command line applications. Whether it be interfacing with some sort of REST API, taking actions on the local system, or some sort of network client for devices on my LAN. It works well for quite a few cases.

It seems to fit well with my mental model quite often, so I use it. And it's a simple language, so it was easy to get started with it. At the end of the day, it's a tool like many others. I think it's up to the creator to choose the tool that feels best to them.

This is something I haven't seen discussed much recently.

Do people generally think static linking is a good idea for things other than self-contained system-level daemons? (Where that daemon and supporting libraries might be the only thing you deploy to a server/vm/container)?

As I recently read in a (rather poor microbenchmark article) [1]: "The C assembly code I got with the following command is just 40 lines long. (...) The Go assembly code is 161.021 lines long which must be due to the static linking of Go.".

As everyone (should) know(s) any kind of language that lets you write a useful program in a page or two of code, will include a runtime of some sort (or be depressingly machine- and kernel-specific assembly code, and probably slower than anything a modern half-decent compiler produce). But I don't see a lot of discussion on how you make sure all your go daemons get updated with a new TLS/SSL/GZIP/PNG/XML-library when there's new serious bug found.

[1] Just included for reference, I don't really mean to pick on the author, but it's rather standard fare in the "quickly do a microbenchark; prove only that I'm wrong"-vein:

http://karlheinzniebuhr.github.io/en/2015/09/28/C-vs-Go-vs-p...

Yeah, I think it may be because it's situation dependent. For me, it always consisted of recompile all binaries and deploy them. And even then, I'm not sure people would enjoy a blog post just telling you to recompile all the things. It's not very sexy, honestly.

In my situation, it wasn't that big of a pain to do so. A lot of these libraries are within stdlib, so a security bug would incur a new release of Go. So an update should be pretty easy.

If's an external library (i.e., one picked up from GitHub for example), it's pretty much the same. Get new source, recompile binary with patched library, ship to all the things.

There are tradeoffs, absolutely. The alternative would be to write something in an interpreted language. That means we need to push a runtime environment up to the node, and that may include managing any libraries that are needed (think Rubygems). Managing these kinds of setups can be a pain, especially if a node has multiple projects with different dependencies. I found that shipping a single binary was often easier for me.

But it goes back to it being an item in the toolbox, depends on what you need and how your systems are built.

The servers dont have internet access and to get files onto them i have to do the same story as above (using sftp). So having 1 static binary that i copy over without having to worry about the dependencies is great.

"TLS/SSL/GZIP/PNG/XML"

all of these are part of the go standard libs, and gets regularry updated with the language.

tls and ssl: https://golang.org/pkg/crypto/tls/ gzip: https://golang.org/pkg/compress/gzip/ png: https://golang.org/pkg/image/png/ xml: https://golang.org/pkg/encoding/xml/

since golang also has built in support for fuzzing in the toolchain, the standard parts are quite battle tested already.

if you study their sourcecode you will also find Benchmark functions, that you can use to benchmark the implementations (go test -bench ./...)

So no, you shouldn't learn Go unless Go solves the problems that you need to solve. That said, as others have mentioned it's a pretty simple language and I found it quite easy to pick up and start writing programs in.

Indeed, if you already know Java, the only reason to learn Go would be if you had a burning need to produce self-contained statically linked binaries. For example, at my company, we have a habit of producing command-line clients for our services, and Go is a good choice for that.

Go has been most useful for people who know a dynamic language like Ruby or Python, but who are encountering problems where they need more performance, better concurrency, or stronger static guarantees. Go improves over dynamic languages in those respects, and it's pretty easy to learn, so it's a great addition to their toolbox.

Google is the perfect counter-example to your argument. C++, Java and Python were the 3 main programming languages in use at Google, and despite that, they designed Go and started using it instead of C++/Java/Python in some projects.

Go can be used instead of C++ when you need and can tolerate a garbage collector, and you don't need things like a custom memory allocator.

Go can be used instead of Java when you need a native executable, statically linked (like you wrote), when you need a better control over memory layout (especially to reduce pressure on the garbage collector), and when you need async IO without callbacks/promises/futures.

[1]http://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fro...

Warranted or not, it usually fills the space where fast microservices are necessary.

Personally I think Go's closest competitor is Scala.

Coming from Python, Ruby, and TypeScript -- Go is a fair bit more verbose, and Java takes that a step further. So Go is a nice go-between from scripted environments to compiled.

I've never tried to make a whole web app with it, but it's great for making microservices.

Yea if you are doing any devops and want to contribute to or use consul/docker/swarm/kubernetes/terraform....

curious if rust has a hit project like one of those above.

I mean, eventually...hopefully...

Since confounding downvotes, a tldr: closer to Python than Java.

If you start having to Marshal/Unmarshal JSON, it'll get pretty annoying pretty quick depending on the JSON format.

For most web applications, JSON in or out is of a known schema, so this generally impacts other servers moreso than web applications.

I guess I was trying to call out that, depending on the API you are supporting, it can get hairy. If you are designing it from scratch, when starting the Go project, you can structure your JSON in a way that's easy to work with.

If you're coming in to something that was easy to use in a language like Python, it may not be that easy in Go.

One thing to consider is that the language is purposefully small, and you can learn the basics very quickly. Spend a day with it, and you'll get a feel for the language syntax and maybe some exposure to the standard library. You'll have a sense then whether you want to pursue it further.

So if you're curious, the compelling reason is that you can satisfy your curiosity without much effort, and that will ultimately be more satisfying than asking strangers to convince you one way or the other.

Go is drastically less bloated than Java. Stupidly fast compilation and running lets you use it almost (but not quite) like you might Python for some things.

A recent example for me: Writing a quick & dirty server that talked to a device that was spouting a stupid binary serial-over-TCP protocol. Goroutines made handling the bidirectional communication trivial, and go being a bit on the low-level side makes it easy to cope with binary protocols without worrying that your chars and bytes and unicode characters are getting all mixed up. You can do all this in Java - but it's so clean in Go.

My current playbook looks something like:

Network servers: Go. Go go go and more go. Things that talk to lots of other things and involve interesting communication are a natural match. I rewrote my pi searcher in Go a year or so ago, for example - http://da-data.blogspot.com/2013/05/improving-pi-searchers-s... - and this year was able to run the thing through Pi day on only a single (larger) AWS instance. Woot. We use it for research, such as writing Paxos derivates. Great stuff.

Go's also pretty amazing for little utilities if you want them to be faster than Python -- particularly if you want the launch time to be faster than Python. Which can be great for utilities you build to use in loops in shell scripts, etc. The fact that they're purely statically linked makes a lot of otherwise hairy cross-platform nastiness just go away.

The fact that it's statically typed and includes great, easy-to-use parsing support for itself also makes it much better for refactoring than Python is. The tools aren't as mature as those for Java, but the language is well-designed to support it (think "go fix" -- which can automatically port forward much old code to newer versions of the language). The tooling for this kind of thing is great for Java, good for C and Go, and absolutely horrible for Python. As a consequence, Go can more roubustly handle being worked on in very large codebases and teams. What would be a slightly scary regexp replace in Python can be a much more syntactically and semantically safe change in Go (at the cost of a little more writing of the replacement code).

Tensorflow (and most things numeric): Python. Because it was pre-decided. :) But, more seriously, Go's lack of generics hurt it here (you can't express matrix/tensor manipulation natively, and saying A * x is about as right as it gets when you're talking math). The ML community has adopted Python to a pretty strong degree, particularly because of NumPy, and so it fits in really well there. I still get grumpy about it -- I've lost count of the number of times I've messed things up that static checking could have caught, requiring quite a long time for tests/running it to finally do so. But I do like Python, to the point of:

Beginners: Python. I pushed hard to switch CMU's intro course for non-majors to it, and succeeded with a lot of help from others. It's awesome seeing what a bunch of motivated, smart first-years can accomplish in Python in one semester. Damn. And they can 'take it with them' -- scientists/engineers and numpy are a pretty good match, for example.

Fast as hell: C++, light on the ++, heavy on the C. A lot of our research code is very low-level. I'm still finding Rust incredibly annoying, but I may just be a slow learner, and it's on my list to take a really serious look at it after I'm back from Google.

(You'll note that nothing that I do involves a UI. I'm a unix & systems person through and through, which helps explain the utter lack of Java, C#, Swift, etc. in my life.)

Tensorflow has a minimalistic, but good-enough C API for running graphs. So, once you've built/trained a graph in Python, you can run it from Go without much trouble.

(Source: did that last week.)

still get grumpy about it -- I've lost count of the number of times I've messed things up that static checking could have caught,

For basic numpy-like functionality Armadillo and Eigen also work fine. I agree, I highly dislike numeric Python for the lack of type checking. Combined with the relatively long compile times of e.g. Theano it's a disaster (yes, I know 'fastrun').

I'm still finding Rust incredibly annoying, but I may just be a slow learner,

I'd encourage you to continue. I am also a beginner, but wrote some small crates. Once you get the hang off it, it combines the strengths of most things out there - C++-like memory control and performance, the terseness of Python/Haskell (though map/fold/etc.), and safety. It's a truly fun language to program in. Unfortunately, the library ecosystem is still rough.

You are writing most of your code in Go, so you don't really have practical knowledge of Rust. I recommend you to try start some project (or tool) in Rust, keep patience first month or two and then you'll love Rust. It's how came to Rust, now I'm in the "honeymoon" period with Rust and I love everything I do with it. Before Rust, I started thinking I'm losing joy in programming, by doing stupid and boring things every day.

I don't really see a reason why this should be the case, so I hope it will improve over time.

But using mandatory reference counting does limit the sort of tasks for which Swift will ultimately be suitable. I wouldn't put it in the same category as C++ and Rust for that reason.

- Swift performance issues involving working with strings, some of which have been ameliorated by later releases;

- 'Hidden' bridging between NSString and String, which can be expensive and might have something to do with some of String's APIs actually being Foundation APIs in disguise.

There is much to be done with regards to Swift performance, though. If you have any sample benchmarks I would be interested in writing/running them myself, just for personal edification.

In terms of 'close to the metal', I freely admit this is a ill-defined term I am using for my own benefit. Swift code doesn't execute on something akin to the JVM or CLR; it still requires a heavier runtime than (e.g.) Rust. It is AOT-compiled to machine code. (But then again, this is possible to some degree for Java as far as I can tell, although it is certainly not the most popular way to run Java code.)

I agree that mandatory RC for classes and boxed types makes Swift impractical for a certain definition of 'systems software' typically written in C++ and occasionally Rust. For a different definition, one that encompasses the garbage-collected Go, Swift is theoretically suitable. The language designer has mentioned that he would personally like to see Swift gain some form of borrowing/lifetimes, although even if that did happen Swift would not get it for years to come.

The simplest benchmark I used is a function that does the equivalent of

  str.split(/\s*,\s*/)

Swift: 3.5 seconds

Java: 0.31 seconds (after warmup)

So that makes Java more than 10 times as fast as Swift.

Here's the source code. I would be more than happy if you could tell me that I'm doing something horribly wrong (which I frequently do):

    import Foundation

    let N = 1000000

    func generateTestData() -> [String] {
        var a = [String]()
        for _ in 0..<N {
            a.append(",,abc, 123  ,x, , more more more,\u{A0}and yet more, ")
        }
        return a
    }

    func splitAndTrim(s: String, sep: UInt16) -> [String] {
        var result = [String]()
        result.reserveCapacity(10)
        
        let space = NSCharacterSet.whitespaceAndNewlineCharacterSet()
        let cs = s.utf16
        let eos = cs.endIndex
        var begin = eos
        var end = eos
        
        for i in cs.startIndex..<eos {
            let c = cs[i]
            if c == sep {
                result.append(begin == eos ? "" : String(cs[begin..<end.successor()]))
                begin = eos
                end = eos
            } else if !space.characterIsMember(c) {
                if begin == eos {
                    begin = i
                }
                end = i
            }
        }
        
        result.append(begin == eos ? "" : String(cs[begin..<end.successor()]))
        return result
    }

    func doSplits(data: [String]) -> Int {
        var count = 0
        let sep = ",".utf16.first!
        for s in data {
            let parts = splitAndTrim(s, sep: sep)
            count += parts.count
        }
        return count
    }

    let data = generateTestData()
    let start = NSDate()
    let sum = doSplits(data)
    print("elapsed: \(NSDate().timeIntervalSinceDate(start))")
    print("sum: \(sum)")

    import java.util.List;
    import java.util.ArrayList;

    public class ParseTest {
    
        static int N = 1000000;
    
        public static void main(String[] args) {
            List<String> data = generateTestData();
            for (int i = 0; i < 3; ++i) {
                long start = System.currentTimeMillis();
                int sum = doSplits(data);
                System.out.println("elapsed: " +
                        ((System.currentTimeMillis() - start) / 1000.0 + " seconds"));
                System.out.println("sum: " + sum);
            }
        }
    
        static int doSplits(List<String> a) {
            int count = 0;
            for (String s : a) {
                List<String> parts = splitAndTrim(s, ',');
                count += parts.size();
            }
            return count;
        }
    
        static List<String> splitAndTrim(String s, char sep) {
            List<String> result = new ArrayList<>(10);
            int eos = s.length();
            int begin = eos;
            int end = eos;
    
            for (int i = 0; i != eos; ++i) {
                char c = s.charAt(i);
                if (c == sep) {
                    result.add(begin == eos ? "" : s.substring(begin, end + 1));
                    begin = eos;
                    end = eos;
                } else if (!Character.isSpaceChar(c)) {
                    if (begin == eos) {
                        begin = i;
                    }
                    end = i;
                }
            }
    
            result.add(begin == eos ? "" : s.substring(begin, end + 1));
            return result;
        }
    
    
        static List<String> generateTestData() {
            List<String> a = new ArrayList<>();
            for (int i = 0; i < N; i++) {
                a.add(",,abc, 123  ,x, , more more more,\u00A0and yet more, ");
            }
            return a;
        }
    
    }

There is nothing special in Go about it.

Except Java and NET developers worth their salt are aware of ways to AOT compile their code to native, thus enjoying the same startup time as Go.

There is still the RoboVM version before it got acquired by Xamarin.

There are also Avian and JikesRVM, but it depends a bit what features you are using.

The problem with Java non-comercial AOT compilers is that the majority of the Java shops that really care about AOT compilation don't mind to pay for it, so there isn't a real effort to invest on a free AOT compiler.

The lack of community support for RoboVM was a good example of it.

Even the upcoming AOT compiler in the official JDK will be a commercial feature, at least it was announced as such.

Basically DIY everything outside standard library ( e.g. section 9.1 building CSRF) Personally switched to http://www.phoenixframework.org/ for json apis/web apps

There is little more to it than that.

here's an interesting article: http://www.whitesmith.co/blog/why-i-started-to-use-golang-mo...