I still don't get the Go love.

That being said, if I were starting a web service as a business today, it would be very hard to persuade me to not choose Java. It's simply the best platform from a business perspective. For better or worse, CS departments across the US produce Java programmers more than anything else. This makes it very easy to hire Java developers. Java has stability, Java has concurrency, Java has hot reloading, Java has a good track record, Java scales, Java has really nice functional programming support, and Java is very popular with the everyday programmer. It Java has so many benefits outside of it's technical or philosophical specifications, that it's almost an obvious choice to me for web.

What's funny is that Erlang is the ideal platform for me from an idealist perspective, but I don't think I have the luck or experience it takes to successfully start an internet company with Erlang.

But the ecosystem around Java is very complex and hard to manage. Dealing with JVM configuration, webserver configuration, build system configuration, IDE configuration and God knows what else takes up all kinds of brain-space.

And every so often the community goes off on some crusade. Everything must be Design Patterns. Everything must be specified in XML. Everything must be a Bean. No, everything must be Injection. No, no, everything must be Annotation.

The Java culture really needs to learn the value of the simple and explicit.

You couldn't have described this better for me. This is my exact frustration with the ecosystem, and it's the only thing that keeps me from using Java as my default language of choice. The language itself can be used very well, just wish the tooling was more concise and functional.

Then you will get testing frameworks, libraries each with its own generics workaround and cool interface spaghetti that looks beautiful in UML diagrams at the scrum wall room.

People don't really get that before Java there was C EE and C++ EE, all with similar sins.

One can change the language of the enterprise, but not what those architects do with them.

Perhaps the best thing for the language would be for it not to become too popular.

-- Haskell

Avoid (success at all cost)

Rather than what you might be (others do at least) implying:

(Avoid success at all cost)

This is the mother of all premature optimization. Other than maybe modifying heap size or setting client vs. server, most of the default JVM configurations work for almost everything.

> build system configuration

I actually find maven pretty easy to use, but maybe it's just that I am used to it.

> IDE configuration

I don't know what crazy IDE you are using, but both Intellij and Netbeans need very little, if any, configuration out of the box.

> [Java] community goes off on some crusade

As opposed to everyone else? /s

There's also the initial indexing, but I can live with that, since it enables beautifully fast jump-to-definition, which is hard to live without.

Having the webserver is useful for reasons beyond just being independant of the webserver itself, like exporting metrics. Making the logs inspectable. Getting thread dump, inspecting current state, ...

This is true for any programming community.

All language arguments aside, Go coders are usually pragmatic and humble and Go code is usually simple and explicit.

Type erasure was a pretty big one that I've felt the impact of a few times in the small amount of Java code I've written (99% being school assignments). One of the reasons I strongly prefer C#/.NET as a language/environment. What I've tried of ASP.NET coding seemed nice.

I have a love hate relationship with Java. I do have Java apps that runs 24x7, day after day without failure.

I think I protest too much.

This is actually the reason I would not choose Java. I started programming Java in the 90s and spent the better part of 2 decades writing code in it. The last 8 years of that time, I was a lead developer, so I've interviewed hundreds of Java developers. The most kind way to describe them, as a whole, is uninspired. If I were more honest, I'd say that the vast majority of Java programmers are completely unqualified. There are very few Java programmers who write code because they have a passion for it and it shows...most just learned Java to make lots of money.

On the other hand, if you were to choose a language like Go or Erlang, you'd get less than one tenth of the resumes for your open position, but the majority of those resumes would be highly qualified. The reason is that each of those candidates was motivated to learn a new language solely out of curiosity. You'd be automatically selecting for intellectual curiosity and that's a powerful tool that will save you hours upon hours sifting through Java candidates who are simply a waste of your time.

This isn't an indictment of the Java platform...it's no longer my favorite programming target, but there's nothing fundamentally wrong with it from a technical perspective. It's just a recognition that more != better when it comes to language ecosystem. Quality matters.

> what I would consider the ideal creative process for me as programmer.

Java has long been my primary professional language, and over the past few years Go has taken on a strong secondary niche at my job. I'm big fan of both, and tend to play Switzerland in arguments between them.

That being said, the best Go IDE out there right now is the official Go plugin for IntelliJ... which again, happens to be the best Java IDE out there. If you are doing modern software development in ANY language, then you are probably traveling one of three paths:

