Go 1.11 Beta 3 is released(groups.google.com)
groups.google.com
Go 1.11 Beta 3 is released
https://groups.google.com/forum/#!topic/golang-announce/Q5N8mPD9dUM
16 comments
What do people use go for specifically? I haven't ever been able to work out the use-case that Go is meant to fill.
Go excels at:
- Anything that talks to a network (webservers, load balancers, caches - due to the fantastic built-in support for everything you eed, and concurrency primitives)
- CLIs (static linking and cross compiling make distributing binary CLIs a piece of cake)
- Gluing stuff together (it talks C, and all your favourite libraries are probably already available (gRPC, protobuf... etc)
- Munging data (expect orders of magnitude speedups over Python)
Go is bad at:
- GUIs
Why consider Go over other things?
- For me, Go is "the language with the least BS" there is. The "let's just get some engineers writing some code and ship it" story is literally miles ahead of Python/C++/Java/X language. It has been painstakingly crafted to minimise friction onboarding, building, testing, upgrading, and deploying.
- Anything that talks to a network (webservers, load balancers, caches - due to the fantastic built-in support for everything you eed, and concurrency primitives)
- CLIs (static linking and cross compiling make distributing binary CLIs a piece of cake)
- Gluing stuff together (it talks C, and all your favourite libraries are probably already available (gRPC, protobuf... etc)
- Munging data (expect orders of magnitude speedups over Python)
Go is bad at:
- GUIs
Why consider Go over other things?
- For me, Go is "the language with the least BS" there is. The "let's just get some engineers writing some code and ship it" story is literally miles ahead of Python/C++/Java/X language. It has been painstakingly crafted to minimise friction onboarding, building, testing, upgrading, and deploying.
What specifically keeps the BS away in Go? I feel like a lot of languages would try to claim that they are low-BS.
I’ve been writing Go at work for about a year now. I have built a VoIP gateway, an HTTP API, an SRGS parser, and a modified beam search algorithm for a deep learning speech to text pipeline. I would say there are a few moments along the way where it started to click how awesome Go is (the only reason I chose it in the first place is because it was the only internal SDK I had access to).
1. The first time I had to design a concurrent module. Goroutines and channels are amazing. In most cases you still need to dress them up a bit, but the first class support makes it really easy to start simple and add as needed. In fact, as I type this I feel that that is a general theme of the language. It kind of urges you to start simple and iteratively improve things.
2. Cgo. Cgo has a lot of mixed opinions, but I am on a team with very few resources, so my output in terms of volumes of code is limited. I have been very thankful that I could both link in existing C dependencies into my project, and also build my project as a C library for other existing projects. This again, allowed me to start small, and slowly rewrite the important pieces in Go when it was worth it.
3. Pprof. That tool is amazing. There’s some really good YouTube demos of it so I won’t go into detail about it, but particularly for algorithms, this tool has helped me speed up certain parts of code by a few orders of magnitude, essentially making them practical for real world use.
4. The build system is fantastic and very fast (when compared to the aforementioned C / C++ projects)
There are definitely more reasons, but I love Go primarily because it feels like one of the most pragmatically thought out language that I’ve ever used. It has lots of tooling and features that make it fast to build working, robust, and fast software. It may lack some syntactic sugar and certain language features that allow you to make clean, gorgeous abstractions, but it’s a trade off that I care less and less about every day that I use Go.
1. The first time I had to design a concurrent module. Goroutines and channels are amazing. In most cases you still need to dress them up a bit, but the first class support makes it really easy to start simple and add as needed. In fact, as I type this I feel that that is a general theme of the language. It kind of urges you to start simple and iteratively improve things.
2. Cgo. Cgo has a lot of mixed opinions, but I am on a team with very few resources, so my output in terms of volumes of code is limited. I have been very thankful that I could both link in existing C dependencies into my project, and also build my project as a C library for other existing projects. This again, allowed me to start small, and slowly rewrite the important pieces in Go when it was worth it.
3. Pprof. That tool is amazing. There’s some really good YouTube demos of it so I won’t go into detail about it, but particularly for algorithms, this tool has helped me speed up certain parts of code by a few orders of magnitude, essentially making them practical for real world use.
4. The build system is fantastic and very fast (when compared to the aforementioned C / C++ projects)
There are definitely more reasons, but I love Go primarily because it feels like one of the most pragmatically thought out language that I’ve ever used. It has lots of tooling and features that make it fast to build working, robust, and fast software. It may lack some syntactic sugar and certain language features that allow you to make clean, gorgeous abstractions, but it’s a trade off that I care less and less about every day that I use Go.
Go is currently also really, really bad at dependency management but Go 1.11 is finally addressing that.
It makes sense when you want to distribute your product. I'll usually close the page when a tool tells me to use pip/gem/npm (unless it's a library intended to help with my product using same environment) to install as it means I have to prepare that environment on every server I want to deploy it including compilation tools as some dependencies of them just don't come with binaries.
You do realize that with all those mentioned tools, AFAIK, you can bundle dependencies together with the shipped product, right? Shipping to production shouldn't depend on any third-party services.
How are pip/gem/npm materially different from something like apt-get or pacman?
Why do you feel so strongly about avoiding them?
How are pip/gem/npm materially different from something like apt-get or pacman?
Why do you feel so strongly about avoiding them?
I used Go for the web server in Miln Beyond: https://miln.eu/beyond/
The choice between writing the server in Objective-C or Swift, versus Go was easy. For servers, Go is a natural fit.
Beyond's front end is a traditional macOS Cocoa application but the hard work is all handled by a Go binary.
The choice between writing the server in Objective-C or Swift, versus Go was easy. For servers, Go is a natural fit.
Beyond's front end is a traditional macOS Cocoa application but the hard work is all handled by a Go binary.
This is a very big think in golang I think! I really like to write a quick microservice etc.
And distributed database: https://github.com/pingcap/tidb
there are blogposts here detailing some use cases and experiences: https://github.com/golang/go/wiki/GoUsers#united-states
microservices, deployed in containers like dockers and orchestrated through docker/swarm kubernetes. This is the very typical setup I have seen. people love to use go because it's simple, fast(goroutines for concurrency.
web services
Really? Most webservices are dealing with untyped data at their input as well as their data sources. In this respect, Go inherits all the pain points of most static languages with the addition of having a pretty poor type system.
Further, the most common way to deal with errors in a webservice (frankly, in a lot of types of systems) is to have an outer error handler catch an exception, log the error and tell the user "oops, try again". Pain to achieve this in Go.
It's hard for me to come up with a type of system where Go is more ill suited given how much choice you have. Go for web services only makes sense if your workload is CPU bound or you need to throw cores at large block of shared memory (and you have your reasons for not wanting to use Rust or the JVM ). 99% of webservices are better off in Elixir, Node, Ruby, Python or even PHP.
Go's best use case is for CLIs.
Further, the most common way to deal with errors in a webservice (frankly, in a lot of types of systems) is to have an outer error handler catch an exception, log the error and tell the user "oops, try again". Pain to achieve this in Go.
It's hard for me to come up with a type of system where Go is more ill suited given how much choice you have. Go for web services only makes sense if your workload is CPU bound or you need to throw cores at large block of shared memory (and you have your reasons for not wanting to use Rust or the JVM ). 99% of webservices are better off in Elixir, Node, Ruby, Python or even PHP.
Go's best use case is for CLIs.
For when you need to develop RSI in an emergency.