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.

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.

https://www.reddit.com/r/golang/comments/46bd5h/ama_we_are_t...

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.

How does the community feel this far along?

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.

if err != nil ...

I know you can do if ; err!=nil but that not that much better and you end up in deeply nested if blocks.

i have to mentally block out err !=nil to read any gocode linearly. How is this acceptable, I don't get it.

https://blog.golang.org/errors-are-values

We recently scanned all the open source projects we could find and discovered that this snippet occurs only once per page or two

This seems false from my experience, def way more than 1 or 2 instances per page.

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.

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.

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

https://golang.org/doc/go1.6

Notably new this time is transparent http/2 support and tighter rules for integration with C.

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.

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.

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.

A google seach show that you could build for NaCal in Go 1.3 but only run it in special builds not Chrome itself.

Does anyone know if that was included in this release?

That seems a little bit distasteful.

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.

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

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

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.

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.

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.

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.

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

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.

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!

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.

    try:
        x := blah()
    except Foo:
        yadadad

    x, err := blah()
    if err != nil {
        yadada
    }

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.

and you don't need massive if blocks, you can use more early returns as part of the err checks.

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

3) Yes, Go runtime is linked in to executables build with Go.

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.

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.

[1] https://github.com/abiosoft/atom-go-imports

In addition, once your workspace increases in size, GOPATH becomes a mess in my opinion.

iirc the workflow with that is change a file and process will rebuild and test it.

http://goconvey.co/

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

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

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

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

But golang doesn't have generics.

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

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

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

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

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.