The Go Programming Language and Environment
cacm.acm.org
cacm.acm.org
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.
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.
With python binding? Or pure Go? It seems impossible for data scientists to all switch to Go
I can’t help but wish for at least mature dataframes
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).
If we're comparing it for system performance I'd expect comparisons to other high level compiled languages like Rust, D or C++.
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++.)
I can't imagine many of these being around any more though
> 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.
- Netflix tech blog: https://netflixtechblog.com/ready-for-changes-with-hexagonal...
- Wikipedia: https://en.wikipedia.org/wiki/Hexagonal_architecture_(softwa...
- Article by the inventors themselves: https://alistair.cockburn.us/hexagonal-architecture/
It's definitely not a square, and a circle would imply no difference from either point of view of the circle..
At least that was always my assumption on that lol.
- Parallel execution / multiple threads.
- Handling of blocking system call and network I/O.
- Handling of blocking user level (on channel) calls.
- Scalability.
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.
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.
Naturally in such scenarios Go does a better job.
Whatever floats your boat, man. You're free to keep using C.
I don't hide behind throway accounts, and you snarky remark regarding C only proves the point how little you know of my HN history.
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.
I'm all for large standard libraries. Implementing things in the language instead of stdlib on the other hand usually smells bad.
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.)
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.
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.
Never mind decent or multi-platform, is there any built in facility for developing a GUI?
The Go version control history has never contained the word GOPROJECT. Maybe you meant GOPATH?
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.