(1) Using an IDE based on JetBrains or Eclipse.

(2) Using a variant of Microsoft Visual Studio, which is about an order of magnitude more bloated than #1.

(3) Using a plain text editor, which for a typesafe language is a bit daft.

When I had the displeasure of using IntelliJ it would use 1.2GB RAM for a fucking 5 file project. Debugging would then use another 1GB RAM.

Visual Studio uses 1GB RAM with a 150 project solution open, and it opens said solution about as fast as IntelliJ opened that tiny project.

Adding something like Resharper (by your beloved Jetbrains) will make Visual Studio bloated and slow.

What's wrong with using Vim, Emacs, or Sublime? There are plugins out there which get you a lot of the IDE magic (including jump to definition, autocomplete, autofmt, and there probably is something for inline errors)

E.g. if you call a statically resolved function, your IDE should be able to take you to the function's definition.

And it's pretty trivial to get Vim super integrated with go: https://github.com/fatih/vim-go/blob/master/README.md

An Integrated Development Environment?

Most of this can be added to emacs too. Then it's an IDE.

it is lightweight, enough features and gets the job done.

That is real a problem of quality of those CS departments.

My humble Portuguese CS department teached me about Pascal, C++, C, Prolog, Caml Light, Smalltalk, Java, Lisp, MIPS and x86 Assembly.

Having a quick look at their current curriculum, now around 25 years later, they seem to still provide a good mix.

I agree it's a problem. I've always found it odd that the AP test is in Java for example. I would imagine pseudo code would be a better choice for a conceptual test.

Those of us, like myself, that opted into the compiler design classes had a quite a few more to play with.

I guess the problem are those universities that tend to be more focused on "languages to get a job" than doing the real work of an university.

All commercial JVMs support AOT compilation to native code.

Yes even some of the Oracle ones, e.g. Java Embedded.

Do you think this large pool of programmers are good?

>This makes it very easy to hire Java developers.

Yes, if you are looking for sub-par developers. I don't think Google thinks to itself "oh man we're so glad we use java, otherwise hiring would be challenging". No, they have just as much difficultly hiring as anyone else. I'd even say that considering it's the 'blub' language to use PG speak, it makes hiring harder for them.

>Java has stability, Java has concurrency, Java has hot reloading, Java has a good track record, Java scales,

No, those are things the JVM has.

>Java has really nice functional programming support,

You can't honestly believe this. How much functional programming experience do you have?

Yes, why not? I have yet to see evidence that Java programmers are not good. Seems like a discriminatory mindset. The large pool also makes them easy to replace. I think Facebook has had an ad for an Erlang developer for a few months now. I don't think a startup needs that kind of stress.

Also, I'm sure there are Java Devi who are absolutely fantastic. That is, I think the idea of the meme "real passionate programmers use less mainstream languages" is entirely unsubstantiated. This line of thinking comes from immaturity, elitism, and a desire for validation by association.

It's just like the "the best lawyers were on the debate team" meme that's also very untrue. It sounds nice if your kid is on the debate team, though

>No those are the things the JVM has.

I meant Java as a platform. Funny, you were the only one who didn't know what it was what I meant here.

> You honestly can't believe this. How much functional programming experience do you have?

I've dabbled with Erlang and Haskell. I don't have as much functional programming experience as I would like. Also, I've only heard good things about Scala and Clojure. What was so ridiculous to you about what I said? Or are you unable to forgive an accidental conflation of Java and the JVM?

Your criticism come across as nothing more than unreasonably pedantic expectations for terminology. They either reflect your inability to use context clues effectively or your lack of common sense.

> It's the 'blub' language to us PG speak

This is a poor reason to think Java developers are incompetent. I hope this isn't the premise that led you to that inherently false conclusion.

I do agree, the JVM is a solid language choice. I also don't think going with too esoteric of a language is a good thing. Probably a little early to bet a company on Idris or Ceylon.

Still, I apologize for my tone. Let me give you purely anecdotal information about me, so you can at least see where I'm coming from with regards to my anti-java stance.

After doing java/C# for many many years, I will not do it again. I'm much more productive in Scala/F#/ML, it's more pleasant to use, and I believe the average programmer using those languages ends up being a different caliber than the java programmers.

