> Although the design of most languages concentrates on innovations in syntax, semantics, or typing, Go is focused on the software development process itself.
This important fact is often missed in flame wars. No, Go is not the most expressive, performant, or pure programming language. But it is darn pragmatic and has produced amazing results in just a decade of widespread availability.
An example of that pragmatism:
> The language provides strings, hash maps, and dynamically sized arrays as built-in, easily used data types. As noted earlier, these are sufficient for most Go programs. The result is greater interoperability between Go programs—for example, there are no competing implementations of strings or hash maps to fragment the package ecosystem.
Some language enthusiasts argue that strings shouldn't exist in programming languages, because they don't actually exist -- after all, they are just byte arrays that can be decoded in a variety of ways. But in the real world, "strings" are everywhere (e.g. this comment), and it is a great benefit to having them easily available to the programmer with little to no ambiguity.
Go is a great language and every other language has a thing or two to learn from Go, but this reply sounds like a strawman argument. The article says Go is focused on the software development process, but the means to that goal is mostly nothing to do with the language proper. There are tons of programming languages with strings, hash maps and dynamically sized arrays built-in and the pragmatism doesn't well align with Go team's conservative approach towards new language features (which is great by the way, but shows that Go does not always highly value the pragmatism).
The point of Go is being highly opinionated and not being ashamed about that. Many languages start out of necessity with some degrees of opinion, but they are or will be consequently affected by external opinions in order to survive or to accomodate other needs. Many aspects of Go, either the language proper or other "results" that the article wants to pitch, are not and never unique to Go for that reason. But Go is unique in that such opinion is highly guarded and the Go team has more than enough energy to do so thanks to the main supporter, Google.
To add to your valid statements, Go has easily outperformed any other language we have compared it to in modern backend development.
We are using it for our new API iteration and see consistent performance improvements of over 40-50x the performance of Python and at least 5x that of Node, not to mention the 2x reduced cold start times of cloud functions and much smaller binary sizes.
We use it in a hexagonal architecture pattern which it is just perfectly suited for and couldn't be happier. I personally believe it is the best choice these days for business and backend logic.
Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good.
That was not the point that I am trying to make. Of course it's faster.
It's also much closer to Python or nodejs in its use-cases than C++, while still being faster. It's not meant as a replacement for other compiled languages, it is intended for backends.
Yeah Go is basically a scripting language. Most users are coming from Python, Ruby, etc. The original idea that people at Google would migrate to Go from C++ never happened. It’s used as a logs analysis tool that non-CS data scientists can write, with no fancy features at all, to prevent them from crashing batch dataflow pipelines that are running offline, seamlessly scale horizontally, and have no direct production impact if they miss deadlines. The application code for real time serving is all in C++ because Go is too slow and unpredictable at runtime, and the teams are staffed by people with strong software backgrounds. The whole “Go as a systems language” or “Go as a cloud services language” is kind of laughable. It’s like those Tik Toks that say No One: and then it’s Go fans claiming the language has a strong suit other than keeping people who haven’t passed CS 101 from crashing the batch job, productivity speed and control for concurrent real time services be damned.
Proper backends are written in compiled languages already long before Go was born, C#, Java, C++, D, Rust, F#, Ocaml, Haskell.
Anyone using scripting languages to write backends is only accumulating technological debt, increasingly writing C extensions to duck tape their lack of performance.
A lesson learned with AOLServer, Zope and mod_perl in early 2000, but it seems everyone has to face their own destiny instead of learning from others.
I was expecting a comparison in development effort rather than performance, since that's the strength of Python. System performance is not necessarily a priority of Python, and no one would expect it to be comparable to a language that compiles to machine code without using something like pypy, and even then it'd be likely to lose.
If we're comparing it for system performance I'd expect comparisons to other high level compiled languages like Rust, D or C++.
Even that is highly questionable. Try implementing hexagonal patterns with Python.. the first thing you get to read is about how that is not the pythonistic way.
Nothing against Python, it is favorable for beginners and engineers in different fields, but at the point where even Node starts outperforming Python by 10x and you actually want to implement bigger systems you might wish for something different.
I don’t see the need to specifically compare Go to either high or low level languages. It sits comfortably right between them and is perfect like that.
(This might be an opinionated comment, but I’d love to see anyone try implementing a public API with a dozen of adapters and ports in C++.)
Well, that is how we used to do, when servless was known as CGI, Apache modules or ISAPI extensions, or microservices where known as SunRPC, CORBA or DCOM endpoints.
> The libraries we are releasing come with a pedigree: many years of experience using these APIs in Google’s production environments. We’ve seen what works and what doesn’t, what designs lead to bugs, performance problems, and misuse. What you see here is what we found to be a good balance between simplicity and meeting the needs of production use and an ever-evolving codebase.
From Google's C++ open source framework, https://abseil.io, mostly accessed via gRPC, the new fashion for Sun RPC, CORBA, DCOM.
Never heard of hexagonal patterns (architecture?) but it look like a lot like what my go project architecture at work looks like. Time to learn more about it...
> Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good.
I thought that Go might take more territory from Python, especially with generics, but now I'm settling on Python<->gRPC<->Go backends for the foreseeable future.
Go will never be as expressive as Python -- for good reasons -- which is important for high-level data science (ORMs, DataFrames, viz, NNs, etc).
I don’t expect them to switch at all, quite honestly, Python is still an excellent language and super suitable. I’d just love to see at least mature alternatives be present for the likeminded. I also have a lot of trouble with Pythons inconsistency now after spending all my time in Goworld quite honestly, and seeing how we have managed to move to Go completely yet we still run a queued Python environment exclusively to send data jobs to from the Go environment..
I can’t help but wish for at least mature dataframes
(Immutable) strings being built-in is hardly unique. As for hash maps and dynamically sized arrays being built-in, instead of provided by the standard library: there is no benefit adoption-wise. The real reason is that Go didn't use to have generics, so in order to provide generic containers, Go creators bolted selected containers into the language, instead of providing the features facilitating their implementation in the standard library. It actual signals that Go creators reached the limits of practicality of the language and reached for a solution not available to the users of the language (implementing things in the compiler instead).
I'm all for large standard libraries. Implementing things in the language instead of stdlib on the other hand usually smells bad.
Yeah, I should be able to use a third-party bignum library and have it feel natural.
2022 hardware is so powerful that it’s weird that so many languages still default to overflow and rounding semantics. Those are risky optimizations that we shouldn’t opt into without a good reason.
Your question sounds provocative, nonetheless I'm going to give an honest answer.
First, let me preface that with a disclaimer that those opinions are reserved for general purpose languages. Domain-specific languages should be judged differently.
Built-in types like int don't bother me. Built-in string also doesn't bother me, because it is immutable. strings.Builder is part of the standard library on the other hand. I think this division is perfect, because I feel that anything that's denotable as a literal should be built-in. Algorithms on the other hand belong in the library.
When it comes to integer division, it's an operation which has a pair of inputs and one output. In other words, it behaves like a function. On the other hand, its most reasonable implementation is a single machine code instruction and compilers usually have a bunch of optimizations for it, which turn it into something else. In other words, I think the best option here is for it to be an intrinsic, a bit similar to how it is in Standard ML[1] or Scheme[2].
The reason for those opinions is that I think implementing things in the compiler instead of the library signal that an instance of a legitimate general problem occurred which lacked a solution in the language, and instead of changing the language to solve the problem for all users, only the specific problem with, in this case, map and dynamic array was solved, and only those specific implementations of those concepts.
As you obviously know, Go gained generics, so this is in large part irrelevant now.
Also let me state that overall I think Go is a pretty good language. I like it (with generics and without). My comment just comes from the disagreement with the quoted argument.
[1]: Tangentially, one thing I don't like in Standard ML is polymorphism of built-in operators. It's another example of a feature which language designers reserved for themselves, and did not give it to users.
[2]: I'm basing this on my understanding of the Chez Scheme implementation, which implements the division operator in the library, in Scheme itself, but this implementation relies on an intrinsic. (Assuming it's implemented the same way as other operators I've checked. I haven't checked this one specifically.)
Apologies if the comment sounded like I was trying to provoke. My point was that there is a line, and different languages draw the line in different places. It's true that ints _can_ be made more library-like, but it's also true that most people don't complain about them being built-in to nearly the same degree as, say, built-in maps.
My initial impressions back in 2013 when I started using Go was that it's development environment was annoyingly opinionated (the GOPROJECT env var crap, which is now gone). I was mainly using C/C++ at the time and for smaller tools python. Go with it's static binaries however looked like a very interesting python alternative, so I tried it anyway, and found a language that was very easy to dive into. Took me only a few days to really feel comfortable with it, which surprised me a bit.
My main take-aways, other than what is mentioned in the article:
* it was a lot easier and even a natural thing to dive into other people's and even the stdlib's code. I had been coding in C/C++ and the only time I did that was when I was tracking bugs. Now I just do it to figure out how things are done or even out of curiosity.
* libraries are source-code only. This is great for developers, and is a large reason for the previous point, but some businesses are hesitant towards this. One thing to always keep in mind here however is licensing.
* while not actively encouraged, the way you write Go pushes you towards writing reusable libraries, with just a small wrapper frontend. You see this in many larger projects you can easily integrate many in your own application.
* the standard library is fantastic, and contains a lot more than many expect, but clearly shows what the target audience is: operations and backend development.
* dependency management used to be garbage, this has massively improved. Not perfect, but better.
* Cross-compiling is a breeze. Coming from C/C++, this blew me away. Even when using CGo, which complicates things a bit, there is pretty good tooling around this.
* It's very opinionated, but most of the times, in my opinion, right.
It ended up replacing pretty much all my need for C/C++ code, except for embedded Arduino-like hobby stuff, and I haven't looked back. The main valid thing I've seen people complain about is the lack of a decent multi-platform GUI library, which I don't need, and is always a mess anyway. Web-frontends are a thing though, and goes hand in hand with Go being pretty damn good at backends and APIs.
> Go is efficient, easy to learn, and freely available, but we believe that what made it successful was the approach it took toward writing programs, particularly with multiple programmers working on a shared codebase.
A discussion on the factors that make Go successful that doesn’t include the fact that it’s designed, dogfooded, and marketed by one of the largest software developers in the world is… incomplete to put it lightly.
I mean just the name of the language proves this point. Golang was a decade old PL project when Google Go was released. But Google, enamored with the name, steamrolled over that project and claimed no one would be confused. Clearly, because overnight Go came to mean Google Go to 99% of developers, and Golang might as well have never existed.
This shows Google Go from the very beginning has relied on the clout of Google for growth and adoption. We can talk about the merits of the language, sure, but to hear the authors of Go attribute its success to its focus on the practice of software development and leave out the 5000 lb software gorilla just adds insult to injury.
This important fact is often missed in flame wars. No, Go is not the most expressive, performant, or pure programming language. But it is darn pragmatic and has produced amazing results in just a decade of widespread availability.
An example of that pragmatism:
> The language provides strings, hash maps, and dynamically sized arrays as built-in, easily used data types. As noted earlier, these are sufficient for most Go programs. The result is greater interoperability between Go programs—for example, there are no competing implementations of strings or hash maps to fragment the package ecosystem.
Some language enthusiasts argue that strings shouldn't exist in programming languages, because they don't actually exist -- after all, they are just byte arrays that can be decoded in a variety of ways. But in the real world, "strings" are everywhere (e.g. this comment), and it is a great benefit to having them easily available to the programmer with little to no ambiguity.