Go 1.6 is Released

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.

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

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.

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.

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)

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.

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.

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.

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.

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.

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

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

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.

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

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

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.

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.

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

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.

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.

Yep. That's exactly what I was talking about. You know that's what prepared statements do, right?

Yes?

This seems like a response to something that wasn't my comment. I even went out of my way to state what I thought might be obvious: "pay as much attention as required to make things work".

Handling errors is a given in this thread. The question was how to represent that in the structure of the program.

> There's element of personal preference here.

I agree that there's some of that, but if you accept that the main purpose of programming language syntax is to ease reading, writing, and understanding programs, then preference only matters to the extent you can know it, and most of us can assume that we do not know the preferences of the people reading and trying to understand our code. Given that, we must try to use somewhat more objective measures.

When reading code, is it more useful to get a broad overview of the algorithm, or more useful to dive into every possible branch? The answer to this won't always be the same, but for a given type of code it will likely lean heavily toward either breadth-first or toward depth-first readings, which correspond fairly closely to whether error handling is done locally at the site of the error. Further, I think most programs will benefit more from a breadth-first organization, such that errors are better handled (syntactically) in a way that doesn't interrupt the process of understanding what the code is supposed to do.

Go has a lot of things I like, but the difficulty of laying out a clear "do this, then this, then this, then that" is not one. Either you end up with "do this (or handle the error from trying to do that by doing this other thing), then this (unless there's an error here, in which case...)", or you abuse panic, or explicitly ignore errors. If you're in this situation, then the first is the best of a bad lot, but unless you're doing some very finicky, low-level code, it would be nicer to be able to handle errors outside of the purposeful flow of the application.

I agree that having a distinction between different kinds of errors is nice, but errors of type (1) are not the purpose of your code. They're problems that prevent your code from fulfilling its purpose. That's a whole different conversation, though. :/

A lot of technologies employ temporary, cache data storage to build for specific platforms and/or configurations. This data is derived from the actual project, and is not saved in the repo, but it often takes significant time to generate.

For example, I work with Unity3d. Unity3d has a great graphics pipeline; if you release the same project for different platforms, you still have the original PSD textures in source control, and they are automatically exported to relevant graphic formats when you switch between different platforms. However, this generation takes a LONG time on different projects, and you usually have several copies of the project on your hard drive, each with a different platform selected.

git even introduced a feature that is usable precisely for that scenario, worktree.

Well, since I cannot just patch a library, I am a lot more worried about the implications of Go programs being the "unmaintainable, unfixable binaries".

I don't even know if it's possible at this point, since it would break Go's reflection library. No IMHO it's designed not to be extendable at all.

That's what I remember from reading about it.