There are absolutely good Java programmers. They just probably work at Google or Facebook and you'll be competing with Google. I would take less money (and have, though not too much less) to not work at Google because I get to use a functional language.

shrug

If a startup is using java, I think to myself 'why java? why not Scala, F#, or C# at the very least?'. Usually the answer is 'scala/F# programmers are too hard to find', but that's not really true, what they mean is they're not willing to pay the 20% premium for them. That's a strong indicator that a start up doesn't value talent.

It's all good! I've had the same heat of the moment responses on here, so I get it. But thanks anyways.

> If a startup is using java, I think to myself 'why java? why not Scala, F#, or C# at the very least?'. Usually the answer is 'scala/F# programmers are too hard to find', but that's not really true, what they mean is they're not willing to pay the 20% premium for them. That's a strong indicator that a start up doesn't value talent.

Definitely. If I chose the JVM or (blanking) the Microsoft VM I would not limit myself to the object oriented languages for those platforms. I was under the impression that using multiple languages was a given, but apparently not? I wouldn't know, I'm doing iOS right now (hence the username). I graduated fairly recently, so I can only go off of what I've read.

So, I would probably do Java and Scala together if that was possible. I really haven't looked into it. My startup was completely hypothetical.

Most of the stuff Kotlin does, absent much nicer functional syntaxes, I can do in Java 8 already. I think Kotlin does a better job at expressing it. I especially like the first-class nature of functions, and I know I'm just in the early days of understanding it.

The programming language has really nothing to do with the quality of a developer. A new language is learned quickly, software engineering skills not.

So you willfully ignorant but will continue to spout off opinions anyway?

Take interfaces. In Java you might start with them. In Go - in the best case - they emerge, when it's time for them. Java has more mature tooling, but then, I cannot remember gathering runtime insights with Java quicker than with Go pprof[1].

Java is rock solid and more and more libraries are written in lightweight and clean way. Go has more momentum and also a growing number of curious users, who explore the language in creative ways[2].

[1] Google image search for "go pprof": https://goo.gl/6l7t1b

[2] Just discovered this amazing guy recently, https://github.com/fogleman/ln, https://github.com/fogleman/nes

And it's a relatively subtle language feature that does this, the way that any struct that implements a given interface automatically conforms to that interface without having to be declared. Which means you can declare an interface that foreign packages already conform to, and then freely use them. Which means that you can code freely with concrete structs to start with, and then trivially drop in interfaces to your code later, without having to go modify any other packages, which you may not even own.

I completely agree that on paper Java and Go look virtually identical. But the compounding effect of all those little differences makes them substantially different to work with. Good Go code does not look like good Java code. You'd never confuse them.

But you cannot do the reverse: you cannot make a type from a foreign package conform to your interface by adding new methods to it. This is because, with structural typing, it's not safe to add methods to types in other packages, since if packages B and C both were to add a conflicting method Foo to a type from package A, B and C could not be linked together. This is a major downside of structural typing for interfaces. Swift, for example, has the "extension" feature, and Java's design allows for it in principle, but it's fundamentally incompatible with Go's design.

I don't understand the idea that not having this feature somehow helps enforce dependency order either. Extension implementations of traits don't give you any more abstraction-breaking power than downcasting interface{} to a concrete type not defined in your package does. In fact, they're pretty much strictly less powerful.

I disagree. My best, fastest to compile code has always focused on just one type. You mention graphics programming: for 99.999% of the cases you want to pick a type. Usually, this will be float, and thus for SIMD a 4 or 8-vector of these, like https://github.com/aktau/threedee-simd/blob/master/include/t.... Despite the support of recent graphics cards for doubles, the fact is that they are usually quite a bit slower. Even when precision bound, there are usually tricks that will let one keep using floats (esp. wrt to Z-buffers).

I thought you could.

You don't add the methods directly to it, but you can easily embed the foreign type into a new type that confirms to the interface you want.

  type FooWrapper struct {
    Foo
  }

  func (fw FooWrapper) SomeFunc() {
  ...
  }

There are times when I love the structural typing aspects of golang (trivial dependency inversion) and there are times when I hate it (nontrivial renames), its one of many trade-offs you have to be prepared for in golang.

