I'm a big fan of C and python and I've never used Go. My initial impressions from readings were that Go is a better C. But then I came across a Go person who was lamenting that misunderstanding and that Go is python but with better performance. What's it all about?
Also even if we compare it to C I don't like the garbage-collection thing at system level. Also what does Go let you do in terms of garbage collection that cannot be done with a C gc library (which anyone can use if they want but then also have the choice to do raw/manual memory management if they want too).
Go is a very pleasant language to develop software products in.
Unlike the dynamically typed languages, it doesn't trade speed for beauty of syntax. This means that sometimes syntax can be a little non-uniform, but there's always a reason. Unlike C and C++, it doesn't trade safety for speed of execution. There are no buffer overflow vulnerabilities in Go applications. It treads a fine line of where to let the language do the lifting and where to make you do it. In general, it does a really good job of finding the pragmatic side of the line to sit on in any particular situation.
I don't know of any widely used C garbage collection libraries. The benefit of it being a language-level is that everyone uses it, which means your code works the same as everyone else's, so you can easily just reuse other people's code, without having to restrict your search to some small subset of repos that use your particular GC Library.
Also, in Go, unlike most other garbage-collected languages, there is a stack, and you can pretty easily write code that only uses memory from the stack, and never needs to run GC.
Finally, Go's tooling is really phenomenal. Testing, doc generation, performance reporting, code coverage, linting, package distribution, code formatting, refactoring, cross-platform compiling, and soon, pre-processing, are all built-in and really well done.
The toolchain part of Go is very interesting (I only know the basics). Go doesn't use GCC, LLVM or other existing compilers. Go's compiler/linker originated from the Plan9 C compiler (that Rob and Ken worked on)[0]. Because of this, it allows you to create binaries for any target platform from any platform you have the Go toolchain on. So from my OSX macbook, I can compile Windows and Linux executables.
When you start diving into it a a bit more, you'll see that Go has it's own ASM language[1] that your code is first compiled into (which then can be translated into specific os/platform asm).
This has it's own ups and downs. Debuggers don't work all that well on Go generated executables (gdb is the closest, even that one isn't all that great). You also don't have the years of optimizations that GCC and LLVM bring to the table. But the Go team has tight control of the tools, which allow for quick compilation and allow them to pick their own direction.
Yeah, a lot of magic lives at the tooling layer, and Go is going to leverage that with Go Generate in Go 1.4+. A lot of great tools already leverage that core.
I like that fact that a lot of the tooling/editor support is not picking a winner nor demanding an IDE. Tools like errcheck, goimports, gorename (announced today), oracle, gocode, godef, godoc, gofmt, golint, gotags, ... (on and on) ... all can be leverage by IDEs, emacs, sublime, vim and others equally... or just used from a console or in your own stacks.
Gccgo misses out on some key optimizations, like escape analysis IIRC, and therefore on real world tests usually is not as fast as gc. Also, since gc is the de facto standard, it has a LOT more real world testing. Gccgo has a few bugs (I forget exactly, something about embedding an interface or something just causes a panic - avoidable, but frustrating).
Go was originally pitched as a better C, but it seems to be finding a niche as a better Python or possibly a better Java. Go binaries have built-in GC, and Go will probably never reach C levels of performance. There is a lot to like about Go and it is working out very well for a lot of people, but it isn't appropriate for every situation.
When Google will completely deprecate Java for Go on Android (could be a number of years, if ever), then Java should imminently become irrelevant (over a number of years, maybe a decade, or maybe it will never disappear completely, but the point is it will rapidly decline with new and existing developers).
Given Android's core team statements at Google IO 2014 about Java being the only official language, with no plans to improve the NDK beyond the existing support, I find it very hard to ever happen.
Unless Management forces the team to change their mind, that is.
I really hope Google deprecates Java on Android, because Android is even having problems with the standard library in Java SE 6, let alone Java 7 or 8. I rooted for them in the Oracle lawsuit, but they are holding back progress on the Java platform, as now library authors have to worry about the "Android problem" - every other JVM vendor is able to keep up the pace of updates, but not Google, because hey, ART / Dalvik is not a JVM, haven't you heard? So they should either get their shit together and keep up with the latest standard library, class format and bytecode in their toolchain or drop it.
I don't see any reason why Java usage would rapidly decline. The only thing that's likely to replace Java is Java 8, since everyone wants lambdas and there's a clear upgrade path. Even that's a big change and migration will take a while on Android.
It's unclear what the big missing feature is after lambdas. I think there will be little incentive for further change, so large companies will keep on running it.
> It's unclear what the big missing feature is after lambdas.
- Value types, GPGPU, replacing JNI with an improved JNR, reified generics, making Unsafe an official package, modularity, AOT compilation, replacing Hotspot by Graal...
The Java community is so large that these are important communities in themselves. But they're still subsets. Someone writing a portable Java library isn't going to want to call into native code or rely on specific hardware. Changing the language itself affects everyone.
> It's unclear what the big missing feature is after lambdas.
I agree. I think Java pretty much is what it is by now. As someone said, "For those who like this kind of thing, this is the kind of thing they like."
Java-the-language is pretty complete. (Even though Haskell people complain about the lack of a decent type system, and Lisp users complain about the verbose syntax, and C++ folks wish they had destructors.) Java-the-platform is in fine shape (the library is Java's unsung best selling point.)
Java-the-enterprise-bloatware-behemoth... well, it really needs to be shot in the head and the body incinerated, but it may actually do the jobs it's given to do about as well as anything that might replace it.
In terms of language features, lack of properties are the thing that is keeping me from using java. I would love to be able to have public variables, with the understanding that I could just convert them to properties later on if I need to. Instead, java conventions suggest that I always make a getter and setter for every single variable that I want to expose.
Some Java conventions are unfortunate. Setters aren't a great idea, actually. The Guava team recently open-sourced AutoValue as a more modern approach:
Fixing this stupid issue seems like such an obvious thing to do I can't imagine why it wasn't addressed ages ago. Having property notation would immediately get rid of 30% of the code in the codebase I currently work with, and that seems incredibly valuable.
Rust???The language which is more complicated than C++??? I have learned Rust almostly, but it is too enormous to replaced the C/C++. If rust can't simplify its concepts and syntax, this language will turn to failure again like D...
Rust is not more complicated than C++; you actually have to be thinking about the concepts (ownership and lifetimes) in C++ too, there's just no compiler help, so it seems like you don't.
(Well, you get some help: the compiler inserts (arbitrarily expensive) copies of your data for you.)
The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars".
I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.
> The problem with "languages for those who can" is that they get relegated to pet projects, because real teams need code that everyone can understand, not just the "rock stars".
> I actually hope that Rust does not become that kind of a language. I think it has a lot going for it, but I do agree that it's a pretty dense language, and that will cause problems in uptake for real projects.
Many of those real projects can't use anything easier than Rust. Sure, using a GC for everything is easier, allowing memory safety violations is easier, and allowing data races is easier (for some definition of "easy"). But for many projects, like browser engines, kernels, games, etc. neither of these are an option. In other words, avoiding new concepts comes at a price. The concepts in Rust aren't there for no reason; they're there because they're solving real problems.
(Incidentally, I don't think that "simpler" is the right term; I think there's a lot of confusion between "simple" and "easy".)
In my experience most people won't even learn the ins and outs of the "for those who can't" languages. Worst yet, it's not about the language: most people won't grasp more important concepts that maybe "for those who can" languages force them to know upfront. And clearly while not knowing upfront some things is easier in the short term, it is a recipe for disaster as problems get more complex. So maybe it's about problems "for those who can" and "for those who can't".
People can write bad code in any language. I don't know that "forcing" people to know about it will do anything other than force people to make a possibly bad decision... such as simply marking all values as mutable.
The nice thing about go is that there's just a lot less to know. You can learn everything in a weekend. There just aren't many dark corners in the language.
And the problem with "languages for those who can't" is the rise in off-shoring and erosion of working conditions for everyone involved, in both sides.
Not targeting any specific language, as I imagine all of us that went through this, have own hard earned war scars.
Suggesting that offshoring is a result of languages that are "too easy" is both insulting to those who work offshore, and totally inaccurate.
There's plenty of off-shore C++ programmers, and I doubt anyone would say that's an easy language.
And yes, offshored work is almost always of poor quality, but I actually think this is due to the inherent problem with paying people to write a product that they are not fully invested in. The same thing happens with contract work done in your own country. If the developers don't work for your company, they don't have your culture and they don't know your business. This is compounded by the communication inefficiencies from being outside your trusted mediums.
I have seen pay-for-code (contracting, offshore or not) fail many times. The only times I have seen it succeed is when the contractors are hired to work for the company directly, are taken inside its boundaries, and given full access to the company communication facilities and culture. But then, they may as well be regular employees.
None of this has anything to do with the language being used. As they say, you can write bad code in any language, and even the best code doesn't help if it's not doing the right thing.
For me, touting a language as being "Python, but with X" is a big turnoff.
I worked for about 2 years in Python and hated most things about it - from the whitespace sensitive indentation that led people to write really long lines and the limited expressive capabilities forcing people to do meta voodoo in their libraries leading to incomprehensible DSLs, to the legacy that sticks like "old-style vs new-style classes", to the performance problems and the sad state of libraries in the ecosystem, let alone the complete cluster-fuck that is dependency and deployment management on top of Python.
So you know, I want to hear about languages that are not like Python.
Oh, then you'll love Go. It's nothing like python. At least, not like the python you've described above.
Go is actually quite different from python in a lot of ways. Most of the stuff you hate about python does not apply to Go in any way. You can't really make a DSL in Go - there's no operator overloading, no meta classes... no classes at all. The performance of Go is an order of magnitude faster than python and only a few times slower than C. Dependency management and deployment are trivial - Go compiles to a standalone binary with no dependencies (except sometimes libc depending on what you're using).
So... Go is nothing like Python. When people say it is, what they mean is, Go tries to make its syntax really obvious, and make life pleasant for experienced developers writing software in the language.
Go's syntax and semantics seem ad-hoc, hard to remember, and inconsistent, but that's because Go was designed from uses cases and experience by prominent thought leaders such as Rob Pike and Ken Thompson, and Google. For example, sometimes you'll get Unicode code points, but sometimes you'll get bytes of UTF-8. The language was designed to give you the right one in the right case. UTF-8 is coupled with the language because it's the most useful choice. Another example is that pointers are automatically dereferenced, but not when you have pointers to pointers, because that's less useful. If any thread runs in an infinite loop that doesn't call built in functions, the entire runtime will freeze. But this is by design. You're meant to do actual useful stuff in your loop such as calling IO functions (which will yield to the scheduler) or calling GOSCHED.
It was designed to compile fast, and compiles faster than most languages and still has near C-speed. It doesn't have a GIL so it has better concurrency (Java style memory model). It has no complicated features like generics, instead you just use type assertions when you need. It also has impeccable tooling.
> If any thread runs in an infinite loop that doesn't call built in functions, the entire runtime will freeze.
That's not entirely true. Go 1.3 introduced pre-emptive scheduling, so now only the most trivial (useless) of infinite loops will hog the scheduler. But if you're doing real CPU-bound work you won't block other goroutines from executing.
Correct, pointless programs like this freeze but that's by design since they're pointless:
package main
import "fmt"
func main() {
go func() {
for ;; {}
}()
for ;; {
fmt.Println("still here")
}
}
Even bigger pointless programs also freeze:
package main
import "fmt"
func f(v int) int {
return v+1
}
func g(x int) int {
if (x > 100) {
return 1
}
return 0
}
func main() {
go func() {
for ;; {
if g(f(111)) == 0 {
break
}
}
}()
for ;; {
fmt.Println("still here")
}
}
This is of course by design, because Go was designed only to support useful programs. The programmer trying to figure out how the concurrency model works may whine that it's inconsistent and he can't figure it out, but that's only granted because threading is hard. Go makes it easier by only supporting useful cases.
>For example, sometimes you'll get Unicode code points, but sometimes you'll get bytes of UTF-8.
This isn't true, you only get code points when you convert to []rune, I'm not aware of any situation where you would magically get codepoints.
>If any thread runs in an infinite loop that doesn't call built in functions, the entire runtime will freeze.
This is not true, since 1.3 all function calls can potentially yield. Also it only happened if you had as many goroutines running infinite loops as you had kernel threads.
> Go's syntax and semantics seem ad-hoc, hard to remember, and inconsistent, but that's because Go was designed from uses cases and experience by prominent thought leaders such as Rob Pike and Ken Thompson, and Google. For example, sometimes you'll get Unicode code points, but sometimes you'll get bytes of UTF-8. The language was designed to give you the right one in the right case. UTF-8 is coupled with the language because it's the most useful choice. Another example is that pointers are automatically dereferenced, but not when you have pointers to pointers, because that's less useful.
How about Go's syntax and semantics seem ad-hoc, hard to remember, and inconsistent because _they are_ ad-hoc, hard to remember and inconsistent? What does your thought leader have to do with your genuine opinion?
Any language seems inconsistent and has hard to remember syntax for people who are new to it. Unlike most of other languages, you can learn Go in a weekend and get beyond the newbie problems. There was a great article lately about Go's syntax - http://robnapier.net/go-is-a-shop-built-jig
The crux of the matter is that there are inelegant parts to the language because they are usefully inelegant, and when you're actually writing software, useful is better than elegant.
For example: if you have one thread polling `x` and another thread writing to `x`, there's no guarantee that the polling thread will ever see any updates to `x`.
Most concurrent C programs of a reasonable size eventually have some kind of big global lock. The linux kernel had one for a long time and it took a lot of effort to add more fine grained locking. Similarly most large C programs have a garbage collector of some kind.
most large C programs have a garbage collector of some kind
[citation needed] - the vast majority of Linux software is C or C++ and I can't immediately think of any with GC. It's not normally assumed, everyone does explicit deallocation, possibly ending up writing their own slab or pool allocators.
A C garbage collection library generally has to be very conservative because most C code is written with the assumption of not being garbage-collected. Having GC built in allows you to do more aggressive collection without worrying about breaking code that assumes it has precise control over memory. There's a reason why even people who like garbage collection don't tend to use garbage collection when they write C.
Like any other language, there're some pros and cons with Go. For example, C gives you complete control at a very low level, but can make higher-order operations more complex. On the opposite end of the spectrum, Python removes a lot of that friction at the cost of doing more things behind the scene, which obviously affects performance. I regard Go as somewhat in-between -- it provides you with some of the lower level constructs (like pointers) but also reduces complexity (by giving you goroutines, for example).
Specifically about garbage collection, I'd recommend taking a look at what's coming up in 1.4:
The Golang FAQ will help answer your questions about some of their design principles[0]. Rob Pike also has some interesting views on why Go seems to attract Python and Ruby devs rather than C and C++ devs[1].
If I had to summarise Go; I'd say it does most things better than most languages but doesn't do anything significantly better than specific languages.
Which isn't very exciting but it is generally what people want. Something that's a good enough multi-purpose language to cover normal use cases. And in the rare examples they need something more niche, then there's other languages that will serve those functions better.
The comparison to C has always struck me as strange. It has curly braces and pointers, but few semicolons, no pointer arithmetic, garbage collection, and tons of high level language primitives (maps, slices, channels, select, goroutines, a userland scheduler).
Many people, myself included, find it a wonderful language suitable for all sorts of service development whether it's data processing systems or web APIs.
I love Go and I consider it to be the spiritual successor to C, in a way (sort of an anti-C++, which the creators have said they used as an explicit example of what not to do).
Given that it was co-created by Ken Thompson (of Unix/C/Plan9 fame), I think the comparison is justified.
I think the general idea is C++ (not C) in the style of Python.
You still have access to memory/pointers/unsafe, it shares a C-style syntax (go ahead, put in the semicolons if you want!), is compiled but offers the gentle, elegant watchfulness of a Python-like scripting language.
In most cases it can be a relatively drop-in replacement for C++ or Python as a binary. It will never be like C in that there's a lot of overhead and lack of memory control for embedded systems, so you probably can't treat it as a C competitor in any way.
Another similarity is that both Go and C compile to dependency-free and portable binaries with no VM needed to run them. In my mind, that's the biggest similarity.
And regarding semicolons: you don't use them as much while coding, but the lexer puts them in for you, so they're there on some level.
Go is a slower C[1] with worse syntax and oversold ideas.
Stockholm syndrom is a builtin feature that comes with it and not much else. It doesn't provide basic stuff like generics, warnings, or exceptions because the authors want to make a bold statement about how they are in the Right and their potential users are wrong.
Meanwhile system software will continues to be built in C and C++ since Go addressed some real problems with system programming but created new ones.
Go was explicitely created for the average programmer like is said in videos talks. It is a dumbed down language to address the maintenance problem through tools instead of through better craftmanship. Go isn't very successful at Google but in startups who could do technically anything and still have the same outcome.
"It's Stockholm Syndrome." "It's one of the languages for those that can't."
The reason so many Go advocates seem irrationally biased is because they're under near-permanent assault. Personal assault. The anti-Go crowd never lets a Go post fly by without arguing against it, but it's the "...and everyone who is using it is stupid, ignorant, a kid, or just doesn't understand programming" that leads to the kind of defensiveness that tends to crop up. Argue against the language, but please, stop assuming people who have made different choices and have different priorities or preferences are dumb.
Guys slightly off topic, but please do keep the colorblind people in mind. The colors used for the graphs are so similar that I can not differentiate them.
Tools like Color Oracle[1] are great when checking UI color design for its color safety. Some monitor software also has similar features. E.g. NEC monitors' MultiProfiler tool supports a number of different color vision emulation modes; see the "Color Vision" pane in that app.
Red/blue would be safer colors to differentiate for many colorblind people. Red/green colorblindness is so common it baffles me that comparisons using red/green are still so prevalent. Especially considering how heavily biased the tech population is toward men.
And as Sanddancer points out, any colors that make use of red/green are going to be problems as well. (hence blue/purple being an issue as the difference is the red component).
In a given group of 5 men, you have a 50% chance that 1 is red/green color deficient.
Pc = Probability that someone is colorblind
(1 - Pc) = Probability they aren't colorblind
(1 - Pc)^5 = Probability that no one in group of 5 is colorblind
1 - (1 - Pc)^5 = Probability that someone in group of 5 is colorblind
It usually doesn't come up in conversation. Even when I was working on an image processing toolkit, it was several months before I realized my boss was red-green colorblind.
I'm red/green colorblind and blue/purple is the worst combination for me. I colored all my skies purple in elementary school because I couldn't tell the difference.
It's both interesting and suprising that how steady this exponential growth curve is. The increasing speed of Go usage on stripe doesn't slow down as time goes by.
Of course without knowing the base we don't know how big usage it actually is, also we don't know if it's counting one-per-client or one-per-request. Still nice to see that nonetheless.
Right, just look at August! Although I wish there were numbers on that graph. Was there a conference talk? Glad to know there'll be lots of fellow devs using it anyway.
Interestingly, it looks like the Go library uses structs rather than `map[string]interface{}`, even though the Java library was recently criticised for its usage of `Map<String, Object>`[0], a decision defended by the developer[1] on grounds that "[they] add new parameters to the API frequently, so it's a tradeoff to avoid devs needing to update stripe-java every time."
There's a tradeoff space here, as that tweet indicates. Doing things generically makes the library less idiomatic, but means developers don't need to churn their library dependency as often. Go's a different language from Java, and it's less common to have to deal with casting, etc. As that tweet conversation indicates (particularly https://twitter.com/JimDanz/status/511732603884294145), we're also considering changing the Java library implementation in the future.
My sense is that the Go developer culture is a lot more open to frequently updating their dependencies than the Java developer culture. Fetching dependencies from git is built into Go, after all.
AFAIK GSON (which stripe-java users) also ignores fields which are not present in the destination type, but the original post was about parameters so that's not even relevant: deserialisation would only be relevant for responses.
Honestly parsing json as map[string]interface{}, rather than using a struct is a major pain in the butt.
I'm currently doing a project that takes json, with no predefined structure, or at least very varying struct and transforms it. Dealing with checking for keys and doing type conversion it's that much fun. The same project need to parse an XML file, with a clear and defined structure, it took something like five minutes and work on my first try.
I don't think you would need to update the Go library in the case of just adding new parameters, not if the parameter can be excluded. The json parser should just skip that value, it won't be available to you of cause, but it should break the parser. Given that I haven't touched Java in 10 years I don't know how Java deals with unexpected parameters.
Isn't this generally done anytime you don't know the structure of the json document that will be unmarshalled? If a new field is added and you're parsing to a struct that struct will have to be changed to accommodate that field, rather than letting it happen anonymously as through an interface.
That was porting from Ruby. Go is particularly good for any application where you want to get better utilization out of your CPU, or want to cut down on memory usage.
Most of the code we've been porting has been infrastructure: parsers, reverse proxies, and the like. We're still getting a feel for what it's like writing complex application logic in Go, but what we've seen so far has been promising.
Well if you're not particularly CPU- or memory-bound, you probably won't want to spend your time optimizing them. As well, there are plenty of softer aspects you might care to optimize: productivity, maintainability, library support, etc.. There's unfortunately never a free lunch with software engineering.
Out of curiosity: Where would this be used? The only places I ever hear the word "lua" being used are with "embedded in a game as a scripting language".
Is this the case here? Does lua have a lot of use elsewhere?
The majority of developers I know (across several camps) strongly oppose Go, often to the point of ridiculing it.
But then I see Go support being added to everything, usually by a few key people who strongly prefer it. In fact I hear Heroku is internally adopting Go pretty rapidly.
So every time I see an announcement like this, I look up whether Go has added some kind of generics yet. And as usual, they haven't.
But to me, the worst part of this is that the whole community has Stockholm syndrome, being perfectly content to instantly defend every position the Go team makes, no matter what.
So I'm gonna make a wild guess here and assume you haven't written in Go. If you had, you'd probably find it fun and convenient. Not revolutionary, just fun and convenient.
That's enough for me to like it better than python or ruby or perl.
Developers & managers at Stripe decided that Go was being used often enough to spend precious dev time writing an official library which will have to be supported from here on. They wouldn't do that if the numbers didn't justify it.
People often ridicule what they don't understand. People who haven't written real code in Go don't understand why it's good. And what makes it good isn't that it has X feature, so it's hard to explain to people who haven't used it.
Missing generics is not a major problem. Yes, it means you can't write a generic red black tree in the language that doesn't require type-casting. However, for real software solving real problems, you don't often actually need generics. I work on Juju, which is a couple hundred thousand lines of code, consisting of a client and networked servers deployed across an arbitrary number of machines in the cloud. The number of times we might have wanted to use generics in the codebase is approximately 2... and only one of those pieces of code is actually used by more than one type.
Sure, some software really benefits from generics. But most of the time, generics just complicate the code with little to no benefit. Many things people do with generics can be accomplished with interfaces and just writing code that has fewer assumptions about the outside world.
I write Go on a daily basis, and the lack of generics support is really not high on the list of problems that I encounter. I think it's a great tradeoff between C & say Java for the kind of programs that I write -- backend server software with moderate to high performance requirements.
I'm a big fan of C and python and I've never used Go. My initial impressions from readings were that Go is a better C. But then I came across a Go person who was lamenting that misunderstanding and that Go is python but with better performance. What's it all about?
Also even if we compare it to C I don't like the garbage-collection thing at system level. Also what does Go let you do in terms of garbage collection that cannot be done with a C gc library (which anyone can use if they want but then also have the choice to do raw/manual memory management if they want too).