Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes.
EDIT: I must highlight the point about checking lot of boxes. In many discussions about features of programming languages, we get responses like, "language Y does that too. Why not choose that language?" Well, because we don't pick languages for one specific feature. We pick them for the combination of features.
I don't like Oracle. I don't like the JVM. I refuse to learn Java because I personally have a strong bias for native, compiled code. In fact, I really dislike everything about the Java way of programming. The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with what I would consider the ideal creative process for me as programmer.
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.
For my money, Java is a pretty good language; there are only a couple of things that I think were real mistakes in the core language. And the JVM certainly performs.
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.
> 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.
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.
I fear you are right. Go's simplicity, its pattern of having one and only one way of doing anything, is likely a product of its youth and unpopularity. As the years pass and its following grows, people will come along who want to do things differently, and the ecosystem will become richer but also more confusing.
Perhaps the best thing for the language would be for it not to become too popular.
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.
To combine the JVM configuration and IDE configuration points, out of the box on a new 16GB Macbook Pro Retina, Intellij (at least, as PHPStorm) will spend an enormous amount of time unresponsive at startup and periodically thereafter. Why? Because of two things: the default JVM settings it ships with starve it of resources, and the default validation settings have it trying to check everything under the sun.
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.
Why would you configure a webserver for a java process ? Just have every process include a webserver. At what address ? Well simple : any free address, then register the address you've started up on in zookeeper. Likewise, contact your dependencies by resolving them on zookeeper (this can be done using DNS if you want minimal changes. Protip: SRV records have both ip and port).
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, ...
>there are only a couple of things that I think were real mistakes in the core language.
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'm lucky that I develop Java CLI apps that only I need to maintain and one other person. But damn there are days in which I scratch my head and wonder why I have to write so much code to do simple things. But on the other hand my best work has been writing Java apps.
I have a love hate relationship with Java. I do have Java apps that runs 24x7, day after day without failure.
> it would be very hard to persuade me to not choose Java...For better or worse, CS departments across the US produce Java programmers more than anything else.
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.
I have a similar experience with interviewing Java developers in offshoring projects, and I started to think like that, until I was involved into similar projects done in other languages and came to the conclusion any mass market programming language suffers from the same sins.
> The mental image of a huge ram sucking IDE with code completion for frameworks is simply incompatible with
> 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.
What does the Go plugin for IntelliJ offer that Go plugins for Emacs don't? My setup right now has live error checking (highlights errors as they occur), gofmt on save, safe refactoring via gorename, jump-to-definition, proper autocomplete, and Go Oracle integration, for e.g. finding all callers of a method. Due to being Emacs it also has much better support for Vim keybindings via Evil mode.
Debugging, cross-platform, integration with a lot of other languages, and databases, local history, out of the box configuration for everything you've just mention (including the Vim key working mode, via a plugin) so that people don't spend time in doing all of that and so much more :)
> (3) Using a plain text editor, which for a typesafe language is a bit daft.
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)
That may be stated too strongly, but the argument is in a statically typed language you go to all the trouble to provide the compiler with sufficient amounts of information, but then don't leverage that in your editor.
E.g. if you call a statically resolved function, your IDE should be able to take you to the function's definition.
Because if it's a text editor it doesn't have all the info and functionality you have available in an IDE. Run tests for your current function, navigate to definition, manage large projects, configure builds, see test coverage, step with interactive debuggers, REPLs, vcs integration, symbolic refactorings, autocomplete, etc.
Most of this can be added to emacs too. Then it's an IDE.
I agree Erlang is probably not the correct fit for the average startup, but for some areas it is essentially unparalleled (and businesses have had great success with it). Consider the online advertising industry, for instance -- in order to guarantee the kind of uptime and debuggability that real-time bidding and decision making on ads requires, Erlang is an excellent choice (cf. https://www.youtube.com/watch?v=qURhXHbxbDU).
If it's just concurrency and scaling, things are a toss-up. Where Erlang really comes into its own are all the fault tolerant and distributed things that Erlang adds, like the supervision tree.
Go is such a simple language that I believe any decent developer could be productive with it within a week. I'm not sure the hiring argument is all that great.
I have to admit I'm jealous you had such a diverse exposure to programming paradigms.
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.
>For better or worse, CS departments across the US produce Java programmers more than anything else.
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?
> Do you think this large pool of programmers are good?
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.
Eh, most of my post was an emotional response because of my hatred of the java language. Your reasoning I mostly agree with.
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.
Might I suggest starting with Java, but moving into Kotlin after getting the basic syntax of Java down? I have a good feeling about the language after translating a system of classes to it recently. About 60% of the code vanished, and working in it let me free up a few concepts for the resulting java code after doing my thinking in Kotlin.
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.
I am reading and writing Go and Java almost daily. Java has a tendency to be written in an over-engineered way. The Go community has an inclination towards cautious abstractions.
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].
"Take interfaces. In Java you might start with them. In Go - in the best case - they emerge, when it's time for them."
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.
> Which means you can declare an interface that foreign packages already conform to, and then freely use 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.
The list of languages that permit that in a principled way is short, and the list of languages where it's a good idea is even shorter. I've come to the conclusion that it's generally not a good idea. (And it's not Go making me say that, it's more Haskell.) Keeping dependencies flowing in one direction seems to be a good plan.
I totally disagree. It's not only a good idea, it's essential for certain core functionality to work at all. Take serialization, for example: without this feature it's impossible to write a good serializer as a library without code generation (messy and brittle) or reflection (very slow). To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such libraries are essential for high performance graphics programming). The only way I can think of to make it work is to make callers explictly box their numbers into wrapper types you create, which is really ugly and causes various other problems.
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.
> To give another example, try writing a linear algebra library that's generic over the data type without this feature (and such libraries are essential for high performance graphics programming).
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).
Are we talking about the same thing? That is the most full-throated defense of orphan instances I've ever heard. The reaction to such things is generally... less positive... to put it lightly.
Orphan instances arise when the implementation of the interface is in neither the same package as the package that defines the type nor the package that defines the interface. I'm defending the latter (which Go's rules rule out), not orphan instances.
That's making a new type, which causes a lot of friction. For example, a []Foo array is not castable to a []FooWrapper array without recreating the entire thing.
There is a big downside to structural typing as golang implements it though. Refactoring tools. They quite simply cannot do the same kinds of safe refactoring something like a Java refactoring tool can do, because you can't be sure if the function you are trying to rename, add parameter too, etc. is actually the same function in question.
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.
> Which means you can declare an interface that foreign packages already conform to, and then freely use them.
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.
For me, I like Go's slim profile. Native compilation, aggressive allocation, low memory usage, static compilation.
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.
Startup times are largely going to be a thing of the past in Java9. Improved code cache, out of the box optional AOT compilation, and the modularization work is going to be great.
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.
Go starts very fast compared to jvm. Go compiles into a binary that does not require a jvm to be installed... Go does not require an IDE to develop in... Go is also less verbose
Java doesn't require an IDE either: emacs/Ant/Maven is all I've ever used. Barring specialized platform-specific toolsets (like Android Studio) you don't NEED anything else (you might WANT something else, but that's a separate issue...)
I try to use CLI editors for everything (for me it's vim, but lets not make that a big deal :P), but I have never been successful in doing so with java.
I would like people that keep saying stupid stuff like this to try and compare the size of GNU Emacs to the size of, say, NetBeans, Eclipse or Visual Studio.
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
Anything that there aren't plugins for. Same as for Netbeans, Eclipse, IntelliJ, and yes, even notepad. They're all just glorified text editors with plugin/scripting support.
Green threads are awkward to express with the JVM threading/memory/io model. The runtime is massive (contrasting to the go model of statically linking deployment binaries). Some semantics (such as unsigned 64-bit integers) are difficult to express. Java's JNI is a PITA. I don't believe go's c bindings are much better, but the JVM definitely has its sore points.
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.
FWIW there have been methods added to the Math class that perform math operations on unsigned integers, allowing a Java int to be treated as an unsigned int (cf long). In addition there have been other libraries such as JFFR and JNA that make it more sane to inter operate with C libraries in a much less painful way. There's even a future enhancement request to add this info a future release of Java.
Yea, I wouldn't read my above list as a list of roadblocks. The JVM is a serious work horse and every year the list of complaints I have shrinks. Go certainly has its own problems as well, and the performance profiles that pain java are probably not going to fare much better under Go. The major win is probably goroutines.
It's not even goroutines. Its the scheduler. I am continuously impressed by the amount of quasi-generic performance they can get out of something so simple. You can understand the entirety of the golang scheduler in minutes, and it works out of the box for most of my golang use cases.
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.
Actually JNA is actually way better than Go or JNI.
And if you are looking at Kotlin / Scala you won't find yourself inside the object-oriented pain. The JVM is actually not that bad.
However there are mostly alternatives for Java8 something like that: Collections.singletonList(1, 2, 3) which actually gives a List<Int> by the end it all comes down to syntactic sugar.
There are less options in golang so its easier to get started or to jump into the middle of a project. For certain classes of problems the golang standard library is dramatically better than the java ones so you don't have to spend as much energy researching alternatives. It tends to perform well by default for web service and/or cli applications. Compared to java it is more terse (though not compared to some jvm alternate languages, but that is a whole different barrel of fish). The TLS stack in golang is finicky but I trust it. And gofmt. No really, the best part of golang is gofmt.
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.
It is pretty much an undisputed fact that modern Java tooling beats mostly everything else out there for any other language. If you're coming from a more modern JVM background, yes, the first thing I have felt was that most plang tooling is abysmal ... relative to the JVM.
Yes, I'd say modern Java is a good candidate too. However, the verbosity is a deal-killer for me. Go's error handling can be verbose, but while scanning the code, if I want/need to, I can easily skip through the error handling parts mentally. Java, though, is verbose everywhere. EDIT: Actually mtrn said it better: Java feels over-engineered.
> adopt one of Kotlin, Groovy (w/ @CompileStatic) or Scala
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.
I've heard complaints about Scala and binary compatibility often breaking, and it remains to be seen if Kotlin will even be successful enough to catch on.
Java also can't beat Go's concise syntax. Even compared to writing in IntelliJ, an awesome IDE for saving keystrokes, I relish the simplicity and brevity of Go code.
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 could justify my ignorance by pointing out that for all the time I've spent using Go with http, I've not had occasion to use it for html. But, that would only mask my utter embarrassment at missing a core language feature, and worse yet something I complain about as a weakness of Go.
I'll be over here muttering to myself about monadic error values...don't mind me.
Thanks, I've never seen that used and didn't know they special-cased it until I found https://golang.org/ref/spec#Calls. I wonder why it's not more common...
I'm sure there are good uses for it, but I personally haven't found one yet. I mostly use Go's multiple return values to also return errors -- and that's really like using checked exceptions in Java. So whether it's a try/catch or an if statement, you have to code for these things one way or another.
A try-catch block can cover many complex statements and pushes the recovery code down where you aren't forced to continually reread it. Even if it's possible to write concise Go, nobody seems to be interested in trying, it always seems to become a mess that spends 2/3 of its time on errors.
¯\_(ツ)_/¯ I'm personally a fan of the style, and like explicitly seeing where the fault points in functions are, rather than having to memorize what exceptions might get thrown by what. But it can definitely cover many complex situations.
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.
This type of comment is common, but specious. It sounds nice: "what works for you; great! this works for me" but it undermines a large category of important discussions: e.g. analyzing which, out of several competing discussions, is a better fit for large classes of people, or on average. In other words, I think this sort of comment strays too far in the direction of niceness, and tends to undermine simple, and desirable, notions of better vs. worse, etc.
TL;DR being nice and polite is over-rated. Some things are wrong and it is helpful to say so.
The problem, I think, or at least part of the problem, is that it is hard to discuss the relative merits and problems of languages (frameworks, operating systems, ...) without feeling like somebody is trying to push his/her favorite piece of tech on somebody else.
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.
I agree 100%. Also, a lot of good devs have poured their heart and soul into golang. They are a part of this community, like it or not. They find go news interesting, but I totally feel for them that every conversation feels like somebody kicking their sandcastle down because "theirs is better.". Same goes for nodejs. Same goes for PHP. Same goes for every language actually.
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 didn't even interpret that as politie. That's the kind of "polite" comment I would make if I thought you were being an an aggressive idiot and I didn't care to help you.
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.)
Java doesn't exactly check the box of a community that prefers the use of standard libraries for most work. Java community is all about Frameworks with a Big, MVC, F where you need only 200 lines of code and XML for an hello world :P
Depends on the usecase. I deal with java in the hadoop/big data space and I constantly wonder how much better the ecosystem would have been had it been implemented in a solid systems language.
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?!
If I may also chime in with one idea as to why someone might prefer Go: Java simply is not opinionated enough. Compare two developers Java code and it looks, flows, feels completely different.
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.
Embed the JRE then. You have to build packages for each platform you want to support, but that's no different than Go.
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.
> With Go, you've only got one runtime to choose from.
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.
If you use Maven/Ivy then your transitive dependencies are automatically managed based on your direct dependencies. If you don't, or if that's not enough, use ProGuard to get rid of all the classes that you aren't actually using.
The more I dig into type coercion and interfaces the less I miss generics. Still not 100% there, but for day to day the things I used to use generics for have been replaced by alternates. I still wish I never had to write `interface{}` though.
I'm getting furstrated by code generation. I have a big project with has 3 files with (only) generated code. It's essentially repeating the same 15 lines about 50 times with slightly different types.
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).
What are you using generated code with lots of types for out of interest? I haven't felt the need as yet but would like to try it out.
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.
> What are you using generated code with lots of types for out of interest
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.
If it has been generated as boilerplate (e.g. To build out an API) with the explicit purpose of being extended, I think it's fine. It just saves a lot of typing. It's only inappropriate if you'd be better to adjust the template, not the code generated; if you're adding unique code (which you should be), it's fine IMO.
Go feels similar to where Microsoft eventually wants to be with .NET Core and their native compilation.
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.
One superficial example: There is only one correct formatting of a particular Go source file, so you never have to debate with someone (or yourself) whether to use newlines here or there, or to place that opening brace on the next line, or to put spaces around your assignment operator in that function call, etc. The toolchain formats it the "correct" way and that's it.
In addition to what melted said, Go has strong opinions about things (we want to keep language simple, we want to encourage writing maintainable code, we want fast compilation, etc) and it's okay if those opinions mean it can't please some critics. For example, Go isn't against generics. They just don't know (yet) how to do it while keeping language simple and compilation fast.
Nitpick - Go is very much an OO language. Almost everything is done using objects. It has a different way of handling inheritance however - it makes a different decision in the "Composition over inheritance" debate.
I've found that there is no real standard definition of what OOP is and people get very angry when you say Go is OOP but it doesn't have inheritance. YMMV though.
Not to start a flamewar or anything, but what about clojure (or any lisp for that matter, I just like the CLJ ecosystem) doesn't vibe with your 'minimal syntactic sugar' and other requirements?
Oh, don't mistake my comment for favorable opinion. I only wrote a few hundred lines of Go in my life. It worked well for the particular problem I was solving, but I'm really more of a C/C++ guy.
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.
The little secret of Lisp is that you can use it pretty much as an imperative language, even though it also enables functional programming. The main barrier is that Lisp is taught as a functional programming language, and many believe that this is the only way you should use it.
Go tends to emphasize the simple, imperative way to get a computational thing done. It goes so far as to never hide a for loop from you. I'm not experienced with lisp, but from reading sicp, it seems to be a paradigm built on creating stacked layers of syntactical sugar (dsls).
Which is kind of a shame, since many of those concepts would complement the strengths of Go quite nicely -- i.e., a pure goroutine that had no visible side effects apart from channel activity would help enable automatic remote execution in a cluster.
> I take opinionated to mean one obvious way to do things. Python and Go are opinionated.
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.
Take a look at a curated list of opinionated ecosystems. Hilariously, they contain some of the most popular use-cases going forward, and the price point is good.
I'm not being negative. I was confused by the unfamiliar anthropomorphic terminology being applied to an artifact. I take away a sense that "opinionated" seems to be an idiom popular within the golang community for a sense of principled design along the lines of Smalltalk's message passing, Lisp's homoiconicity, Haskell's purity from side effects, and so on.
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.
I felt like I owed the world a response to your question even though the first sentence made no sense to me whatsoever. I guess that "opinionated" makes no less sense as a characterization of an artifact than "ambitious" or "stupid" does, so I'm going to have to learn to live with it, but it's one of those things like "performant" or "impactful" that will make me cringe if I ever catch myself saying it. Anyway, thanks for the response, my comrade-in-downvotes.
"opinionated" is just shorthand for "the language authors held strong opinions when designing". There's no anthropomorphism so hopefully that takes away the confusion.
This is very similar to my experience. There are some very obvious flaws that have been analyzed to death, but I find myself returning to Go despite them. The native binaries and extremely simple cross-compilation are the features that I really miss with other languages.
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/
Go tools support code generators. So just use those for advanced data structures. As auto-generated it can support more features than even an advanced generics could provide.
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.
The reason I love Go is that every time I pull it out, I write a small amount of it and it runs beautifully. For example my company has a critical micro-service implemented in ~300 lines of Go, it's been running for six months now without a single hiccup, highly performant, very sexy.
The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries. Maybe I'm spoiled by the likes of Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's a huge drop in efficiency to spin my own SQL.
The point to take away here is that Go, more so then many other languages IMO, has its strengths and weaknesses. If you use Go in one of it's weaker use-cases you're gonna have a bad time. If you use Go for one of it's strengths you're gonna have a great time.
See you guys and gals in n weeks when we need to rehash the pros and cons of Golang again.
> The reason I will almost never use Go for web apps is because interaction with databases is limited
> but it's a huge drop in efficiency to spin my own SQL.
Sorry, I have to disagree. I come from PHP, where when you sneeze an ORM appears. I actually am a DBA also. I am very familiar with SQL and I love writing out raw SQL.
I don't see this as a limiting feature. It doesn't affect me at all.
There are ORMs for Go as well. But I don't know how good they are. YMMV!
Last point. I have shipped into production a web app using GIN framework. I ported from PHP to Go. I didn't feel I was losing anything.
Go is amazing. It hasn't let me down yet. I doubt it will.
The reason I will almost never use Go for web apps is because interaction with databases is limited (almost entirely) to raw queries. Maybe I'm spoiled by the likes of Active Record, Sequelize, Mini-mongo, Sql-alchemy, etc, but it's a huge drop in efficiency to spin my own SQL.
There are plenty of ORMs and query builders available for golang, many of which have a very similar interface to AR. I personally use a query builder and let structs be in charge of reconstituting themselves from the db rows returned, and am quite happy with that tradeoff, in fact I prefer it to having objects magically instantiated behind the scenes as in AR. There's no need to restrict yourself to raw sql if you prefer a query builder of some kind or even an ORM (if you don't mind using reflection).
Exactly. I love how every release of Go, or Rust, mainly those two, turns into so much rehashing...it hurts.
Little discussion about the release changes happens...a simple google search will return all the discussions of pros and cons you would ever want to read in a life time...
> Maybe I'm spoiled by the likes of [...] Sequelize
Sequelize was a huge drop in efficiency for me any my team. As soon as you go outside of the typical select-where statements, it completely falls apart. I spent hours manipulating that horrible "almost-SQL" syntax to get it to spit out the query I wanted, and often I would just give up and fall back to using a raw query. Yeah, it's great that you can use raw queries when you need, but I soon realized that I almost always wanted to use them.
I switched to KnexJS which has syntax that is practically one-to-one with SQL and have had very few problems since then. Generated queries are much more predictable and easy to write, and it forces you to improve your SQL skills. I view that as a good thing.
Just build yourself some simple mappers with hand written queries, and you've got better performing code than any ORM will ever give you. Honestly, the biggest problem I find with most webapps performance I've worked is on caused by terrible queries written by the ORM.
Doing things a bit lower level with beautiful standard libraries is OK. In subjects like html parsing, templating, routing or intercepting requests it has a meaning. You learn dynamics more down to the metal. However raw sql and value mapping with NullString etc. doesn't give the same joy. Maybe a higher level standard or additional x package can solve this problem.
I've really enjoyed the time I've spent with Go but feel like the state of dependency management has kept me away.
Am I being stubborn in my longing for an npm, Ruby Gems, or pip? Is there a reason why one of these hasn't emerged/been adopted by the community? (I'm aware of the 1.5 experiment with vendoring.)
Semver and pinning versions has always just made sense to me. I can easily adopt new features and fixes automatically without worrying about things breaking.
> Is there a reason why one of these hasn't emerged/been adopted by the community?
Personally, I believe package management is one of those things that really does need an official blessed solution. Otherwise, you have a nasty bootstrapping problem: if there are ten competing package managers, how do you install them, and how do package developers know which one to put their packages in?
Collection types have the same problem. You basically need to put some collections in a blessed core library, otherwise it's virtually impossible to reliably share code. Any function that wants to return a list ends up having to pick one of N list implementations and which ever one they pick means their library is hard for users of the other N-1 lists to consume.
The Go team hasn't blessed a package manager, I think, because it's not that relevant to them: they mostly live within Google's own infrastructure which obviates the need for something like version management. They probably don't feel the pain acutely and/or might not have the expertise to design one that would work well outside Google.
Use the platform's blessed solution (rpm or dpkg). It's ridiculous for a language to consider a solution worthy of blessing when it doesn't interop with the one my platform was already using or even the ones other languages have.
> Use the platform's blessed solution (rpm or dpkg).
Most languages are cross-platform. No language maintainer is going to say, "sorry, Windows, Mac, or <random Linux distro> user, you don't get to use our language."
Likewise, you can't require every package maintainer to just publish their package to every single OS and distro's package repository every time they want to release a new version. Well, you can, you just want have any users if you do.
But it makes sense if half the configuration (or what not you expect from a package) is platform specific, like where do the libraries and resources live, does pip know about the windows registry? I doubt it.
I've never really understood this general complaint about dependencies and go.
Maybe it's my work environment?
Either: i'm writing something quick and/or as a one-off in which case i just 'go get' anything i need.
Or: It's 'full-enterprise' style where each third-party thing that gets used is checked and stored locally. The build is built against these stored versions. If an improvement is made to a 3rd party thing then the changes are reviewed and if suitable that new version is stored locally. If the older go release needs to be rebuilt or investigated it can be rebuilt with the earlier versions by the clean build system.
Anything in-between wouldn't get passed QA.
but obviously ymmv.
It's not a package manager per se — Go doesn't have a package system with manifest files like RubyGems and NPM — but it does manage dependencies in the same way, with versioning constraints and lock files.
Dependency management is a huge weakness in golang and there isn't much point in debating it.
That said, my time in golang has crystalized something I'd been leaning towards anyway, that is dependencies are way more dangerous than we think they are. I find all of my code now (golang or otherwise) less likely to have dependencies, and therefore dependency management weaknesses are mitigated (not solved).
I agree that it's necessary to pin dependency versions down somehow. So I commit my Go dependencies into my project's version control. I heard Google does this internally too, but I can't confirm that. But I can say that I've had zero problems using this dependency approach for building web systems in Go.
There's just something about the ecosystem of dependencies. Most of the deps I use are considered to be done. They are simple, small, and orthogonal to each other.
Maybe it's because of the convention to make your library implement interfaces defined in the standard library. Maybe it's some kind of ingenious magical feedback loop where, since there is no package version manager, authors are encouraged to write once and then publish finished products instead working on overreaching and interconnected packages that get API changes every month. Therefore alleviating the need for a package version manager.
My point is just that I wouldn't want people who are considering Go to immediately write it off because of the lack of a standard dep version manager. You can lock dependencies with godep. Or you can check in your dependencies to your project's source control. Either way, even though it's unconventional, it most likely won't be a problem.
Its generally unlikely those things lead to interface changes. e.g. func bcrypt(salt string, password string). Generally the bug isn't in the interface. So its somewhat safe to upgrade the dep and see if the compiler complains
Also exporting of interfaces is protected by case private()/Public() which leads to refined interfaces being exported. And the go vet tool expects all exported functions be documented.
This didn't directly answer my question, but it implies that you just periodically update all of your dependencies to the latest versions and pray your tests pass with minimal changes required.
The tools essentially causes that to happen (its a bad thing). When someone installs your package (and you don't pin them somehow with something like godeps, path management, http://labix.org/gopkg.in, etc) you recursively retrieve the deps from some source at HEAD and that package is now updated for every other package using that GOPATH.
Oh, I misread the parent I replied to. I thought he was saying he downloads a copy of his dependencies and commits them to his repository without any tooling.
But he was only saying he uses the tools (which auto-update as your run them), and commits the result as a poor man's pinning arrangement.
I can't wait to see what's new in 1.6! I really had a pleasure working with Go for my senior project last year. If I need to write either a server (HTTP or TCP/UDP), or a client application that must be easy to build and distribute, Go is my first choice.
What Go is lacking at this moment in my opinion is:
1) A comprehensive and mature web framework. Play w/ Scala is my go-to choice now, with Django a very close second.
2) A decent cross-platform GUI toolkit; heck, I'd settle with Qt and/or .NET bindings for Go. The power of Go is statically linked binaries, and I think the area of desktop applications will be easy to target if a good solution emerges.
> What Go is lacking at this moment in my opinion is:
1) A comprehensive and mature web framework. Play w/ Scala is my go-to choice now, with Django a very close second.
I completely agree here. GIN is my fav framework so far, but it falls down sometimes on documentation and also on features. A lot of features.
I know there are three viewpoints with Go.
1) Use net/http and just import libraries.
2) Use a "lightweight" framework if you must, just import libraries.
3) Use a "full fat" framework and get to work on the app.
I would love to have something like where Codeigniter was for PHP. An MVC framework where you could just write code, it was lightweight and had the best documentation for a framework out there.
Now if something like that was out there for Go and actively maintained. I would be all over that!
1) Go produces 100% portable code. I absolutely suffered doing the same for a very basic C++ program that used C++11's std::regex. Compiled fine on clang-3.5 on OS X, fails on clang on Linux. It took me hours of searching online to find and install the exact version of GCC that actually fills in std::regex instead of just keeping it empty. Trust me, there are some versions that do that! No errors during compilation, but still doesn't run.
2) Statically compiled binaries. I can be confident that the absence of some essential library from the user's end won't break my app.
3) Cross-platform, especially with something like Qt. Write once, compile for each OS, then run - done!
You can't currently link to Qt statically though. (And holy smokes, that would be a huge binary if it did, just libQt5Widgets.so links to 49 other libraries, everyting from X11 libs to libbz2 to opengl)
Because a C# GUI on Linux or Mac is not very native looking. Also for the same reason some like Go over Java, static binaries instead of requiring JVM or CLR be installed.
On another note, because writing programs in Go is much faster than say C++ or C for most use cases.
Call me old fashioned, but I've only ever used the stuff from Gorilla (mux and sessions) and before that plain CGI with Go, and running behind uriel's cgd to hook it up with nginx.
I've never been fond of web frameworks that try to hide a lot of stuff from you.
Hard to say without specifics, but my experience writing server code in, say, Python, was, I ended up wanting to handle errors in the best possible way, so my code turned into:
try:
x := blah()
except Foo:
yadadad
which is worse (IMO) than
x, err := blah()
if err != nil {
yadada
}
Besides the extra syntactic clumsiness, it was really hard to know what was going to throw exceptions, and which exceptions, and when. Frequently I would get bugs from unexpectedly thrown exceptions.
You said "I have to mentally block out err != nil to read...code" -- for me, the error handling code is code, code I want to pay just as much attention to as the non-error path.
So for that reason I really like Go error handling.
For a client-side script or something, maybe this isn't true; feel free to use log.Fatal or panic if that makes sense for your use case.
> for me, the error handling code is code, code I want to pay just as much attention to as the non-error path.
You likely want to pay as much attention as required to make things work, but the purpose of your code isn't to generate errors -- errors are what get in the way of the actual purpose of your code.
For people who want to get an overview of what some code does, the error code is interesting only after you understand the actual purpose, and sprinkling the error code throughout the code that describe the purpose of the program causes distraction.
A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll reopen the app and try again/rerun the script'), but I think not so reasonable for server-side code..
There's element of personal preference here.
The longer I program the more I favor systems and styles that minimize unexpected problems; explicit error handling is very much in that vein.
Another complication is that the word "error" actually encompasses two very different kinds of situations:
(1) expected-but-non optimal external conditions (there's no file at that path, the tcp connection got closed) and (2) unexpected conditions caused by a bug (array index out of bounds, the regular expression typed into the code is invalid).
Handling (1) gracefully is very much part of the actual purpose of your code: files WILL be missing sometimes, network connections WILL die, so it behooves you and your program to think about these situations as first class.
(2) is not part of the purpose of your program, it's an error IN your program. These are best handled by crashing/exceptions/panic.
A lot of languages mix the handling of (1) and (2), e.g. Python and some styles of C++, which use exceptions for everything. Go uses explicit error returns for (1) and panics for (2), which feels right to me.
> A reasonable attitude for client-side code, perhaps, ('oh it blew up, I'll reopen the app and try again/rerun the script'), but I think not so reasonable for server-side code..
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. :/
> errors of type (1) are not the purpose of your code. They're problems that prevent your code from fulfilling its purpose.
I don't really agree with that. In a module that checks whether a user has the right credentials to perform a given task, for instance by checking the used IP is correct and a correct password is given within 3 attempts (or else the account is blocked), dealing with errors (checking password is valid, checking IP is valid, checking account is not blocked, blocking it if needed) is the purpose of the module.
This is the same with any kind of automaton. Knowing when you go into an error state and how you get out of it is part of the problem you deal with.
Well, ultimately all I can say is that my personal experience is it's easier for me to build software to the level of quality I want using an explicit error handling regime (like Go) than an implicit, exception-throwing regime (which I've used with Python and C++). YMMV.
But, You don't immediately handle an exception right there in the same method majority of cases. If I have function for copying files, that function doest know how to handle filecorruptionexception it just bubbles it up.
I agree, it's exactly why I stopped using the language. err != nil checks all over the place gave me a headache. I since moved on to Elixir and it's really great. I just wish that it would allow me to have just a single deployable binary. That's something I really miss about Go.
No point in raising an error if you aren't going to do something about it.
If you don't care about an error then don't check it.
If you do care then handle it.
and you don't need massive if blocks, you can use more early returns as part of the err checks.
I don't exactly understand what you are suggesting. Ofcourse, I care about error and want them to be handled. Problem often is that method I am in doesn't know how to handle the error and have to bubble it up to a place where there is knowledge about how to handle it.
Here is Erik Meijer talking about golang exception handling
The golang guy doesn't answer the question properly and repeats "exceptions are not for control flow". Really disappointing answer and cringeworthy interview.
I just recently started with go, but I love how simple (apart from horrible $GOPATH) and effective that is.
Still can't get over the moment I realized that in order to deploy my web server on an empty virtual box all I had to so was to build and upload. After all the languages and frameworks that required endless customization and setting up it was a true eureka moment.
The notion that you can't put the codebase wherever you want to on your own computer. A "project", as a folder, should be atomic and work regardless of where it is moved; the $GOPATH convention just breaks this encapsulation completely.
For example, when I create client-server projects, sometimes I put both client and server under the same git repository, in the same folder (whether it is a good or bad decision is another discussion). $GOPATH forces me, therefore, to put a client project in the $GOPATH tree, and this just feels ugly.
Of course, you can change $GOPATH per project, and I end up with `export $GOPATH` in makefiles, but this is rather ugly too.
I completely agree that a developer should have the freedom to put the "project" folder anywhere. As a golang newbie, I went through the motions of setting up GOPATH, but did not give it too much consideration. It also isn't clear to me how one might have multiple copies of the same project.
> It also isn't clear to me how one might have multiple copies of the same project.
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.
Sorry, I should have phrased this a little better. What I meant to say was that I almost always have multiple copies of the code that I am actively working on. And if Go has restrictions on where you can place your source tree, then it complicates the ability to have multiple copies of it.
I wrote an extension to gb (the go build tool released by Dave Cheney) that uses gb's functionality to determine the $GOPATH where it operates, plus an alias gbpath="eval `gb gopath`", so a simple gbpath sets the right $GOPATH no matter where I am in the filesystem. I should probably release that at some point.
Can someone give a decent explanation of the following:
1) Supposed I have a library that was written in C that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program.
2) Supposed I have a library that was written in Go that receives a security update which is used in a Go program. Under what conditions do I need to get a recompiled version of the Go program.
3) Is there a way to tell from the binary that the program was written in Go?
Trying to figure this out for my Sys Admin dealing with Vendors role.
1) If my understanding is correct, you won't need a new Go binary. You can simply update the library, Go just links to it. Go even links to libraries if you use certain packages from the standard library, e.g. `os/user`:
$ cat homedir.go
package main
import (
"fmt"
"os/user"
)
func main() {
fmt.Println(user.Current())
}
$ go build homedir.go
$ otool -L homedir
homedir:
/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 0.0.0, current version 0.0.0)
2) You (most likely) have to recompile and re-deploy the downstream Go program with the patched library.
3) Not sure.
3) A compiled Go binary contains the import paths of all used libraries plus all variable names that they are using. Also the header of the binary contains a string like "Go" followed by a hash. If you open a binary in a Hex Editor you will see it yourself.
1) Was this static C library? Then you need to recompile. If it was dynamic then the question is did abi change? If yes, you need to recompile, otherwise you don't (but security updates usually don't break abi).
2) Always.
3) Yes, Go runtime is linked in to executables build with Go.
It's up to you to decide how/what you want to link, just like in C. I've prepared simple example at https://github.com/tumdum/go_libs that you can use to see how exactly it's all working.
I am a bit worried about accepting software from vendors written in Go given those circumstances. For example, the recent OpenSSL patches would be an example. Are the Go programs fine if I update OpenSSL or did they include OpenSSL's libraries statically? If someone writes a Go replacement for OpenSSL does that change the scenario.
Given a lot of software makes it to my door written by government contractors for grant management / compliance, I don't have the source code.
Go has its own crypto library that's maintained by a real crypto expert so that might not be the best example. Still, if they do find a bug, there will be a new release of Go and you (or your supplier) should be prepared to recompile.
Running unmaintainable, unfixable binaries may be standard practice in other places but for Go it's not really viable. It's a different culture with different practices.
> Running unmaintainable, unfixable binaries may be standard practice in other places but for Go it's not really viable. It's a different culture with different practices.
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".
Read the debate with Go vs Java here with interest. I'd like to add a point I think is missed by the Java crowd in favor of Go.
Complexity isn't free. Java might have and abundance of tools, IDE's, language features etc, but you can't claim that matching up every Go feature or tool with something superior found among the huge Java universe makes Java superior in every way.
I find that there is an unfair assumption being used by the Java advocates, here which is that every software developer has a deep knowledge of Java.
As one of those people who can certainly write Java code, but who is not familiar with the Java eco system and has not spend a lot of time with I must say that Go to me is a clear winner.
My exposure to professional Java development has been quite frustrating compared to writing Go code. Every Java project I have gotten has used some different built tool: Ant, Maven or Gradle. They have also all seem to use different IDE's. The complexity of each of these tools is staggering. Considerable time has to be spend learning these tools.
Go in comparison is laughably simple. You can get productive in less than a week without ever having used the dam thing. The tools and the libraries are very quick to get into. In fact I find Go code so easy to read that although I am an iOS developer by trade, I frequently read Go code to understand how various algorithms and network stuff works.
An organization would easily be able to add people to a Go project without much previous exposure to the language. Adding people with limited Java knowledge to a Java project however would be far more expensive. Considerable time would be needed for training.
There is a lot of money to be saved from having a well thought out standard library combined with a simple language with simple well thought out tools.
As a Swift/Objective-C developer, my major gripes with my development process is actually the complexity of the tooling. Both Swift and Objective-C are fairly straightforward languages IMHO. In this regard I greatly envy Go developers although I do enjoy the strong typing and generics in Swift.
I fell in love with python because it was clean and easy to work with. Like most developers, I used to use c when I needed a performance boast. Then I got fade up and decided to learn a new language that could give me the feel of python and the performance of c. Two languages from a list of 10 passed the above criteria Go and Rust. Java did not even make the list because I Don't use languages that are owned by evil empire's(Oracle).
I went with Go because it was easy to use and understand. I could read other people's code easily( Even with a large code base, I have never found myself scratching my head trying to figure out my own code does), could set up my workspace in less than a minute and all the text editors I used (sublime, Atom, Vim) supported it. I Don't really care about the fancy IDE's. Just syntax highlighting and code completion is good for me.
I started learning go on September 2015. And I have managed to implement the porter stemmer algorithm and an inverted index in it. Miss generics but LOVE interfaces. The fact that any concrete type that implements method 1 satisfies interface 8 is awesome. You can easily reuse code from different package without changing anything.
Go CSP is minimal and ortongonal, I just wish it did three things:
0. could lto optimize or link against a shared library to reduce the titanic size of compiled programs and cut down on duplication of instruction. Therue is no practical sense in wasting memory and storage on systems with dynamic linkers: edge cases of including the world for rare situations but YAGNI in real production systems.
1. could output flat binaries and self-host runtime (panics) for practical kernel development in Go
2. Generics (both types and immutable constraints), I think C++1z has the right approach to this (and constexpr and constant arrays are nice and are able to provide more hints to the compiler).
I also wonder why Go wasnt developed as an IR compiler / llvm frontend, because it would've levered an existing debug and portability ecosystem with much less work.
0. It does dynamic linking on most stdlibs (libc, etc)
1. What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly)
2. Generics would be nice. Who knows, maybe they'll be in 2.0?
Go wasn't developed in llvm, because they wanted to build something very fast, and they were planning on writing the compiler in golang from the start (so that it could be part of the libs). Also having your own scheduler kind of breaks debugging, you can build go programs with gccgo, but gdb doesn't work because it has no concept of what a "go routine" is. Delve (https://github.com/derekparker/delve) will eventually fill the hole of the missing debugger, imo.
> What do you mean self-hosted runtime? Anyways, golang will likely never be a good candidate for kernel development, but in theory you could do it (go supports assembly)
Oberon, AOS, EthOS, Singularity and Midori projects prove otherwise.
Go just needs an OS research PhD student proposing "Goberon" to their tutor.
> 2. Generics would be nice. Who knows, maybe they'll be in 2.0?
There will be no 2.0 and there will be no generics, at all.In fact there will never be any changes to the type system, cause it's impossible at this point.
Not that I even care that much, but that's total crap. Compile-time generics, which is what most people seem to be referring to when they say they want generics in Go, are eminently doable. It would not be hard to implement. Runtime generics are probably possible as well.
What are you even basing your assertion on?
Edit:
What do you mean, "there will never be a 2.0"? Do you have a crystal ball?
The issues list has a bunch of breaking changes they've put off to Go2. It won't come soon, but probably at some point they will produce a Go2, if only to fix a few small annoyances and things they got wrong in the stdlib which would otherwise break the Go1 pledge. Of course, that doesn't mean Go2 will introduce lots of huge changes to the language, I doubt very much it would, but it probably will happen sometime.
As another datapoint, here are the answers of the team to a question on what they dislike about Go1. These are mostly breaking changes which would require a Go2. I don't think anyone is hostile to it long-term, they're just not in a hurry. There is a huge value to developers in not having churn in an ecosystem and breaking changes, I and many others really value that and am pleased they take this approach.
So I think you've misinterpreted the above statement, it was probably an off hand remark in response to proposals for Go1 which would have radically altered the language (I can find no ref to it on the web, 0 results for that phrase).
Have been using Go since its release, and like the deployment experience, the feeling of solidity of putting together a tight system. The toolchain is great. 1.6 is yet another Solid release in that direction. Thank you all.
However, the _language_ doesn't give me much programming pleasure alas. Since there is plenty of time for Christmas, here's my syntax wish list :)
'?': C's if-then-else operator.
Block-syntax for closures ala Ruby. Unifying blocks and closures makes creating DSLs easy, but doesn't add to cognitive load (no more than using anon funcs)
Pattern matching like Scala, ML, Rust.
Sum types -- (Yeah, I lied. Not just syntax enhancements), or at least discriminated unions. I'd like to see an example (in the FAQ entry on the topic) on why support for it is troublesome.
For 2017 Christmas,
-------------------
Macros ala Nim.
Systemic support for Goroutines, including detection of conditions where a goroutine would never get scheduled. Erlang-like tools for built-in goroutine insight.
------
My ideal language would be an intersection of Nim+Go
That said, there were a few points I noted, based on a recent go I gave it (pardon the pun), at least in relation to my style of development for this project:
1. It's hard to tinker, mostly because it's fussy about what variables are defined or used. This is a strength in the usual course, but when one is trying to posit what a poorly documented 3rd party API is doing it can be a serious pain.
By tinkering, I found that I often had to comment out or uncomment lines, or handle or ignore errors. There was a lot of flipping up to the beginning of the file. I would spend so much time fiddling with the lines that I would at times forget what I was even trying to do.
I might just have memory problems, I acknowledge. :)
However, what would make sense is a go "mode" where it runs in a non-strict way, with what would ordinarily be errors being warnings. A "tinker" or "whirl" mode, so to speak, that softened the requirements so one could get a better sense of what was happening before committing to a design.
An interpreter mode might also be quite valuable, to address this problem and the ones below.
2. Error propagation - I see the point of errors being returned and the lack of a "throw/catch" style, and its benefit, but I feel it's a lot of typing for marginal gain. I usually end up with an error propagating a set of strings that ultimately conclude as: "Database error: transaction error: processing error: http error: reason", which is to say: equivalent but less information than a stack trace would give. I see the mandatory error acknowledgement simultaneously as a strength and a waste of time, and I admit being on the fence about it.
3. The next point I am not on the fence about: Debugging. It is not apparent how to get a stack trace, and the best option looks like including a third party application that generated errors. For the obvious and reasons below, this is a problem.
4. Package management: This was fussy and could be time-consuming. It is not apparent to me why one needs a GOROOT and a GOPATH. I think Python's virtualenv gets it right, by comparison. A second but related problem is package versions. Maybe I'm missing something, but making sure you get the latest semantically equivalent version (in the semver sense) was not apparent.
5. Package debugging: If you include a 3rd party package, and it's broken in any way, it's a veritable quagmire to identify and fix the problem. My experience was that the best way to debug a third party package was to block and copy all its bits and then debug it as a local source in your own. Obviously this is bad for a long number of reasons, and I might be missing something, but no more apparent option appeared when I investigated on how to tell what is even happening inside third packages.
6. Automated testing: I've not seen a test runner that reloads when source files change, particularly one that might be used with goapp from AppEngine, meaning go auto-testing can be quite a bit of patient thumb-twiddling as the binary reloads.
Which is all to say that there are some concerns about developing a larger project in this language, particularly if there is quite a bit of complexity that needs lots of testing or potential debugging and/or inclusion of many third party packages.
I've not reviewed the 1.6 notes, so perhaps these are addressed to some extent there.
In any case, none of the issues above is insurmountable, and overall I give the Go design a lot of credit for experimentation and interesting choices, but the issues I've seen above give me pause before committing a team to the language – for the moment.
For (1), I'd highly suggest using 'goimports' (my editor's fmt-on-save uses 'goimports' by default). It will remove and add non-referenced imports as needed. Also, quick prototyping is partially what the underbar (_) notation is meant for in variable assignments.
As for (2), I feel it's more of a consequence of programmers not using error types to its advantage. Since Error is an interface it allows for an absurd amount of flexibility (e.g. bundle up a whole bunch of information into one error and send it back) and typed errors, both of which are excellent for testing and debugging.
As for (3), I usually rely on printing output (github.com/davecgh/gospew is quite useful). To get a stack trace just calling panic() in the offending code area will suffice.
No arguments on (4) - it could be better - but I think support for vendoring is a good step, and the maintainers seem to be taking it slow and getting it right.
On (5) -- if you go get the package it's available in GOPATH and/or it's usually vendored, so you can just go edit it in place (including debugging statements if you need more insight) without needing to know any magic $X_PATH rules -- I see this as a huge advantage. Furthermore, go get-ed code is each in its own version control repo, so sending patches back upstream is (generally) easier than ever.
Anyway, hope I don't seem argumentative (everyone has different tastes), but maybe some of these suggestions might help you a bit with your language peeves.
On (2) I'm probably biased by having spent a lot of time with Python and Javascript and bound to some preconceived notions of how one should deal with exceptions, so perhaps I give Go a harder time than I should for my failings and not its. :)
On (4) I hope they get it right; packaging can definitely make-or-break the system.
On (3) and (5) I found these techniques could/did-not work when testing Go App Engine. Editing the third party source had no impact, even after restarting App Engine, re-running tests, and deleting the .a files. I'm sure it's just another trick, but I couldn't find it so I eventually just gave up ... hence it being in my list of concerns.
Thanks for the feedback, I appreciate the suggestions.
As zenlikethat points out, "goimports" works around this weakness. For Atom, this package works great [1].
It's so damn arbitrary, though; it refuses to let you have unused imports (which is not a source of bugs) but will happily allow you to shadow variables (which is a serious source of bugs) without even warning you. Super weird.
You're looking for go-plus [0]. Set the Format Tool to goimports, check Run Lint Tool on Save, check Run Go Vet Tool on Save, and add these vet arguments: "-shadow=true -shadowstrict=true".
You may have to leave off that last argument for your own sanity. I found that 'shadowstrict' drives you mad at first, but you end up making better code for it -- mirroring my general experience with all the things about go that annoyed me at first.
I was already using go-plus, but I think the addition of goimports is something recent — it wasn't there when I last looked. Thanks for the pointer.
I know that "go vet" can warn about this, my point was that it's amazing that Go refuses unused imports but allows shadowing. It reveals a very skewed idea of what is important when compiling.
iirc, the decision to disallow unused imports was largely motivated by improving build times. And not just for your package either. If each package in the tree can accidentally have an extra import or two it could end up ballooning to crazy proportions where everything and their third cousin is imported with only some of them being used.
But that concern is about releasing, which is completely orthogonal to building.
Go conflating the two is, I think, its biggest design mistake on the build system side. In Go, dependencies are inferred from imports, which, since it can't express versioning information, leads precisely to this sort of problem.
It makes sense only if you're putting all of your dependencies in a single versioned work tree, but almost no developers work like that outside of Google. And it's not a good pattern for most devs/companies. Yet Go is completely infected by it.
Other languages typically use a dependency manifest, which IMHO is the only sane, logic approach.
The funny thing, a dependency manifest is a superset of Go's current import behavior. But they chose implicit over explicit, which in CS is a mistake 9 times out of 10.
What are you talking about? How is unused imports related to library versioning? And how is focusing on improving build times orthogonal to "building"? The concern with build times is to make building while developing faster [0], how is that related to "releasing"?
Your points are tangential at best, and nonsensical otherwise.
First, Go doesn't have any concept of "releasing". "go get" just (1) just grabs the latest HEAD from whatever repo you're using, and (2) follows import paths. It doesn't even use release tags.
So the "build times are affected by unused imports in dependencies" problem only exists as a hypothetical issue because "go get" implicitly trusts dependencies' import statements.
Other package systems don't do this. They (RubyGems and NPM are good examples) require that you build a release that you then publish. Included in such a release is a dependency manifest (Gemfile.lock, npm-shrinkwrap.json) that the package manager can read.
The more natural solution is to generate a dependency manifest at release time that only includes valid imports, and refuse to release something that contains unused imports.
The build time issue only exists locally if you run a monorepo like Google's, and in that case it's my opinion that, just like code linting, this is your own concern, not something to pollute an entire developer ecosystem with.
Oh yes for 4). Why can't I include a package from the current directory? Would it be that difficult to first search for a directory containing a `main.go` before jumping to GOPATH - similar to how Python defines packages with a __init__.py?
In addition, once your workspace increases in size, GOPATH becomes a mess in my opinion.
Seen a lot of Erlang mentions in this thread. Is that the native alternative to Go?
Personally, I prefer to write code in a functional manner. While I've always thought Go looked like an amazing platform for programming in general, I haven't been keen on moving to another imperative language.
It seems the landscape for functional alternatives are mainly Scala and Clojure which are both based on the JVM and require a bit of time to learn the tooling. I am not a Java or JVM export, so I haven't been too inspired by this either.
> It seems the landscape for functional alternatives are mainly Scala and Clojure
Cannot talk about functional alternatives without mentioning Haskell. OCaml (when abstaining from the "O", as many OCaml'ers do; similarly Scala'ers often abstain from the "O" in Scala) is also an interesting option.
Finally there's Rust, which is besides being a bit more functional also more low-level than Go.
While being fairly young, Frege[1] also deserves a mention. Very similar to Haskell, but on the JVM.
Well, I was tempted to mention Haskell. Problem is, I haven't found a practical use for it. Of all the FP languages, this is actually the one I am most tempted by.
I had forgotten about Rust. Are there major projects being used for this yet? I've heard it's picking up quite a bit.
Depends on how you define "major". Dropbox is currently running Rust in production, at the core of their product. Has been for about six weeks now. That's probably the largest, most serious use. There are also tiny bits in Firefox, that will be included starting with the next release.
There's a lot of other usage too, it all depends on how you define "major".
I would just love some IDE-debug love and better packaging. More packages I use and more I distribute my files, compilation takes considerably longer. Maybe I do not know, but is there some process to compile some parts before hand and link only the changed resulting binary?
Can anybody tell me if you can run Go in Chrome using the NaCL stuff? I remember there was talking of it a few years ago but I don't know if anything ever came of it.
A google seach show that you could build for NaCal in Go 1.3 but only run it in special builds not Chrome itself.
There was some discussion leading up to the release about whether to merge the "SSA" branch, which seems to be a refactor that allows for easier compile time optimisations but also slows compile times for the time being.
Does anyone know if that was included in this release?
IIRC from the e-mail thread, the idea being discussed was to potentially merge the SSA branch immediately after the release (in order to have as much time as possible to test it), so I'd be surprised to find it in this release. There were concerns about the compiler slowdown but I didn't see the end result of the thread.
They won't. The Go authors value simplicity. Many people dislike ternary syntax and find it hard to read. Go errs on the side of verbosity and readability. It is sort of the opposite of Perl in that respect.
EDIT: I must highlight the point about checking lot of boxes. In many discussions about features of programming languages, we get responses like, "language Y does that too. Why not choose that language?" Well, because we don't pick languages for one specific feature. We pick them for the combination of features.