Except that it is very difficult to find out which struct implements what interface, you'd have to go look through the code. Not to mention there is always the possibility of accidentally implementing an interface. This has already caused real issues it seems (there was a blog post about it).

There already exists a solution for this issue, via typeclasses.

But golang doesn't have generics.

JVM suffers from slow startup times and tends to eat a lot of RAM, even when the app doesn't technically need it around. It has an object model that spawns a bazillion tiny objects, and much of the JVM's GC design exists to cancel out those tiny object allocations.

JVM has many upsides (the portability and pluggable nature of JAR files is a huge one), but I think a lot of people are attracted to Go's bare-bones approach. Closer to the metal, a "better C", smaller overhead.

I am running several (albeit Kotlin) daemons right now that are using less than 256MB of ram on my machine. Everything on the JVM is configurable.

At some point, I think it's just simply a matter of taste. If you want to be closer to the metal, then Java (and I'd even argue Go) isn't really the right language for that.

The alternative is a commercial JDK, almost all of them do support AOT compilation.

Java also does not need a JVM to installed.

1 - Use a fat jar

2 - Use the upcoming Java 9 linker which bundles everything together

3 - Spend some money and get a commercial JDK with AOT compilation to native code. All the major ones support it.

4 - Eventually Java 10 Oracle JDK will support AOT compilation to native code, but it remains to be seen if will remain commercial only

2. See #1.

3. Neither does Java, although of course it can be helpful.

4. Error handling is certainly not less verbose.

None of the above overcome the lack of tooling, libraries and generics, at least for me.

Java is 100-ton dinosaur to be working with using a simple editor. Spring, it dependencies, hibernate, junit alone make you want to work with an IDE.

There is an enormous amount of stuff that "conventional" IDEs to and emacs does not do.

Consider NetBeans: there are a lot of people that use the NetBeans platform to create stuff that have nothing to do with programming, the very same way emacs users create modes that have nothing to do with programming: https://platform.netbeans.org/screenshots.html

Seriously guys, grow the fk up.

In what programming language could Emacs possibly not be feasible option for a seasoned Emacs user?

Finally, the object-oriented nature of the JVM is sometimes a pain. This can be worked around, but there is something to be said for preferring the typing of Go.

That said, the JVM scheduling is pluggable, so I have options for a much bigger variety of use cases. With go if the default scheduler doesn't do what I want, I'm stuck.

List<Integer>[] j=new List<Integer>[10];

and this is a a serious problem. If generics are correctly implemented, then it should compile.

val j = List(1, 2, 3)

But that's beside the point—OP was pointing out that you can't have generic allocation.

For those benefits you trade off vs the jvm a) abysmal tooling b) extremely primitive concurrency support c) a more primitive type system and d) a much smaller ecosystem.

I very much like golang for 2 classes of problem 1) http/s based microservices and 2) command line programs that are a touch more complex than bash. I would never choose golang for a system that I thought was going to have a high LoC count or had a complex domain to model.

Scala's the only one of these three languages with any adoption right now. Groovy is virtually only used in its original dynamic mode from 2003 for things like scripting and Gradle build files, and very few people use the @CompileStatic mode introduced in 2012. Kotlin 1.0 has just been released, was subjected to stringent QA, and I expect JetBrains to use it more and more in its own products like IntelliJ, so it's a good bet it will become more popular with developers. So I'd say use Scala and Kotlin if you need static typing. Clojure, though it doesn't have static typing, has other features like syntactic macros for terseness, default immutability, and concurrency that would recommend it in many situations.

Here in Germany you almost don't hear about Groovy anymore in any JUG event.

If it wasn't for Gradle and Android adopting Gradle, I bet we would hear even less about it.

[edit]

Though maybe I was thinking of adding parameters like https://play.golang.org/p/FKUMlQzCI5

In any case 'thebaer continues to be my hero.

We have a small library of functions for sweeping up error returns, and for collecting errors from multiple functions and checking them all at once. It helps a lot.

Golang is very much on to something with it's "errors are values" philosophy, but I'd be the first to acknowledge that it's not a fully baked philosophy. It is weird to discover fundamental things about how to structure basic code several years into writing in a language, but that happens somewhat regularly with Go.

I'll be over here muttering to myself about monadic error values...don't mind me.

Edit: prodigal_erik found it: https://golang.org/ref/spec#Calls

