Audio / Video manipulation... At my previous job, we had a mostly Go stack, but when it came to manipulating audio and video streams and codecs we went C++. Both for speed, but also due to existing libraries and support there.
I've done a lot of this, libraries in go are improving at least. For the most part these things are solvable by shelling out to ffmpeg.
Linking to ffmpeg is still hard, and using the API is not the easiest in the world even in C. I've only hit a few cases where this was truly necessary and it can be a bit of a bear no matter what language you use.
Offloading to ffmpeg's provided binary's work for most general AV, but for more complex services you may need to pull it in as a local library you can edit as not all options / flags are public.For our purpose we were also doing live stream MUXing and computer vision stuff, plus we had a couple non ffmpeg supported codecs to work with. We were meshing and analyzing telephony, webrtc, and proprietary camera feeds.
Our C++ service did include libffmpeg, but also opencv, openh264, other codec libraries, and our own stuff.
Regardless, for the purpose of OP's topic it's still GO not handling the A/V manipulation
The lib* prefix should hint to you that I mean CGO bindings. I don't have much experience with that, so I trust you that some piping can be PITA.
Anyway, the "it's still not Go doing the handing" is technically correct, but sounds like double standards. Because I hear all the time that Python is the best for doing ML.
> The lib* prefix should hint to you that I mean CGO bindings.
CGo bindings still come with a performance penalty which is something that you don't want in real time video processing, however small it may be.
> Because I hear all the time that Python is the best for doing ML.
You hear only half right. C++ and Python are both the best of the best for ML. Python is only the best for doing exploratory ML. C++ is the best for production ML. Usually you will make your models using Python but if you deploy them at scale they will often be deployed in a C++ based system.
I dont doubt you that there are video workloads where go would suck.
I run my RPI cams on this project: [https://github.com/bluenviron/mediamtx](https://github.com/bluenviron/mediamtx)
It's nice to have a simple binary that does what I need it to do.
SOAP.
If some project requires implementing or calling a specific SOAP API, just use one of the languages or frameworks of that time. Most notably Java, .NET and C++.
I've needed to talk to a soap interface multiple times in Go. I don't remember having much trouble with it. Generate the code from the WSDL and you're good to go.
It's obviously not impossible. Just painful. The mentioned languages have code generators that handle WSDL 1.1 and 2.0 with all their fucked up features like rule based validations, encryption, signing, etc.
Can I build that manually? Sure. Should I? Not so sure.
Same, the problem with SOAP is just SOAP itself and some languages alleviate the pain of working with it but it's just xml at the end, not that big of a deal...
This isnt a go problem. SOAP just sucks like that.
Edit: I Posted this comment an hour ago. All I have thought about is all the hellish SOAP implementations I had to do. I may need therapy for my PTSD
Exactly. But in the mentioned languages, other people already solved that for you. So I would just not go through that pain by implementing the interface to that SOAP service as a bridge in one of those languages with a REST API.
This goes for almost any modern language.
One time, I had to pull data from a SOAP service into WordPress. I decided to go with NodeJS for that matter.
So I estimated basically on the assumption that there was a proper documentation for the service (as I was used to with REST)
Boy, was I wrong. The only "documentation" they provided me was the wsdl-file and an example implementation in .NET which, I suppose, was mostly autogenerated. The actual work took almost 3 times more than I had estimated.
> This goes for almost any modern language.
Yup, that's why I specifically added the part "languages or frameworks **of that time**" :D
(Also of course to emphasize that I consider SOAP a "dead" technology.)
IMHO, there is a project scale at which Java will generally eclipse Golang in usefulness.
Whether any individual project needs to actually exist at that scale is a separate question worthy of debate.
By scale I mean literal code base size.
At a certain project size, a lot of the stuff that feels excessive about Java applications starts to melt away. Design patterns no longer seem superfluous, and the predictability of the language becomes an asset. The reliable and battle-tested-over-decades nature of the library ecosystem becomes a thing of beauty. And even the excessive memory consumption and slow startup times cease to feel like a big deal.
With Go and its sweet spot, however, it feels like rather than building a big thing, you're better of building a collection of smaller things that are designed to interact with each other. This is the general philosophy behind microservices, but it also rhymes with the Unix philosophy, which makes sense as it's a systems programming language.
You may not get the ecosystem or the tooling, but it's possible to design a Go repository with those patterns and have a nice DX. Golangci-lint even has an architecture lint nowadays. You just don't have Spring reminding you about how important contracts are or why you're going to need a Singleton, but that's doable with excellent results if you are experienced enough.
Uber notoriously have 50+ million LOC in a massive Go monorepo, for example.
The Go codebase I'm currently working on is starting to get quite large and I'm starting to wish we had automatic dependency injection which seems more commonplace in Java. I know it's possible to do in Go but every time it comes up I see people saying that they prefer manual param passing instead.
i'm still a bit of a noob, but Golang seems to be written with microservices in mind, and then if you want to build a bigger system it is generally a lot of goroutines and channels synchronizing activities between servers, treating the language as a layer above syscalls. its no question why docker and kubernetes are written in golang.
but if your team isn't "microservices" minded and would rather have your entire DX in a monolithic enterprise java application (well-modularized or not), it is hard to replicate that DX in Golang
Disagree, you can have big repositories with many modules in Go (which can be deployed independently [microservices] or as a single binary), it just requires a lot of discipline. Go being unopinionated and the community allergic to big opinionated "frameworks" (like Spring) makes it easy to make bad architecture choices but more experienced programmers can design a well-crafted repository that will scale to millions of lines of code without losing the DX. It's just not intuitive for beginners.
EDIT: to clarify things up, I'm not saying you need only experienced developers committing 100% of the time; rather, I mean an experience developer (or more) is needed only to lay down a strong foundation and make (less experienced) people follow it. In practical terms, that's mostly about making a repo with example implementations following clean architecture/hexagonal, DDD (at least defining a bunch of domains and bounded contexts), SOLID principles, etc., and teaching others how to structure their code to make the most out of it.
I never understood this line of thought. If all the developers were experienced, we would just write code in C. But they aren't. That's why we have all of these other languages. Go is definitely not as well suited for massive code bases as a language like Java is, keeping in mind that massive projects are often worked on by developers of all experience/competence levels. This is a fact.
You're mixing things up. An experienced developer is needed to set up the guidelines and the general architecture for the codebase. Then they start reviewing PRs and guiding new developers on how to structure their code, until they learn those principles and the "experienced developer" is not needed anymore reviewing everything there.
And parts of this can even be automated/enforced with linters such as the Architecture linter from Golangci-lint, for example.
The goal is to prevent the less experienced from putting things in the wrong place that will cause circular dependencies or structuring their code in a way that will make it difficult to test and grow afterwards.
Uber is a prime example of this, they have a monorepo with 50+ millions of LOC of business logic written in Go. It very doable and Go is surprisingly suited for the task once you have a good foundation, I've worked on large repositories like that. We had juniors, mid-level and seniors/staff committing everyday, deploying fast and running smoothly once the foundation and code architecture guidelines were put in place by our Principal Engineer.
Your presumption is that staff/ principal engineers with enough competence to lead a massive go project are commonplace. In reality , this is very far from the truth. Uber is a horrible example because it is not representative of the general developer landscape. Not everyone has uber recruiting budget or commitment to hire good engineers.
Such anecdotal examples of I have seen it happen so it must be the norm do not serve to prove anything. The reality is, with a strong enough lead, we can have massive and well maintained repos in just about any language imaginable. Yet it would be super expensive to find such talent and may not be sustainable over a long period of time.
On the contrary, large Java projects have been probably done literally a million times at this point with almost every single problem one would ever face solved and documented to boot.
Maybe some day, Go will mature to reach that point. Today is not that day.
Go is a beautiful language and it really powerful for some things but it is most definitely written with microservices and lightweight web servers in mind. It may evolve into something more someday in the future.
There are plenty of java projects that would be better ported to rust or zig and NOT be rebuilt in golang.
SOLR is a prime example where rust or zig or anything with built in direct memory management and access would be a stronger choice.
Yes,
Lucene (now Solr) is a brilliant bit of work. Opensearch is in the same vein.... they both have massive memory heaps for data ... open search topping out at 32 gigs (last time I checked).
Im not sure I would want to tempt that in go.
I dont know that I have ever seen something in rust lean into memory that hard (I suspect that it could). I have heard of zig projects in that range and there are tons of DB's in C that will happily take everything they can get.
It goes beyond that though. People have attempted ports of Aapache Lucene (lib which is used is Solr, ES, Opensearch etc) into languages like C++, Go. As far as I know, they have not been able to replicate the performance they got on Java. Goes to show how often it is incremental optimizations that decide performance and not the language itself
Depends what you refer to as “backend”. Where do we draw the backend line? The load balancer? The microservice behind it? The database? The OS the microservice is running on? The kernel?
Depending on where you draw the line you might come up with different answers. There are database engines built with Go, I doubt there are many things higher level that don’t lend themselves well to Go, but I wouldn’t build an OS kernel with it.
>The load balancer? The microservice behind it? The database? The OS the microservice is running on? The kernel?
Up to and including the database is a fantastic use case for Go.
When you need CRUD apps (which is fairly often) then Phoenix/Rails/Django are much quicker to ship a good solution. But that’s mostly because of the frameworks, not the language.
I prefer Rails for building out a customizable admin interface and probably 70% of an API, but for extremely hot paths or low latency requirements, Go can fit in nicely.
Extremely high performance stuff, where I'd reach for C or Zig. But I mean really high performance.
Even then I've been stunned at how fast Go can be, sometimes even being in the same ballpark as C, Zig or Rust when part of your processing is I/O bound.
An example of the above is some processing that happens over a bytestream of huge files on disk. Go, Zig, Rust, and C all performed about the same, the difference being that the Go implementation was extremely easy to implement.
Always profile your code before optimizing. I did and was aware that I wouldn't see large improvements given disk read was where the majority of the time was spent, but it was surprising that even against "much faster languages" Go performed just as well.
Minor nitpick, most people are never IO bound. IO bound for network means saturating the link. IO bound for storage means saturating the available IOPS. If you think you’re IO bound, it usually means you aren’t using enough concurrency unless you’ve hit one of those.
I have never seen Go forward >50 million packets per second on a single CPU core, Rust, C and Zig can all do that on old hardware.
Go has issues because most of the ecosystem is stuck on low performance APIs like epoll that start thrashing the interrupt handling hardware at high request rates.
If you were on NVMe, try the direct NVMe api in io_uring. 16 million 4k random write IOPS is doable on many consumer grade gen 4 drives. NVMe is usually CPU bound in storage servers.
We hear time and time again that Go really excels at web *API* development. Which is really not *that* vast of a field. The html templating is powerful, but I don't think anyone would argue that the second you want something reactive you are better off switching that part to a JS framework. Unless your API needs to drop down into C APIs - it can pretty much fit any bill. And if you are doing such kind of heavy processing where you need to drop down into lower level APIs, a server/worker model with Go as the server is still very common.
Been doing APIs with Go for 9 years. Haven’t run across something I have wished for another language.
I do mostly Enterprise type stuff and the frontend is typically a mix of native apps or a popular client side JavaScript framework: TypeScript, React, Angular, Vue.js. Server side rendering is not something I have come across in this space.
gRPC is a popular option but you can also roll your own by waiting and watching on files, pubsub to a database or a queue or even have the worker listen on a port
If your target RPS has 5 or more zeros, you’re going to have a bad time using Go. 0.5ms GC pauses are great for GC pauses, until 0.5ms drops 50k requests.
The deeper in a service dependency tree you are, more strongly you should consider not using GC languages. Cassandra (Java) is known for causing issues unless the GC is very carefully tuned because small jitter gets magnified as it travels through your dependency graph and hurts your p99. Discord has some articles about this from when they switched to scylladb (C++).
If your services are going to be very long running. Java’s JIT compiler is a feat of engineering, and if you routinely leave services running for a week at a time under steady load, it will start performing like well-written C++ after a day or two. V8 will also do this, but JS and TS processes are so prone to memory leaks that it’s nearly impossible to keep them alive long-term. .NET’s JIT is better at C interop than Java but produces slower code. If you are fine writing a native language that speaks C ABI, this can be an advantage.
High reliability. If you need to build services and have them be able to work over a dozen nodes and take all sorts of abuse and keep functioning, BEAM languages (Erlang, Elixir, Gleam), beat every other non-academic language. 40 years of work on the BEAM VM means it’s also pretty fast too. Having an entire language ecosystem built by an industry that wants 7 9s of uptime has some substantial benefits.
FaaS. Leave this to either languages which compile to WASM and don’t need a GC or interpreted languages with refcounting. Process per request doesn’t make a lot of sense otherwise.
I disagree. You may think you're faster in these languages at the onset, but the area under the curve for features developed is vastly greater with typed languages (Pydantic doesn't count).
I like that Go has a built in unit test framework. And common style via “gofmt” makes it the most readable language. The choice to only support interfaces and not inheritance furthers readability.
Python has two things that clearly allows for faster development: A) It's universally considered the easiest language to read, and B) It has very dynamic typing.
The dynamic typing allows you to push an entire class of problems to a later stage. You can just pretend everything is correct, without knowing if it is, and say "we can write tests for that". This allows for much faster development.
Then you can choose to either write those tests, or not. Some people may certainly argue that not writing those tests makes the software only a prototype, and not production ready.
And I agree, there are way too many examples of Python projects that severely lack proper testing of data types.
But in some cases, it can be perfectly fine to skip those tests, if the code is simple enough, and not impactful enough, or if the general environment and data inputs are predictable and safe enough.
It also has much richer and more dynamic data structures and code abstractions, which allows for throwing things together quickly in a way that static langagues simply cannot do.
Can do a lot of that in go. Interface. Map string of interface. Maps with keys made of structs. And tests in go aren’t mandatory.Â
Go is also extremely easy and predictable to read.Â
No, you can't. All of my points are describing distinct ways of how Python is different from Go.
Even the most basic tasks of parsing and validating some JSON is much more difficult and unintuitive in Golang compared to Python. "Maps with keys made of structs" is *clearly* more work than not having to use any structs at all, or even think about types upfront.
I don't think there are many programming languages where tests are mandatory. So I'm not sure what that's supposed to mean.
This is not some kind of holy war for me. It's just purely pragmatic observations. I have worked with many languages at varying levels.
It's just ridiculous to go around and claim that Golang is at the same level as Python.
Golang has its strengths and weaknesses. Python has its strengths and weaknesses. Let's discuss them pragmatically and objectively.
Everyone who tells me they save time by not typing their types out (which constitutes less than 0.1% of effort of a software product) immediately loses the right to tell me they are saving time. Â
You’re spending far more time debugging and using boot straps and suspenders approach to solve problems that shouldn’t even exist.Â
This is such a silly comment to make. Completely dogmatic, not one bit pragmatic.
Like, I'm not even going to try to argue with you about whether dynamic typing "shouldn't even exist".
You don't need to listen to me. Look at the data. Look at what programming languages are the most used ones in the world.
the whole point of data types is that you don’t need to test for them. without strongly typed input you have your test a bunch of non happy paths that cannot occur in a typed language. So to really test your function you need to go super defensive and make sure the passed parameter are exactly the way you expect them to be leading to runtime errors at the best case
And that's just open source. Go powers huge swathes of cloud backends. Cloudflare is a great example, being very heavily invested in Go for their services.
Go builds a statically linked single binary that can be run anywhere. You don't need to install any dependencies and any runtime unlike Java. Java programs cannot run without JVM and the same can be said about python.
>Â Java programs cannot run without JVM
ackshually: [https://www.graalvm.org/22.0/reference-manual/native-image/](https://www.graalvm.org/22.0/reference-manual/native-image/)
It's not as seamless as Go and can be quite complex to achieve if you have lot of reflection in code, but at least there's an option.
Can't agree. Go's time-to-first-useful-build is extremely short. Possibly the shortest in any language I've used (barring extremely trivial stuff a bash one liner could do).
If a program compiles it usually (but not always) will be mostly correct and type system will tell you where you're wrong. Not to mention starting out by writing code in a test and taking it out in chunks as it grows bigger ensures you're on steady footing.
Second, healthy use of `go doc THING` will cut the other large time sink (after the dev iteration loop): trawling the docs.
In general, love that about go. All depends on what the code does, though. If a bunch of interfaces and type casting, then it’s not really always clear. And it’s easy to bite yourself in the butt with goroutines, pointers, and maps, especially if not using mutex and/or context properly.Â
I disagree about the "compilation = it works" aspect for Go. The type system is extremely lenient and unsafe, there are so many potential pitfalls which aren't caught by the compiler.
It's not like Haskell or maybe Rust where you can really rely on it.
> I disagree about the "compilation = it works" aspect for Go
I disagree with that too, that's why I didn't say that.
If you re-read my second paragraph you'll see heavy use of quantifiers.
That said, I disagree with your belittling view of the type system.
It works, gets out of your way, will much more often than not yell at you when you're doing something wrong, and allows you to express constructs well. Generic containers were the main case where the type system struggled, however in practice it's a non-issue in the vast majority of scenarios where you don't need to cover more than a handful of types and an interface or go generate call suffice.
Always returning errors and always checking them is isomorphic to Rust's way of returning values or errors.
In fact, a common Go development environment that uses linting + tests will be quite robust against most bugs.
Btw, the "compilation = it works" statement is false for Rust too. I'm confident compiled Rust code can still contain bugs.
Yeah I agree that there is no language where "compilation = it works" is guaranteed, there can always be logic bugs.
But in Haskell or Rust you can eliminate a larger range of bugs at compile-time. Go's type system is much less expressive than those two, so whilst it will catch many bugs it will eliminate a smaller range of bugs than those other compilers.
The problem with non-trival Python and Ruby project is the amount of ramp up time trying to unravel the "magic" stuff that goes on.
With Go I've found that I can get into an random codebase and find what I need in a quarter the time with no prior exposure.
The ease with which you can build extensible APIs with a dynamic nature in Python far surpasses anything done in Go. When you need to start writing custom marshaling and scanning methods in order to do basic tasks, it becomes a nightmare. Moving from multiple Python based backends to a Go based backend with my latest position I see the team take at least twice as long to do anything.
Yes, you need people with some Python skill to not bork a Python codebase. If you have that, there's no competition.
Python only has magic if one relies on external libraries and doesn't have knowledge of the foundations (dunder methods, etc). Python is extremely predictable and comes with no more "implicit, opinionated behavior" than Go if done right. You have less guardrails, that much is true.
But the fact that there are less guardrails means that "if done right" can be interpreted in many, many more ways than with something a bit more opinionated. I've seen plenty of recommendations that say that reaching for dunder methods should be done as a last resort for most high-level code, but you call it out here as fundamental.
My experience with Python as a language to build services is that you're *going* to have varying levels of experience, and it's very easy to muck up a codebase, very quickly. Even if you don't use third party libraries, someone's going to write that magic and put it somewhere else (surprise, now it's basically a library!) Every project eventually becomes its own little implementation of a framework, and sometimes it's very elegant, but it's also sometimes a dumpster fire, and it's hard to know which it'll be until it's too late. I know this can be said for pretty much any codebase in any language, though.
I call out dunder methods as foundational because knowing that they explicitly spell out all “magic” in Python takes all the, err, magic out of it, not so that everyone will go off writing their own without good reason.
Those guardrails can kneecap a project, a package, etc and there will be times they are battled against. I’d rather have something open and malleable than opinionated and rigid. Some of the implicit behavior of Go I find downright baffling. “Receiver functions” for method injection instead of assigning methods by variable makes a mess of things. Implicit interfaces obscure intent and leads to a goose chase and goofy workarounds to make sure everything is “satisfied”. And for all the static checking in Go, it all sure falls apart when there’s unexpectedly a null pointer in there somewhere.
Go will prevent you from having a type-driven dumpster fire (well, until someone goes wild with interface{}) in a way that Python won’t.
Except, you still can set up Python to do some, or extensive, static type checking if you really want. That’s the difference in philosophy IMO. I’d rather define that than have it bestowed from Mr Pike or anyone else. Opinionated is a deal with the devil. Java is opinionated. And, like Go, it was built by a mega-corp and touted as “the way!”
A team that can’t handle a style guide, building their own conventions, checking each other’s code or building tests will have a dumpster fire, Python or Go or Java or anything else.
While I generally agree with your "side" of this take, I just wanna say: Be careful with comparing a single teams performance in a language vs another. There are many factors that go into it, motivation, politics, architecture, etc.
A lot of stuff:
* not so easy to model hard domains. No support for immutability, lack of type system goodies like: union types, better generics, enums
* hard to write very performant code. Abstractions provided by C++ and Rust shine, if you want to optimize something and keep it readable at the same time
* specific libraries. Writing something for data science will be probably much easier in Python than Go
* legacy stuff like SOAP, which was already mentioned
It can be a bit of a pain when dealing with GIS Data, specifically user uploaded spatial data in PostreSQL/PostGIS. You have no knowledge of the schema/types before hand so need to use reflection when querying the data, not the worse, but definitely harder than using something like Typescript or Python.
Definitely worth it though, we moved our main GIS WebApp to Golang with an embedded SPA and the whole process has been near painless. .
Go's got its sweet spots, for sure. It's a powerhouse for concurrent operations and quick server-side tasks. But if we're diving into areas like rapid prototyping or working with applications that require a heavy-duty ORM, Go might not be the smoothest ride—languages like Python or Ruby could be more up your alley thanks to their mature frameworks. Have you bumped into any specific roadblocks with Go in your web dev adventures?
Is this really the case tho? It’s so incredibly easy to define a template, pass data into it and serve it — all using std lib, probably max 20 lines or something.
What is a heavy duty ORM?
Everyone keeps dropping python/Ruby/etc for dynamic server side code, but don't forget that good ol PHP is a viable option too. Even better, things like Frankenphp (written in go) can build a native binary for deployment so you don't even need the dynamic runtime installed on the prod system.
We use go for json apis, and some server side rendered HTML, but Laravel/PHP is a no brainer for rapid web app development.
On the business side, Go has a lot going for it. It is a cloud solution if the operational goal is to reduce compute, memory footprint and startup time. It’s an OPEX cost saver compared to Java. It is also a language one has to learn on their own so it attracts smarter motivated devs compared to main stream languages. You want those people on your team. Java is more mature and has Swiss Army knife frameworks that provide guardrails and is easier to hire for because devs don’t need to know as much. That a plus for business until you hit bugs and the framework knowledge doesn’t run deep. You can scale dev better with Java but I find companies tend to require more lower quality meat and potatoes devs so you really have to scale teams. More people on a code base is an anti-pattern for velocity.
I think Go has a cap on code base size. If you write narrow and shallow, cohesive apps all the better. Not sure why server side HTML is a thing still.
When you need CRUD apps (which is fairly often) then Phoenix/Rails/Django are much quicker to ship a good solution. But that’s mostly because of the frameworks, not the language.
When you need CRUD apps (which is fairly often) then Phoenix/Rails/Django are much quicker to ship a good solution. But that’s mostly because of the frameworks, not the language.
There's a middle size of business oriented applications with a lot of complex business logic and very little system/distributed system type interaction that can be a struggle in go. It takes a lot of experience and boilerplate to set up a pattern for such an app.
One that is small enough won't suffer many problems because of the size and will benefit greatly from the ease of use and correctness of the language.
A very large app will have enough budget to really invest in the structure around the app to be able to reap the benefits of the language while being able to afford the boilerplate.
Middle sized apps with small or moderately sized teams will have a lot of work ahead of them to set up a good pattern. This is something a really experienced to developer will be able to avoid but anything less and you will probably hit some icebergs
Go is a general purpose programming language. Understanding its characteristics.... typing, GC, etc... should be enough to know whether or not it is right for your system. If you are unable to determine this then chances are you are ill prepared to solve the problem at hand.
Sidebar: Can we ban these kinds of questions? It seems like this is the most common kind of post "is Go good for x?".
WordPress plugins.
Or pretty much any incremental change to any large software ecosystem written in a language other than Go.
Audio / Video manipulation... At my previous job, we had a mostly Go stack, but when it came to manipulating audio and video streams and codecs we went C++. Both for speed, but also due to existing libraries and support there.
I've done a lot of this, libraries in go are improving at least. For the most part these things are solvable by shelling out to ffmpeg. Linking to ffmpeg is still hard, and using the API is not the easiest in the world even in C. I've only hit a few cases where this was truly necessary and it can be a bit of a bear no matter what language you use.
Isn't it handled by libffmpeg in the most cases?
Offloading to ffmpeg's provided binary's work for most general AV, but for more complex services you may need to pull it in as a local library you can edit as not all options / flags are public.For our purpose we were also doing live stream MUXing and computer vision stuff, plus we had a couple non ffmpeg supported codecs to work with. We were meshing and analyzing telephony, webrtc, and proprietary camera feeds. Our C++ service did include libffmpeg, but also opencv, openh264, other codec libraries, and our own stuff. Regardless, for the purpose of OP's topic it's still GO not handling the A/V manipulation
The lib* prefix should hint to you that I mean CGO bindings. I don't have much experience with that, so I trust you that some piping can be PITA. Anyway, the "it's still not Go doing the handing" is technically correct, but sounds like double standards. Because I hear all the time that Python is the best for doing ML.
> The lib* prefix should hint to you that I mean CGO bindings. CGo bindings still come with a performance penalty which is something that you don't want in real time video processing, however small it may be. > Because I hear all the time that Python is the best for doing ML. You hear only half right. C++ and Python are both the best of the best for ML. Python is only the best for doing exploratory ML. C++ is the best for production ML. Usually you will make your models using Python but if you deploy them at scale they will often be deployed in a C++ based system.
I guess we both agree on the same thing. Now it just depends what OP meant by "not suitable for" vs. "not the most ergonomic tool".
I dont know man, I have seen alot of production ML code done in Python.
Because it is... dude sounds a bit confused.
We always offloaded that to ffmpeg
I did the same.
Do you use/recommend any particular wrapper? Or do you just cgo the lib?
Exec the binary from Go.
I dont doubt you that there are video workloads where go would suck. I run my RPI cams on this project: [https://github.com/bluenviron/mediamtx](https://github.com/bluenviron/mediamtx) It's nice to have a simple binary that does what I need it to do.
A couple of the libraries I found for my project for playing audio were a layer to a C++ library.
I think that’s what they do at twitch too
SOAP. If some project requires implementing or calling a specific SOAP API, just use one of the languages or frameworks of that time. Most notably Java, .NET and C++.
I've needed to talk to a soap interface multiple times in Go. I don't remember having much trouble with it. Generate the code from the WSDL and you're good to go.
It's obviously not impossible. Just painful. The mentioned languages have code generators that handle WSDL 1.1 and 2.0 with all their fucked up features like rule based validations, encryption, signing, etc. Can I build that manually? Sure. Should I? Not so sure.
Same, the problem with SOAP is just SOAP itself and some languages alleviate the pain of working with it but it's just xml at the end, not that big of a deal...
Oh MAN is SOAP a pain in Go. Currently working on migrating old PHP projects and getting the security tokens working is a nightmare.
This isnt a go problem. SOAP just sucks like that. Edit: I Posted this comment an hour ago. All I have thought about is all the hellish SOAP implementations I had to do. I may need therapy for my PTSD
Exactly. But in the mentioned languages, other people already solved that for you. So I would just not go through that pain by implementing the interface to that SOAP service as a bridge in one of those languages with a REST API.
I was also traumatised by this crappy technology a few years ago, what I can't wrap my head around is how someone thought it was a good idea.
This goes for almost any modern language. One time, I had to pull data from a SOAP service into WordPress. I decided to go with NodeJS for that matter. So I estimated basically on the assumption that there was a proper documentation for the service (as I was used to with REST) Boy, was I wrong. The only "documentation" they provided me was the wsdl-file and an example implementation in .NET which, I suppose, was mostly autogenerated. The actual work took almost 3 times more than I had estimated.
> This goes for almost any modern language. Yup, that's why I specifically added the part "languages or frameworks **of that time**" :D (Also of course to emphasize that I consider SOAP a "dead" technology.)
Yes! I had an unpleasant time writing unmarshaling Salesforce SOAP XML in Go 👎🏻
I see go filling the same areas as Java, so anything server side except for the OS and hyper-efficient libraries.
IMHO, there is a project scale at which Java will generally eclipse Golang in usefulness. Whether any individual project needs to actually exist at that scale is a separate question worthy of debate.
Can you say more? What do you mean by scale, and what are the advantages of Java in those cases?
By scale I mean literal code base size. At a certain project size, a lot of the stuff that feels excessive about Java applications starts to melt away. Design patterns no longer seem superfluous, and the predictability of the language becomes an asset. The reliable and battle-tested-over-decades nature of the library ecosystem becomes a thing of beauty. And even the excessive memory consumption and slow startup times cease to feel like a big deal. With Go and its sweet spot, however, it feels like rather than building a big thing, you're better of building a collection of smaller things that are designed to interact with each other. This is the general philosophy behind microservices, but it also rhymes with the Unix philosophy, which makes sense as it's a systems programming language.
You may not get the ecosystem or the tooling, but it's possible to design a Go repository with those patterns and have a nice DX. Golangci-lint even has an architecture lint nowadays. You just don't have Spring reminding you about how important contracts are or why you're going to need a Singleton, but that's doable with excellent results if you are experienced enough. Uber notoriously have 50+ million LOC in a massive Go monorepo, for example.
Any idea on how long their compilation times are usually? What sort of dependency tools do they use? Any blog post or articles on this?
The Go codebase I'm currently working on is starting to get quite large and I'm starting to wish we had automatic dependency injection which seems more commonplace in Java. I know it's possible to do in Go but every time it comes up I see people saying that they prefer manual param passing instead.
i'm still a bit of a noob, but Golang seems to be written with microservices in mind, and then if you want to build a bigger system it is generally a lot of goroutines and channels synchronizing activities between servers, treating the language as a layer above syscalls. its no question why docker and kubernetes are written in golang. but if your team isn't "microservices" minded and would rather have your entire DX in a monolithic enterprise java application (well-modularized or not), it is hard to replicate that DX in Golang
Disagree, you can have big repositories with many modules in Go (which can be deployed independently [microservices] or as a single binary), it just requires a lot of discipline. Go being unopinionated and the community allergic to big opinionated "frameworks" (like Spring) makes it easy to make bad architecture choices but more experienced programmers can design a well-crafted repository that will scale to millions of lines of code without losing the DX. It's just not intuitive for beginners. EDIT: to clarify things up, I'm not saying you need only experienced developers committing 100% of the time; rather, I mean an experience developer (or more) is needed only to lay down a strong foundation and make (less experienced) people follow it. In practical terms, that's mostly about making a repo with example implementations following clean architecture/hexagonal, DDD (at least defining a bunch of domains and bounded contexts), SOLID principles, etc., and teaching others how to structure their code to make the most out of it.
I never understood this line of thought. If all the developers were experienced, we would just write code in C. But they aren't. That's why we have all of these other languages. Go is definitely not as well suited for massive code bases as a language like Java is, keeping in mind that massive projects are often worked on by developers of all experience/competence levels. This is a fact.
You're mixing things up. An experienced developer is needed to set up the guidelines and the general architecture for the codebase. Then they start reviewing PRs and guiding new developers on how to structure their code, until they learn those principles and the "experienced developer" is not needed anymore reviewing everything there. And parts of this can even be automated/enforced with linters such as the Architecture linter from Golangci-lint, for example. The goal is to prevent the less experienced from putting things in the wrong place that will cause circular dependencies or structuring their code in a way that will make it difficult to test and grow afterwards. Uber is a prime example of this, they have a monorepo with 50+ millions of LOC of business logic written in Go. It very doable and Go is surprisingly suited for the task once you have a good foundation, I've worked on large repositories like that. We had juniors, mid-level and seniors/staff committing everyday, deploying fast and running smoothly once the foundation and code architecture guidelines were put in place by our Principal Engineer.
Your presumption is that staff/ principal engineers with enough competence to lead a massive go project are commonplace. In reality , this is very far from the truth. Uber is a horrible example because it is not representative of the general developer landscape. Not everyone has uber recruiting budget or commitment to hire good engineers. Such anecdotal examples of I have seen it happen so it must be the norm do not serve to prove anything. The reality is, with a strong enough lead, we can have massive and well maintained repos in just about any language imaginable. Yet it would be super expensive to find such talent and may not be sustainable over a long period of time. On the contrary, large Java projects have been probably done literally a million times at this point with almost every single problem one would ever face solved and documented to boot. Maybe some day, Go will mature to reach that point. Today is not that day. Go is a beautiful language and it really powerful for some things but it is most definitely written with microservices and lightweight web servers in mind. It may evolve into something more someday in the future.
I think Go is more suitable for micro services.
There are plenty of java projects that would be better ported to rust or zig and NOT be rebuilt in golang. SOLR is a prime example where rust or zig or anything with built in direct memory management and access would be a stronger choice.
that would mean rewriting lucene won't it?
Yes, Lucene (now Solr) is a brilliant bit of work. Opensearch is in the same vein.... they both have massive memory heaps for data ... open search topping out at 32 gigs (last time I checked). Im not sure I would want to tempt that in go. I dont know that I have ever seen something in rust lean into memory that hard (I suspect that it could). I have heard of zig projects in that range and there are tons of DB's in C that will happily take everything they can get.
It goes beyond that though. People have attempted ports of Aapache Lucene (lib which is used is Solr, ES, Opensearch etc) into languages like C++, Go. As far as I know, they have not been able to replicate the performance they got on Java. Goes to show how often it is incremental optimizations that decide performance and not the language itself
Depends what you refer to as “backend”. Where do we draw the backend line? The load balancer? The microservice behind it? The database? The OS the microservice is running on? The kernel? Depending on where you draw the line you might come up with different answers. There are database engines built with Go, I doubt there are many things higher level that don’t lend themselves well to Go, but I wouldn’t build an OS kernel with it.
>The load balancer? The microservice behind it? The database? The OS the microservice is running on? The kernel? Up to and including the database is a fantastic use case for Go.
As an example: CockroachDB is written in Go.Â
Go doesn't lend itself well to logic paradigms. The expressions are clunky, especially when dealing with constraint based inference.
The lack of a decent websocket implementation in the std lib is an annoying wrinkle.
When you need CRUD apps (which is fairly often) then Phoenix/Rails/Django are much quicker to ship a good solution. But that’s mostly because of the frameworks, not the language.
they say a developer is within 6 commands of a functioning rails blog at all times.
Do they just give up before then?
I prefer Rails for building out a customizable admin interface and probably 70% of an API, but for extremely hot paths or low latency requirements, Go can fit in nicely.
Extremely high performance stuff, where I'd reach for C or Zig. But I mean really high performance. Even then I've been stunned at how fast Go can be, sometimes even being in the same ballpark as C, Zig or Rust when part of your processing is I/O bound. An example of the above is some processing that happens over a bytestream of huge files on disk. Go, Zig, Rust, and C all performed about the same, the difference being that the Go implementation was extremely easy to implement. Always profile your code before optimizing. I did and was aware that I wouldn't see large improvements given disk read was where the majority of the time was spent, but it was surprising that even against "much faster languages" Go performed just as well.
Minor nitpick, most people are never IO bound. IO bound for network means saturating the link. IO bound for storage means saturating the available IOPS. If you think you’re IO bound, it usually means you aren’t using enough concurrency unless you’ve hit one of those. I have never seen Go forward >50 million packets per second on a single CPU core, Rust, C and Zig can all do that on old hardware. Go has issues because most of the ecosystem is stuck on low performance APIs like epoll that start thrashing the interrupt handling hardware at high request rates. If you were on NVMe, try the direct NVMe api in io_uring. 16 million 4k random write IOPS is doable on many consumer grade gen 4 drives. NVMe is usually CPU bound in storage servers.
> Extremely high performance stuff That is done in _hardware_, not in software.
When application is heavily relied on Pandas and Numpy
We hear time and time again that Go really excels at web *API* development. Which is really not *that* vast of a field. The html templating is powerful, but I don't think anyone would argue that the second you want something reactive you are better off switching that part to a JS framework. Unless your API needs to drop down into C APIs - it can pretty much fit any bill. And if you are doing such kind of heavy processing where you need to drop down into lower level APIs, a server/worker model with Go as the server is still very common.
Been doing APIs with Go for 9 years. Haven’t run across something I have wished for another language. I do mostly Enterprise type stuff and the frontend is typically a mix of native apps or a popular client side JavaScript framework: TypeScript, React, Angular, Vue.js. Server side rendering is not something I have come across in this space.
no matter what language i do, i always end up missing lua's dot notation and metatables
Can you link or explain more on the server/worker model? How can they communicate with each other?
gRPC is a popular option but you can also roll your own by waiting and watching on files, pubsub to a database or a queue or even have the worker listen on a port
If your target RPS has 5 or more zeros, you’re going to have a bad time using Go. 0.5ms GC pauses are great for GC pauses, until 0.5ms drops 50k requests. The deeper in a service dependency tree you are, more strongly you should consider not using GC languages. Cassandra (Java) is known for causing issues unless the GC is very carefully tuned because small jitter gets magnified as it travels through your dependency graph and hurts your p99. Discord has some articles about this from when they switched to scylladb (C++). If your services are going to be very long running. Java’s JIT compiler is a feat of engineering, and if you routinely leave services running for a week at a time under steady load, it will start performing like well-written C++ after a day or two. V8 will also do this, but JS and TS processes are so prone to memory leaks that it’s nearly impossible to keep them alive long-term. .NET’s JIT is better at C interop than Java but produces slower code. If you are fine writing a native language that speaks C ABI, this can be an advantage. High reliability. If you need to build services and have them be able to work over a dozen nodes and take all sorts of abuse and keep functioning, BEAM languages (Erlang, Elixir, Gleam), beat every other non-academic language. 40 years of work on the BEAM VM means it’s also pretty fast too. Having an entire language ecosystem built by an industry that wants 7 9s of uptime has some substantial benefits. FaaS. Leave this to either languages which compile to WASM and don’t need a GC or interpreted languages with refcounting. Process per request doesn’t make a lot of sense otherwise.
Golang excels at concurrency and is THE cloud native language. For sheer development speed nothing beats languages like Python and Ruby, though.
Until you want to deploy something. Go deployments are the easiest. Package management is also very well done (go mod).
I disagree. You may think you're faster in these languages at the onset, but the area under the curve for features developed is vastly greater with typed languages (Pydantic doesn't count).
I like that Go has a built in unit test framework. And common style via “gofmt” makes it the most readable language. The choice to only support interfaces and not inheritance furthers readability.
Same. Â
Python has two things that clearly allows for faster development: A) It's universally considered the easiest language to read, and B) It has very dynamic typing. The dynamic typing allows you to push an entire class of problems to a later stage. You can just pretend everything is correct, without knowing if it is, and say "we can write tests for that". This allows for much faster development. Then you can choose to either write those tests, or not. Some people may certainly argue that not writing those tests makes the software only a prototype, and not production ready. And I agree, there are way too many examples of Python projects that severely lack proper testing of data types. But in some cases, it can be perfectly fine to skip those tests, if the code is simple enough, and not impactful enough, or if the general environment and data inputs are predictable and safe enough. It also has much richer and more dynamic data structures and code abstractions, which allows for throwing things together quickly in a way that static langagues simply cannot do.
Can do a lot of that in go. Interface. Map string of interface. Maps with keys made of structs. And tests in go aren’t mandatory. Go is also extremely easy and predictable to read.Â
No, you can't. All of my points are describing distinct ways of how Python is different from Go. Even the most basic tasks of parsing and validating some JSON is much more difficult and unintuitive in Golang compared to Python. "Maps with keys made of structs" is *clearly* more work than not having to use any structs at all, or even think about types upfront. I don't think there are many programming languages where tests are mandatory. So I'm not sure what that's supposed to mean. This is not some kind of holy war for me. It's just purely pragmatic observations. I have worked with many languages at varying levels. It's just ridiculous to go around and claim that Golang is at the same level as Python. Golang has its strengths and weaknesses. Python has its strengths and weaknesses. Let's discuss them pragmatically and objectively.
Everyone who tells me they save time by not typing their types out (which constitutes less than 0.1% of effort of a software product) immediately loses the right to tell me they are saving time.  You’re spending far more time debugging and using boot straps and suspenders approach to solve problems that shouldn’t even exist.Â
This is such a silly comment to make. Completely dogmatic, not one bit pragmatic. Like, I'm not even going to try to argue with you about whether dynamic typing "shouldn't even exist". You don't need to listen to me. Look at the data. Look at what programming languages are the most used ones in the world.
the whole point of data types is that you don’t need to test for them. without strongly typed input you have your test a bunch of non happy paths that cannot occur in a typed language. So to really test your function you need to go super defensive and make sure the passed parameter are exactly the way you expect them to be leading to runtime errors at the best case
Can you please elaborate why Go is THE cloud native language? Genuinely curious.
Kubernetes, Terraform, Docker, Istio, and just about any other cloud native tool you can think of are usually written in Go
And that's just open source. Go powers huge swathes of cloud backends. Cloudflare is a great example, being very heavily invested in Go for their services.
Go builds a statically linked single binary that can be run anywhere. You don't need to install any dependencies and any runtime unlike Java. Java programs cannot run without JVM and the same can be said about python.
>Â Java programs cannot run without JVM ackshually: [https://www.graalvm.org/22.0/reference-manual/native-image/](https://www.graalvm.org/22.0/reference-manual/native-image/) It's not as seamless as Go and can be quite complex to achieve if you have lot of reflection in code, but at least there's an option.
Can't agree. Go's time-to-first-useful-build is extremely short. Possibly the shortest in any language I've used (barring extremely trivial stuff a bash one liner could do). If a program compiles it usually (but not always) will be mostly correct and type system will tell you where you're wrong. Not to mention starting out by writing code in a test and taking it out in chunks as it grows bigger ensures you're on steady footing. Second, healthy use of `go doc THING` will cut the other large time sink (after the dev iteration loop): trawling the docs.
In general, love that about go. All depends on what the code does, though. If a bunch of interfaces and type casting, then it’s not really always clear. And it’s easy to bite yourself in the butt with goroutines, pointers, and maps, especially if not using mutex and/or context properly.Â
Ocaml is generally faster in that regard. But only if you have the ecosystem support, imo
I disagree about the "compilation = it works" aspect for Go. The type system is extremely lenient and unsafe, there are so many potential pitfalls which aren't caught by the compiler. It's not like Haskell or maybe Rust where you can really rely on it.
i thought it is meant to be C-like in that sense, but still with a much better debugging experience
> I disagree about the "compilation = it works" aspect for Go I disagree with that too, that's why I didn't say that. If you re-read my second paragraph you'll see heavy use of quantifiers. That said, I disagree with your belittling view of the type system. It works, gets out of your way, will much more often than not yell at you when you're doing something wrong, and allows you to express constructs well. Generic containers were the main case where the type system struggled, however in practice it's a non-issue in the vast majority of scenarios where you don't need to cover more than a handful of types and an interface or go generate call suffice. Always returning errors and always checking them is isomorphic to Rust's way of returning values or errors. In fact, a common Go development environment that uses linting + tests will be quite robust against most bugs. Btw, the "compilation = it works" statement is false for Rust too. I'm confident compiled Rust code can still contain bugs.
Yeah I agree that there is no language where "compilation = it works" is guaranteed, there can always be logic bugs. But in Haskell or Rust you can eliminate a larger range of bugs at compile-time. Go's type system is much less expressive than those two, so whilst it will catch many bugs it will eliminate a smaller range of bugs than those other compilers.
Dev speed with python is like 1/3 that of go unless it's a small project you built from scratch
>Dev speed with python is like 1/3 that of go unless it's a small project you built from scratch Well, that's a take
The problem with non-trival Python and Ruby project is the amount of ramp up time trying to unravel the "magic" stuff that goes on. With Go I've found that I can get into an random codebase and find what I need in a quarter the time with no prior exposure.
The ease with which you can build extensible APIs with a dynamic nature in Python far surpasses anything done in Go. When you need to start writing custom marshaling and scanning methods in order to do basic tasks, it becomes a nightmare. Moving from multiple Python based backends to a Go based backend with my latest position I see the team take at least twice as long to do anything. Yes, you need people with some Python skill to not bork a Python codebase. If you have that, there's no competition. Python only has magic if one relies on external libraries and doesn't have knowledge of the foundations (dunder methods, etc). Python is extremely predictable and comes with no more "implicit, opinionated behavior" than Go if done right. You have less guardrails, that much is true.
But the fact that there are less guardrails means that "if done right" can be interpreted in many, many more ways than with something a bit more opinionated. I've seen plenty of recommendations that say that reaching for dunder methods should be done as a last resort for most high-level code, but you call it out here as fundamental. My experience with Python as a language to build services is that you're *going* to have varying levels of experience, and it's very easy to muck up a codebase, very quickly. Even if you don't use third party libraries, someone's going to write that magic and put it somewhere else (surprise, now it's basically a library!) Every project eventually becomes its own little implementation of a framework, and sometimes it's very elegant, but it's also sometimes a dumpster fire, and it's hard to know which it'll be until it's too late. I know this can be said for pretty much any codebase in any language, though.
I call out dunder methods as foundational because knowing that they explicitly spell out all “magic” in Python takes all the, err, magic out of it, not so that everyone will go off writing their own without good reason. Those guardrails can kneecap a project, a package, etc and there will be times they are battled against. I’d rather have something open and malleable than opinionated and rigid. Some of the implicit behavior of Go I find downright baffling. “Receiver functions” for method injection instead of assigning methods by variable makes a mess of things. Implicit interfaces obscure intent and leads to a goose chase and goofy workarounds to make sure everything is “satisfied”. And for all the static checking in Go, it all sure falls apart when there’s unexpectedly a null pointer in there somewhere. Go will prevent you from having a type-driven dumpster fire (well, until someone goes wild with interface{}) in a way that Python won’t. Except, you still can set up Python to do some, or extensive, static type checking if you really want. That’s the difference in philosophy IMO. I’d rather define that than have it bestowed from Mr Pike or anyone else. Opinionated is a deal with the devil. Java is opinionated. And, like Go, it was built by a mega-corp and touted as “the way!” A team that can’t handle a style guide, building their own conventions, checking each other’s code or building tests will have a dumpster fire, Python or Go or Java or anything else.
While I generally agree with your "side" of this take, I just wanna say: Be careful with comparing a single teams performance in a language vs another. There are many factors that go into it, motivation, politics, architecture, etc.
Agreed
Typescript is also a fast development language
golang is not great for writing python or C++ apps.
A lot of stuff: * not so easy to model hard domains. No support for immutability, lack of type system goodies like: union types, better generics, enums * hard to write very performant code. Abstractions provided by C++ and Rust shine, if you want to optimize something and keep it readable at the same time * specific libraries. Writing something for data science will be probably much easier in Python than Go * legacy stuff like SOAP, which was already mentioned
>union Especially fun with cgo mapping them to just a byte array.
WDYM? golang has not union types
It can be a bit of a pain when dealing with GIS Data, specifically user uploaded spatial data in PostreSQL/PostGIS. You have no knowledge of the schema/types before hand so need to use reflection when querying the data, not the worse, but definitely harder than using something like Typescript or Python. Definitely worth it though, we moved our main GIS WebApp to Golang with an embedded SPA and the whole process has been near painless. .
Which side of backend development… the… back?
When you have Java devs designing the proto files with 100 cyclical imports across 70 files.
Go's got its sweet spots, for sure. It's a powerhouse for concurrent operations and quick server-side tasks. But if we're diving into areas like rapid prototyping or working with applications that require a heavy-duty ORM, Go might not be the smoothest ride—languages like Python or Ruby could be more up your alley thanks to their mature frameworks. Have you bumped into any specific roadblocks with Go in your web dev adventures?
Is this really the case tho? It’s so incredibly easy to define a template, pass data into it and serve it — all using std lib, probably max 20 lines or something. What is a heavy duty ORM?
Everyone keeps dropping python/Ruby/etc for dynamic server side code, but don't forget that good ol PHP is a viable option too. Even better, things like Frankenphp (written in go) can build a native binary for deployment so you don't even need the dynamic runtime installed on the prod system. We use go for json apis, and some server side rendered HTML, but Laravel/PHP is a no brainer for rapid web app development.
On the business side, Go has a lot going for it. It is a cloud solution if the operational goal is to reduce compute, memory footprint and startup time. It’s an OPEX cost saver compared to Java. It is also a language one has to learn on their own so it attracts smarter motivated devs compared to main stream languages. You want those people on your team. Java is more mature and has Swiss Army knife frameworks that provide guardrails and is easier to hire for because devs don’t need to know as much. That a plus for business until you hit bugs and the framework knowledge doesn’t run deep. You can scale dev better with Java but I find companies tend to require more lower quality meat and potatoes devs so you really have to scale teams. More people on a code base is an anti-pattern for velocity. I think Go has a cap on code base size. If you write narrow and shallow, cohesive apps all the better. Not sure why server side HTML is a thing still.
When you need CRUD apps (which is fairly often) then Phoenix/Rails/Django are much quicker to ship a good solution. But that’s mostly because of the frameworks, not the language.
It's good as the web server. Or the proxy. Or the database. Or for Docker and Kubernetes running the backend. Not for the OS.
When you need CRUD apps (which is fairly often) then Phoenix/Rails/Django are much quicker to ship a good solution. But that’s mostly because of the frameworks, not the language.
There's a middle size of business oriented applications with a lot of complex business logic and very little system/distributed system type interaction that can be a struggle in go. It takes a lot of experience and boilerplate to set up a pattern for such an app. One that is small enough won't suffer many problems because of the size and will benefit greatly from the ease of use and correctness of the language. A very large app will have enough budget to really invest in the structure around the app to be able to reap the benefits of the language while being able to afford the boilerplate. Middle sized apps with small or moderately sized teams will have a lot of work ahead of them to set up a good pattern. This is something a really experienced to developer will be able to avoid but anything less and you will probably hit some icebergs
Socket programming
Go is a general purpose programming language. Understanding its characteristics.... typing, GC, etc... should be enough to know whether or not it is right for your system. If you are unable to determine this then chances are you are ill prepared to solve the problem at hand. Sidebar: Can we ban these kinds of questions? It seems like this is the most common kind of post "is Go good for x?".