I'e been writing my first production-sized Go app over the last few months, and really enjoy it. Some observations:
- The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see.
- I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go.
- The tooling for Go is excellent: More languages need something like "go fmt".
- In general the document is solid, but I've found the usability of the generated docs to be poor. You think they could bribe a few Google designers to spend some time fixing that...
- I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use. The only issue is parsing JSON when you're not marshalling it to struct. They need to fix that (although there are some nice third-party tools to make it easier).
- Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before.
> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use.
Go doesn't have generics. To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.
> saying that your type system doesn't have generics is like saying your car doesn't have wheels.
To overburden an analogy, it'd be more like complaining that your tank doesn't have wheels[0], or your hovercraft. Go takes a different approach to the same problem (in this analogy, getting from point A to point B).
But really, this is a rather tired flamewar that gets beaten to death literally every time a post about Go makes the front page, and there's really nothing more that can be said about it. Either program in idiomatic Go, which means using the language as it's designed (ie, without generics, at least in its current form), or don't, but it's very tiresome to see this argument rehashed again and again.
Sorry. In the spirit of Go, you're not allowed to re-use this analogy; you're going to need to write another different one that can perform a similar function.
It's ok if you copy and paste some of the text from the first analogy and structure it similarly, though.
That's the really disappointing part. I've read the thread where the designers talk about implementing generics, and they basically say that every language's implementation of generics sucks, and since they can't come up with a design that's perfect (no codegen duplication, but still all the perf of specialization), they're just gonna punt.
And then the code I've seen is littered with "interface {}".
That's a pretty big thing to give up, and I don't get the point. Something like F# gives you high level features (and green threads if you want) with fair perf, and Rust gives you a fair amount of language with C perf.
I think littered might be a bit strong. I'm writing a service in Go, and have yet to use interface{}. However, you might have to use it more when writing libraries.
That's false. Go has structural subtyping. It enables you to sort collections of things without actually writing a sorting algorithm. Seems like generic code to me.
It has interfaces to write generic code. It doesn't allow you to write your own generic data structures but it's not an issue because it has built-in dynamic arrays and dictionaries. You supposed to use built in data structures most of the time like with python or ruby.
This happens because almost every time there's someone who more or less asks what in the world generics are for since they can do everything they want to with Go's type system. Sure, it's possible, but it's missing the point.
Or just build your furniture without using screws, like in Japanese carpentry. When people are already having a decent time building things using the tool, it looks pretty stupid to tell them they've done it all wrong for years in all the decent products they made.
Parametric polymorphism gives safety guarantees that you can't easily obtain without language support. For example if you have a function typed "forall a . a -> a" you know it has to be the identity function (or something that bypasses the typesystem, like infinite loops or a runtime exception).
And in Go since there is no parametric polymorphism you would end up writing either:
1) Methods with names that indicate the parameter types.
2) Method calls on objects to convert some internal struct data from one type to another.
3) Something I haven't thought of that doesn't involve losing a handle on your type.
So there is certainly a loss in convenience, but if you use the type system it can be just as safe as a functional language as far as I can tell. So, yeah, it isn't as intellectually elegant, but it also isn't really that hard to deal with.
No you can't. The point of generics is that you don't need to specify the parameter types - the parameter type is also a parameter. This means that you can write type safe container operations like "map" and "filter".
The only way to write this kind of generic code in Go is to cast everything to `interface{}`, which can't be checked statically.
If you are still not convinced, one of the things you can do with generics is say "these two parameters have the same type". In Go the best you can do is say "these two parameters are subclasses of something", which is less precise.
Yeah I follow you. I am providing ways of trying to work around the lack of a higher level type class system. As a baseline, I would recommend not jumping outside golang's given type system just because it feels inconvenient for the programmer. That means you don't get to write a generic method for, for instance, all integers. Too bad :P This means the programmer does have to do more work, but the type system is always strictly enforced. That is better in my opinion.
Having written in both Go and Rust, I can see the arguments. Go has a relatively simple, easy to use type system. The problem is that whenever you need to do anything generic, you have to use Go's "any" type, "interface{}", and the reflection system. This results in doing stuff over and over at run time that could have been done once, preferably at compile time. For much web back-end stuff, though, you don't need a really fancy type system with generics. Mostly you're pushing strings around, which Go does quite well.
Rust's type system has most of the bells and whistles of C++, plus some new ones. It's clever, well thought out, sound, and bulky. Rust has very powerful compile-time programming; there's a regular expression compiler that runs at compile time. I'm concerned that Rust is starting out at the cruft level it took C++ 20 years to achieve. I shudder to think of what things will be like once the Boost crowd discovers Rust.
The lack of exception handing in Rust forces program design into a form where many functions return "Result" or "Some", which are generic enumeration/variant record types. These must be instantiated with the actual return type. As a result, a rather high percentage of functions in Rust seem to involve generics. There are some rather tortured functional programming forms used to handle errors, such as ".and_then(lambda)". Doing N things in succession, each of which can generate an error, is either verbose (match statement) or obscure ("and_then()"). You get to pick. Or you can just use ".unwrap()", which extracts the value from a Some form and makes a failure fatal. It's tempting to over-use that.
The lack of exception handling in Go yields too many "goto" statements. There's also a tendency to turn the panic/recover mechanism into an exception system. This has roughly the problems of C's" longjmp".
As a practical matter, Go now has most of the libraries you need for server-side programs. (Not GUI programs, though.) Rust has only very basic libraries, and they're not stable yet. The language hasn't quite settled down. People are writing and porting libraries at a good pace, and this problem will be solved.
> I'm concerned that Rust is starting out at the cruft level it took C++ 20 years to achieve.
That is the core reason why there are no generics in Go. Not because the Go team thinks they're a terrible idea, but because they think cruft is a terrible idea.
The default answer to a new feature is "no". When everything seems to be going fine without generics (except for internet flamewars), the answer stays "no".
The reason there are no generics in Go is because nobody has implemented them in Go (or presented a concrete proposal for implementing them, i.e. something less vague than "just do what C# did" while ignoring that C# is not AOT compiled). Thre are some monomorphizing preprocessors but they tend to punt on the interaction betweeen generics and the rest of the language.
I find the community's insistence that Go does not have them because they somehow make programming worse to be fairly ludicrous, when there are much more practical reasons. Obviously you can write useful code without generics (C does not have them), but that does not make them useless, or "cruft", or an undesired feature (unless you simply choose to believe that every single person complaining about them does not use Go): you can also write useful code without many other features that Go does have.
Does this take significantly longer to compile than regular C# code (I can't imagine the answer is no)? If so, it doesn't really address the concerns Go's implementors brought up, which precisely revolved around the compile time : runtime performance tradeoffs that the JIT compiler helps mitigate for C#'s generics.
Idiomatic Rust uses try!. It is a less verbose version of the most common pattern of error handling in Go. You have not programmed very much Rust and are not yet familiar with its idioms, but that is by far the most common and avoids all the problems you just described.
"try!" is close to something one might call "cruft". It tests a function for an error value, and if it gets one, it returns from the containing function. "try!()" is written like a function call, but it doesn't work like one - it can execute a return statement. That's outside the normal semantics of the language. This is the only macro in the standard macros with such semantics. Fortunately. This is a capability which needs to be used with extreme restraint. Writing a macro "try_except_finally!(maincode, exceptioncode, cleanupcode)" would probably be a bad idea.
There was at one time a fad for extending C with macros like that. Fortunately for program readability, it didn't last.
`throw` in Java's exception handling also prematurely exits a function. So?
While `try!()` is a macro and not a core language feature, most of the macros in the standard library can be treated as such. So a Rust programmer will know that `try!()` can return, just like a Java programmer knows that `throw` returns early.
Besides, macros are syntactically distinguishable in Rust. When you see that exclamation mark, you have to rememeber that it's a macro and might be doing arbitrary compile time things along with arbitrary token tree expansion.
Except that in Rust, all macros are syntactically distinguished from non-macros (as well as hygienic, unlike C macros), and try! is extremely common (so the claim that people won't know what it does is questionable). I agree that macros like this should be carefully considered, but I think experience has already shown us that try! is perfectly fine.
FWIW Go does implement a significant subset of generics in a type-safe way. For any parametric type P[T], if P has no public methods or fields that mention T, then Go can implement it by allowing an interface (not necessarily interface{}) type for T. As long as the implementation of P does not upcast T values (something which is generally frowned upon, although tolerated in some circumstances), this will be as type-safe as in any language with parametric polymorphism.
For example, bufio.NewReader would probably, in a language with generics, be phrased as a type with respect to a type parameter. Something like (in bastard Haskell)
class Reader a where
Read :: a -> [Char]
newReader :: (Reader a) => a -> BufioReader a
In Go, it's:
package bufio
func NewReader(r io.Reader) *Reader
The interface argument is implicitly a type parameter here.
This subset of generics covers a wide range of software components, even if it doesn't include the usual container types.
I think it's important to think of these features in terms of their smallest possible descriptions. One mistake with Java, I think, is that "inheritance" is how you do both polymorphism and composition (I know you can do either without inheritance, but it's especially a pain to do composition without).
With Go, polymorphism is done with interfaces. Composition is done with embedded fields (and the very convenient method promotion).
> To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.
That's ridiculous. Plenty of people can appreciate the trade offs between "no generics" and "generics." There's nothing "non-negotiable" about it.
However, I still think the out of the box performance is great and for problems that don't require generics it is a very good option. I especially like the static compiling feature that makes deployments more straightforward. Handling HTTP requests and performing routing, dispatching requests to other services reliable async way is the biggest use case for me using Go. It can totally be written in any other language(Rust), if using generics is a must.
this will work on either Objects or on an Array. But if you have static typing and no generics to make it work you have to either:
- create two versions of the same function, one for Objects, 2nd for Arrays
- use any as a type of input - this will work, but you will loose most of the benefits of type checking, e.g. you will be also able to pass Number as an input and compiler won't complain, it will be detected as error only on runtime and other things (your function will also return any so further on in the program you won't know what type is used).
With generic it's easy, you write the function once and when you call it you tell what types are used:
// definition:
function addKey<X,Y,Z>(input:X, key:Y, value:Z):X { ... }
// call:
var a = addKey<Array<string>,Number,string>([],0,"fubar");
With this particular example there are probably other ways as well (sum types, common interface) and also compiler may actually detect passing Number as an error (depends how smart it is), but there are more complex cases, where lack of generics will lead to a lot of copy/pasting and boilerplate.
Thanks a lot. That was a really good explanation which instantly made me understand generics. In fact, I think this is an awesome way to learn new languages and concepts. You start with an example in a language you know and reason about the functionality from that.
To someone coming from a language like Rust, saying that your type system doesn't have generics is like saying your car doesn't have wheels. It's just considered non-negotiable.
Analogies are almost always useless diversions, but this one is particularly ridiculous.
People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't seem to be doing with Rust). It is obviously working pretty well, and that "non-negotiable" point turned out to not be a showstopper.
A car without wheels? If we have to abuse analogies, more like a car with a manual transmission. People can have hysterics about how will they ever eat their burger while they drive, but somehow some people manage.
If being able to get things out the door anyway is the standard for "well, guess this language is nice enough!", there goes any argument against JavaScript, or for that matter Go over Java.
I'm one of the people who is currently making a working solution in Go. Are generics the equivalent of missing wheels? Probably not, but I am absolutely finding it a present and persistent pain point that I don't have something like that or even just overloaded function/method signatures, and instead have to frequently repeat a lot of rewritten code scattered full of lots and lots of if/else cases.
Life could be worse. But the fact that people are shipping doesn't mean it's a language in which people aren't finding a specific missing features to be a problem.
This is specious logic. People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum. The only possible reason someone would choose Go is because, somehow, it is advantageous to their process. And we've seen an enormous number of success stories with Go recently -- all people choosing to use it for no external reason, but somehow it benefits their project. This is in contrast to, for instance, JavaScript (which debatably has its own merits) where if you want to script on the web client, that's your choice, love it or leave it. In the Go domain, there are countless alternatives.
I find it hard to even express clearly why Go feels so...natural and productive. But it does. And one of those reasons is that the language is so simple and, well, crude, that you don't stop and sit on questions of approach. Somehow it works.
If we need to stick with vehicle analogies, it's more like someone is using a dumptruck to move massive piles of Earth, but complaining that the steering isn't as light as their car.
And FWIW, when people talk about the lack of generics causing them great pain, usually they aren't making a solution, but instead are toying with the language. Doing the typical "make a library that solves all problems" sort of thing. When I am using Go it is almost always for a specific, practical requirement (as duct tape between processes, to orchestrate some high performance C code, etc), and it just...isn't a problem. It really isn't. Unless you're making library code it just isn't this issue it is held to be.
> People are not being told to use Go grudgingly because it is mandatory. It isn't a required component of some entrenched industry dictum.
You're registering this objection on the basis of JS's privileged status in the browser; I'm invoking it because of The Fine Article's comparison with JS on the server, where it's adopted as voluntarily as any other language -- and where, yes, despite claims that event-driven/callback scattered code are worse than what Go offers, people are able to get things out the door anyway!
And that's true of Node, it's true of PHP, it's true of Java, it's true of most languages people have moved to Go from.
The claim that being able to ship in a language doesn't mean it's wart-free is a pretty solid one, and that's what we're talking about.
> I find it hard to even express clearly why Go feels so...natural and productive. But it does
Does it? I've been working in it for 8 months and... nope. Doesn't feel unusually productive. But I guess your subjective opinion that you can't explain should trump everyone else -- after all, we're using "specious logic!"
> And one of those reasons is that the language is so simple and, well, crude, that you don't stop and sit on questions of approach.
Ah, yes. It's like Java:
"I liked programming in Java mainly because I found it very relaxing. With a bad language, like say Fortran or csh, you struggle to do anything at all, and the language fights with you every step of the way forward. With a good language there is a different kind of struggle, to take advantage of the language's strengths, to get the maximum amount of functionality, and to achieve the clearest possible expression.
Java is neither a good nor a bad language. It is a mediocre language, and there is no struggle. In Haskell or even in Perl you are always worrying about whether you are doing something in the cleanest and the best way. In Java, you can forget about doing it in the cleanest or the best way, because that is impossible. Whatever you do, however hard you try, the code will come out mediocre, verbose, redundant, and bloated, and the only thing you can do is relax and keep turning the crank until the necessary amount of code has come out of the spout."
http://blog.plover.com/prog/Java.html
(When I started working with Go last May, I had no idea or expectation of the extent to which I'd have thought this article would apply.)
> And FWIW, when people talk about the lack of generics causing them great pain, usually they aren't making a solution, but instead are toying with the language.
Really?
> it just...isn't a problem. It really isn't.
Oh. Sorry, then. I'll just realize that the unpleasantness I've encountered working with it really isn't there, and I'm not focusing on solutions.
You almost sound angry that other people are enjoying and having success with a language that you loath. I would wager that you simply are not taking enough time to shift your thought process to a state that is more in line with what is available in golang.
"and where, yes, despite claims that event-driven/callback scattered code are worse than what Go offers, people are able to get things out the door anyway!"
You misunderstand my argument. If someone is begrudgingly complaining about JavaScript in the browser, well they have a legitimate gripe because they really have no option (beyond various compiles-to-javascript kludges). If those same people used nodejs, on the other hand, which many people do, they clearly found some compelling reason to do so. In the case of node it was that it made code very easily, and by default, asynchronous, instead of the classic .NET/PHP synchronous model. There was a benefit, and people gained from it.
Really?
Why are you using Go? Are you solving a real problem? Did you say "here is my itch, and I am using Go to scratch it?" I have never seen, in these discussions, people solving actual problems complaining about Go. Instead it's the code tourists who want to do some flippant, vaguely directed project and then add "Go Guru" on their resume to give credibility to their complaints.
Apparently. I have no idea why JavaScript's position in the browser is relevant at all to the point that being able to ship in a language isn't evidence that its featureset is ideal.
I do invite you to argue the point further, though. And please continue to ask questions like this again:
"Why are you using Go? Are you solving a real problem?"
Yes, please do imagine out loud that everyone who's critical of Go is just not building real software in it. Hell, follow your "argument" to its natural consequence: anyone not using your personal flavor of Blub is probably just farting around.
Ah, sweet delicious sarcasm. Always the last resort.
There is absolutely nothing drawing anyone who doesn't want to use Go into using it. There are zero external forces or dependencies that are making you build solutions in Go.
So when you come telling a tall tale of your peril with Go, it just stinks. Do you understand? You can, from the outside looking in, have criticisms of the language, but when you try to add authority to your claims by manufacturing great experience, it sounds absurd.
The relevance of JavaScript -- and this really doesn't seem that difficult, though I think you're trying to be difficult -- is that, to reiterate, people have to bear it regardless of their feelings about it, so there are a lot of people who despise JavaScript but ply their trade in it daily. There is zero parallel with Go, where there is absolutely no reason for anyone to ever make use of it if it doesn't offer some significant advantage to their project.
> People are building real, working, successful solutions in Go with rather surprisingly regularity (which, if the comparison needs to be made, they don't seem to be doing with Rust)
I have written hundreds of thousands of lines of Rust code for Servo, the Rust compiler, and other projects. Of course it's a less mature language, but people are building plenty of solutions, including production solutions, in Rust.
<snark>
had to be hundreds of thousands because you didn't come out of the gates with a decent design and you had to wing it for the last 6 years
</snark>
Two things. First, I think it's more about the initial reaction to Go, from someone coming from Rust (or Java, C#, C++, etc).
But even so, I agree the wheels analogy is too extreme. I'd maybe say that it's like hearing that a car uses two motors instead of a differential -- "weird, I thought we solved that problem a while ago..."
> I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system.
I think it depends on the kind of things people write. Most people I see writing Go code seem to be writing programs, a piece of code that performs a specific function for a user. In those cases, you very often know exactly the domain types, and Go's type system is perfectly adequate there.
Other programmers write libraries, functionality that is meant to be used by other programmers to build their code upon. In this case, you rarely know the context in which a user of your library will use it, therefore you cannot really make any decision about types. This is a big reason why people like having parametric polymorphism.
The constant arguments that we see online probably comes from people writing programs and people writing libraries arguing with one another without understanding the context in which the other writes code.
> Other programmers write libraries, functionality that is meant
> to be used by other programmers to build their code upon.
> In this case, you rarely know the context in which a user of
> your library will use it, therefore you
> cannot really make any decision about types.
Uh ? Even for a library you certainly can make decisions about types, document them and enforce them. Who wants to accept unspecified data types ?
That doesn't mean no decision has been made: in a typed language with subtyping, this amounts to choose the "top" type of the type hierarchy, and without subtyping, you're choosing not to enforce structural constraints. In untyped languages with structured values (like any usable language), you make those decisions in the way your code checks for this or that value attribute or runtime structure. I guess unspecified and specified as "any" is often the same, but for me the former is a design mistake.
> - Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before.
I was drawn to Go initially because of its promises around concurrency, but this is why I stayed. Within less than a month, I was as productive in Go as I was in Python, despite the fact that I had been programming in Python for several years at that point.
> - I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go.
For what it's worth, Docker has more or less replaced this need for me. I know it doesn't actually do "dependency management" in the traditional sense, but by the time that ad-hoc vendoring no longer works, I've found it's already time to start using Docker for deployment for other reasons anyway. At this point, it's just as easy to use Docker to manage the dependencies at the application level while developing as well.
I'm curious, how does Docker help with that ? You still need to include the dependencies somehow, either by vendoring or using something like Gom, or straight go get.
As someone who has recently ventured into the world of Docker, I have been questioning if there is a need for virtualenv anymore, especially in production.
I do believe the need for virtualenv stays, in development as well as in production. Even when using a Docker container, you will still want to pin your dependencies strictly to specific versions and not risk any interference of Python modules that happen to be on the OS. I think it's important to not make assumptions in that area (dependency management) when wanting to create stable software.
Actually languages with stronger/more capable type systems are a feature and like all features they are wanted by some people who find that it makes their life easier.
Not having a strong type system is not a fault per say it's just that I need a strong type system as a feature(indispensable for me).
For me choosing between Go and Rust is mostly because of the type system.
If Go works for you then it's fine. Although if you want to find out how type system can help you, it's a different story.
They are just third party tools that aren't integrated into the language. Which for me is perfectly acceptable. There are sometimes legitimate reasons for formatting code different to what the language creators believe.
I used to agree with you more strongly but I think it's easy to forget just how much time and confusion is saved by having a single standard format which anyone can trivially check and apply. It's not just about avoiding unnecessary bike-shed arguments but also things like the cognitive cost of having to dealing with each project / developer's style quirks.
I'm now inclined to believe that a basically free way to avoid bugs and make things like code review easier and more productive is worth the minor cost of people having to break out of old ruts.
Honestly, it's not the 2-4-8 indentation or the placement of braces that gets me when reading code. In Go, my biggest problem is that there are so many x, err := foo(); if err { ... } that I get lost trying to figure what the happy path behavior is.
I'm hoping Go's error handling is improved in 2.0. I understand the objections to Java-style exceptions but I think they underestimated the actual cost of having so much boilerplate clogging up every non-trivial program, not to mention the way it actively encourages people to punt on error checking which is why so many projects are littered with `x, _ := foo()`.
The approach I'd like would be a lightweight assert-style failure mode where the compiler would treat any function which returns an error as being followed an implied `if err != nil { panic("Unhandled error") }` unless the error is checked on the next statement. That'd allow you to handle things which you expect to fail regularly while preventing the litany of bugs in C programs caused by forgetting to check return codes on things which rarely fail.
indeed. Pretty sure there's some cognitive load involved for developers who come onto a team who uses a style that's different to what that developer is used to. Languages with strict style standards remove this problem.
> Again. Third party tools will have exactly the same benefits.
If that were true, the frictional problems I mentioned would not be the rule in every other language. Even something like Python, where PEP-8 has been recommended strongly by the community for many years and has widely available validators and automatic reformatters, still has perpetual low-level debates about this.
In languages like C, where there are multiple well-established conventions, you can still find bitter arguments going on over things like optional braces because there are still tons of bad programmers out there who think it's preferable to ship massive bugs every few years than type two extra characters.
>- Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before.
>- In general the document is solid, but I've found the usability of the generated docs to be poor. You think they could bribe a few Google designers to spend some time fixing that...
- The standard library is solid, and I was surprised how well-rounded and mature the third-party library support it. Coming from a Python/Ruby background, that was nice to see.
- I totally agree with the comments on this thread about dependency management. Godep [1] is nice, but it would be great to see a canonical dep management tool for go.
- The tooling for Go is excellent: More languages need something like "go fmt".
- In general the document is solid, but I've found the usability of the generated docs to be poor. You think they could bribe a few Google designers to spend some time fixing that...
- I've noticed a lot of Rust lovers commenting about how great Rust's type system is. It probably is, but I haven't run into any problems with Go's type system. I've found it to be practical and easy to use. The only issue is parsing JSON when you're not marshalling it to struct. They need to fix that (although there are some nice third-party tools to make it easier).
- Go is a minimal language and has been called boring. [2] I don't claim to be an expert yet, but I don't think I've reached this level of productivity with a language this quickly before.
[1] https://github.com/tools/godep
[2] http://stevebate.silvrback.com/go-is-boring