That sucks to see people making a mess with error handling code, but there are examples of good uses out there. This [0] is one I quickly found.

[0] https://github.com/schachmat/wego/blob/master/we.go

Go just works better for some of us, and that's all the justification we need.

TL;DR being nice and polite is over-rated. Some things are wrong and it is helpful to say so.

And thus continues the never ending cycle of "You're wrong! No you're wrong!"

If we discuss what e.g. Java does better than Go and vice versa for purely technical interest, there is little emotional pressure. But if I feel that somebody is trying to make me use Java (or Rust, or C++, or Visual Basic) over whatever I prefer and feel comfortable with, I get defensive. When people get defensive, they become unwilling to admit shortcoming in their preferred language/framework/OS/..., and so the debate devolves into "You're wrong! - No, you're wrong!" and namecalling.

A person may have the best of intentions, but they need to realize that their words can have unintended consequences. There are places times and ways to properly discuss go's shortcomings, but there are also times when it is wildly inappropriate.

This is a good event for a very hardworking and capable part of oyr community. They deserve a little respect.

i.e. You think Andoid apps have the same revenue potential as iOS apps? That swell! Good for you buddy, whatever works for you is fine with me :) (Now go back to your cubicle and stop bothering me me.)

I also find the tooling for go vastly superior out of the box compared to what i end up using with java/Scala. XML?! Wtf?!

Go forces people more into boxes and leaves a lot less up to discussion. This is annoying for the individual contributor, but I believe is a net plus for a team of contributors.

Besides that, different JVM's? Very rarely does code depend on a specific JRE unless we're talking between versions (say 7 vs. 8), but you would have the same problem in Go if significant language changes were made between releases.

With the JVM you can use HotSpot, Dalvik, WebSphere, or OpenJDK. The JVM is just a spec. With Go, you've only got one runtime to choose from. That said, if you code to the JVM spec, then you don't care what implementation you run on.

Since Go compiles to a binary, the concept of a runtime doesn't apply the same way it does for Java. You can compile a Go program with the Go project's compiler or with the GCC. The GCC Go compiler uses different optimizations and may produce faster binaries in some circumstances. Since the Go language is also a spec, other compilers may arise if there's a demand.

Much of the Go love comes from doing (almost) everything Java does with a lower cognitive load... and goroutines are really useful, too.

Golang fits in nicely in such cases. If I want the JVM, I rather build a clojure'ified uberjar.

Debugging absolutely needs work though.

And yet I far prefer all of them over an interface{} solution. Works so much better. But the files are just so ugly, and changing them is rather hard.

Worst of it all, I've been thinking about generating other pieces of the code. For instance, I hate the http handlers and structure surrounding them being the same thing all the time.

Http handlers = decode and basic argument validation, then authentication and CSRF protection, and then conversion (to be done ad-hoc because no types in http parameters), some using strconv, some using json encoding, all with "error handling" (essentially if error then bailout 502), followed by calling the actual method. All of them are the same (save for small bugs due to me not paying attention).

I'm thinking of replacing it with generated code.

Re handlers, you really don't have to use the http handler. I use one which accepts a context, and returns an error (for rendering), which simplifies the boilerplate somewhat as errors are rendered by the router. I'd look into using your own interfaces before generating standard http handlers.

The other thing to bear in mind is that if you try to make things all implicit rather than explicit in order to avoid repetition, it's very easy to be unaware of what's happening behind the scenes (auto-auth, or auto-render as in rails), and get stuck when you want to do something off the beaten path. I rather like Go's more verbose but very explicit style. It's a trade-off.

Auth, CSRF, parameter parsing should definitely be in a separate pkg you're using, not repeated each time IMO, so there should be minimal boilerplate for those.

Using text template is a really nice way to generate http handlers if you typically set up resources in a similar way, so I'd definitely recommend trying that out. I haven't looked into go generate as that came out after I started this approach.

