Actually, Ho has generics and has had them from the beginning. But they're only available for builtin types (slices, maps), not for user-defined types/functions.
And you can see already that starts them onto the slippery slope as they don't support variance rules. Which leads to lots of boilerplate/runtime-typed code.
It is fairly clear by now that omitting generics is not an oversight, but rather a design choice. If you disagree, it sounds like Go isn't for you. Maybe it's time to just move on and ignore it instead of beating a dead horse.
I am always confused by the push to make every language exactly the same by using the same paradigms and features. Some languages try to take a different approach. If you can't figure out how to work within that paradigm, don't use it. Your comment is akin to complaining that Haskell doesn't support an imperative style.
It is by design that Go does not have generics as the Go team have not found a design they feel works and they are unwilling to compromise the current design.
You're both right. I'm paraphrasing, but the FAQ says "We will add generics if somebody can demonstrate that the value of doing so would outweigh the complexity it would add". I'm assuming nobody has demonstrated that, so they haven't added them.
Should really read "We will add generics if somebody can perform the impossible and convince the very stubborn and opinionated Go leadership that the value of doing would outweigh the complexity it would add".
Nonsense. Reread the FAQ. They are choosing to not implement generics. If someone can find a way to implement them without violating Go's design principles, they will. In other words, it's a choice. It's not that they just haven't got around to it.
I suppose it depends on the precise definition of "oversight". My understanding of the term allows it to be used when someone deliberately chooses a course of action, but not having taken into account the full consequences.
>I am always confused by the push to make every language exactly the same by using the same paradigms and features.
More like: some paradigms and features have been proved useful, and experienced programmers ask for them in a language that lacks them.
And not indiscriminately, but usually only ask for them if that language is of a certain paradigm / family of languages were those things fit well with (e.g. few ask for immutability in Go, or logical programming in Javascript).
>Some languages try to take a different approach.
Yes, the wrong one.
>If you can't figure out how to work within that paradigm, don't use it.
A lack of a feature is not always a "paradigm".
Besides, by the same logic, every language is perfect as is all the time, and users and potential adopters should not ask for anything new.
The lack of closures in Java for ages is a strong counter-argument to that. Or the rejoicing by which people adopted "auto" in C++. And tons of other examples, besides...
>Your comment is akin to complaining that Haskell doesn't support an imperative style.
More like his comment is akin to complaining that Java doesn't have Generics (pre 1.5).
Please just stop. This is not an objective issue. I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics.
And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go.
If they find a way to introduce generics while upholding Go's other strong points (fast compilation being another), then great. But it looks like it's not trivial.
If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics. Your condescending remarks are entirely unproductive.
>Please just stop. This is not an objective issue.
When it comes to computer science generics have been an accepted part of PL research for decades. The extra expression power they give and the paradigms they enable are neither controversial, not something that's up to individual tastes to judge.
Someone might not like them subjectively, but that's not different than someone not liking closures, or map or any other established thing. People will always have their preferences.
>I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics.
That doesn't prove it's not an objective issue, just that a specific use case, in a specific domain, didn't need it.
Or even more precisely, that a specific programmer didn't feel the need "held back" by their lack. Perhaps others would feel "pushed forward" by their presence.
For example, I mentioned Java above, who only got Generics after 10 years. Tons of far bigger Java programs than the one described have been created with Java-without-Generics (from financial services to automobile controllers).
All those projects weren't any "proof" that Java doesn't need Generics (and/or closures). Just that you can do without them too (which is true -- nobody argues that you can't).
Besides, isn't Paul Grahams whole "Blub" concept based on the idea that people using languages without X features have little means to understand their importance (and what they're missing)?
In any case, there are counter-examples to what you write too: several posts from teams that have used Go in production that say they like it but still lament the lack of generics.
>And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go.
Generics are not "loose", if anything they're even tighter type-wise than what Go makes you do to overcome their absence. Either you create concrete types for everything, ad nauseum, or you go "loose" and use interface{} and the like, throwing a lot of assurances out of the window.
>If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics.
Again, happiness doesn't say much -- that's personal preference and can't be debated.
Java programmers were perfectly happy to write code without Generics and Closures for like 15 years too. Most were even oblivious that those things existed in the PL world at large. Javascript programmers suffered without correct scoping or an import system for 20 years, etc.
It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language. I actually think comparing Go to Java is silly because a lot of motivation behind Go's design came out of avoiding what was done to Java and C++.
The point is, plenty of companies manage to create very good production software with Go, without generics. I didn't mean to rest my argument on my personal anecdote. You can look to Google, CloudFlare, SoundCloud, Dropbox, etc. for reassurance.
>It's funny that you mention Java because I have always avoided learning Java. Even from afar it grosses me out as a language.
May I guess you're either some old Lisp/Smalltalk etc veteran, or, much more probably, someone who entered IT after, say 2005?
Because back in the day very few thought of Java as "gross" -- it was greeted as a welcome change from the existing landscape which at its best was something like C++.
Yeah, so the second case, someone who entered IT after 2005!
I guessed so, because back in the day (1995-early 00's) most devs outside of seasoned functional etc veterans (who were extremely few) or hardcore systems guys, saw Java in mostly positive light, and never considered it "boring" back then.
The change (for new devs to consider Java "boring" and lacking in features) happened sometime after 2005, with Rails entering, Javascript catching up, C# getting more features with 2.0 and 3.0.
(Consider than back then Scala, Go, Clojure et al weren't even started, and AJAX had just been made mainstream).
The tired old argument gets trotted out again. If an important, beneficial addition to the language is missing then it's by design and if you don't like it go use something else.
Feel free to downvote me if you want, but I'm skeptical about Go and what caught my attention in this linked article is the picture. Pretty much what I feel about Go. Was it a (sub)conscious choice?
> The prevailing feeling of Go is "getting things done".
This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true.
I think a more accurate way to look at Go is that the language, tools, and standard library make decent design trade-offs when your target software is 1) simple 2) network daemon-y or a CLI and 3) going to be worked on by a wide variety of developers. There are lots of problems that fall into that problem set, and it is very nice to have a language targeted at it, but Go is certainly not a good fit for a huge number of software projects. You will be less productive in those cases using it.
"Getting things done" is quite accurate considering large number of popular Go projects in short time compared to allegedly better design languages ( Scala, Rust, Haskell, D, OCaml etc..)
You are mixing productivity (getting things done), quality (better designed languages) and popularity (large number of projects) in the same sentence, but you generally cannot find causal links among them.
In Haskell a lot of it is due to people thinking they need to deeply understand everything before cranking out code. It's like trying to understand music theory before strumming some guitar strings... actually it's probably something less useful than that.
However, I guess the inability to deeply understand or pontificate about Go is an advantage in itself... forcing your only potential activity to be getting work done.
Also, are you sure that there are more popular Go projects than popular Scala projects?
It's true though. Go has a small number of language features, and they are only the simplest ones. It can be learned in a day. Other languages like JS, Ruby, and Python have a big fixation on figuring out the prettiest syntax for stuff (JS promises and chaining etc, "Pythonicness", and Ruby's incessant cuteness). In Go, you can't really make things pretty, so you just bang out code.
Yes, but there's a kernel of truth there. I wouldn't say I managed to learn Go in a day, but after perhaps six months using it I was much closer to mastering Go than to mastering other languages I'd been using for years. Go's road to proficiency is a shorter one, there's just less stuff to cover.
Take initialization for example: look at all the edge cases belabored in section 8.5 of the C++14 spec, or even the intricacies of initialization in a simpler language like Python. Now contrast this with how much lexical and conceptual space it takes to describe zero initialization in Go's spec: https://golang.org/ref/spec#The_zero_value
As in other areas, Go's approach here has downsides. (Possibly major ones.) But those tend to be conscious design decisions to minimize the total number of concepts and idioms present in the language.
"Ruby's incessant cuteness" is a first class feature of the language in practical environments, but not of the language itself, in my opinion. While I can knock python for whitespace, and not a whole lot else, I think ruby is probably the most "learn in a day" language I've ever experienced. Without any background in strongly typed language or anything else C-like, Golang actually took me several days of work just to understand paradigms like slices, which were pretty foreign to someone who only worked in dynamically typed language.
JS is pretty damn tricky though, I'll give you that one.
I don't know that "pretty" is the right description. High quality, well made, canonical C has a certain beauty to it and Go tends to offer a degree more on that vein. I personally find that much of the js, Python, and ruby "beautifying" is related to compactness more than being easy for the next guy to view the correctness of or understand.
It's subjective though. I'd guess that if you're a fan of the suckless style of engineering, go might be right in your wheelhouse and you will probably find it very beautiful if you can accept garbage collection.
Promises (which aren't limited to JS) are about far more than pretty syntax. Promises and promise combinators give you guarantees about your code, such as "no promise will ever execute both its success and failure callbacks" and "of the callback that is executed, it will never be executed more than once," and "once a promise is resolved, it's state cannot ever change."
Also, I don't understand the benefit of being able to learn a language in one day. You can learn how promises work in a single day and then apply that to any language that implements them. With Go, you will learn the language but then have to re-implement promises for every type that you have [0].
Consider the use case of issuing two API requests concurrently and assembling their results. You can do this using the fan-out, fan-in pattern described at http://blog.golang.org/pipelines
Search the page for "func merge". Any time you want to fan out and fan in, you will have to write that block of code for the types of the channels you have, or else use interface{} and lose type safety. So the cost of a language that can be learned in one day is that every single time you perform this very common concurrency pattern, you will have to repeat this code and potentially make errors in the process. And if you want to change how this merge pattern works across your codebase, you will have to change it in many places. What happened to DRY and reusability?
[0] There is a Go promises library, but it uses interface{} for all callbacks and does not appear to have been an active project over the past year. https://github.com/fanliao/go-promise
>Other languages like JS, Ruby, and Python have a big fixation on figuring out the prettiest syntax for stuff (JS promises and chaining etc, "Pythonicness", and Ruby's incessant cuteness). In Go, you can't really make things pretty, so you just bang out code.
I think a difference here is not that people don't get things done with other languages, it's that the language was designed with that as a first class metaphor. (Whether or not that is true I can't say, but that's the feeling the poster gets.)
I agree with you, but there is something to the argument; it's just poorly phrased as "getting things done".
gofmt, for instance, is uncontroversial. Taking the decisions about how to format code away from developers and standardizing it is widely seen as a win (a win Python flirts with as well).
Well, there's a lot of other things in Go that have been pre-decided for you, not just the formatting. The net effect is that you don't have to waste time:
* thinking about designing a DSL for your programming problem (DSLs in Go require parsers)
* designing a class hierarchy to express your programming problem
* choosing between event-loops and callbacks or pools of threads
* picking the right associative container library (do I want a red-black tree? a hash table? a trie?) for routine coding problems
These pre-decisions can feel confining, but I think for a lot of developers Go reveals that those decisions were usually a waste of time. When you actually hit a place where you need a red-black tree, it's not that big of a deal in Go to bring one in. You're just not going to do that for your session store or for a simple lookup cache --- which is, I think, what a lot of people who can't stand Go's lack of generics would be doing.
I think that falls into my use case of "simple". If you don't need to make those kinds of decisions, then by definition your problem set is simple (at least from a business logic point of view, even simple business problems get complex at scale).
The problem, I have with the sentiment (which I grant is largely me over reading into it) is that a lot of the things people think of as noodling or a waste of time, are the central problems in more complex environments. Making sure your program is correct is very important in some environments. Making it easy to express complex domain knowledge as a subset of a programming language is a huge win in some environments.
That isn't a lack of getting things done, thats just more complex logic requirements.
I think you're missing a subtlety of my argument. I'm not saying you never need to pick a container that isn't a simple hash table, or design a DSL, or roll your own event loop, or design a hierarchy of abstractions. I've done all of those things in Golang --- even the event loop!
But in C++, those are decisions you might make in parsing a config file, or in managing a simple table of sessions, or adding an LRU cache to something. You can't get away from the decisions. I have an array of stuff, and I have to decide, "do I want a list, an slist, a vector, or a deque, and what the fuck is a deque?". 98% of the time there is one sane decision that is so close to optimal that it's not worth tinkering with.
In Go, for prosaic, routine code, those decisions have been made for you. You have to go just annoyingly enough out of your way to second-guess those decisions that you almost never do, and you're almost always better off for not having to do it.
> You can't get away from the decisions. I have an array of stuff, and I have to decide, "do I want a list, an slist, a vector, or a deque, and what the fuck is a deque?". 98% of the time there is one sane decision that is so close to optimal that it's not worth tinkering with.
I'm currently working on a project (WebRender) in which we keep using the standard library hash table in the first cut of code whenever we need an associative lookup table, and every time we use it it keeps coming up #1 in the profile. Almost every single time. We then have to switch to another, more optimized data structure, and generics really help here so that we can reuse these data structures. In fact, if we didn't have them, we'd probably be sunk.
I'm saying that some projects need custom containers all the time—to the exclusion of the built-in ones—and need to reuse the implementations of those containers.
So did we! We didn't use Golang's maps to implement limit order books; we used a red-black tree. We did not build our own, nor did we find a red-black tree that was designed for order books.
This just isn't as much of a big deal as people think it is. Go makes it a drag to use a custom container, but it doesn't make it hard, and that might be how it should be!
And you had one data type that you used with that red-black tree, so you didn't mind not being able to abstract over the types of objects you were placing in the container. But we have lots of data types that we reuse for freelists and other types of containers. We don't want to have to reimplement that code for every single type we want. That's where generics save us.
> This just isn't as much of a big deal as people think it is. Go makes it a drag to use a custom container, but it doesn't make it hard, and that might be how it should be!
I believe you that it wasn't a big deal in your case. But I disagree with your general claim. I think you're extrapolating from your use case to claim that generics aren't important (vital, in some cases). I'm saying that, in my use case, they are.
I sum this phenomenon up as "frictionless development". I don't have to stop and make a decision about something not core to the problem I'm working on while writing code.
If the default doesn't work for some reason then I can tackle that problem but at that point it usually is core to the problem I'm working on.
For some people Go is anything but frictionless though. They spend all their time in Go fuming that their favorite abstraction isn't there. For those people my experience doesn't translate.
> This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true.
It could just be the feeling that Go gets out of your way more than other languages do. (For example, people complain about how much ceremony is involved in writing Java. Go could easily feel like "getting things done" in contrast.)
maybe not specific to language, but compared to projects like Angular, React etc... Go has much less traction. Swift is a new language and is already much more widely used.
What the heck are you talking about. Who uses Swift on this sort of scale? This is just one of the many MANY large companies using Go to power their core infrastructure.
Go brings some good things to the table, yes. I've seen it's popularity rise in recent years, but it seems to be rising slowly. There are a ton of companies that can be listed for almost every technology.
Node is another technology I would put ahead of Go as far as adoption. Maybe Go will get better, to me, it's too different than a lot of what I see day to day with Java, C#, Python, JavaScript and on and on. The part I love about Go is that it handles garbage collection, other than that, it's atrocious looking C like code.
> Go brings some good things to the table, yes. I've seen it's popularity rise in recent years, but it seems to be rising slowly. There are a ton of companies that can be listed for almost every technology.
Then name any company using Swift to the level Dropbox uses Go, or retract your claim.
Go code looks nothing like C other than general brace styling. I can't decide if you're trolling or just genuinely this ignorant.
Just stating my opinion, not trying to troll. I said "C like" because it is very much different than any C like language I'm used to. Dropbox was using Python as a main technology stack not that long ago so I'm not all that surprised they are seeing huge gains using Go. If Go gains more traction I'll consider using it, until that time, 6 years have gone by and I personally haven't seen anybody asking for Go in the Washington DC metro area.
> Dropbox was using Python as a main technology stack not that long ago so I'm not all that surprised they are seeing huge gains using Go
They still use Python if you read down the Twitter thread, but I can name so many more. Cloudflare for example.
The likely reason you see such a difference is that the languages are suited to different things. Swift for example is all but mandatory for iOS apps, and so this is not adoption but migration. If you're just looking for small freelance projects then I expect Go will be a long time coming, but if you're looking for large infrastructure work you'll find an awful lot of people very interested in Go.
>Go code looks nothing like C other than general brace styling.
I disagree. The one thing that makes Go code look more like C than other C descendants like Java, C#, JavaScript, Swift and even to some degree C++ is its error handling style. Having a seperate error value is of course a big improvement over C but visually the error checking code following many statements appears a lot like C.
And the second reason is that Go has pointers with a syntax modelled after C.
So in the eyes of the 90% or so developers who have been using mostly Java, JavaScript and C# for 15 or 20 years, Go has to look a lot like C.
I've had this message several times, but "What the heck are you talking about" doesn't break any rule whatsoever that I can find. In fact I fail to see how it could be toned down anymore. Are we not permitted to express confusion? Is 'heck' not the lightened American friendly version of 'hell'?
How much more would you like me to blunt what I say in order that it doesn't violate unclear rules?
What you posted was uncivil. "What are you talking about" adds no information and is a variant of name-calling. Asking whether someone is "trolling or ignorant" is also name-calling, just with a branch in it. And "name X or retract your claim" is a form of intellectual bullying, so also uncivil.
Any substantive point you have will become sharper once you edit such rudeness out, so it isn't a question of "blunting", but of being respectful. Even if you don't respect the person you're talking to, you need to respect the community by holding yourself to a higher standard.
In a golang conference, the presenter talking about youtube's vitess said:
"If vitess servers are down, then youtube is down. That's how golang is crucial for youtube"
Not going to debate your claim, but Swift is an unfair comparison, as it is practically forced upon you if you want develop for one of the most important platforms today (you can of course still write stuff in objC, but Apple has made it clear that you'd better learn Swift).
Angular...React, are you serious?
Haven't even tried Go tbh but I wouldn't even dare to make such a comparison on HN or anywhere else for that matter. You just don't do it. It's like saying that Go sucks, google maps is better.
Who cares about adoption rate? Is PHP the best language to make websites because of it's popularity? Hell no!
I tell you what I care (and I know I will eventually pick Go for these reasons):
- concurrency
- parallelism
- stability
- speed
- community
- libraries
- proper use of hardware
- small footprint
Java, JavaScript, PHP, C# and ActionScript each got pretty good traction within their first six years as new languages. So did Ruby amongst the language community (of Japanese speakers) it originated from. As others have mentioned, Swift has had a good adoption rate.
I'm assuming you trolls down vote because you know it's true. I've tried to use Go, I think it's syntax and unique style sucks compared to C#, Java, Python or even JavaScript.
Go's syntax is pretty much C-like though. Try comparing Go to Lisp, Pascal, Python, Visual Basic, COBOL, FORTH, etc etc.
But at the end of the day, syntax is really just a superficial element of a language. Particularly when you're comparing Go with very syntactically similar languages such as Java, JS and C#.
Actually one of the guiding principles of Go's design is that syntax is anything but superficial. It affects nearly all aspects of your design. Everything from the parser to the compiler to the stdlib. Syntax is the UI/UX of your language. Dismissing syntax as superficial is a mistake.
Imperative languages really aren't massively different in the grand scheme of things. Sure, some are more OO than others, different type systems, and so forth. But you do more or less tackle the same problems with similar kinds of solutions. So a lot of the time, the syntax changes are relatively superficial compared to the complete mindset change you require if you were to tackle the same problem with a LISP, or Prolog, stack-based languages, or even a procedural SQL (albeit to a lesser extent).
I do welcome the breadth of choice we have in programming languages, but sometimes we get too caught up on the finites of one language of a particular sub-genre when compared to another language of the same sub-genre. Particularly when a good programmer should be more interested in coding good logic and thus understand the paradigms enough to swap between the different languages of the same ilk with relative ease.
Go seems like a fun language that has been sitting on my "look into it list" for a while, can't belive it's already six years old.
Since the TensorFlow video post is currently on the frontpage as well...as someone who uses neither C++ nor Go (I can write FizzBuzz level of code in both and read both well enough to get what's going on) I have to wonder how much internal buyin Go really has at Google if the core of such a project is implemented in C++.
It's a project they see as valuable in the future and it would lend itself really well to Go as these calculations are done distributed and yet they picked C++.
[I'm not sure how much of the old framework they reused but if the will to Go was really strong I'm sure that wouldn't have been an issue]
I think in the TensorFlow case it is just a purely technical decision - I don't see how they could achieve what they aim for with that project in Go (or really, in anything but C/C++ at this point in time). Right tool for the job, etc.
+1 for right tool for the job. Also, I can imagine they have large amount code already there in C/C++ since this is the second deep learning system they designed.
and if you watch Jeff Dean's video, he mentioned more front end in other languages, Go is the only example and as the interest from internal.
It is a standard language at google. It gets used for things like the download service and other high throughput service which is it's sweet spot. The TensorFlow project in previous iterations predates Go's official stamp of aproval at Google I believe and stopping to rewrite is an unnecessary step. It's possible that now something like Go would be used instead.
It's a project they see as valuable in the future and it would lend itself really well to Go as these calculations are done distributed and yet they picked C++.
Go is not Erlang. Go supports green threads (goroutines) and offers CSP-like channels to communicate between threads. However, it does not have a distributed computing story yet (at least, not compared to Erlang, the usual Java frameworks, etc.).
For a library such as TensorFlow, Go is not really an option yet, for many difference reasons. E.g. the lack of parametric polymorphism makes it hard to parametrize code for single, double, or even half precision. Go does not support anything like expression templates, which exploit laziness to eliminate temporaries. Moreover, a lot of machine learning happens on GPUs nowadays. AFAIK, there are no CuDNN bindings for Go yet.
As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produces native code (no VM). And, the goroutines can be multiplexed (depending on implementation) to OS level threads.
Green threads can be managed by a runtime library or VM, so no VM doesn't mean no green threads.
> the goroutines can be multiplexed (depending on implementation) to OS level threads.
Being multiplexed onto OS level threads is normal for green threads. Goroutines are "hybrid" (M:N) rather than "user-level" (N:1) threads, but anything other than 1:1 native threading means that you need a runtime or VM managing it, and its a kind of green threads.
I see. So goroutines are just green threads with a nicer name? Thanks for correcting me. EDIT: Editing my comment because I can't reply to your reply. Yeah, I used "just" with the intention of saying that goroutines are well within the category/definition of green threads.
> So goroutines are just green threads with a nicer name?
I don't know that I'd say "just": like Erlang processes, goroutines have some special features not shared by all other green threads, even with a similar M:N threading model. I'd say that Erlang processes and goroutines are each specific kinds of M:N green threads with unique features and distinct names. So, its useful to distinguish them within the broader category, they just shouldn't be distinguished from the category.
I've used Golang extensively for a few years now anywhere from ARM/Linux to x64/cloud based containers (and I admit, occasionally on Windows!). It's really a great platform, very robust and has an excellent ecosystem. I can't recommend it more highly.
I tried Goland for two of my personal projects. Initially I thought I will get used to the new syntax, but it never happened. It may have certain performance-edge over other languages but I wouldn't call it a modern language. I find coding in C more fun than Golang..
* No built-in runtime or GC
* A choice of dynamic vs static compilation
* A good libc is wonderful but not necessary to get work done fast
* The tooling is mature and plentiful
I'm sure Go is a fine language. I probably suffer from some sort of first-language bias as I've been using C for a long time and only know a smattering of Go from toy programs, blog posts, and reading the source to interesting projects like CockroachDB.
1. Variable Length Arrays: Go has slices
2. Anonymous Structs: Go has these
3. No built-in runtime (in C): This is not true unless you are compiling -ffreestanding -nostdlib, etc. I have done this in C, but such programs have to call system-calls directly and provide their own malloc, etc.
I love Go. It helped me so much, not only career wise but also on a more personal level, bringing back the excitement in programming I missed so dearly from my early days. Drop by at one of our Golang meetups if you're in the Munich area. http://www.meetup.com/Munich-Gophers-Go-User-Group/
Started using Go for my latest project (a successor to Evernote). It feels like such a relief, especially having just come out of a node.js project. It's everything I wanted in a (web-app) programming language, and for the first time I can say that a language has actually made my code better. I've never had a codebase this clean before.
I understand the basics of Go, but do you have any advice on where to start using it for web app development? Any framework that you're using (if one at all)?
I've used go-martini on a number of projects; it strikes a nice balance between performance (it's by no means the fastest Go web framework) and usability.
- Gorp[1] for SQL stuff (I like that it "encourages" your program data structure to reflect your DB structure)
- amber[2] for templating
- gorilla/mux[3] for routing
- gorilla/securecookie[4] for login/auth management (they have a sessions and context library too if you want that)
Go also has libraries that handle basic versions of most of these tasks (and these third-party libraries extend them). If you're building something simple they might be sufficient.
I've found the standard library to be more than capable for most CRUD style apps. You can add in simple middleware chaining using a library such as Alice (https://github.com/justinas/alice) and for passing around request contexts between them, you can use something like xhandler (https://github.com/rs/xhandler).
If you want more performant or flexible routing, httprouter (https://github.com/julienschmidt/httprouter) has a nice feature set.
Maybe it's personal preference, but there's something more satisfying about the modular approach of building up an app using only components I need and understand, rather than starting with a magical feature-laden framework but quickly realizing you don't need half of what it does. I think Go aligns particularly well with this philosophy given its emphasis on composition.
That's the libraries I use, too. I really wish contexts were built into Go's HTTP library. Without contexts, you have to use global variables to accomplish things like per-request logging and access to configuration data.
Not to mention that since goroutines cannot be forcibly terminated, it's the only way to control the lifetime of a handler (e.g. applying timeouts).
You may be looking for https://godoc.org/golang.org/x/net/context which is likely to make it into stdlib in the 1.7 timeframe from what I've seen in various channels. Doesn't quite solve the global logging problem though.
It's what devs are saying about any tech that's becoming popular.
It's much more useful to read a competent critique of Go (of which there are a couple) than post after post saying how everything is great. Everything can't be great, it's a basic fact of software engineering!
Yes, every language/framework is good at something and bad at some other. They are just tools. What matters is what one builds. A lot of technical news these days are about tools, not products.
So a master woodcarver works with chisels, his "tools", for his entire life...30 years, and with them he turns bare wood into incredible works that the world recognizes as valuable art.
Someone hands him a chainsaw, which by all measurable metrics should allow him to do the work 10x faster because, of course, it is more powerful, modern, and designed by "superior minds" whom understand IC engines, gearing, etc etc.
I think what I want for Christmas is a language with C syntax and keywords, no header files, no GC, ships with a library that has everything (threads, http, websockts, crypto). This new language takes all the bad parts of C and throws them away and does not care about backwards capability. Call this new language C++ or whatever.
I've been coding since forevs, and I really do feel like Go pushes you to keep clean code. Maybe the language, but a lot of it's just culture and leading by example.
Every time I peak into the source of a standard Go package, I'm blown away by how clean and simple the code is -- and it's a fantastic way to gain a deeper understanding of the language.
That has mostly not been my experience diving into std C library code, or quasi-standard stuff like boost...
I like the aesthetics of JavaScript. It makes the code cleaner because it doesn't require so much boiler plate. There - I said it :-)
Oh and compared to Go, I always point to sorting in Go. Just look up the library. I think it's awfully complicated, compared to JavaScript where you simply pass a comparator function. In Go you need a lot of lines to achieve the same thing.
For what it's worth, I moved to node.js late and even then only reluctantly. I only used it for one project, and found it to be a somewhat difficult experience, like I was fighting the language all the time. (It was still a step up from PHP which I'd been clinging to.)
I didn't realize how much I disliked JS playing "loose and fast" until I used Go with its rigidity.
Perhaps it's because what makes a codebase messy is having written code in it over time.
In the beginning, those Node.JS codebases were clean and manageable. Then came bug fixes, changing requirements and refactors. 2 years worth of that led to something that was quickly becoming unmanageable.
But then came Go and, after a rewrite, everything was clean again! It doesn't matter than the code base is only 3 months old, I'm sure it's going to stay this clean forever!
But hey, should those Go codebases become messy a couple of years from now, I'm sure Rust will have matured into a worthy successor and, after a rewrite, we'll all have the cleanest codebases ever!
I didn't. I tried node.js for a couple of months and it was like a breath of fresh air. But later on drowned on constant promises and never called back ;)
I've been having this vision for a while of making a HN-style site where you have to explicitly tag your comment as 'in agreement' or 'in critique'. (And also maybe a slightly hidden away, 'off topic, but that reminds me...' section.)
Then you could, for example, browse the ed column of birthday wishes & happy usage stories of Go, say on the left hand side, and then also, scroll through the op-ed right column of dissenters and critiques.
There's just something very disheartening about having a bunch of "anti X" dominating what you were hoping would be a discussion of "X"; downvoting is certainly not the right solution -- it's fine to be anti-X, it just needs a little bit of its own space.
(1) you'd self-tag -- imagine clicking 'in support' or 'in opposition' to comment.
And then (2), those two different sets of comments would go into different parts of the page.
Maybe a two-column view? Maybe separate pages?
Basically, conversations in a single-section format like HN are constantly getting overrun by criticism. Criticism is interesting and has its place, but it tends to be noiser, and it's disheartening when it's getting in the way of something you want to be excited about.
I wish the gdb support were better or that delve were more stable. I also had some weirdnesses using cgo on osx. Then I went into #go-nuts on freenode, and I got told I was wrong and there was no problem.
Back in 2009 #go-nuts seemed to be a much different place.
I write Go at work, and I admire many of the same things in Go I admire about Python.
I still wish generics were part of the language and will say their excuses about not being able to do it in a performant way seem to just be away of avoiding the subject.
Ocaml for instance, has a performant generics implementation.
Sometimes the Go community can have an anti-programming language research and anti-intellectual feeling which can be annoying, since in addition to Go I write a good amount of Haskell.
The tooling is nice as people say, however I think more maturing of the platform needs to be done. It's also never talked about how much slower Go's claim to fame of fast compilation got much slower after the 1.3-1.4 switch to a compiler totally in Go. In all fairness, I could be wrong about the last one since I haven't benchmarked it... but I can say it feels much slower than it was around 1.1/1.2.
Concurrency in Go is easy, however I feel like many erroneously think that channels or concurrency primitives like it only exist in Go. There are other languages with rich concurrency and parallelism options as well.
Using lots of interfaces and casting everywhere gets on my nerves since I like to have the strongest guarantees possible via static typing.
Overall though, I can't say I've had a bad experience with Go. I can say it feels like I'm using an okay tool (great in some places) with maintainers who put their hands over their ears to potential improvements (see the generics proposals over the years).
I've been yelled at on #go-nuts too; I ran into what turned out to be an authentic limitation of Go's I/O scheduling, and was instead chided for _'ing out error results in my minimized example code.
Given other aspects of Go's design, I'm actually a little surprised that Go makes it as easy to drop errors on the floor as it does. It feels like the language's strict checking of unneeded or missing imports and its lack of checking for capture of return values are philosophically at odds.
If compiler did it, how else would they get to chide people in people on bad style ;-)
But yes, good point. I think a better type system should handle it and make it harder to drop errors on the floor. But that kind of asks for Rust's like sum-type which is too close to generics for their comfort.
It's really a shame when a community's most visible public channel devolves into "you're doing it wrong"-itude. When I first started looking at Go in 2010 or so, coming from the rails community, I thought it was wonderful how friendly and helpful #go-nuts was. Unfortunately, it seems like an inevitable result of the regulars in a room seeing a deluge of similar questions and increasingly losing their patience. Eventually, everything starts to look like an instance of some annoying newbie pattern with a pat answer, and you have to fight to convince people that there is something novel and non-pat going on.
Go's concurrency is limited to the CSP-style and favors share nothing problems. Languages like Clojure can do CSP just fine, but also have powerful language-level support for heterogeneous concurrency problems that are easy to use and easy to understand.
CSP via goroutines and channels is idiomatic Go, but it's not the only option. Go offers mutexes and other concurrency primitives which, along with goroutines as lightweight thread analogues, allow what you're looking for.
.. mutexes limit you to the locking paradigm. You know there's more/better out there, right? If you want an actor / agent model you still must do this with mutexes channels and goroutines, resulting in some pretty fugly code, more so than normal go code.
The real problem here is that Go does not allow a user to create their own powerful concurrency primitives.
Locks exist, but you can't create a synchronized data structure. You can't create your own channel type because that's a generic thing which is reserved for the language authors, not the language users.
The whole point of modern programming is to create useful abstractions that allow a programmer to get things done without having to worry as much, and concurrency-related abstractions like parallel map-reduce and actors are powerful, but you have zero chance of making an abstraction for that in Go.
In Go it's basically CSP or bust; saying "you can use locks" is not an answer; locks are not a way to handle concurrency, they're a primitive for shooting yourself in the foot if you're unfortunate to be in a language where you can't abstract them away suitably.
I tried to go there to ask some questions while picking up the language, and what I got was RTFM, where manual includes the language specification, Effective Go book, and A Tour of Go. Apparently you're unfit to ask a question unless you know everything about the language already. Killed my excitement for learning the language.
Sounds like a sadly universal experience. It's really unfortunate — Go is an interesting language, but the place they tell beginners to go to interact with the community is so utterly toxic to anyone who wants to ask any kind of question.
What I don't understand is the people who say Go doesn't need generics. Go already has generics: channels, maps, make(), len(), range, etc. are all generic.
Nobody can argue that generics in Go isn't extremely useful. After all, you couldn't have typed channels without generics. One has to be pretty obtuse to argue that the utility afforded by Go's internal generics wouldn't extend to the language as a whole; that somehow Go's standard library needs to be special.
If you look at the standard library, its authors had to jump through some serious hoops in many cases. Packages like "reflect" (the megatype Value), "builtin" and "sort", to pick a few, are a graveyard of typing awkwardness. The sort package and its special function just for sorting strings is practically a written confession.
Generics being a speedbump is an argument I haven't heard before. Can anyone comment on what the performance challenge is? Nim instantiates unique concrete type instances based on their parameters, couldn't Go do the same?
It's extremely incomplete. They enumerate some challenges, but don't investigate languages where generics is apparently a solved problem. Whole sections are blank, especially — and perhaps revealingly — the ones that are about less C-like languages such as Haskell and OCaml.
I wonder how the situation compares to Swift, Rust and Nim, three recent languages that have managed to implement generics without (as far as I know) a single complaint, and without descending into C++ madness.
It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. Before that we had been using Java for some years. The reason for the move were few:
1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusing via a long chain of navigation between sites.
2) Boredom after nearly a decade with Java programming.
3) Memory usage of Java in our conditions was much higher compared to other languages (C, C++, Go)
4) Not Java's problem, but whenever one thinks of hosting a HTTP service in Java, thinks of using a container (e.g. tomcat, jetty, Jboss etc.). Go seemed to have made making services very easy. Its possibly just a perception issue, but its there in my experience.
So we wanted to move, and Go looked stable at the time from all my HN readings. C was too bare bones(even string handling was a pain to me, after a gap), and even C++ would not have matched some of the things which Go has inbuilt. Few examples:
1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code.
2) Great HTTP client and server libraries, which make very easy to write your own standalone services, as well as write http crawlers. (I am quite excited that Go 1.6 will have HTTP/2 support for both, as per this birthday blog).
So, in nearly three years of usage, with largely no regrets[1]. It is what they say it is: a bare-bones, fast (both compile & run) and stable (hardly get any errors after you have coded stuff, one of the stablest programming paradigms in error handling, etc).
Thank you, Go team! Hoping to use it for many years, as default server side language.
[1] Some of the 3rd partly libraries, we use are still not ported over to Go. They have Java, C++/C versions.
Just to push a counterpoint, I never understood those startups with foosball tables, sponsored beer, team workaholidays on tropical islands but god forbid the work itself is any fun.
If a technology choice makes people enjoy their work more, learn new things, help them think differently and thus get more creative, then isn't that a big plus? Sure, maybe it does not weigh up to whatever downsides there are, but it counts! The whole idea that "fun" isn't allowed to be an important argument in a business decision feels horribly outdated to me.
Do you really thing it's fair to blame a whole language for making your project unmaintainable, when you admit you were just learning it -- and you had come from PHP?
php is much maligned here on HN, but it doesn't mean that it automatically makes for a bad programmer.
Here's another exmaple for you: Over the years, the project I work on has used the following:
vb .NET
C# .NET
WCF
asp Webforms
MVC2
MVC4
The result is a maintenance headache (it's not a nightmare, but we do have to pause every time we unexpectedly encounter VB!), and that's where we've been disciplined enough to stay within the MS/ASP stack. Had developers been allowed to really go off-piste then we no doubt would have even more choices, and as a result be even less maintainable.
Yes, you might not be attractive to a certain subset of programmers if you are seen to be not using a trendy new language or framework, but there's the other side that by often switching you are left with a long laundry list you need to satisfy when you're recruiting so they can maintain the older parts. We already don't require vb experience, and we expect that people can pick it up well enough to maintain it, but a side-project in "go" might seem fun now, but if it becomes part of the business then you might find that in 5 years you have to take a bad choice in recruiting because otherwise you're left without anyone who can maintain that application.
> but it doesn't mean that it automatically makes for a bad programmer.
I came to PHP late from proper languages circa 2008/2009ish been programming since I was a kid in the 80's, I've no great love for the language, it's purely a tool and once you ignore the rusty bits it's not a bad language for a lot of web stuff but I've never been concerned with purity/beauty for it's own sake I just care about what I can do in a language, these days I use PHP a lot on the web, Python for just about everything else (even my build system for automating browserify is in Python using Envoy) and I play with Go and such on the side.
All that and there is a lot of work in PHP clearing up after others (if you like those kinds of engineering problems which I do) which is also nice.
MongoDB I can see, but Coffeescript is just sugar on top of Javascript, and I struggle to see how it could make any code unmaintainable – but i'd be interested to know why!
What's the problem with document databases, really? To be honest, for 80% of the projects I've ever worked with, fixed-schema rdbms's fitted just like... a square peg in a round hole!
Heck, even for advanced analytics, I find mongo aggregates and mongo map reduce 10x more intuitive and SQL that inevitably ends up using zillions of non-portable tricks, stored procedures and god knows what. And atomicity and whatever else transactions guarantee you in theory can be easily emulated with some good db structure design tricks and app design tricks in practice.
And the smarter a RDBMS is, like Postgres, the more dangerous it becomes for maintainability: it's a zillion times easier to maintain 'logic expressed in app code' (because you have basic stuff like version control, tests and so on), than 'logic trapped in the db' (good luck explaining to a new developer how "X automagically happens because of trigger Y and stored procedure Z, so there is no app code for X that you can instantly tweak to change how it works"). This is why I at least have some respect for mysql: it's retarded enough that it forces you to put the login in the code, where it f belongs!
Really, give me a dumb document db like mongo any day! And if I want something "less dumb" there're things like arangodb and rethinkdb that can also do joins and graphs. And there're also "true graph-dbs" for index-less "joins"/traversals, like neo4j and orientdb, for when the relationships for when you actually end up doing more than 3 to 4 levels deep joins...
Imho the development of "high-end rdbms" like postgress and oracle has been a huge waste of human brainpower and all the benefits supposedly provided by these pieces of technology were actually from the clever app-level code that mostly worked around their inappropriateness...
I was not referring to document databases as a whole, just to MongoDB in particular. You can use PostgreSQL as a document database. I heard too many stories with Mongo where people were dealing with locks or broken data instead of solving their business problems.
<quote>All because I was bored of the old tech.
and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that.</quote>
I think the blame would logically reside with you.
>It was early 2013, when we adopted Go as a default language for all our server side (micro or not) services. (...) The reason for the move were few: 1) Ambivalence on Java roadmap
So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 year old language with tiny adoption compared to it (outside of echo chambers), an arbitrary roadmap as set by the core team which might involve anything coming the time for a 2.0 release, and whose majority of development depends on a handful of people Google pays their salaries?
Lets just put it this way, I bought onto the basic proposition which was offered, after having read Rob Pike's original blog introducing it, and having watched lots of Go team videos. Some points which also went into decision making:
1) I am not a functional language programmer. No disrespect, just stating fact, after having noticed a Lisp programmer having questioned my choice regarding "boredom". So languages like Lisp, etc were out, and had to look for a C like language.
2) My boredom with Java was also because of years of using, YMMV ofcourse. Also we were seeing issues in containers we hosted on, and that entire deployment paradigm seemed liked that of 2000s. As I said, in another reply, thankfully I had the luxury to choose, which is often missing in Enterprisey setups. And my co-programmers were also excited about it.
3) One thing which I forgot to mention in my parent comment is channels. It really appealed to me as a model, compared to the Barrier style of programming in Java's util.concurrent. We use that feature heavily in our now migrated Go services, and its ultra stable.
4) At the time of the switch, I wanted to move to a more bare-bones language, which is C-like. So did some benchmarks with C, C++ and Go. And Go was found to take a little more memory than C/C++, C was the least. But it was good enough. And as a successful validation of the move, I have been able to recently move to AWS compute instances from the standard instances (m3.large -> c3.xlarge to be precise). So we are getting more compute power, by paying roughly equal, because of lower memory requirements.
So I made due effort to find the right language, outside the "echo chambers" you see. And this "echo chamber" is also not so actually, honestly speaking, I learn a lot from guys like you on a regular basis :-)
If everyone thought this way, our realistic professional choices of languages would be C, C++, and Perl. The exact same things you're saying about Go were things people said about Java --- a language, by the way, with much more harrowing ownership issues than Go, which is an open-source project top-to-bottom.
What do you feel are the much more harrowing ownership issues? If you google 'goroutine leaking' you get a pile of convoluted stuff. I don't mean to language-war, if anything I find 'stuff proponents and detractors said about Java in its early days' eerily similar (and likely as overwrought) to the same said about Go now.
If you took those away not to mention the message it would send to everyone would be enough to put the language in a death spiral. Good luck convincing management to use a language that even Google abandoned.
- Do all opensource projects require corporate sponsorship to be viable?
- Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support?
- Does Java, being under the control of Oracle, present a better option?
- Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use.
The Go code I write and compile today will continue to work for a significant period of time. If Google stopped paying the committers, this would not change - the language may not evolve, but this is a minor concern on a project of Go's popularity.
Some businesses still rely on COBOL and Fortran, but those are not exactly evolving either.
It is not FUD. It is a factor to consider, especially if you are thinking of creating mission critical software. There is no doubt that Google has plenty of form in killing projects, some of which were quite popular and/or highly visible. After all what percentage of Google income/infrastructure depends on Go? I presume it is really, really tiny and could become a casualty in corporate politics.
I personally think it is highly unlikely that Google would kill Go, but I do think one has to consider the possibility before betting the farm.
We're talking about decisions to adopt a language, so FUD and especially "uncertainty" is a very important factor to consider. This is not 1999 and Microsoft badmouthing Linux.
>Do all opensource projects require corporate sponsorship to be viable?
Not all of them, but a lot of them do. Especially languages. Even something like OCamL needs Jane Street and that french university a lot.
Go is not setup as even a 50-50 internal/external community. While the long tail is, well, long, the majority of commits and all of the steering is from Google devs.
>Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support?
Rust has Mozilla and lots of paid programmers (all the core team for one). Without it, it would have gone nowhere.
Python and Ruby had had corporate sponsorship themselves too, but they have been far more organic (grass-roots) open source communities than Go from the start.
>Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use.
Devs/Teams using F# are extremely few and far between compared to any established language such as C#, Java, etc. We're talking probably 2 orders of magnitude or more.
>Some businesses still rely on COBOL and Fortran, but those are not exactly evolving either.
Fortran is still evolving actually. Also Fortran and COBOL have been always mostly based on commercial compilers -- not community efforts, because that's how stuff worked back in the day.
And it's not like people write green projects in COBOL -- they just rely on it because they have huge important codebases that are 40-50 years old.
Tons of open source projects faltered and died when they lost core contributors. The core will remain open source and available, and you might even see a few commits here and there, but that will be it.
Go for the most part is written by a small team of paid contributors -- it's not certain at all that if they went away, other people would step in their shoes.
I don't think it would immediately kill it. If Google abandoned Go then given it has only a few unique features it would likely fall in amongst the hundred other second-tier languages that are around today.
It is pretty inarguable that a large part of Go's success has been it's affiliation with Google.
Ha. I built my first company on Java back in 1996. It was a terrible decision. Very buggy, lots of BS from Sun & Oracle that was really more about Ellison and McNealy envying Bill Gates. Netscape made a similarly bad decision when they tried to create a pure Java version of the browser.
I'm sure Java is 10x better now, but I'm not convinced it will be here in 2100.
I don't think there's any 85 year old Cobol though. Most of the S&P 500 is less than 50. It's entirely conceivable the companies that embrace new technologies starting today will, within 50 years, extinguish or acquire most of the of the companies using technologies from 1995.
1995? Are you sure? I started studying maths and computer science in 1993 and Cobol was ever only mentioned as a remote curiosity. I remember Pascal, Perl and C/C++ were common.
Yes but it was still dominant in terms of actual code in production. I remember working at a consulting firm then and we had a ton of work in Cobol and JCL. Banks in particular but also telecom.
Client-server 4GLs were really starting to take off -- PowerBuilder, Visual Basic -- but those got washed away with the web.
Yeah, where the owner is suing one of those multiple implementations, and playing silly buggers with J2EE certification. That really lends a fuckton of conifidence.
> 1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code.
Obligatory plug - if you're sick of writing out the struct definitions yourself, you can generate them from sample JSON: https://github.com/ChimeraCoder/gojson
This is especially useful when implementing REST servers/clients, because you can simply include an example JSON response which your tests use, and then use `go generate` to autogenerate the struct. Since they're both based on the same file, you don't have to worry about keeping them in sync - if there are any changes to the response structure, you only have to update it in one place.
I've used gojson several times and highly recommend it. Originally I'd planned to make the tool myself but found you'd already created precisely what I envisioned!
4) is actually quite important. People wonder why PHP is so popular, and it's because the deployment overhead is tiny compared to, say, Tomcat. Especially on shared hosting.
honestly I have hard time comparing go to java and finding any valuable reason to switch from one to another.
Go in my opinion was not mean for writing large/distributed web applications. But instead for writing tools (and fits very nicely in that space) and therefore replace C code base.
If I had to write something like docker, go of course would be a natural choice for it. But If I had to write the next big social network, well Java would be the natural choice.
Java has a much larger community, libraries, tools, ide and a whole ecosystem that makes Java and JVM a solid platform for writing application at scale (large team, large code base).
MAYBE. But maybe not: what if your app has a Javascript based rich client, and the back end is primarily micro-services? Does Java still shine for that kind of a stack? (OK, I would still avoid C, but that's not saying much)
Go is a great language. Building REST servers in Go is a doddle and the related tools have obviously been designed to work well together from the outset which is unusual.
That said, I started learning D at about the same time as Go, and for some reason D has attracted me more. Possibly the C ABI compliance (I was doing some JNI work at the time).
One question that I haven't found the answer to yet though is how well Go apps perform for long running processes, eg weeks or months? Have there been any issues around memory usage or resource handling? Any need for restarts?
Go websites are essentially long running processes. I have several websites built in Go, all of them running for about 2 months already with no hiccups.
I have been running multiple instances of the same Go app on multiple servers without it ever crashing for about a year. The current uptime (since the last release) is about 4 months, no issues at all, and very low resource usage.
Have been using Go for the last few years, from backend, tools, and even complex scripting type of tasks (for things more than I would like to do in Bash). Start using Go for game development as sideline projects recently, it is fun.
Granted there are things I would like to see may not on the road map, but I am very happy with what we have now, the great tools, and the great community.
Keep up good work and looking forward to the future releases!
I would have used Go for an API recently until I found out the AWS SDK for Go isn't production ready. Libraries still have some catching up to do but will only get better with more time and testing.
I've been working on a huge monolithic project (for 1 person) for the better part of 2 years now. It is in PHP, but the backend segments ported over to various other languages like python, javascript(nodejs), and now to Go.
Having now developed 30 micro-services for Go, which all utilise channels and thus run much faster than any other language I used is just amazing.
Not only has my productivity increased majorly, but also my support time has rapidly decreased.
These micro-services which run in the background just work:
- With PHP they don't run out of memory or the database connection doesn't time out.
- With Python I don't get random crashes due to pool.map.
- With NodeJS I don't have to run multiple instances to get the speed.
I've looked at web frameworks like beego, gin, revel and others. But I'm waiting till something comes out that's more inline with what I have used with PHP. Something like slim framework.
If it ever does come out, it will give me the push to switch 100% to Go. Can't wait really.
I've never used Go before, so I went to the project's home page. There's an editing window on the home page with a sample program showing, and a few other programs available in a drop down list. I couldn't help but start playing with the language.
I wonder how much the simple presence of an editing window on a language's home page contributes to overall adoption of the language. It sure lowers the bar to "I'll just write a few lines of code and see how this language feels."
There's a section called A Tour of Go [0] which has a series of code samples with explanations. The last part of the introduction to the tour says a little about what they call the Go playground [1]:
"This tour is built atop the Go Playground, a web service that runs on golang.org's servers.
The service receives a Go program, compiles, links, and runs the program inside a sandbox, then returns the output."
I'm surprised to not see any mention in the comments about the biggest change coming in 1.6: the package vendoring mechanism. This has been a big missing piece for awhile and I'm glad they're addressing it in an official way.
I was super excited for the cross compilation abilities on Go 1.5 and now I have something else to be super excited for in Go 1.6, can't wait!
It would be a surprise to me, but we'll see. I haven't seen much discussion since the vendor experiment, weirdly. (But I haven't been looking, either.)
I've started working in Bioinformatics. The languages in use and libraries seem to by Perl/Python and some java. Except for the stuff that needs to be fast, then its C. Although I notice some movement to use Rust instead of C (having installed some C based tools having package management would be glorious).
It would seem the concurency model of go would be a great fit for a lot of those existing python/perl tools. My searchingg for projects show it hasn't really taken off in this domain. I might start rolling my own packages.
How is the package management in Go? Data structures and String manipulation? And is does that concurency scale across nodes (al la MPI)?
I'm a computational biologist that recently ported our webserver (genestation.org) from Tripal (PHP/Drupal) to Go. The performance gains were huge, but the simplicity of development and deployment was even better. I'd strongly recommend Go for a biology web server. However, Biogo is not remotely as far along as Biopython or Bioperl. Also, Perl beats Go for ease of string handling. Unfortunately, there is no equivalent to Numpy/Scipy in Go. Despite these areas of weakness in the ecosystem, I have switched to Go entirely except for one-liners and one-off parsing in Perl.
You said above you 'may start rolling your own packages'. If you're interested in helping develop the numeric ecosystem, please come join us at gonum https://groups.google.com/forum/#!forum/gonum-dev github.com/gonum.
Dan (the lead developer of biogo) is very competent and I'm sure would love bug reports and PRs in biogo as well.
Chado does have substantial performance problems for use as a webserver backend. We use elasticsearch for full-text search and as JSON document store, which improves performance substantially.
326 comments
[ 2.6 ms ] story [ 151 ms ] threadI am always confused by the push to make every language exactly the same by using the same paradigms and features. Some languages try to take a different approach. If you can't figure out how to work within that paradigm, don't use it. Your comment is akin to complaining that Haskell doesn't support an imperative style.
It is by design that Go does not have generics as the Go team have not found a design they feel works and they are unwilling to compromise the current design.
They may never.
Why not both?
Good luck; it's an autoantonym. In my experience, your usage is as common as many others, though.
More like: some paradigms and features have been proved useful, and experienced programmers ask for them in a language that lacks them.
And not indiscriminately, but usually only ask for them if that language is of a certain paradigm / family of languages were those things fit well with (e.g. few ask for immutability in Go, or logical programming in Javascript).
>Some languages try to take a different approach.
Yes, the wrong one.
>If you can't figure out how to work within that paradigm, don't use it.
A lack of a feature is not always a "paradigm".
Besides, by the same logic, every language is perfect as is all the time, and users and potential adopters should not ask for anything new.
The lack of closures in Java for ages is a strong counter-argument to that. Or the rejoicing by which people adopted "auto" in C++. And tons of other examples, besides...
>Your comment is akin to complaining that Haskell doesn't support an imperative style.
More like his comment is akin to complaining that Java doesn't have Generics (pre 1.5).
And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go.
If they find a way to introduce generics while upholding Go's other strong points (fast compilation being another), then great. But it looks like it's not trivial.
If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics. Your condescending remarks are entirely unproductive.
When it comes to computer science generics have been an accepted part of PL research for decades. The extra expression power they give and the paradigms they enable are neither controversial, not something that's up to individual tastes to judge.
Someone might not like them subjectively, but that's not different than someone not liking closures, or map or any other established thing. People will always have their preferences.
>I for one have spent the last 2 years using Go to build a very performant system which is used by thousands of Bitcoin day traders every day. It's fast, stable, and easy to modify. I have never felt held back by a lack of generics.
That doesn't prove it's not an objective issue, just that a specific use case, in a specific domain, didn't need it.
Or even more precisely, that a specific programmer didn't feel the need "held back" by their lack. Perhaps others would feel "pushed forward" by their presence.
For example, I mentioned Java above, who only got Generics after 10 years. Tons of far bigger Java programs than the one described have been created with Java-without-Generics (from financial services to automobile controllers).
All those projects weren't any "proof" that Java doesn't need Generics (and/or closures). Just that you can do without them too (which is true -- nobody argues that you can't).
Besides, isn't Paul Grahams whole "Blub" concept based on the idea that people using languages without X features have little means to understand their importance (and what they're missing)?
In any case, there are counter-examples to what you write too: several posts from teams that have used Go in production that say they like it but still lament the lack of generics.
>And yes, I've spent plenty of time using languages that do support generics. It can save you time but I've found it also enables "looser" code, which can be more error-prone. In fact one of my favorite things about Go is how restrictive its type system is. I feel a lot more confident about my code doing only what I think it's doing when using Go.
Generics are not "loose", if anything they're even tighter type-wise than what Go makes you do to overcome their absence. Either you create concrete types for everything, ad nauseum, or you go "loose" and use interface{} and the like, throwing a lot of assurances out of the window.
>If the language is not for you, move on. There are plenty of us who are perfectly happy to write code without generics.
Again, happiness doesn't say much -- that's personal preference and can't be debated.
Java programmers were perfectly happy to write code without Generics and Closures for like 15 years too. Most were even oblivious that those things existed in the PL world at large. Javascript programmers suffered without correct scoping or an import system for 20 years, etc.
The point is, plenty of companies manage to create very good production software with Go, without generics. I didn't mean to rest my argument on my personal anecdote. You can look to Google, CloudFlare, SoundCloud, Dropbox, etc. for reassurance.
If you have a suggestion on how generics would fit into Go, I think the Go team would be happy to read your thoughts: https://groups.google.com/forum/#!forum/golang-nuts.
May I guess you're either some old Lisp/Smalltalk etc veteran, or, much more probably, someone who entered IT after, say 2005?
Because back in the day very few thought of Java as "gross" -- it was greeted as a welcome change from the existing landscape which at its best was something like C++.
I guessed so, because back in the day (1995-early 00's) most devs outside of seasoned functional etc veterans (who were extremely few) or hardcore systems guys, saw Java in mostly positive light, and never considered it "boring" back then.
The change (for new devs to consider Java "boring" and lacking in features) happened sometime after 2005, with Rails entering, Javascript catching up, C# getting more features with 2.0 and 3.0.
(Consider than back then Scala, Go, Clojure et al weren't even started, and AJAX had just been made mainstream).
Programming language "research" and computer "science" research has been irrelevant in the sausage industry for about four decades.
It's just like complaining accounting refuses to use category theory.
I also write a little Go program every day as practice. If you want a sample of some Go. https://github.com/kris-s/daily-go
This is a common refrain amongst go proponents and I find it quite distasteful. It either implies those of us who prefer other languages aren't "getting things done" or those who feel productive in Go aren't smart/hard-working/educated/etc enough to "get things done" in other languages. I don't think either is true.
I think a more accurate way to look at Go is that the language, tools, and standard library make decent design trade-offs when your target software is 1) simple 2) network daemon-y or a CLI and 3) going to be worked on by a wide variety of developers. There are lots of problems that fall into that problem set, and it is very nice to have a language targeted at it, but Go is certainly not a good fit for a huge number of software projects. You will be less productive in those cases using it.
However, I guess the inability to deeply understand or pontificate about Go is an advantage in itself... forcing your only potential activity to be getting work done.
Also, are you sure that there are more popular Go projects than popular Scala projects?
The syntax perhaps. In reality there are a large number of concepts and idioms to learn on the never-ending road to really becoming proficient.
Take initialization for example: look at all the edge cases belabored in section 8.5 of the C++14 spec, or even the intricacies of initialization in a simpler language like Python. Now contrast this with how much lexical and conceptual space it takes to describe zero initialization in Go's spec: https://golang.org/ref/spec#The_zero_value
As in other areas, Go's approach here has downsides. (Possibly major ones.) But those tend to be conscious design decisions to minimize the total number of concepts and idioms present in the language.
JS is pretty damn tricky though, I'll give you that one.
It's subjective though. I'd guess that if you're a fan of the suckless style of engineering, go might be right in your wheelhouse and you will probably find it very beautiful if you can accept garbage collection.
Also, I don't understand the benefit of being able to learn a language in one day. You can learn how promises work in a single day and then apply that to any language that implements them. With Go, you will learn the language but then have to re-implement promises for every type that you have [0].
Consider the use case of issuing two API requests concurrently and assembling their results. You can do this using the fan-out, fan-in pattern described at http://blog.golang.org/pipelines
Search the page for "func merge". Any time you want to fan out and fan in, you will have to write that block of code for the types of the channels you have, or else use interface{} and lose type safety. So the cost of a language that can be learned in one day is that every single time you perform this very common concurrency pattern, you will have to repeat this code and potentially make errors in the process. And if you want to change how this merge pattern works across your codebase, you will have to change it in many places. What happened to DRY and reusability?
[0] There is a Go promises library, but it uses interface{} for all callbacks and does not appear to have been an active project over the past year. https://github.com/fanliao/go-promise
So, just like VB then?
gofmt, for instance, is uncontroversial. Taking the decisions about how to format code away from developers and standardizing it is widely seen as a win (a win Python flirts with as well).
Well, there's a lot of other things in Go that have been pre-decided for you, not just the formatting. The net effect is that you don't have to waste time:
* thinking about designing a DSL for your programming problem (DSLs in Go require parsers)
* designing a class hierarchy to express your programming problem
* choosing between event-loops and callbacks or pools of threads
* picking the right associative container library (do I want a red-black tree? a hash table? a trie?) for routine coding problems
These pre-decisions can feel confining, but I think for a lot of developers Go reveals that those decisions were usually a waste of time. When you actually hit a place where you need a red-black tree, it's not that big of a deal in Go to bring one in. You're just not going to do that for your session store or for a simple lookup cache --- which is, I think, what a lot of people who can't stand Go's lack of generics would be doing.
The problem, I have with the sentiment (which I grant is largely me over reading into it) is that a lot of the things people think of as noodling or a waste of time, are the central problems in more complex environments. Making sure your program is correct is very important in some environments. Making it easy to express complex domain knowledge as a subset of a programming language is a huge win in some environments.
That isn't a lack of getting things done, thats just more complex logic requirements.
But in C++, those are decisions you might make in parsing a config file, or in managing a simple table of sessions, or adding an LRU cache to something. You can't get away from the decisions. I have an array of stuff, and I have to decide, "do I want a list, an slist, a vector, or a deque, and what the fuck is a deque?". 98% of the time there is one sane decision that is so close to optimal that it's not worth tinkering with.
In Go, for prosaic, routine code, those decisions have been made for you. You have to go just annoyingly enough out of your way to second-guess those decisions that you almost never do, and you're almost always better off for not having to do it.
I'm currently working on a project (WebRender) in which we keep using the standard library hash table in the first cut of code whenever we need an associative lookup table, and every time we use it it keeps coming up #1 in the profile. Almost every single time. We then have to switch to another, more optimized data structure, and generics really help here so that we can reuse these data structures. In fact, if we didn't have them, we'd probably be sunk.
This just isn't as much of a big deal as people think it is. Go makes it a drag to use a custom container, but it doesn't make it hard, and that might be how it should be!
> This just isn't as much of a big deal as people think it is. Go makes it a drag to use a custom container, but it doesn't make it hard, and that might be how it should be!
I believe you that it wasn't a big deal in your case. But I disagree with your general claim. I think you're extrapolating from your use case to claim that generics aren't important (vital, in some cases). I'm saying that, in my use case, they are.
If the default doesn't work for some reason then I can tackle that problem but at that point it usually is core to the problem I'm working on.
For some people Go is anything but frictionless though. They spend all their time in Go fuming that their favorite abstraction isn't there. For those people my experience doesn't translate.
Otherwise, the go built-ins are usually the "get on with it" win.
It could just be the feeling that Go gets out of your way more than other languages do. (For example, people complain about how much ceremony is involved in writing Java. Go could easily feel like "getting things done" in contrast.)
What the heck are you talking about. Who uses Swift on this sort of scale? This is just one of the many MANY large companies using Go to power their core infrastructure.
Node is another technology I would put ahead of Go as far as adoption. Maybe Go will get better, to me, it's too different than a lot of what I see day to day with Java, C#, Python, JavaScript and on and on. The part I love about Go is that it handles garbage collection, other than that, it's atrocious looking C like code.
Then name any company using Swift to the level Dropbox uses Go, or retract your claim.
Go code looks nothing like C other than general brace styling. I can't decide if you're trolling or just genuinely this ignorant.
They still use Python if you read down the Twitter thread, but I can name so many more. Cloudflare for example.
The likely reason you see such a difference is that the languages are suited to different things. Swift for example is all but mandatory for iOS apps, and so this is not adoption but migration. If you're just looking for small freelance projects then I expect Go will be a long time coming, but if you're looking for large infrastructure work you'll find an awful lot of people very interested in Go.
I disagree. The one thing that makes Go code look more like C than other C descendants like Java, C#, JavaScript, Swift and even to some degree C++ is its error handling style. Having a seperate error value is of course a big improvement over C but visually the error checking code following many statements appears a lot like C.
And the second reason is that Go has pointers with a syntax modelled after C.
So in the eyes of the 90% or so developers who have been using mostly Java, JavaScript and C# for 15 or 20 years, Go has to look a lot like C.
> I can't decide if you're trolling or just genuinely this ignorant.
Stuff like this breaks the HN guidelines. Please edit it out of your comments when posting here.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newswelcome.html
How much more would you like me to blunt what I say in order that it doesn't violate unclear rules?
Any substantive point you have will become sharper once you edit such rudeness out, so it isn't a question of "blunting", but of being respectful. Even if you don't respect the person you're talking to, you need to respect the community by holding yourself to a higher standard.
>Apple has made it clear that you'd better learn Swift
Can anyone point to any statments to this effect by a leader at Apple? I haven't found any with a web search.
Who cares about adoption rate? Is PHP the best language to make websites because of it's popularity? Hell no!
I tell you what I care (and I know I will eventually pick Go for these reasons):
- concurrency - parallelism - stability - speed - community - libraries - proper use of hardware - small footprint
But at the end of the day, syntax is really just a superficial element of a language. Particularly when you're comparing Go with very syntactically similar languages such as Java, JS and C#.
I do welcome the breadth of choice we have in programming languages, but sometimes we get too caught up on the finites of one language of a particular sub-genre when compared to another language of the same sub-genre. Particularly when a good programmer should be more interested in coding good logic and thus understand the paradigms enough to swap between the different languages of the same ilk with relative ease.
Since the TensorFlow video post is currently on the frontpage as well...as someone who uses neither C++ nor Go (I can write FizzBuzz level of code in both and read both well enough to get what's going on) I have to wonder how much internal buyin Go really has at Google if the core of such a project is implemented in C++. It's a project they see as valuable in the future and it would lend itself really well to Go as these calculations are done distributed and yet they picked C++.
[I'm not sure how much of the old framework they reused but if the will to Go was really strong I'm sure that wouldn't have been an issue]
and if you watch Jeff Dean's video, he mentioned more front end in other languages, Go is the only example and as the interest from internal.
What are your company's official languages used for?
[Former Googler around when Go got it's start]
Go is not Erlang. Go supports green threads (goroutines) and offers CSP-like channels to communicate between threads. However, it does not have a distributed computing story yet (at least, not compared to Erlang, the usual Java frameworks, etc.).
For a library such as TensorFlow, Go is not really an option yet, for many difference reasons. E.g. the lack of parametric polymorphism makes it hard to parametrize code for single, double, or even half precision. Go does not support anything like expression templates, which exploit laziness to eliminate temporaries. Moreover, a lot of machine learning happens on GPUs nowadays. AFAIK, there are no CuDNN bindings for Go yet.
tl;dr: impedance mismatch
As far as I know, goroutines are NOT green threads (threads managed by run-time environment instead of OS). Go produces native code (no VM). And, the goroutines can be multiplexed (depending on implementation) to OS level threads.
Green threads can be managed by a runtime library or VM, so no VM doesn't mean no green threads.
> the goroutines can be multiplexed (depending on implementation) to OS level threads.
Being multiplexed onto OS level threads is normal for green threads. Goroutines are "hybrid" (M:N) rather than "user-level" (N:1) threads, but anything other than 1:1 native threading means that you need a runtime or VM managing it, and its a kind of green threads.
I don't know that I'd say "just": like Erlang processes, goroutines have some special features not shared by all other green threads, even with a similar M:N threading model. I'd say that Erlang processes and goroutines are each specific kinds of M:N green threads with unique features and distinct names. So, its useful to distinguish them within the broader category, they just shouldn't be distinguished from the category.
I prefer C99. A smattering of features I like:
Some of the meta-"features" I like: I'm sure Go is a fine language. I probably suffer from some sort of first-language bias as I've been using C for a long time and only know a smattering of Go from toy programs, blog posts, and reading the source to interesting projects like CockroachDB.1. Variable Length Arrays: Go has slices 2. Anonymous Structs: Go has these 3. No built-in runtime (in C): This is not true unless you are compiling -ffreestanding -nostdlib, etc. I have done this in C, but such programs have to call system-calls directly and provide their own malloc, etc.
- Gorp[1] for SQL stuff (I like that it "encourages" your program data structure to reflect your DB structure) - amber[2] for templating - gorilla/mux[3] for routing - gorilla/securecookie[4] for login/auth management (they have a sessions and context library too if you want that)
Go also has libraries that handle basic versions of most of these tasks (and these third-party libraries extend them). If you're building something simple they might be sufficient.
[1] https://github.com/go-gorp/gorp [2] https://github.com/eknkc/amber/ [3] http://www.gorillatoolkit.org/pkg/mux [4] http://www.gorillatoolkit.org/pkg/securecookie
Maybe it's personal preference, but there's something more satisfying about the modular approach of building up an app using only components I need and understand, rather than starting with a magical feature-laden framework but quickly realizing you don't need half of what it does. I think Go aligns particularly well with this philosophy given its emphasis on composition.
Not to mention that since goroutines cannot be forcibly terminated, it's the only way to control the lifetime of a handler (e.g. applying timeouts).
It's much more useful to read a competent critique of Go (of which there are a couple) than post after post saying how everything is great. Everything can't be great, it's a basic fact of software engineering!
So a master woodcarver works with chisels, his "tools", for his entire life...30 years, and with them he turns bare wood into incredible works that the world recognizes as valuable art.
Someone hands him a chainsaw, which by all measurable metrics should allow him to do the work 10x faster because, of course, it is more powerful, modern, and designed by "superior minds" whom understand IC engines, gearing, etc etc.
Does it? And should he switch?
Every time I peak into the source of a standard Go package, I'm blown away by how clean and simple the code is -- and it's a fantastic way to gain a deeper understanding of the language.
That has mostly not been my experience diving into std C library code, or quasi-standard stuff like boost...
Oh and compared to Go, I always point to sorting in Go. Just look up the library. I think it's awfully complicated, compared to JavaScript where you simply pass a comparator function. In Go you need a lot of lines to achieve the same thing.
I didn't realize how much I disliked JS playing "loose and fast" until I used Go with its rigidity.
In the beginning, those Node.JS codebases were clean and manageable. Then came bug fixes, changing requirements and refactors. 2 years worth of that led to something that was quickly becoming unmanageable.
But then came Go and, after a rewrite, everything was clean again! It doesn't matter than the code base is only 3 months old, I'm sure it's going to stay this clean forever!
But hey, should those Go codebases become messy a couple of years from now, I'm sure Rust will have matured into a worthy successor and, after a rewrite, we'll all have the cleanest codebases ever!
Its incredible how much easier things get when you need to refactor if you have types.
[1] https://en.wikipedia.org/wiki/Roast_(comedy)
Then you could, for example, browse the ed column of birthday wishes & happy usage stories of Go, say on the left hand side, and then also, scroll through the op-ed right column of dissenters and critiques.
There's just something very disheartening about having a bunch of "anti X" dominating what you were hoping would be a discussion of "X"; downvoting is certainly not the right solution -- it's fine to be anti-X, it just needs a little bit of its own space.
My idea is different, though -- the essence is
(1) you'd self-tag -- imagine clicking 'in support' or 'in opposition' to comment.
And then (2), those two different sets of comments would go into different parts of the page.
Maybe a two-column view? Maybe separate pages?
Basically, conversations in a single-section format like HN are constantly getting overrun by criticism. Criticism is interesting and has its place, but it tends to be noiser, and it's disheartening when it's getting in the way of something you want to be excited about.
Back in 2009 #go-nuts seemed to be a much different place.
I write Go at work, and I admire many of the same things in Go I admire about Python.
I still wish generics were part of the language and will say their excuses about not being able to do it in a performant way seem to just be away of avoiding the subject.
Ocaml for instance, has a performant generics implementation.
Sometimes the Go community can have an anti-programming language research and anti-intellectual feeling which can be annoying, since in addition to Go I write a good amount of Haskell.
The tooling is nice as people say, however I think more maturing of the platform needs to be done. It's also never talked about how much slower Go's claim to fame of fast compilation got much slower after the 1.3-1.4 switch to a compiler totally in Go. In all fairness, I could be wrong about the last one since I haven't benchmarked it... but I can say it feels much slower than it was around 1.1/1.2.
Concurrency in Go is easy, however I feel like many erroneously think that channels or concurrency primitives like it only exist in Go. There are other languages with rich concurrency and parallelism options as well.
Using lots of interfaces and casting everywhere gets on my nerves since I like to have the strongest guarantees possible via static typing.
Overall though, I can't say I've had a bad experience with Go. I can say it feels like I'm using an okay tool (great in some places) with maintainers who put their hands over their ears to potential improvements (see the generics proposals over the years).
But yes, good point. I think a better type system should handle it and make it harder to drop errors on the floor. But that kind of asks for Rust's like sum-type which is too close to generics for their comfort.
I got around it by coding down to syscalls and allocating a goroutine to a simple poll() loop.
CSP via goroutines and channels is idiomatic Go, but it's not the only option. Go offers mutexes and other concurrency primitives which, along with goroutines as lightweight thread analogues, allow what you're looking for.
Locks exist, but you can't create a synchronized data structure. You can't create your own channel type because that's a generic thing which is reserved for the language authors, not the language users.
The whole point of modern programming is to create useful abstractions that allow a programmer to get things done without having to worry as much, and concurrency-related abstractions like parallel map-reduce and actors are powerful, but you have zero chance of making an abstraction for that in Go.
In Go it's basically CSP or bust; saying "you can use locks" is not an answer; locks are not a way to handle concurrency, they're a primitive for shooting yourself in the foot if you're unfortunate to be in a language where you can't abstract them away suitably.
type MyChannelType chan MyStruct ?
Are there other nice ones out there? Good to know...
Nobody can argue that generics in Go isn't extremely useful. After all, you couldn't have typed channels without generics. One has to be pretty obtuse to argue that the utility afforded by Go's internal generics wouldn't extend to the language as a whole; that somehow Go's standard library needs to be special.
If you look at the standard library, its authors had to jump through some serious hoops in many cases. Packages like "reflect" (the megatype Value), "builtin" and "sort", to pick a few, are a graveyard of typing awkwardness. The sort package and its special function just for sorting strings is practically a written confession.
Generics being a speedbump is an argument I haven't heard before. Can anyone comment on what the performance challenge is? Nim instantiates unique concrete type instances based on their parameters, couldn't Go do the same?
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX...
I wonder how the situation compares to Swift, Rust and Nim, three recent languages that have managed to implement generics without (as far as I know) a single complaint, and without descending into C++ madness.
1) Ambivalence on Java roadmap, in my understanding (gradual build up, since after the Oracle's Sun acquisition). Even the earlier clean java docs, suffered from Oracle branding efforts. Downloading older versions were confusing via a long chain of navigation between sites.
2) Boredom after nearly a decade with Java programming.
3) Memory usage of Java in our conditions was much higher compared to other languages (C, C++, Go)
4) Not Java's problem, but whenever one thinks of hosting a HTTP service in Java, thinks of using a container (e.g. tomcat, jetty, Jboss etc.). Go seemed to have made making services very easy. Its possibly just a perception issue, but its there in my experience.
So we wanted to move, and Go looked stable at the time from all my HN readings. C was too bare bones(even string handling was a pain to me, after a gap), and even C++ would not have matched some of the things which Go has inbuilt. Few examples:
1) Json/XML parsing is the easiest with no work (or minimal) required, you can just have the field names capitalized (or use stereotypes) and it gets done, with a line of code.
2) Great HTTP client and server libraries, which make very easy to write your own standalone services, as well as write http crawlers. (I am quite excited that Go 1.6 will have HTTP/2 support for both, as per this birthday blog).
So, in nearly three years of usage, with largely no regrets[1]. It is what they say it is: a bare-bones, fast (both compile & run) and stable (hardly get any errors after you have coded stuff, one of the stablest programming paradigms in error handling, etc).
Thank you, Go team! Hoping to use it for many years, as default server side language.
[1] Some of the 3rd partly libraries, we use are still not ported over to Go. They have Java, C++/C versions.
What size team are you working with, that you were able to switch from Java to Go?
*
*
*
*
*
*
* *
* * * *
* * * * * *
(2) (1) (3) (4) (5) (all others)
Just to push a counterpoint, I never understood those startups with foosball tables, sponsored beer, team workaholidays on tropical islands but god forbid the work itself is any fun.
If a technology choice makes people enjoy their work more, learn new things, help them think differently and thus get more creative, then isn't that a big plus? Sure, maybe it does not weigh up to whatever downsides there are, but it counts! The whole idea that "fun" isn't allowed to be an important argument in a business decision feels horribly outdated to me.
* Mysql to MongoDB * PHP to Python * Javascript to Coffeescript
All because I was bored of the old tech.
and it made the site unmaintainable. I mostly blame the MongoDB and Coffeescript for that.
Now to be fair, I learned a ton and I am so glad for that experience, but I lost my website.
Here's another exmaple for you: Over the years, the project I work on has used the following:
vb .NET C# .NET
WCF asp Webforms MVC2 MVC4
The result is a maintenance headache (it's not a nightmare, but we do have to pause every time we unexpectedly encounter VB!), and that's where we've been disciplined enough to stay within the MS/ASP stack. Had developers been allowed to really go off-piste then we no doubt would have even more choices, and as a result be even less maintainable.
Yes, you might not be attractive to a certain subset of programmers if you are seen to be not using a trendy new language or framework, but there's the other side that by often switching you are left with a long laundry list you need to satisfy when you're recruiting so they can maintain the older parts. We already don't require vb experience, and we expect that people can pick it up well enough to maintain it, but a side-project in "go" might seem fun now, but if it becomes part of the business then you might find that in 5 years you have to take a bad choice in recruiting because otherwise you're left without anyone who can maintain that application.
I came to PHP late from proper languages circa 2008/2009ish been programming since I was a kid in the 80's, I've no great love for the language, it's purely a tool and once you ignore the rusty bits it's not a bad language for a lot of web stuff but I've never been concerned with purity/beauty for it's own sake I just care about what I can do in a language, these days I use PHP a lot on the web, Python for just about everything else (even my build system for automating browserify is in Python using Envoy) and I play with Go and such on the side.
All that and there is a lot of work in PHP clearing up after others (if you like those kinds of engineering problems which I do) which is also nice.
Heck, even for advanced analytics, I find mongo aggregates and mongo map reduce 10x more intuitive and SQL that inevitably ends up using zillions of non-portable tricks, stored procedures and god knows what. And atomicity and whatever else transactions guarantee you in theory can be easily emulated with some good db structure design tricks and app design tricks in practice.
And the smarter a RDBMS is, like Postgres, the more dangerous it becomes for maintainability: it's a zillion times easier to maintain 'logic expressed in app code' (because you have basic stuff like version control, tests and so on), than 'logic trapped in the db' (good luck explaining to a new developer how "X automagically happens because of trigger Y and stored procedure Z, so there is no app code for X that you can instantly tweak to change how it works"). This is why I at least have some respect for mysql: it's retarded enough that it forces you to put the login in the code, where it f belongs!
Really, give me a dumb document db like mongo any day! And if I want something "less dumb" there're things like arangodb and rethinkdb that can also do joins and graphs. And there're also "true graph-dbs" for index-less "joins"/traversals, like neo4j and orientdb, for when the relationships for when you actually end up doing more than 3 to 4 levels deep joins...
Imho the development of "high-end rdbms" like postgress and oracle has been a huge waste of human brainpower and all the benefits supposedly provided by these pieces of technology were actually from the clever app-level code that mostly worked around their inappropriateness...
Not just boredom but Java induced boredom. In case of Java boredom is symptom not the essence.
So, because there was some "ambivalence for the Java roadmap", a language with multiple implementations, a huge community (including open source), and so entrenched in the industry that will be there in 2100 too, you switched to a 3-4 year old language with tiny adoption compared to it (outside of echo chambers), an arbitrary roadmap as set by the core team which might involve anything coming the time for a 2.0 release, and whose majority of development depends on a handful of people Google pays their salaries?
1) I am not a functional language programmer. No disrespect, just stating fact, after having noticed a Lisp programmer having questioned my choice regarding "boredom". So languages like Lisp, etc were out, and had to look for a C like language.
2) My boredom with Java was also because of years of using, YMMV ofcourse. Also we were seeing issues in containers we hosted on, and that entire deployment paradigm seemed liked that of 2000s. As I said, in another reply, thankfully I had the luxury to choose, which is often missing in Enterprisey setups. And my co-programmers were also excited about it.
3) One thing which I forgot to mention in my parent comment is channels. It really appealed to me as a model, compared to the Barrier style of programming in Java's util.concurrent. We use that feature heavily in our now migrated Go services, and its ultra stable.
4) At the time of the switch, I wanted to move to a more bare-bones language, which is C-like. So did some benchmarks with C, C++ and Go. And Go was found to take a little more memory than C/C++, C was the least. But it was good enough. And as a successful validation of the move, I have been able to recently move to AWS compute instances from the standard instances (m3.large -> c3.xlarge to be precise). So we are getting more compute power, by paying roughly equal, because of lower memory requirements.
So I made due effort to find the right language, outside the "echo chambers" you see. And this "echo chamber" is also not so actually, honestly speaking, I learn a lot from guys like you on a regular basis :-)
edit: typo
As opposed to the brilliant stewardship of Larry Ellison?
Besides even if Larry said "kill it" tomorrow, Java would still survive -- so much that it's used in all kinds of enterprises.
If you took those away not to mention the message it would send to everyone would be enough to put the language in a death spiral. Good luck convincing management to use a language that even Google abandoned.
- Do all opensource projects require corporate sponsorship to be viable?
- Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support?
- Does Java, being under the control of Oracle, present a better option?
- Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use.
The Go code I write and compile today will continue to work for a significant period of time. If Google stopped paying the committers, this would not change - the language may not evolve, but this is a minor concern on a project of Go's popularity.
Some businesses still rely on COBOL and Fortran, but those are not exactly evolving either.
I personally think it is highly unlikely that Google would kill Go, but I do think one has to consider the possibility before betting the farm.
We're talking about decisions to adopt a language, so FUD and especially "uncertainty" is a very important factor to consider. This is not 1999 and Microsoft badmouthing Linux.
>Do all opensource projects require corporate sponsorship to be viable?
Not all of them, but a lot of them do. Especially languages. Even something like OCamL needs Jane Street and that french university a lot.
Go is not setup as even a 50-50 internal/external community. While the long tail is, well, long, the majority of commits and all of the steering is from Google devs.
>Do Python, Ruby, even Rust have corporate backers that cannot widthdraw support?
Rust has Mozilla and lots of paid programmers (all the core team for one). Without it, it would have gone nowhere.
Python and Ruby had had corporate sponsorship themselves too, but they have been far more organic (grass-roots) open source communities than Go from the start.
>Many business are using VB, C# and F#, which Microsoft owns. F# especially could be abandoned, but it continues to find new use.
Devs/Teams using F# are extremely few and far between compared to any established language such as C#, Java, etc. We're talking probably 2 orders of magnitude or more.
>Some businesses still rely on COBOL and Fortran, but those are not exactly evolving either.
Fortran is still evolving actually. Also Fortran and COBOL have been always mostly based on commercial compilers -- not community efforts, because that's how stuff worked back in the day.
And it's not like people write green projects in COBOL -- they just rely on it because they have huge important codebases that are 40-50 years old.
That's not the case with Go.
Not all (Yehuda and me, Huon), although both of us have been paid by Mozilla at some point in the past.
Go for the most part is written by a small team of paid contributors -- it's not certain at all that if they went away, other people would step in their shoes.
It is pretty inarguable that a large part of Go's success has been it's affiliation with Google.
I'm sure Java is 10x better now, but I'm not convinced it will be here in 2100.
Profitable code dies hard.
It is the lingua de franca of enterprise software development. In every sense it is the modern day Fortran/Cobol.
Client-server 4GLs were really starting to take off -- PowerBuilder, Visual Basic -- but those got washed away with the web.
That says something about the language to me.
You have a point but they seem pretty happy with their choice.
I believe that happy developers are more important than the tech stack.
dBase III derivatives.
4GL languages.
Yeah, where the owner is suing one of those multiple implementations, and playing silly buggers with J2EE certification. That really lends a fuckton of conifidence.
"2) Boredom after nearly a decade with Java programming."
Obligatory plug - if you're sick of writing out the struct definitions yourself, you can generate them from sample JSON: https://github.com/ChimeraCoder/gojson
This is especially useful when implementing REST servers/clients, because you can simply include an example JSON response which your tests use, and then use `go generate` to autogenerate the struct. Since they're both based on the same file, you don't have to worry about keeping them in sync - if there are any changes to the response structure, you only have to update it in one place.
/me tips hat to you :)
Go in my opinion was not mean for writing large/distributed web applications. But instead for writing tools (and fits very nicely in that space) and therefore replace C code base.
If I had to write something like docker, go of course would be a natural choice for it. But If I had to write the next big social network, well Java would be the natural choice.
Java has a much larger community, libraries, tools, ide and a whole ecosystem that makes Java and JVM a solid platform for writing application at scale (large team, large code base).
That said, I started learning D at about the same time as Go, and for some reason D has attracted me more. Possibly the C ABI compliance (I was doing some JNI work at the time).
One question that I haven't found the answer to yet though is how well Go apps perform for long running processes, eg weeks or months? Have there been any issues around memory usage or resource handling? Any need for restarts?
Have been using Go for the last few years, from backend, tools, and even complex scripting type of tasks (for things more than I would like to do in Bash). Start using Go for game development as sideline projects recently, it is fun.
Granted there are things I would like to see may not on the road map, but I am very happy with what we have now, the great tools, and the great community.
Keep up good work and looking forward to the future releases!
Having now developed 30 micro-services for Go, which all utilise channels and thus run much faster than any other language I used is just amazing.
Not only has my productivity increased majorly, but also my support time has rapidly decreased.
These micro-services which run in the background just work:
- With PHP they don't run out of memory or the database connection doesn't time out.
- With Python I don't get random crashes due to pool.map.
- With NodeJS I don't have to run multiple instances to get the speed.
I've looked at web frameworks like beego, gin, revel and others. But I'm waiting till something comes out that's more inline with what I have used with PHP. Something like slim framework.
If it ever does come out, it will give me the push to switch 100% to Go. Can't wait really.
Any public code examples ?
The stdlib with a couple convience functions really is quite good.
http://www.gorillatoolkit.org/
https://github.com/gorilla/
I wonder how much the simple presence of an editing window on a language's home page contributes to overall adoption of the language. It sure lowers the bar to "I'll just write a few lines of code and see how this language feels."
More info here: http://blog.golang.org/playground
"This tour is built atop the Go Playground, a web service that runs on golang.org's servers.
The service receives a Go program, compiles, links, and runs the program inside a sandbox, then returns the output."
[0] - https://tour.golang.org/welcome/1 [1] - https://tour.golang.org/welcome/4
[0]: https://blog.golang.org/playground
Let's hope this becomes a trend!
I was super excited for the cross compilation abilities on Go 1.5 and now I have something else to be super excited for in Go 1.6, can't wait!
It would seem the concurency model of go would be a great fit for a lot of those existing python/perl tools. My searchingg for projects show it hasn't really taken off in this domain. I might start rolling my own packages.
How is the package management in Go? Data structures and String manipulation? And is does that concurency scale across nodes (al la MPI)?
Tripal I had never heard of. It uses "Chado" db schema which I have heard of (though flybase) which while flexible isn't always performant.
Performance gains and simplified development are so appealing (I have 12 tools to maintain in Java/perl/php)..
Biogo is what I was looking for. https://github.com/biogo/biogo
Dan (the lead developer of biogo) is very competent and I'm sure would love bug reports and PRs in biogo as well.
We're trying! https://groups.google.com/forum/#!forum/gonum-dev github.com/gonum . Bug reports and contributions encouraged.