Go 2018 Survey Results
blog.golang.org
blog.golang.org
When you need a decent concurrency story, moderate speed, and have a problem that is concrete, choose Go. It’s a good candidate for replacing Python, Ruby, JavaScript, and smaller Java projects.
Rust is better if you need maximum performance, are building a large project where more abstraction where parametric polymorphism can help, or need thread safety. It’s a replacement for larger Java projects, C++, and C.
Generally I write more Go projects, but my Rust projects tend to be bigger and are doing very complex things like user space networking or wringing maximum performance out of a kernel subsystem or running in a very low resource environment.
Both languages have made my teams enjoy their work more. We also have empirically measured a decrease in time spent fixing bugs and other production issues, as well as reduced resource consumption (mostly from getting rid of Python for Go) and snappier cli tools that are saving us $$$$$$ in terms of time and hardware). Both languages are built for modern problems and getting stuff done.
Also Go and Rust position us to hit Wasm hard. I can’t understate how important Wasm support is and how both of these languages are already miles ahead of the competition. This is containers right before Docker. Your company should be pivoting or have a strategy to get on deck with these languages.
That’s a bold blanket statement. Besides the fact that I would die inside a little if I had to use Go every day of my life, Go is in no position to replace any of the aforementioned languages (Python, Js, Ruby, C++), let alone all of them, not by a mile.
Go also favors libraries over frameworks and is super thoughtful about using too many untested dependancies which means we don’t get stuck in frameworks that become legacy (rails) or use stuff that has security holes or that will change out from under us (npm).
The Go standard library doesn't come close to replicating the functionality of Rails, let alone the gem ecosystem of Ruby/Rails. If you don't need it, great! Otherwise, you're spending time re-implementing what already exists and probably doing a worse job of it.
Why would it? It's the standard library. Go has a massive ecosystem of third parties libraries, and unlike Ruby, which was a one trick pony, Go has libraries for pretty much anything you could want to do. It's exceedingly versatile and it has better integration into modern infra. Why? Because it's all written in Go. Prometheus, Kubernetes, etcd, terraform, docker, caddy, fleet, influxDB, synthing, coachroachDB, gogs, mino... all written in Go. Go is cloud first, and has first class support for multicloud abstractions written by the go team. It's got great support for rpc through grpc and protocol buffers both of which are much easier to use in a statically compiled C like language that resembled the protocol buffers primitives.
Rails literally offers nothing you can't get from Go, and it doesn't make you pay for the stuff you aren't using. With Go you don't write in a DSL based on the language, you just write regular Go code. You aren't a rails developer, you're a Go developer.
Why would you even compare both? You wouldn't want to create gitlab V1 with Go just like you wouldn't want to write Kubernetes in Ruby.
Does Gitea[1] count (fork of Gogs)?
I understand your point (I love Python, too), but I can't help finding some amusement in it since it has been done. :)
Except for CRMs, GUI, DB drivers with the same feature level as JDBC or ADO.NET, Office/PDF docs (full spec not hello world stuff), GPGU, 3D game engines (Unreal/Unity/CryEngine,...), ...
Modern infra is the NoSQL of 2019.
I actually try to use as few libraries as possible. Unlike the C# and Java developers I actually know how to code and can whip up something to do exactly what I need in the same time it takes you to read your Javadocs.
If everyone rewrites their own, nobody will ever help you with yours.
citation needed
Performance wise they seem to be pretty similar too. Of course not for startup time in serverless environments but for most server applications.
It sounds like we are down to productivity (and developer happiness) which are a bit unclear and probably different for different teams and organizations. I would guess that large organizations will get into problems if they switch everything to go and then have to re-train all developers, or hire new ones.
That said there are always edge cases, and I have run into places where the only Java library I could get was proprietary, which is pretty usual for Java and pretty rare for Golang.
As you many already know the authors of Go are bell labs folks who practically invented hacking and showing up large enterprises (Multics), so there is a hacker mentality in the Go ecosystem that makes ditching libraries and writing a little bit more code attractive to Gophers. I highly encourage anyone learning Go to try to adopt this mindset, Russ Cox has a great blog post about the dangers of depdancies that are often easily dismissed by the Java and Javascriptors.
As for resource consumption Go and Java generally execute at the same speed but that’s where the comparison ends. Java has been trying to modernize in some ways but they have fundamental barriers over a statically compiled language, and in typical Java fashion there’s a lot of finger pointing at Jigsaw and Vert.X as answers to Java’s failings, but the truth is that the former has been in development for years and the latter is massively complicated for Java’s target audience. I believe they are also working on fibers, but again that’s far down the line.
However, Ruby on Rails still has use cases that it's better suited for than Go. Other languages, too, have their uses.
Please don't trash talk other languages just because you have a favorite. It's unprofessional.
If there are use cases where Rails is a better fit than Go, than by all means make your argument and I'll make my rebuttal. Maybe we will both learn something, or maybe someone who reads the discussion will learn something. Not every tool is useful, and not every useful tool will be useful tomorrow.
Hypothetical situation: a company has a large and complex Ruby on Rails application that is its primary revenue stream. All of its employees are well-versed in RoR. The operations team consistently reports performance to be within acceptable ranges, and customers are happy with the product.
This scenario is common. Just replace "Ruby on Rails" with any other language/framework.
Staying with the existing ecosystem is the ideal choice for the business, rather than rewriting everything in Go.
So they task one or two engineers to learn Go. They learn Go in one or two days, and rewrite some scripts in Go. Big success, the scripts are much faster and are statically typed. Then they decide that for a new piece of functionality they'll write it as a service. Since Ruby and Go are both officially support grpc languages, it's easy to connect them using a protobuf schema, and have the RoR app call out to Go.
Slowly over time, more new features are written as small Go services, until eventually everything in the RoR app is legacy, or can be replaced by any API gateway.
Now if the company needs to switch again, they can just rewrite individual services in a different language.
To put it another way - if my 2007 Honda Accord gets me to work reliably, why should I bother to buy a 2020 Tesla Model S?
In larger companies, spending less on gas can also save you a lot of money. If I can write a Go app that doesn't require as much AWS compute, or have a type system that lets me spend less time on bugs and more time on features, that's hitting my bottom line.
>we don’t get stuck in frameworks that become legacy (rails)
And now advocate
>Go has a massive ecosystem of third parties libraries
What is so special about these libraries that prevent them from becoming legacy?
Libraries are just collections of functionality that you can mix or match. Good libraries are framework or paradigm agnostic and are very unmagical in their interface.
Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot.
>Frameworks trade choice for supposed convenience.
It's not just convenience. By coalescing on one standard set of libraries it becomes much more likely that those individual libraries will be maintained.
>Libraries are replaceable, frameworks are usually not. In Go, if you use an interface to abstract the library calls you need (which is trivially easy to do) you can easily replace any library in your code. But ditching Rails is a ground up rewrite of your entire application and chances are you have read entire books on Rails so switching is going to cost you a lot.
What you describe in the first half is effectively recreating Rails. Expending that initial cost in order to avoid the possibility of expending it later doesn't make sense.
And you're not right about the cost of switching from Rails. You can use pretty much all the code you write without Rails. The effort will come in creating whatever it is you want to use to replace Rails.
Go doesn't have a proper, complete type system. This means entire classes of preventable bugs are not prevented by the compiler. Yeah, its fast, but you can pass in null instead of object references and the compiler won't even bat an eye. Not to mention the extremely verbose error handling and the lack of abstractions all around (no sum types, no iterators, no array filter/map, etc) despite being more "high-level" than Rust in layman terms.
This is nonsense. There's no definition or checklist that defines what a complete type system is. In that vein, Haskell doesn't have a proper type system because it lacks dependent types, and a bunch of other features that are only available through language extensions.
We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach. Rust simply takes more investment to learn, and more time to master, and while I agree that investment pays off 1000x, and that Java and C++ should stop existing, Go is a better fit for the people who just want a productive, reasonably efficient language that can get stuff done. Having a very simple hammer like Go that limits what people can do and sticks to what people already know is useful and beneficial.
The Go programming language and the compiler have too many soundness holes, therefore I call the type system incomplete. When you can pass in a null literal in place of an object and the compiler doesn't stop you, it goes against any common sense. Not to mention the pervasive use of reflection (interface{}) due to lack of generics.
Allowing null pointers to exist in a new programming language is a decision to ignore decades of progress in pl theory and type system research. It makes sense for google knowing the motivation behind Go, but telling people to avoid Rust unless they need polymorphism or performance is disingenuous at best.
> We are still not at a place yet where the from first principles, type driven approach is going to always be the right choice over the hack out code approach.
Why not?
C# 8 will fix this by switching defaults (opt-in due to backwards compatibility), and Java has type annotations since ages.
Hence why it feels wrong to a new kid on the block to ignore what the language community at large already agreed were design errors.
"By 1960, we had a long list of amazing languages: Lisp, APL, Fortran, COBOL, Algol 60. These are higher-level than C. We have seriously regressed, since C developed" - Fran Allen
Why do people pushing those claims think a go program compiled down to native executable is slower then rust Is it the rust compiler is better ? Is the go stdlib slower ? Is it the gc
The GC is going to add some overhead is it that bad for most uses except for real time critical large s/w
- The Rust compiler uses the LLVM backend, which is generally more aggressive about optimizations and code generation. The Go compiler is a custom compiler (I think plan 9 inherited) and as of fairly recently didn't do some optimizations that are fairly common otherwise (non-leaf inlining).
- Rust as a language heavily favors automatic (stack) allocation, and does not favor complex object graphs, so that will often help make algorithms more cache-friendly. In go, stack allocation is strictly an optimization. This is somewhat defeated by the common use of 'smart' pointer types.
- Due to using segmented stacks, the function prologue/epilogue is a bit more involved in go, than it is in a language like rust.
So with rust, it is - with some work - possible to have code that executes as the equivalent C code would. I guess in go you could too, but it'd be quite a bit harder, and go against the grain of the language.
Compared to the performance of a typical interpreted dynamic language, this is a fairly marginal difference however.
Yes, there's can be benefit to starting from scratch with a different language w.r.t. training new teams with good habits and skills from the start.
But going into Rust just because it's fashionable at the moment is a recipe for pain several years down the line.
If you want a working pain-free solution learn C++17 instead.
A solution to what, exactly? I'll admit I haven't worked with C++ in awhile, but I'm skeptical of C++AnyYear being "pain-free". What do you like in C++17 that you feel is lacking in Rust?
C++ 17 is still a mess. You still lack a proper package manager, type constraints, modules, sane lookup rules for function calls, thread safety, a proper monastic future type, I could go on.
Also most people won’t see C++ 17 or 14 for another decade. Even if the language decides to start bolting on more features the ecosystem is still very slow.
No, it is not.
> proper package manager, modules
That's an OS usability issue, not a language problem. Personally, Nix solved this for me.
> type constraints
C++ has type constraints, and ones that actually work. I suspect what you call 'type constraints' is something that can't exist if you understand the difference between 'run-time' and 'compile-time'.
> sane lookup rules for function calls
A very minor issue. If you don't like function overloads, then don't use them.
> thread safety, a proper monastic future type
Please no. The kind of 'thread safety' you want destroys the benefit of using threads in the first place. C++ threading is perfect as it is.
> Also most people won’t see C++ 17 or 14 for another decade.
Frankly, I don't care about these twisted people stuck in enterprise hell.
Coming from Java, I find that I don't miss generics and exceptions as much anymore as I thought I would :)
Rust is not a simple language by any means -- it's a great replacement for C++, but I'd be pretty surprised if it displaced the popular general purpose languages (which Go has actually managed to do.)
Still plain old Java, .NET and C++ as always.
FYI I'm language agnostic, but I'd like to see c++ eventually replaced. .NET is currently looking good, and I'm ambivalent on Java, but I think there are valid reasons to be looking at go right now,if not rust. They both seem to be tuned to modern hardware design despite the hype.
They are today's NoSQL.
I'm guessing your job relies on people sticking with Java SQL stacks.
Unity is increasing C# popularity, though. So maybe .NET is not going away, at least yet.
It maybe won't go away, but I think it lost a lot of relevance.
UWP isn't going anywhere, as much as haters would like to.
I used WPF in medical applications like you said, but that was around 4-5 years ago.
Currently I believe UWP will never significantly take off on the desktop outside of Microsoft.
https://www.c-sharpcorner.com/forums/how-many-c-sharp-develo... (2014)
It doesn't really say much given the selection bias.
Say a person said they're mostly writing finance software and Go isn't a language they'd prefer to use for their next project. Those two data points on their own also don't tell much - but if multiple people answer with that combination the Go team knows that they aren't covering the needs of the finance sector appropriately. With that knowledge they can e.g. request more information from those people and start working to fix those issues.
This is true for anything where Go is underused or not used and the bias here still stands, since those people are very unlikely to be represented in the survey.
Go works very well in domains with a well-defined and limited set of entities.
What causes OOP to be well suited for finance's use case?
What are the short-comings of structs/interface methods that Go! provides in the financial space?
If Go! had generics, would that change it's suitability for finance?
I would think that first-class concurrency would be useful in that space, is it?
“Things” in finance are amenable to the classical PIE of OOP. Many concepts, e.g. financial instruments are extended version of something that was invented earlier. E.g. you have an abstract concept of an interest rate swap and specific versions of it (like fixed-fixed, foxes floating, cross-currency etc). This works pretty well with inheritance and polymorphism.
When you talk about money, finance is very particular about what you can do and what you cannot do. E.g. if money are subtracted from one account, they should appear in another, or balance cannot go negative. It is easier to enforce rules like that on a language level with encapsulation.
> If Go! had generics, would that change it's suitability for finance?
I believe so. You have built in “generics” for most popular collections like maps and arrays, which is fine for command like utilities and lots of system-level software. But in finance (an other problem domains tbh) you often need a generic version of a more complicated data structure, e.g. dataframe, tree, implementation of flyweight pattern, or data cube.
> I would think that first-class concurrency would be useful in that space, is it?
Good support of first class concurrency is useful everywhere. Just so it happened that given that C++, Java, and C# together reign in different domains of finance, we are already quite comfortable with concurrency primitives of these languages (usually some kind of multithreading)
You can define an interface with methods that allow objects to be processed in a more generic fashion.
I think that more than anything it would require a change of mindset that people understandably don't want to deal with.
As well as other options. [3]
I like to imagine that the "no generics, no way" crowd would never use the stairway in their building if the elevator broke down.
[0] https://github.com/clipperhouse/gen [1] https://github.com/cheekybits/genny [2] https://github.com/cosmos72/gomacro [3] https://appliedgo.net/generics/
Go's building architects decided an elevator was superfluous, as everyone should walk 20 stores high every single day, it is good for their health.
Java/net are just not fun and the mentality of the developers seems off-putting to a lot of new devs and those seeking to move fast and ship stable.
I wish the package situation for Go was better for SublimeText. Currently most of the worthwhile golang packages that add vet, goimports, fmt, etc support are either abandoned or buggy. Margo bailed on using Package Control so it's difficult to install, not to mention buggy.
I've used VSCode for a while but it chokes sometimes and you can't beat the speed, ease, and power of SublimeText.
I just maintain my own on-save hooks, build systems and plugins to integrate various quality-of-life Go tools. With the benefit of being able to tailor any such functionality to exactly the way you like to work and nothing more, it's far less effort than it would be to create the all-singing-all-dancing comprehensive package that is absent.
As a system guy, I am also happy to follow two OS projects in these two:
[1] https://github.com/mit-pdos/biscuit [2] https://github.com/redox-os/redox