The approach I take is to generate actions with all the normal code in them as scaffold (for CRUD actions) - so for each one auth, then setup, then business logic, then render, and then edit those as necessary, as often as an app grows each action diverges from the standard (say it doesn't do auth, or processes parameters differently etc). This is easy, explicit, and very clear when returning to code after 6 months at the cost of some verbosity.

Firstly, for data access methods (think load struct type X from offline storage). It's like gobs or encoding/*, but it blasts those away when it comes to speed.

Secondly, for searching through data (given a list of struct type X, and some number of indexes of the data (essentially listing what the sorting order is according to one of the fields), search for the record that satisfies condition X, fast.

It's very handy that after generation, my vim editor will actually autocomplete all the available methods, and adding an extra method or struct to either the datastore or the in-memory searchable index is adding a line to a file and pressing a shortcut.

And the one I've started to write, given function X with named input params a,b,c and named output params d, e and f, accept an http request extracting these parameters, validating authenticated user, check CSRF, all with appropriate error handling, call function X with the parsed parameters, encode it's outputs as a json struct and return the response. Well, I'm working on this one, I guess, so this one might still change. Maybe also write a javascript interface that calls these methods to a typescript file.

And they're writing tests for a lot of these autogenerated methods. Because we do code reviews and they insist on testable code. I think this is unnecessary, but I've been seriously outvoted on this issue (having tests for one or two of the autogenerated methods, leaving the rest untested until you actually run into a problem is my preferred option). I would object, and I have. Oh well, my total lines of code written is through the roof, well on it's way to the moon, far exceeding people who've been writing code for more than double the amount of time I've been here. And it's useful code, and "useful" tests, so ...

> The approach I take is to generate actions with all the normal code in them as scaffold (for CRUD actions) - so for each one auth, then setup, then business logic,

Modifying autogenerated code is tricky and dangerous. You should never do it. It takes discipline, but you should always change the generators, never the code.

yeah, basically type coercion/checking and interfaces have replaced generics in some (not all) use cases

Other than that competitor, I don't think Go has too many others in the same niche. Maybe D? I love the combo of native code + high level language + single binary in a language that also tackles parallelism.

It's as if the Go language designers took a good hard look at Python and went "This is what's wrong with it", taking its greatest weaknesses like dependencies/packaging and the GIL, turning these around 180 degrees, instead becoming main advantages of their new language. Of course, it's not an interpreted language so the comparison isn't perfect, but Go ticks a lot of boxes for me as well that Python perhaps never will due to design.

Only in that it will end in a native binary.

In any other sense Go is worlds behind.

What is that even supposed to mean? The semantics and memory model are nothing like C and the syntax even less so.

> generates a single

Just link against static libraries; it's literally a single switch.

> supports concurrency very well

Better than C; much, much worse than C# and I'd argue even worse than Java with j.u.concurrent (want channels? use j.u.concurrent.BlockingLinkedQueue)

https://en.wikipedia.org/wiki/Composition_over_inheritance

> OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late binding of all things.

Golang does Pseudo OO like Motif. The added value is the composition which is amazing.

The problem with lisps is that you need to know lisp, and relatively few people do. It also requires a different approach to program design. It may or may not be a better approach, but the fact is, that's not what most people are trained for.

In contrast, go is imperative through and through, and its syntax is similar enough to C that people find it easy to adapt to it.

Opposite example: implementations of OOP in Lisp and JS.

IMO Python wants to be opinionated (in your 'one obvious way' definition), and it actually was 10-15yrs ago when Perl was the comparison, but ongoing progress has eroded that a lot - especially across the stdlib :)

But yeah Go and RoR are probably two of the most opinionated technologies I can think of.

Genuine question, why all the negativity?

I was. My previous message is an arbitrary combination of HN clichés, of which "opinionated" is one. It's gibberish, devoid of content but written in a fashionable way. It got zero down-votes so far. Maybe something to think about.

Have you used delve? https://github.com/derekparker/delve

Go makes it easy for third party applications to parse the language,so generics are possible with pre-processing/codegen; e.g., https://clipperhouse.github.io/gen/

For me the big minus of Go is that it is memory unsafe language when it runs with GOMAXPROCS>1 (default since 1.5). It is not that bad like in C as opportunities for bugs are not common, still this is an issue as consequences of such bugs is arbitrary code execution.

Another problem is lack of union types leading to poor code practice when those are emulated through (foo, err) or similar return types.

No, it can't. There are patterns that no monomorphization strategy (including code generation) can express. For example:

    func MakeList<T>(x T) List<T> {
        ...
    }

    func Foo<T>(x T) {
        if ... {
            Foo(MakeList(x))
        }
    }