We are writing/rewriting a lot of services at Timehop in Go. It's not quite as productive as programming in ruby, but it's surprisingly close (For simple services, anyhow) and its multiplexing characteristics seem pretty slick when you're used to using delayed_jobs in ruby.
However, if you do a lot of collection processing, you start to really itch for something like generics (Which can lead down some pretty interesting rabbit holes: http://blog.burntsushi.net/type-parametric-functions-golang). I think this is a pretty big feature to be missing, actually. I hope it comes soon in future updates. It's pretty frustrating to have to reimplement data structures that can accomodate custom structs.
But overall, it's very impressive, and a step in the right direction. I think we're approaching a golden age of programming languages, where syntax, expressiveness, and performance are all given equal seats at the table.
I am only a beginner in Go, but what I have done so far, I have loved. It's a great alternative to your typical scripting languages like PHP, Perl, Python, Ruby, Node, etc, etc, etc... And simpler and funner to use than C/C++ IMO.
It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go.
> It will tend to make a dent one program at a time - like etcd, docker, nsq. Soon, a significant fraction of your installables will have to be compiled with Go.
Only if commercial UNIX and Windows also get rewritten in Go.
> This was reason enough for C to get popular.
C got popular because UNIX was adopted by the enterprise and C was the system language.
(Don't know why I can't reply to the leaf nodes in the conversation...)
>What was taking its place at that time?
Pascal was fairly heavily used, but was dying out. LISP was hot because it was the middle of the Great AI Boom, Modula-2 was supposed to replace Pascal and be a systems programming language, and ADA was supposed to be the next great thing. Apple had created Object Pascal. Self was the big research language. Nothing really took hold until C++ in the latter part of the 1980s.
I might be off, but I think C still would have been popular. It's such a simple language, very easy to learn, easy to reason about, close to the machine but provides enough abstraction to easily write complicated code. C's merits as a language are self-evident beyond its usage in Unix. Of course, some other language with this set of properties might have taken C's role if it had not been for unix, so maybe that's what you meant.
> It's such a simple language, very easy to learn...
Mhm.
> ... easy to reason about...
So very much no. There is nothing about the stateful nature of C-programming, its syntax or the patterns people use that is easy to reason about. You're comparing it to what, exactly? C++? C is an amazing language but comparing it to the languages that were around when it became popular it's not even close to relatively easy to reason about. Even less so nowadays.
> provides enough abstraction to easily write complicated code
This strikes me as a weird thing to list in "pros". Complicated is the opposite of good. Abstractions should let you write simple code, not complicated code. I feel like you've either misunderstood the word "complicated", massively mischaracterized C or you have a very weird view on abstraction.
> Of course, some other language with this set of properties might have taken C's role if it had not been for unix, so maybe that's what you meant.
I'd like to point out that your assumption that people use programming languages because they are better than the alternatives is pretty naive. The most popular languages are decent, no doubt, but have you noticed how every really good language suffers from a pretty huge lack of users? We all know these languages are better, but it's never been an issue of "You're not good enough for people to use you".
If there was ever any indicator for a good language it'd be "What do people choose when they have the freedom, knowledge and opportunity to choose anything without any outside influence?". That scenario is so wildly scarce to observe and anyone who is in that situation likely suffers from biases acquired earlier on his programming journey.
I honestly think it will. Especially for high-performance applications it's going to start making serious inroads. Financial and scientific applications will start the trend and once some infrastructure and best practices get established, it will start seeping into the mainstream. Having a big name like Google behind it is a lot more assuring to businesses than hacker-driven projects like nodejs or academic-driven ones like Scala. Go is built for industry.
Takes me about 10-20% longer to do trivial things in go than ruby, but the results are much faster and bigger refactorings are also much faster to complete (nice type system). The ability to really max your perf out in short amount of time is also delightful
My experience with Go was bizarre -- I loved programming in it, but I don't understand why!
For example, Go has no REPL. (It's difficult for statically-typed languages to provide one.) It's commonly believed that a REPL is valuable and increases productivity. So if you were offered the choice, is there any circumstance in which "no REPL" is equally powerful as having one? Well, the vast majority of great hackers seem to agree that it's always superior to have a REPL than to be forced to live without.
Lots of people love programming in Golang (I especially love to write distributed systems with it!) yet it probably won't ever offer us a REPL. That must mean one of two possibilities are true, both of which are bizarre: either 1) we love Go in spite of being limited by not having a REPL, or 2) having a REPL isn't as big of a deal as everyone thought.
So I'd like to ask all of you: Do we love Go in spite of being held back by it? If so, then what are the factors that cause us to decide that using Go is worth giving up programming power? After all, each of us are choosing to use Go in lieu of more powerful languages. So why do we choose to give up programming power?
Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought? That seems plausible. It's at least as plausible as "it's a good idea to give up REPLs for static typing."
Go is wonderful to work with. But I'm so confused why it feels wonderful to me. I know I love programming in it, but once I start thinking about the implications, I start to wonder: Isn't giving up power a bad thing, and therefore choosing to use Go == choosing to be forever held back by its deficits, and therefore it's a bad decision? Or is it true that having every possible language feature available to you ("maximum potential programming power," i.e. as far above Blub as possible) isn't as big a deal as we all thought?
This pg essay talks about why it's worthwhile to have as much power as possible: http://www.paulgraham.com/avg.html (search for Blub Paradox) .... So either he's wrong, or we're ignoring him even though he's right. Which is it?
EDIT: There are other limitations besides lacking a REPL, e.g. there's no dynamic typing. It seems like we should try to figure out why it's a good idea to give up any programming power at all.
I see go as essentially a polished and robust glue language. It's not particularly well suited to data processing because its lack of functional constructs and generics makes transforming lists verbose, but it's perfect for wiring up databases, apis, system calls, sockets, queues, and the like in a way that's safe, performant, and concurrent by default.
Given this focus, it sort of makes sense why you might not miss a repl as much in go (though personally I do still miss it). Repls are most useful for exploring and experimenting with complex data, while I think go's focus is more on streamlining and bulletproofing all the machinery surrounding the data than doing a whole lot with the data itself.
I don't mean this as a criticism and I'm not trying to say that you can't do serious data processing in go, just that it's not a core strength like it is in functional languages. I think the majority of applications out there actually have fairly light data processing needs and heavy glue needs, so go's set of tradeoffs make it a great candidate for tons of projects.
> It's difficult for statically-typed languages to provide one.
No, it's not. As long as you have a way to polymorphically print a return value, which there are ways around (in Go, with reflection; in Haskell, with typeclasses; in Java, with Object's toString), there is nothing semantically difficult about a REPL for statically typed languages.
The main thing stopping Go having a REPL (when there are ones for C, for example) is that Go can't yet compile to, or load, dynamic libraries. This stops each bit of REPL being compiled up and executed, which would otherwise be simple.
Golang is like a touring car. It's fast, but doesn't have the fastest engine. It's got some nice features, and it's comfortable (at least for the driver), but it doesn't have every bell and whistle. But: the handling is amazing; it's a monster in the corners.
You could give a BMW M3 a faster engine, or a more full-featured Bluetooth sound system, but it's the way the steering wheel feels that makes people love that car. Same with Golang. They did an extraordinary job balancing the language, especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.
Normally, if I see a car analogy applied to programming languages (which hackers seem to do a lot), I instantly brace myself for petty debate on the semantics of the analogy itself (which hackers seem to do a lot).
This one is perfect however, and really explains my feelings towards Go (and recently, C, oddly enough).
>especially if you're the kind of programmer (a systems developer) that appreciates that kind of balance.
Go really failed to appeal to a lot of systems programmers, despite their intentions. Go is picking up people who used untyped languages and still didn't accept that static typing does not mean java. They finally have a simplistic statically typed language that isn't java to use.
This is more "Internet article of faith" than actual fact; it's something people say because it was said in some blog post once. For whatever it's worth to you, I've been a systems programmer since ~1995. The lingua franca of systems programming is C; Golang's type system is strictly superior to C.
It is more "direct observation" than "internet article of faith". I know one person who likes C and go. Every other go convert I know came from a scripting language. Golang's type system is strictly inferior to D.
Go makes it very easy to create tools on top of it. And its fast compiler enables doing things almost as if it's a dynamic language.
I've made a live editor [1] for Go that I use very happily (and I keep working on a 2nd generation version, rewritten in Go, which will be more user-friendly to install and use).
Statically typed languages don't necessarily not have a REPL, most functional languages are statically typed and yet they general have a REPL. OCaml, Haskell, F# and the like.
> Or do you believe in the other possibility: having a REPL doesn't matter as much as everyone thought?
The importance of REPL is very exaggerated. Neither Java, C#, C++ nor C have one (and together, these four languages probably make up for 95% of programming languages).
There is nothing that prevents any of these languages to get one (Scala has one, a bunch of these exist for other statically typed languages), it's just not that useful when you have powerful IDE's at your disposal.
Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.
The REPL and IDEs are somewhat orthogonal. IDEs are extremely limited in fact, as they can only rely on static-type info to infer meaningful stuff about how your software will behave. A REPL on the other hand is a runtime instance of your software that you can touch and interact with.
Btw, in regards to needing initialized state - code that can't be initialized easily, smells badly. And in Python and Ruby for example, you can stop the execution at any point in your software and initialize the REPL, having complete access to the current context.
In Ruby it's as easy as:
require 'ruby-debug'; debugger
In Python it's as easy as the following (add IPython to the mix for extra awesomeness):
import pdb; pdb.set_trace()
I'm working with Scala lately and doing the above is a little painful, but I still work with the REPL a lot, in spite of also using IntelliJ IDEA as an IDE.
It's true that Java, C# or C/C++ don't have a REPL, but that's why I don't use Java, C# or C/C++ (or Go).
Well, it's difficult to see what a REPL is or does, if you're calling Visual Studio's "Immediate Mode" a REPL. It's not. It can evaluate simple expressions, but you can't type arbitrary code in it and hence you can't do arbitrary development in it, so it's not a REPL.
The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.
> The closest thing C# has to a REPL is the Mono C# Shell, built on top of Mono's C# Eval and it's pretty cool, but it's pretty new and raw and needs Mono.
So what?! Languages and implementations are not the same thing.
So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.
Basically, I don't care what the ideal implementation for a language X might look like in 10 years from now, what I care about is (1) what am I able to do with it right now and (2) what's the community's culture like?
Lately I've been learning some Clojure. I'm fascinated by how Clojure developers work with the source-code. Emacs is an extremely capable editor, but for Clojure it's a full-fledged IDE and a shell for the REPL and it can do anything you'd expect from an IDE. And the whole workflow is basically typing code, sending that piece of code for evaluation in the REPL, typing in the REPL some quick invocations to see how it works, rinse and repeat. The learning experience is also completely awesome, as for some reason you end up reading a lot of the standard library's implementation - coupled with the REPL on the other side in which to quickly type what you read - the workflow is amazing (though Smalltalk developers are probably laughing at me right now).
> So languages are plagued with implementation-specific schematics and in truth, all languages grow up at the same time with their reference implementation and it's the reference implementation that defines that language.
Reference implementations only define languages that lack a proper ANSI/ISO/ECMA standard.
> though Smalltalk developers are probably laughing at me right now
Yes we are. :)
Emacs is a light version of a Lisp Machine. Now imagine how would your OS be, if everything would be as customizable as Emacs.
Sadly, Lisp machines and Smalltalk environments died on the mainstream.
> Most of the time I need REPL-like functionalities, I need it in the heart of my application, with all its structures and state initialized and in the middle of a breakpoint. I hardly ever need to type snippets of code with zero context around them, which is what REPL's offer.
This is why we Lisp developers have networked REPLs -- I can start up a remote JVM, in communication with other services, connected to my local vim session. I can dynamically load code into it, start and stop my application, etc, all from my editor.
That's a very large blanket statement right there. I code in five main languages Objective-C, Java, Python, Ruby, and a bit of Javascript. I do back-end web system type of dev work (Python, Ruby, JavaScript, Java) and front end UI (iOS, Android, and JavaScript (Backbone, Angular, Ember). I use Intellij and sublime as my ide/code editor. The most productive, easiest to use, and for me most fun to develop in environments are Django, Rails, Node, and front-end JavaScript. That is almost completely because of the application aware REPL. Django's manage.py shell command, Rails rails console command, and Chrome's dev tools are three of the most important developer tools I've ever discovered. I'd LOVE to find an iOS tool with the same power.
Also, the "Display" tab in Eclipse lets you execute random code while you are attached to a JVM via debugging, in the current breakpoint context - that is like 95% of a repl, imho. Many people don't know this one, and its very useful.
I routinely initialize quite complex states in the repl during development. If anything, it's even more important in that situation since it can often take a long time to get to that state-point in the program.
Like another commenter posted, REPLs are best suited for exploration. When you've got data and you're not quite sure what to make of it, or you want to do with it yet. IDEs, while also having their place, do not really fill that gap in any way.
I often find myself exploring in a language with a good REPL and then implementing the findings in a language that does not.
I constantly use REPLs to experiment, verify output of functions, etc. In the case of Go I open the Go Playground at least once a day, often much more.
Less is often more! I prefer the Go Playground over a REPL, especially since I can easily see others' code snippets running using the Playground's Share feature. My 2nd favorite thing about Go (after its runtime speed) is its compiler and excellent error messages that let me quickly realize what mistake I made.
Perl and PHP are also open source languages were people don't use repls often. Java and C# don't have repls either. I don't think everyone has ever thought they needed a REPL for any reasonable definition of everyone.
I don't think it's invaluable to the modern perl developer. I don't know whether I disagree with your concept of invaluable or your concept of modern perl developer or both. I tried searching "perl repl" on twitter and google to see if there's much talk about it and there doesn't seem to be much. AFAICT it just isn't a big part of the perl workflow, modern or not. Most of the people who like it could manage just fine without it. I don't think the same is the case with python or ruby. Some pythonistas and rubyists use the repl for everything.
I use small files instead of repls most of the time. There's no program that's too short to be stored in a file.
You don't really need a REPL when compiles take literally only a second or two. It's only the fact that C++ had a static type system where programs took (literally) hours to compile that made dynamic typing look so great in comparison. "Poorly designed static type systems drive people to dynamic typing," as Rob Pike said.
And yes, REPL is still helpful even if the compilation is fast; amusingly most languages that have REPL features fast compilation (at least those not based on JVM). The benefit of REPL is that it preserves state which one can experiment on, and sometimes that state can be cumbersome/take long to acquire.
Most languages that have "traditionally" shipped with a REPL don't feature compilation at all. So yeah-- I guess that's fast? (Before you start, I'm not interested in pedantic arguments about how any language can be compiled. I know.)
If it's "cumbersome" to acquire the state you need for testing, then that sounds like a design problem that you should fix. The best kind of tests are reproducible and part of a test suite anyway.
One of the languages that originally featured REPL, Lisp, was always compiled, both to machine code or byte code. Ditto smalltalk. I am not even sure which "traditional" languages you are talking about.
When I mentioned state, I did not mean testing. Sure, a properly designed system will have all it's computaional parts abstracted in a functional way so it will be trivially tested compiled or not. However, REPL is incredibly useful during the development process when the abstractions required are not yet clear, so it allows one to easily explore design possibilities without committing signficant effort of implementing a correct compilable module.
Dynamic typing has nothing to do with compilation speed. Furthermore, static typing is not orthogonal to dynamic; rather static type system is just another utility language on top of the actual language which helps to prove the correctness of the program. Such type systems can event be optional, see e.g. Clojure or Erlang.
On HN there's a lot of people who went from writing Ruby to writing Go. If all you have are a hammer and a screwdriver, everything looks like a blog post comparing the two tools you've tried.
Looks like Go is succeeding more in the space where scripting languages like Python and Ruby are dominant and less in it's original intended space (systems programming). Rob Pike has written about it too. I wonder if they see this as an opportunity missed or unexpected boon.
We definitely made a mistake at launch using the term "systems programming", because people automatically think of operating systems. What we meant were the kind of systems we build at google. Some of the examples in the blog post are "systems programming" in the same sense.
So we are pleased to see Go being used for the job it was designed for, but we are also happy to see that Go has a broader appeal.
> Go was clearly initially targeted at replacing C++ and it's not being successful in that area at all.
This is a strong overstatement. It's true that we thought more C++ programmers would be into Go, but it's also true that there more than a few teams at Google that have moved from C++ to Go, or chosen to use Go instead of C++ for new projects. It's not a black and white thing; there is no archetypal C++ programmer that does or does not like Go.
To reiterate: Go was designed for systems programming. People are using Go for systems programming. On top of that, there are many others using Go for other purposes. We're pretty thrilled about this.
I see that as an obvious mistake. C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution. The problem though is that C++ people likely aren't C purists to begin with, or that C purists are too into C. Compounded by those who only drop to C when needed, you begin to see why it failed initially in this segment. I do think it will continue to gain adoption, but linux is such a firm C membership club that it will either be painfully slow, or else require Go to play nicer with C.
> C++ is so different than C, and I imagine most C purists despite it. Go created a smarter C, and presented it as the solution.
I think it has nothing to do with the difference between C and C++ and everything to do with the reasons why people use C and C++: extreme performance, zero-cost abstractions, and integration with native libraries.
I think you are right, and I tried to convey that in my last two sentences but in retrospect worded it poorly. I guess what I was trying to say there is that people who "drop to C"(or for that matter, start in C) for performance reasons or compatibility reasons aren't going to consider a slower and less integrated language. This is probably most people, I'm not sure many people write everything in C regardless of task anymore(such as say, webapps).
I still think the initial part stands. C and C++ are not visually or mentally similar languages. Go is very similar to C in logic, so I'm not sure why it was expected that C++ people would flock to it(unless of course they weren't happy with C++, which brings us back to the first condition in that they were probably only using it for performance).
The Go team rightly point out that C++ is needlessly complicated. That is why I despise C++. (I guess I was spoiled by doing Borland ObjectPascal first, as well)
Go provides most of the benefits of the JVM without being as much of a memory hog. Thus, it makes it a nice replacement for somebody who would rather use Pascal/Modula than C++. (Java originally was seen by me as a Pascal in C++ clothing for Unix)
Go is more like a Modula (Algol???) variant with curly braces.
Mapping interfaces onto a funky function/routine call syntax (an optional parameter in a second set of parens for the "receiver"), and maintaining stack frames around a procedural type reference (closure) after the enclosing scope returns, are about the only new tricks.
I like Go, but it's too bad they didn't simply enhance FreePascal, if their main concern was compilation speed. Was it just a "Bell Labs" ego concern?
Or, was adding garbage collection that big a need? GC of course makes Go quite different from C++, so they should not be surprised if some "speed demons" refuse to convert over. (note that I hate C++, but can see the point of this aspect)
Well, I would argue that there's a level between "db replication infrastructure" type projects and OS kernels. That is the space occupied by things like database engines (everything from BigTable and descendants to Oracle), distributed storage engines (GFS and descendants) etc. I don't think I've seen a project in Go that aims to deal with that level of "system-ness" yet. And I suspect I know the reasons (why, say, I wouldn't write the packetzoom protocol stack in Go) but I'd like to know more about whether to Go team thinks it made the right choices in language and runtime design for a systems language.
There are a few Go databases mentioned in the blog post, and several more besides. Also there's weed-fs a distributed storage system (and at least one other whose name escapes me right now). I also think Go would be a great language for implementing a BigTable server.
Hmm... I did miss the line with groupcache and kv. Sorry about that. Though I still think you'd agree with me that go is not exactly killing it at that level of the stack (as opposed to the numerous examples of rather more successful usage at a level higher than that).
I think it's mostly a case of storage systems being a very core, important part of any software stack. If shit goes wrong at that level you're really screwed, so it takes longer to develop that kind of software and also longer for people to trust it enough to use it for serious things.
But there is plenty of action at that level in the Go community, and as distributed consensus libraries like go-raft mature it will only become easier to write and trust such software in Go.
I developed software system with hundreds of millions to a few billions data entries items in the core object store (C++) and need to very fast access time. There are needs to open/load/read those objects in database in very fast speed (< 0.01 seconds). When I profiled those operations in early version of the code, the biggest bottleneck is always the malloc/free when the system reached > 10 millions records.
To get around those limitation, I end up design the data structures / datastore that eliminated the malloc/free, new/delete and do my own memory manager to map all the info directly to the structure in the file via mmap and do my own sub allocations. With those, I can get everything in < 0.01 seconds constant access time regardless the size of the database. (from startup of the program to return the value to client.)
I think all modern day database or BIG DATA type system app depend on its own custom memory manager. My theory, a language that depend on garbage collection can not be used in those big data app design.
I love to be proven wrong by someone re-implement the mysql, (or even just sqlite) in "pure golang" (not sqlite driver in C) that can provide similar level of performance with golang's garbage collector compare to sqlite's C counter part.
The use case I care about is DB size of 0.1GB - 50 GB with hundreds of millions of records in the DB.
Go has mmap and casting via the unsafe package, so the go solution to your performance problem looks exactly the same as the c++ solution.
I'd say go is actually an ideal language for building a database because:
1) syscall's and low level io (including mmap) are all pretty much first class.
2) networking (duh)
Some final ramblings:
I realize "systems programming language" has lots of different definitions, some of which go doesn't meet due to it's stop the world gc. I'll concede that point, but as a parting shot let me remind you all that free'ing a tree of objects can cause similar pauses, although at a more convenient time. For me, I would assume that there are no guarantees in a database type system, you just want to go for something like: "99% of requests complete in less than a millisecond under certain controlled conditions". You never actually know if:
1) You have disk contention for that data you're reading causing pauses.
2) You've been swapped out and that pure in-memory operation slows down by an order of magniture
3) A billion other things.
For me personally, I don't really mind adding
4) The golang gc ran
To that list of things because benefits are worth the tradeoff, but that decision depends on the project.
I knew in theory one can use mmap and unsafe pointer in go.
One main different between C and go is this:
C can type cast any mmap pointer and de-reference it got the values (pointer, offset to other locations) extremely fast - < 0.01 micro-seconds (assuming page is swap in.) BTW, I do track C line code execute time nano-seconds resolution all the time. It is not difficult to do with RDTSC instruction. It gave you timing resolution in term of CPU clock cycles - 1 2GHz CPU clock cycle = 500 picoseconds, One can easily see the system paging and context switching info from those resolution.
In C code, that is only a few assembly instructions. In go (or other GC type language) that one operations is translate to multiple C functions calls. That's probably tens if not at lease hundred times different in pure CPU cycles.
When one has to do this hundreds of millions times, that usually makes huge different in overall execution time. I personally know a lot of test cases that means minutes to finished certain operations v.s. days (+GBs of RAM).
No, I found the term systems programming to be brilliant to describe the kind of things exactly between applications and operating systems, and I think the Go team did a good job communicating this from day 1. It just seems it was misunderstood (maybe even intentionally so) by detractors that focussed too much on their very own interpretation of the term.
Well, we have Android and ChromeOS, which are both Linux. While we do have a lot of people doing Linux kernel work, I'm not aware of any "green field" operating systems being built at Google. (Although I wouldn't be surprised to be wrong here.)
Most of the software we build at Google are server processes that talk to other server processes. Go was designed primarily for this role, but it is obviously useful for a lot more.
I want to like Go. There's definitely some parts that are great, but for a relatively new language there were missed opportunities to adopt awesome features in other PLs. There are also some internal inconsistencies that I find grating. These inconsistencies are particularly irksome given how opinionated Go is (and how much I agree with most of those opinions).
I went and looked up some of my notes back when I was trying out Go. I hope to learn from others wether these are real issues or simply my misunderstandings.
1. So we don't get generics, but the language built-ins seem to get to be type-parameterized (channels, slices, maps). Unfortunately the syntax for doing so for each of these is inconsistent (probably as a result of being special-cased rather than dog-fooded using language-level generics): []float, map[float]float, chan float.
2. Built-in types seem to receive other special treatments as well, which includes special initialization keywords (make vs. new) and built-in functions (len, cap, etc.) but I don't see why this needed to be the case, even for performance reasons. There's no reason why the these built-in types couldn't pretend to implement built-in interfaces to make more transparent with user-types while having the compiler optimize them with special-case functions for efficiency.
3. Unused variables are a hard error which is a completely understandable stance. Unfortunately, I think people may use workarounds to get around this. Also, I can't believe unused variables are a hard error, but uninitialized variables are not! Instead we are supposed to trust that everything is OK since they get initialized to some kind of "zero" value that isn't even under the developer's control.
4. Other small quibbles: I think pattern matching on function arguments could have been implemented as sugar that uses interfaces and method calls under the covers. Also named return values are ugly, and the function declaration syntax could have been made more concise.
I find a lot of the types quite annoying, like the byte arrays etc. I'm sure I'm missing out on the benefit but it'd be nice to have more human readable variable types. I also found passing JSON around inside it quite awkward, though I'm no doubt just being a bit thick.
I been using Go for a year now. Its hard to explain but for the most part I enjoy coding with Go. I could say i find it fun/enjoyable but that doesn't seem to convey the right feeling.
When using Go, I sometimes get the same feeling I get when using a well made drill, saw, or other physical tool. I would qualify it as "satisfying" -- the way it feels and how well it accomplishes the task it is designed for.
Like many well designed and well engineered things, I think familiarity and time cause that satisfying feeling to blend into the background and become the norm. You only realize the difference again when you have cause to use some other tool laying around (I just need to pound this nail I will just grab this random hammer laying here) and it "feels" different -- the weight is wrong or the grip is weird.
I by no means claim Go is perfect, but it seems to a great match for the kinds of things I tend to work on, and it "fits in my hand" rather well these days.
I spend about 30% of my time system side in Go, and the rest in Node.js. I'm working to migrate almost all of my time to Go. The language is fun to work in and, personally, the overall experience is much improved over Node.js. It's exciting to see the momentum behind the language and the great people who are attracted to it.
At a startup I worked for we used node.js prototype/sometimes v1.0 and Go for everything after. We shifted to writing everything in Go as we reach a point were we were more efficient from an effort standpoint in Go.
> "The state of the Go ecosystem after only four years is astounding. Compare Go in 2013 to Python in 1995 or Java in 1999. Or C++ in 1987!"
Wow! The state of C++ searches on google were 0 in 1987, as were searches for "Apples" and "Oranges" so go must be doing incredibly well to have infinity times the results!
Keith wasn't referring to the Google Trends chart. It is an unrelated quote about the state of the various languages' ecosystems 4 years after their release dates.
None of the languages being compared against were released in the ubiquitous-internet age with things like Github and widespread blogging to drive interest and adoption.
I don't think the comparison is supposed to be a value judgement of C++, Java, or Python. It's just an observation about how quickly the Go ecosystem has matured. Of course the internet played a huge role in this!
Well since Go made it's appearance in 2009 and C# in 2000, I wouldn't call that 'only slightly older', not even by programming language standards.
Beyond that, Go certainly doesn't have the same backing from Google as C# had from Microsoft, on the other hand Microsoft had a monetary incentive to provide support and tools/frameworks as they charged for those proprietary implementations while Google is giving Go away under a permissive licence.
Anyway, for fun I looked at the language poll made here recently on HN and compared C# and Go:
C# 1130 likes, 465 dislikes
Go 1126 likes, 365 dislikes
>None of the languages being compared against were released in the ubiquitous-internet age with things like Github and widespread blogging to drive interest and adoption.
Which doesn't seem to matter anyway. There are tons of languages released every year that fare even worse than languages released in 1980, despite having "ubiquitous-internet, Github and widespread blogging" at their disposal.
There are tons of languages released every year that fare even worse than languages released in 1980, despite having "ubiquitous-internet, Github and widespread blogging" at their disposal.
Those tools are force multipliers. If the initial force is zero, the output is still going to be zero.
What is your point here? This is a blog post celebrating the 4th anniversary of a programming language. Shame on them for being proud of what they created because other languages had a harder time?
Yes it does, the point is "Go's ecosystem has developed really fast" but maybe a (hypothetical) better language developed in this day & age would've reached the same point in 2 years?
With all due respect, I don't feel he is/was old enough to make such claims, as judging by his picture. Not saying that he is right or wrong, only the wrong person to make such claims.
Seems pretty far behind Java in terms of adoption. By 1999, virtually all new enterprise development was being done on Java. In 1997 Java was already #4 on the TIOBE language popularity index. Go isn't even close.
That's true. Java in the 90s was a spectacular con job that millions of developers and managers bought hook, line, and sinker. XML was pretty big back then, too, and now nobody gives two warm shits about XML. Just saying.
Anyway the hype is surely not the reason why anyone should use go. People should use go because it has good libraries, encourages good interfaces, is fast and space efficient, has good self documentation, is easy to test, etc.
Java can do stuff and people use it which is fine. The con was that it was inherently portable and secure and can be used for client software. None of that is true. Today if someone told me that our new client interface was going to be java that person would be reassigned to a role where their awful judgement would not resurface.
Java today is basically the slower edition of C++ which isn't that amazing of a niche.
It is inherently portable, because the bytecode can be run everywhere you have a JVM. You don't need to compile for every platform you wan't to run your software in, or muck around with cross-compilers. True, you can do plattform-spesific things in any language, but the Java standards library is almost entirely cross-plattform. In this way, Java really is as cross-platform as it gets.
The language itself is more secure. Buffer overflow? Forget about it. Undefined behaviour? Forget about it. Wierd stuff happening due to pointer arithmetick. Forget about it. Memory leaks? Forget about it, (well, almost).
Why can't it be used for client software? A JVM language can be used for anything that doesn't require minimal use of memory or short start-up time. Any program you write that will be running for more than 10 seconds and don't run in a memory strained environment, fits Java rather well.
Java is also easier to learn and reason about IMHO than C++.
Java today is the easier, safer, more portable but slower and memory-hungry edition of C++. Which is why there is a hype. Altough that hype is slowly dying, due to Java (the language, not the vm and ecosystem) being outdated compared to it's competitors.
> Altough that hype is slowly dying, due to Java (the language, not the vm and ecosystem) being outdated compared to it's competitors.
This part I have some issues with: the language is still quite modern (compared to C, for example). There are several other reasons for its slow demise: its licensing issues and initially problematic Linux implementations put it at a disadvantage on the server side and in circles where open source was important. It is quite verbose and not well-suited for web development - not the best proposition at a time where scripting languages and rapid web prototyping were on the rise. Finally, the enterprisey orientation of later developments around Java and heavyweight ecosystem really put off beginners - editing XML (build.xml bigger than the whole program...) sucks.
I'm comparing Java to languages like C#, C++ and Go, and Java is definitely falling behind. Java 8 will be a big improvement, but I'll still miss having variable type-inference (auto in C++, var in C# and Go).
C is supposed to map very easily to what actually happens under the hood. Thus C will never have closures, type-inference, generators and the like as a part of the language. This is a part of the languages design, which is why you shouldn't compare it to feature rich languages like Java or even C++.
Hmm.. I'm not a Java fan by any means but as it turns out that Java is now actually a very popular language for client side programming. Maybe one of the most popular client side[1] programming languages in existence today.
There is nothing wrong with hype if that hype is warranted, and Java certainly has an unmatched track record in terms of delivering solid, portable and easy to maintain code bases that power millions of applications today.
> The con was that it was inherently portable and secure and can be used for client software.
Java hasn't been pitched for client software since the death of applets, circa 1999.
Java is so good in so many domains that it's easier to name the areas where it's not the best: graphical applications and CPU intensive programs (games, numerical calculations). That's about it. For anything else, Java is most likely to be a very solid default choice.
In my opinion Java is pretty good at CPU intensive tasks. Where it falls short is memory usage and memory management. A lot of software is being written in C++ because Java cannot use much of a machine's memory without incurring rather large garbage collector pauses. What Java needs is structured value types and an affordable implementation of pauseless garbage collection.
"There was and continues to remain NOTHING that compares to the Java platform."
... today. Thrownaway2424 said (my emphasis) "Java in the 90s was a spectacular con job that millions of developers and managers bought hook, line, and sinker."
This was true. Sun purchased Java's popularity. It did not even come close to living up to the hype in the first few years. I could segfault it without much difficulty using Swing, and I was hardly using it for anything (school assignment!). I was not a sophisticated developer at the time. I should not have been able to do that.
It is also true that through tenacity and dedication, Java eventually did live up to its promises. But that came later.
Both Java and the XML are in heavy use today with plenty of people caring about them.
XML is still the right tool for the job for many use cases. JSON is great for serializing data structures. XML is great for marking up various types of textual data.
Other people have already covered your comment on Java.
>>Java in the 90s was a spectacular con job that millions of developers and managers bought hook, line, and sinker
In the 90s, before Java, you had C/C++ dominating server based code that wasn't COBOL (Smalltalk tried to compete, but it's failure is a whole different story), with BASIC/Delphi/PowerBuilder/OracleForms/arguablyMFC dominating UI based code.
I will grant that Java gained a lot of buzz due to Java Applets in the browser and with deceptive claims regarding how portable AWT and later Swing applications were. But for server side business application coding (NOT systems coding), Java blew C/C++ out of the water.
C++ on large projects, especially with the feeble template compilers at the time, had insanely long compile/link times. It wasn't unusual to kick off a build and have to wait an hour or more to be able to test it. It's true you could break things up into dynamic libraries to try to reduce link times, but that meant more work, especially if you had to run on different platforms. And there were specialized tools like ClearCase's ClearMake that could speed things up, but they were far from commonplace.
Java for server based code compiled quickly and eliminated the link times (well, it moved linking to runtime, but effectively it also made each class into it's own mini shared library). And Java stack dumps were orders of magnitude more useful than C/C++ core dumps. Performance was slower compared to C/C++, but faster than interpreted languages at the time, and generally "fast enough" for most business applications.
Java's JDK also provided a lot more "out of the box" functionality than what you had with the C++. Heck, even just having a standard String class was tremendously more useful than having to deal with char arrays. And the collection library was feeble, but it was there. (The C++ STL wasn't released until 1998, and RogueWave was probably the closest thing to a de facto C++ library, but it was a commercial product).
The rise of internet e-commerce also convened to help Java out. A lot of sites started with cgi-scripts, which had to launch a new process for every CGI request. Even C/C++ CGI programs were slow because of this. Java's servlet spec provided a very convenient way to run multiple requests in a single process, which was typically at least an order of magnitude faster than CGI at the time. And it was much easier to write servlets than to compile a custom Apache C/C++ module into your apache distribution.
And for as many headaches as Java caused for "cross platform" UI code, it actually worked pretty well for cross platform server side code. Gone were the spaghetti pragmas from cross platform C/C++ code.
So what happened with Java is that the applet/UI buzz got in through the enterprise door, but it's server side conveniences are what enabled it to gain tremendous enterprise acceptance. And IBM jumping on board the Java ship was somewhat of a green light for COBOL shops to move to something else that was still blessed by IBM.
>> XML was pretty big back then, too
XML really didn't come about until the late 90s and was really more of a 2000s buzzard. It's being rightfully replaced by JSON for a lot of browser/server interactions, but for better or worse there are still quite a few places that it's sticking around.
P.S. There's a pretty good chance that Java will see an uptick again when JDK 1.8 finally lands. The lack of a concise format for closures is crippling Java in the midst of the current surge of functional programming idioms.
Yes, but there were several waiting in the wings. In the early '90s lots of people were expecting a GCed language - Smalltalk or Dylan or Self or CL or ML or ... - to make the breakthrough and become a mainstream application-programming language. Many of them (including Bill Joy) were pretty unhappy when it turned out to be Java that made it big.
Who mentioned anything about "C++ searches on google"?
There WAS an industry in 1987 and people who are around now were also around then, and can compare how well Go does compared to how well C++ did circa 1987.
Programming is now multi-language and multi-paradigm. It matters more what you can do and not what you can do it in. Being able to compose libraries and systems from parts is way more important than knowing a specific language.
This is true but, from my experience with developers (not to mention HR/hiring managers) at my own company and elsewhere there is a prevalent attitude that language is the basis of "What You Do". I agree that attitude is totally wrong but a lot of places seem to have this backwards prejudice about hiring good developers and chucking them headfirst into a language or technology they haven't already proven they know.
Indeed, for example getting your brain wrapped around concurrency patterns in Go is very straightforward (especially since there is a plethora of documentation and examples).
These skills will transfer very well into other programming languages.
I'm thinking Go has got to eventually eclipse Python in popularity, since the former can do the same work using a fraction of the servers, for about the same coding difficulty.
One place Go won't be replacing python (or perl) is in the "smarter shell-scripts that don't suck" space. Being able to write a 10 line script, dump it on the server and point cron at it, and then open it in situ to see what it's doing is invaluable. Also, when things get a bit edgy, to copy the file, edit 2 lines, and run it to fix something that the original didn't cover...
It may be better than Python for some kinds of large applications programming, I don't know. But since a lot of apps do need the simple scripts and the application logic, it's kind of nice to have them all in the same language - which is one place where javascript may take over more, I suppose, if ever they can convince OS designers to build node.js tools into the default installs...
I find good old /bin/sh is better than perl or python for the use case you are talking about. Perl rose out of the huge gulf between shell and C. The distance from shell to go is much smaller.
I have a bunch of scripts which are written in standard shell, and for simple stuff, it's fine. But as soon as it starts doing file name manipulation, or working with collections of files (say finding the age of the most recently changed file in a directory, and checking how long ago that was and changing color-extended attributes of the enclosing directory so projects untouched in over a month turn grey...), and you have people on the network who name files by copying and pasting from word documents (I didn't even know you could put a newline in a filename!), I've found python to be much more reliable and easy to write correctly.
What you described is exactly what I mean by simple stuff where shell is ideal. People generally find perl or python easier for those tasks because they took the time to learn perl or python, but didn't take the time to learn sh.
If the function has less chance of erroring than a hardware failure, why check? I have a function that calls functions that call functions and so on. At the top level function I check if Go has panic()ked; if so I recover() and report the nice error message I want. Seems to offer close enough functionality to try...catch.
That is almost doable, but would be exceptional unless your name is Rob, Robert or Ken. I think I could almost claim 9 years at that point, conveniently ignoring the fact I stopped coding a few years back.. :-)
There is a fallacy in this quote: "The state of the Go ecosystem after only four years is astounding. Compare Go in 2013 to Python in 1995 or Java in 1999. Or C++ in 1987!"
This comparison is more than unfair, in the 90's only a few people had an internet connection. Or Do you want to create Open Source projects by mail? Git or Subversion didn't even exist back then.
Now imagine in 1987...
> The state of the Go ecosystem after only four years is astounding. Compare Go in 2013 to Python in 1995 or Java in 1999. Or C++ in 1987!" This comparison is more than unfair,
It's more than unfair since they don't show any numbers. At all. Not for Go, not for Java, not for anything.
The graph is cute but it's not even a number of installations, projects on githubs or lines of source code: it's Google searches. Searches measure nothing more than buzz. I bet Google Wave showed similar curves facing up for months.
If the Go team had hard and impressive numbers, I bet they would show them. The fact that they don't makes me think that Go is not seeing a lot of traction, besides a few Python and Ruby programmers.
So I've given Go a try with a couple of projects, and I like it so far. However, I really don't like its "warnings are errors" feature — in particular in respect to unused imports. If I comment out a line that uses an import, then it no longer compiles until I go to the top of the file and comment it out.
Has anyone come up with a good solution to this? Preferably using Vim tooling.
I'm currently working on a Go project that is meant to sit above the Hadoop FS. Go has been absolutely brilliant to work with. Some of the design decisions make very little sense at first (e.g. no fields in interfaces, no real inheritance, etc.) but as I've used the language more and more, the reasoning behind them becomes clear.
I enjoy writing Go and have done a lot of it over the past couple years, and there are occasions where I miss other kinds of polymorphism. Specifically, parametric and ad-hoc.
However, it doesn't impact whether I enjoy writing Go code or not. It tends to be mitigated by blessed built in types and functions with parametric polymorphism (e.g., `map`, `[]`, `append`, `delete`, etc.) in addition to Go's structural sub-typing and type embedding. First class functions help too.
Actually, this results in a really nice aspect of Go that I've come to appreciate: reading and writing Go code tends to have very little cognitive overhead. Things tend to be very straight-forward and clear. I'm not sure if this is because there aren't generics, but I have my suspicions that it is. The language itself and its semantics is very simple and can fit in your head easily. But this is my experience, YMMV.
Dirty little secret: sometimes I cheat a little when writing small commands in Go and sacrifice compile time type safety by using my `ty` package.[1]
At first, I thought Generic is not that much desired. But after having some time with Go, I think Go really need generics.
The problem is Go lacks immutable data structure. I believe everybody know why immutable data structure is required. Go slice and map are all mutable-only, so to make some read-only data view, we need to write all the containers by hand. Amount of code increases exponentially.
It would be great if Go had such a immutable slice/map stuffs, but they decided not to have that due to legacy compatibility issue with existing []byte/string(which is actually just an immutable view on []byte) types.
So now the only hope is generics. I don't want to write hundreds of same list/map classes just to offer immutable views. That's all duplicated works, and I just want ability to write List<T> and Map<T>.
If you don't think immutable data structure or view is not important, Go is good enough to you. But that feature is crucial to me, and that's one of the biggest reason of why I stopped using Go.
One scenario I ran into is building a generic function call caching solution. Coming from Python, there tons of great libraries for memoizing and caching [0][1][2]. Even the Python 3 standard library has a simple one built in [3]. But building something similar in Golang proved to be near impossible.
I got a half-working solution [4] with a lot of interface{} and some reflection, but upon speaking with some of the Golang devs, the consensus was "this is not something you do in Go." From what I understand, you're expected to build a custom memoizing function for each set of datatypes you're expecting to use it for (which admittedly is not a ton of code), and generic helpers are not advised.
I can't say authoritatively whether "Go needs generics!" or not, but life has been much easier after porting my code back to Python—though a large part of it was because it was a fairly dynamic webapp which is still a pain point for Go. I hope to give Go another try soon, probably for a different project.
Since Go has generics for slices (aka arrays), maps (aka dictionaries / hash-tables) and channels, I was pleasantly surprised how little I miss them in practice. Just some adaptation-of-thinking-habits mostly. Don't miss them anymore. I have a micro-codegen pre-build step (written in Go of course) for the very few use-cases where something akin to those (more generally, templated programming) does come in handy. But those are really far and few between.
Sure. Think of void * in C. interface{} in Go isn't really that different, there's just a bit more language support for testing if it satisfies a specific type or not. Add in type assertions, and it's basically as though you had a dynamic_cast in C++ that worked from void * to an interface type.
To me, it just seems ugly. I like a type system where I know what a type is at each point, and there isn't some ugly "catch all" type that you can use when you run out of other options, which effectively just throws away all type information (and this is what interface{} does, as everything implements it).
That was my initial struggle as well coming into Go (I have worked for several years in C# & Java). You learn to work around this limitation using interfaces for both function parameters and return types. Frankly, I have had to do a little more explicit typecasting that I would have liked (going from interfaces to the actual type) but it is ok.
Isn't the idea behind interfaces that you add whatever methods you need to use to the interface? If that's the case you don't need or want to cast, you can just assume that the object given to you conforms to that interface...
Nope. This mostly becomes a problem if you like to be DRY and try to replace generics (type T) kind of functionality with interfaces. For e.g., I have a method, which does the classic, lookup from cache first before hitting the actual db. In C#, you can use
public T Get<T>(int id, string cacheKey) {
}
When I consume it and say Get for User object, I expect an User object as I already know it's type.
In Go, you have to return an interface (and ideally an error)
Here would be the equivalent,
v, err := s.Get(id int, cacheKey string)
if err != nil {
//Handle error here
}
if v == nil || v.(*models.User) == nil {
return nil, http.StatusNotFound
}
Its a bit more code, but on the flip side, it gets you thinking as a client of all the things that can go wrong with your code
This is called a type assertion in Go. Whenever you ask for something as an interface but want to use the type's own method, you have to make a type assertion.
interface Fooer {
func Foo()
}
type Bar struct {}
func (s Bar) Foo() {}
func (s Bar) Baz() {}
func DoFoo(f Fooer) {
f.Foo() // fine
// f.Baz() compile error
f.(Bar).Baz() // fine
}
Isn't the entire point of an interface to communicate the behaviour expected by the function though?
If you want a Bar specifically (as the DoFoo code does above), it should take a Bar as an argument.
If you want to accept any struct that satisfies Fooer, add all the methods to Fooer that you need them to satisfy...
Doing otherwise is just subverting the type system and you might as well use a blank interface and effectively have no type checking on your input - if you require a Fooer and then typecast someone might pass a Fooer and get a nasty surprise when it doesn't work.
When I look at the Google Trends for "golang", China is the top region by a huge margin (the next highest region after China is Sweden at 30) [ http://i.imgur.com/XHW40kp.png ].
And the rise of interest in "golang" in general seems to correspond to the massive spike in China [ http://i.imgur.com/Y3oO2jf.png ].
People in China that are searching for the game would probably be searching for "weiqi" or "围棋". "Go" comes from the Japanese word for the game, "igo".
Also, in my experience, very few (mainland) Chinese play weiqi. Everyone plays Chinese chess, but very few play Go. So people searching for "go" are quite likely searching for the language. (Although I'd expect that the people who know about the language know enough to search for "golang", so who knows)
Go is quite popular in China, especially on Windows. I'm not sure of the reasons for that, but Rob Pike and Andrew Gerrand do mention it in this interview on the ChangeLog: http://thechangelog.com/100/
The population itself doesn't matter that much. According to this: http://en.wikipedia.org/wiki/Poverty_in_China#Poverty_reduct...
~950 million live on less than 5$ per day. I doubt you can get a decent PC and a decent Internet connection on that kind of money. I'd bet that the US has more programmers than China right now, even though China has 4x the population.
Google's a big company with lots of fiefdoms, and Go is one of the smallest; I'm not sure it even counts as a fiefdom. Android is heavily invested in Java/C++ and those types don't like to admit that you can do anything worthwhile in Go.
After compiling Android a few times, though, you'll appreciate what the Go team was talking about when they said C++ compilation time was a driver for them.
It's search volume. The values are 0 at the origin to 100 at the highest point. But there are no units, I presume Google knows but doesn't give real numbers.
However, if you do a lot of collection processing, you start to really itch for something like generics (Which can lead down some pretty interesting rabbit holes: http://blog.burntsushi.net/type-parametric-functions-golang). I think this is a pretty big feature to be missing, actually. I hope it comes soon in future updates. It's pretty frustrating to have to reimplement data structures that can accomodate custom structs.
But overall, it's very impressive, and a step in the right direction. I think we're approaching a golden age of programming languages, where syntax, expressiveness, and performance are all given equal seats at the table.