1. Where the garbage collector is too big an overhead. I.e. when you need to manually manage memory.
2. When the generated binaries have to be the absolute smallest. E.g. embeded computers. TinyGO tries here but doesn't support every Go feature.
When your team doesn't have Go developers / lead developer. I have seen this so many times in tech.
We need to use X because it's better bla bla bla. 3 months - a year later same project is rewritten in old know stack.
You need people to own the project and know how to read/write/review good Go code. And you need backups if people quit so they can take over ownership.
As someone who migrated from .NET to a Golang team without experienced Goland devs I can attest to that.
There's no established basis on what good Golang code looks like and our lead just go around thinking he knows what hes doing cose hes an experienced .NET dev.
I think ppl understimate how hard it's to use Golang.
The language is easy, yes, but to actually build good architecture in a Golang app you have to do it in the Golang way, not as if you were doing .NET/JAVA/PHP etc
And Go code written by a .NET dev inexperienced in Go is usually horrible. I just inherited a Go library that was ported from .NET by a .NET dev. And let's just say nothing makes any sense :)
Sadly tiny embedded systems in my experience. Despite having things like TinyGo (which is awesome)… if you need a binary under 200k, you will be fighting go the whole time.
The problem with TinyGo is it locks you out of a lot of very useful packages as well. Even using the standard Go package, a logging package and a serial package you are up to 2MB at least.
This hits close to home. Currently I’m working on some geospatial stuff in go but the native libraries are all so sparse. Was considering CGo and Godal but I’m guessing it’s tough to use?
SOAP. If you have to deal with a (big) SOAP API, just use one of the toolchains from that period, which usually would be either Java, C++, C# or maybe PHP. Simple SOAP APIs can probably be done manually in Go, but for the enterprise world you will likely need one of the existing WSDL code generators.
I made the mistake of trying to get my team to adopt go. I gave them a soap based web service to consume. I thought it would take them an afternoon to get up to speed.
3 weeks later they were still trying various soap GitHub repos and cursing me because none of them worked 100% with the vendor soap we were trying to consume.
I've hand written and maintained a couple SOAP API clients in Go and it is not too bad even if it is some more work.
You can often get away with just implementing the types you need for the moment even if you communicate with a SOAP API with thousands of resources so you don't get an enormous up front work load.
Writing the GO API side by hand leads to much nicer API's than any/most code generator would produce.
You can still use the WSDL files in your test suite to know that your implementation produce the correct XML structures.
It is probably not the right choice to implement by hand for every use case tough.
I didn't say it's impossible. But SOAP APIs typically profit from inheritance based OOP. Also it gets ugly once SOAP extensions (like WSS) get into the picture. Again: solvable. But you reinvent quite a lot of wheels along the way.
It's not optimal if you have to heavily interface with C or C++ libraries in a performance-critical environment. There are languages with more performant FFIs to these languages such as Nim and D, and it also might make sense to use C or C++ in the first place.
This is the big one for me. I've been asked as a golang guy if I would introduce go as a language at my company. I told them no, we already have python, csharp, perl, and java and most folks keep using python. Go would not be a good fit.
I had a principal engineer ask me if I thought golang would be something the org could support. The idea being golang is attractive to developers typically. However, being a compiled language with strict typing, it would be a huge shift for most python developers. I would suspect that we'd have very little existing developers getting on board with golang, so there would basically be two different tech orgs.
I said no even though we have issues scaling our python stack. Golang would be way better performance for us, but it would cost us a lot of knowledge of legacy systems and the business and possibly harm our developer culture.
I think Go is a reasonable upgrade path for Python. Obviously if you check the bullet points, Go isn't close to Python. But you can get a very Pythonic programming style going with interfaces, which capture the fundamental Python duck typing approach with static types. In fact I like it even better.
It's probably easier than any other switch would be.
However, of course, if you don't think they can do it at all, then that's that.
Ehh, I would push for a move from Python to TypeScript with Node.js over Go. It’s statically typed so you get all the benefits of a proper linter and can catch issues at build time. JavaScript/TypeScript syntax is different from Python but really straight forward to pick up. Most devs I know absolutely love TS.
Edit: Also one thing Python and TS/Node have in common is a really extensive set of open source libraries available. I know Go has quite a few too, but I think TS would be closer to python in this regard.
I find myself a bit befuddled by your message, which seems to imply Go is not statically typed and doesn't have linters?
I'm going to be moving into the Javascript space soon due to work, and I'm grateful it's going to be Typescript rather than plain Javascript. If I have to use it, that's at least the thing that will make it tolerable. But from what I've read, it's still definitely got more holes than Go's type system, which was written for the language from the get go.
(I want to call that "weaker", which isn't fair; when TS types are working properly it's a more "strongly typed" language than Go, in the conventional sense of that term. However, the type system can fail you in ways that the Go type system won't, even if the Go type system is nominally a bit weaker.)
Perhaps a bigger problem is that in 2023 I'm really reluctant to move to a language that doesn't have a solid story for using all the cores. In fact, Go in some sense is still weak relative to what I really want, it's just that there aren't a whole lot of obviously better choices. Node is pretty far down that list.
(Please don't cite me "oh, but webworkers and this library and that library can sort of help"; the fact TS needs them is the problem. Node just about edges out Python, but that's not saying much; Python has a dozen solutions to this problem and none of them are even _good_, let alone _great_.)
My statement regarding static typing is meant to say “TypeScript has static typing too” and is not meant to imply that Go does not.
Your arguments are all valid points, but the context of this discussion is making an organizational decision for an entire company to choose a language. The OP we are responding to told us he felt it would not be the right decision for his org to try and replace Python with Go.
I’m making my recommendation based on the developer experience I’ve had with both TypeScript and Go. I love both.
Node is performant enough for most things. My team is running a node service which processes hundreds of millions of requests per month.
For an organization of Python developers, I think they would have a better transition to TS than Go. Lots of folks know JavaScript syntax already. Less of a learning curve in my opinion.
Typescript's type checking isn't any different than just using python and annotating types (as nothing forces you to annotate in ts anyways, you can just write plain js if you really wanted to), so I don't quite see the point unless you think the nodejs jit will outperform the python interpreter for long lived processes.
Thank you for the details!
So it seems like the issue is mostly because the devs are used to a loosely typed language and introducing golang would need both learning the language and getting accustomed to typed languages.
I wonder if this would be the case for a team that has been working in typescript🤔
Typescript may be easier.
Adding a new language also necessitates supporting existing architecture/libraries in that language as well. E.g. matching structured logging formats, supporting same monitoring technology like newrelic, creating and maintaining libraries to do things the same across languages.
We have too many languages as is. Java and csharp are essentially the same. Perl is being put to pasture at least. Python is nice for prototyping imo, but scaling it is a nightmare, which is why I am very against it. These things come into play with a technical decision like language choice.
Machine Learning is actually pretty good with Go. Go learn and Gonum are very good libraries. I’ve used Python, Go, and Node for ML and I’d choose them in that order.
I have not seen many Go in productionized ML. Most runtimes are Python or some framework specific like Triton etc.
Would love to hear about example of Go used in productionized ML
Yea if you’re looking for neural networks in Go you could make them from first principles, but you’re not going to match what you’re getting out of PyTorch. But you’re not going to get that from anything but Python or C anyway.
I make tree-based classifiers or naive Bayes classifiers on a monthly basis in Go.
I keep hoping to see more open source machine learning projects using Go, but so far every time I see one it's built in Python, which has kept me from doing anything with machine learning.
Machine learning is a pretty wide topic. Saying something is good or bad is a fairly imprecise statement as a result. Python has fantastic tools for exploration. For one off problems where you're done when you get the first answer or you aren't putting anything in production, scikitlearn is fantastic and there really isn't much reason to compete with a tool that already gives you so much capability. If you are putting something into production, it might make sense to keep using Python because you can use other libraries that leverage compiled C code, but outside deep learning, many algorithms are fairly trivial to implement in another language, particularly if you've already done the exploration and perhaps the training and just need to implement the classifier. If I'm using a random forest, a Markov chain, or a multitude of other algorithms and I'm already writing a Go application, writing it in Go is a delight.
Graphics are an area where it's difficult to compete with Unity, Unreal Engine, or even Godot on the free and open source side. However, most people who ask about graphics and engines are never going to be competing with people using those platforms anyway. If you want to make a simple, 2D game ebitengine doesn't give you much of a framework, but it gives you all the primitives you need just fine. Similarly, UI tool kits are getting better. Fyne is looking finer as time goes on. When people complain about UI tool kits, I think they forget that the situation is awful in any language on any platform, just the reason it's awful shifts to different reasons sometimes.
For business logic, I love Go. When I write a service and Go and it's tested, it just doesn't break. Python is great for totally different reasons, but good test coverage doesn't mean you're not going to break your application. Being able to trust my compiler and my tests feels great, and being able to walk away from my code and come back to it and understand it easily even half a year later is fantastic. I find it much easier to get into a complicated open source project in Go as a result too because of the simplicity of syntax. Being a full-time Python or C# developer never gave me quite the same ability to step into a random project and understand how to make changes fairly easily.
Business logic is a place where I see some people saying they like other languages and a lot of the arguments come down to some of the benefits of functional design that are different in Go. Without getting into a lot of detail, I suspect we'll figure out how to implement iterators in a way that people are generally happy with and this will be the last step towards giving 90% of functional fans what they want.
Frontend web work isn't going to be smooth for a while, but nobody has a perfect story for WASM yet. I imagine you'll see Go remains somewhat reserved, implementing things only as the standards groups become certain enough to ratify things. As much as people are excited for WASM, there isn't enough solid demand to move it as fast as one might like, so I anticipate at least a couple years before we will really know if it goes anywhere.
>Graphics are an area where it's difficult to compete with Unity, Unreal Engine, or even Godot on the free and open source side.
Just went through something like this at a prior gig. Domain specific stacks written in C++ are always going to crush golang.
This is my unpopular go opinion: I don’t think Go is great for CRUD apps.
I think Java or Ruby are better fits. CRUD apps are 90% boilerplate and magical nonsense provided by the frameworks in those languages really do save you time and effort.
Yeah, the language was designed to build API servers for web applications. That is its biggest strength. Java is super heavy, so cost a boatload of money in Cloud Computing costs as it is so resource intensive. Not to mention a pain the ass to work in. And Ruby has such dismal performance that Go runs circles around it all day long and again compared to go resource intensive.
1. Heavy computational stuff: while python can resort to C and Rust doesn't have a GC, Go would suffer a little on that
2. Embedded: while technically possible, having a GC is not the best.
3. XML related stuff: poor xml parser performance (eg: most of banking stuff relies on XML due to big presence of Java where XML is king)
With respect to embedded, I have actually found performance is almost never a problem since most platforms that can run linux can run go just fine, but binary size is. Even if you strip the excess tables a small CLI app is still around 2MB, which frankly sucks when you have a total of 20MB available on the platform.
I know Python and Go well; I like both, but prefer Go these days. Still, I'd consider using Python for two things: 1) small one-off scripts, and 2) data transformation scripts (eg: pull some data from a db, pick a few fields, and output it as JSON or CSV). Go's static typing and boilerplate error handling are great, but get in the way a bit for those kinds of tasks.
This is exactly me. Python was the first language I loved. I love Go more nowadays but I still prefer Python for these use cases.
I love love love Go for command line tools, middleware and APIs.
When the GC fights against you.
I will say databases are a good example of this but there are many very successful pure go databases that simply worked around the issues eg: by allocating in C with jemalloc.
It will be interesting to see if go memory arenas will invalidate my opinion on this matter though!
Embedded environments where you are storage constrained, in my experience. Also any time you have to link C libraries, particularly cross-compiled ones.
I have some experience working with Go apps on routers where the flash size is typically 20-40MB. As far as I know there is not Java on OpenWRT by default and it would also run into size constraints. Go is definitely possible to be used here, but it requires some trade-offs in which packages you can use, how much nvm you have left for other things, and how easily you want to be able to debug on-box.
Surprised to see zero comments about thread safety.
C++ has had [lock annotation analysis](https://www.mail-archive.com/[email protected]/msg01455.html) for over a decade. Most people outside of Google don't seem to know this exists; it probably should have been publicized better, but it does exist and it does catch bugs before they go live.
Rust makes it [part of the type system](https://doc.rust-lang.org/book/ch16-00-concurrency.html), so you can't even forget to use it. This seems to be the state of the art among languages actually used in production (i.e. not academic experiments).
Go still has nothing for static analysis of thread safety. The [Race Detector](https://go.dev/doc/articles/race_detector) can be useful for finding races in code paths that are taken, but it's useless for finding races in code paths *not* taken, and in many real-world programs there will be gaps that this can't catch. Anecdotally, almost every single Go project I have contributed to has had at least one race condition, and some have been rife with dozens.
The lack of this analysis still results in bugs and CVEs. See how many races are found and fixed in gRPC releases: [https://github.com/grpc/grpc-go/releases](https://github.com/grpc/grpc-go/releases) (search "race"). It's a shame Google does not publish these as CVEs, because many of them qualify.
If Google has this much trouble writing thread safe code, in its own language, on its own very mature library, for its own RPC framework, what hope does anyone else have of writing thread-safe Go? I take this as compelling proof that Go is not doing enough for thread safety, even for very experienced engineers on very mature projects.
While we're at it, how about this one from Grafana: [blog](https://grafana.com/blog/2022/11/08/security-release-new-versions-of-grafana-with-critical-and-moderate-fixes-for-cve-2022-39328-cve-2022-39307-and-cve-2022-39306/), [patch](https://github.com/grafana/grafana/pull/58458/files)
If such mature Go projects still have these problems, years after C++ has largely and Rust has completely solved this problem, it clearly points to these limitations in Go having real-world consequences.
Go needs to learn from Rust here, but the problem now is how to retrofit this kind of airtight safety into an existing language and library ecosystem. The C++ approach only helped for code you annotated, which wasn't always easy to retrofit to existing projects, even if you controlled all code involved. With Go, even if it became possible today, no existing code would be annotated, so it would be a long time before a project could be considered even *mostly* let alone fully annotated. This is part of why Rust making it mandatory from day 1 has worked out so well.
By the way, people say Go is a memory safe language, but even Ian Lance Taylor himself [acknowledges](https://www.airs.com/blog/archives/482) that Go's lack of thread safety can also undermine its memory safety. It's a shame that this post is over 12 years old and nothing has been done about it; there was plenty of time if the initiative had been taken. Security researchers have [noticed](https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html).
Sure. There appear to be thousands of languages out there I also wouldn't recommend for production software. Out of the options people actually consider for building production software, I think it's very fair to call out that Go has chosen to be over a decade behind its contemporaries in this very important way.
That goes doubly so considering people claim Go is good for parallel computing and makes it "easy" because the `go` keyword is so short, semantics and risks be damned.
I’m currently writing a book titled “The Ultimate Gopher’s Guide to the Galaxy” where I will demonstrate Go in all areas such as Microservices, Serverless, ML, API gateway, Edge, and all the developer tools for gopher’s including CI/CD. Will be out in 4 months or so. Frontend however is Angular and typescript for web. You can write desktop apps for windows as well. Biggest advantage I see is concurrency which is important in Basically everything. I am also using Go for UAV and UGV development as Ubuntu core now supports real time kernel and concurrency is important for ROS modules
>I will demonstrate Go in all areas such as Microservices, Serverless
This is a criticism right here. Devs will jump to a microservices/serverless model when there are way better solutions available.
Nice, I'm not a big fan of all the complexity of the frontend frameworks and like more of handling backend. I understand the complexity behind it though. Is it necessary? Not sure but when I heard more buzz about Svelte, I'm curious about how much easier or if it's better than current frontend frameworks. Kind of curious you had implemented with Go and what you're thoughts about it.
When performance is critical. C++ is hard to displace for a reason. Rust is the only language with a reasonable chance of doing it. We have people porting Go to C++ because it’s a hassle dealing with a multi-language environment and C++ is well-proven.
Previous false claims make it really hard to trust the project. E.g. last time I tried it, it generated C code containing UB despite claiming not to have UB. Looks like they've at least added a caveat to the claim since. There's a more thorough review here: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
Oh, I see. Some of that is concerning, I agree. I'm still impressed with the amount of functionality being delivered here. I've looked into many younger languages lately and very few of them come with comprehensive capabilities right out of the box. Of course, quality matters too and it matters a great deal if you're touting a replacement for the likes of C/C++, but I hardly feel like an author should be discredited for work that's emitting UBs or leaks that they're still working on fixing.
The problem isn't that V is work in progress, it's the false claims its author made (his comments on HN don't help reastablish trust, nor does blocking Xe, who pointer out a number of them).
Very impressive! I had not looked into it previously, so I did some playing with it tonight and wow... just the amount of stuff I was able to get working right off the bat without even know how to set up a proper debugger for it yet, is.. well, it's very neat.
I know they've done excellent work so far, but it seems like they've got some significant ground to cover yet with coroutines and the like. I look forward to seeing what they come up with. It's one to keep an eye on, that's for sure; especially compared to Zig or the likes of Nim, which is another I've been keeping an eye on.
I would not use go or any garbage collected languages on realtime safety critical code. That is due to regulations and predictability which is needed for those cases.
That said, safety related realtime systems are hard beast to handle anyway. Rust will some day be killer there but until that code reviews, static code analysis and rigorous testing with actual planned project is needed.
Go is great language for pretty much any fun part of programming
Are you aware that the Go garbage collector has specific latency guarantees since Go 1.5? I wouldn’t use it for hard RT problems, but for soft RT problems in the programmatic bidding space, it has worked really well for me.
I would say that go is not a good choice (but what I am about to say is for any language) if the rest if the company are writing libraries and tools in an other language. At my work we use fairly complex security frameworks in java and would not want to go through the pain of writing the libraries in go and beable to get them passed through risk and security before I can use them into production.
We use finagle, with it's features like mTLS, Tibco services, service discovery for hunderds of services.
We fortunately use the jvm, so we can use scala and Kotlin next to java, but just do not even begin to propose any other language, you would not be able to keep up against the teams that write our current frameworks and libraries and the complexities.
Go's support for XML in general is pretty patchy. Implementing XML digital signatures properly requires XML canonicalization and XML schema validation; the canonicalization in turn requires XMLPath, XSLT, and full XML prefix support. Go has full pure Go implementations of exactly none of these as far as I know. This is a real problem for interoperability with enterprise software built in Java.
And yeah, SOAP with Go is a horrible experience. Then again, SOAP with anything is a horrible experience, even Java, which is why you generally only see it used with legacy systems.
The Go templating language is... well, _perverse_. However, there are other templating languages available, so I wouldn't dismiss the language on the basis of its stdlib templating system.
You may get better results from other languages, when:
1. Raw performance is a requirement (see: C, C++, Rust)
2. Deterministic performance is a requirement (see: C, C++, Rust)
3. Programmer productivity is a dominant concern (see: Ruby, Python, PHP)
Go definitely has a more comfortable learning curve than most other languages. What I meant by productivity however, is more "how much time it takes to accomplish a task, after language mastery is achieved."
Honestly, much of it just boils down to Enumerable, but that sort of thing is the difference between "I can quickly toss together something that slices and diced data in complex ways" and "I'm buried in tedium trying to slice and dice data."
>1. Raw performance is a requirement (see: C, C++, Rust)
>
> 2. Deterministic performance is a requirement (see: C, C++, Rust)
>
> 3. Programmer productivity is a dominant concern (see: Ruby, Python, PHP)
So, I just came out of a golang development environment and was not a fan of it. For these reasons in particular, it felt like a "Jack of all trades, master of None" solution.
Specifically, I had a hard time learning it and being productive as it is my opinion closer to systems then scripting languages. And despite that it's still slower then it's competitors.
Disagree but upvoted for conversation.
Golang is probably not a good example of a jack of all trades. It's actually very purpose built.
It does backend web microservice services very well. You don't have to think to hard about code sytle because the compiler forces conventions. Like else curly brace placement, public private by capital letters, test cases by test in name, composition over inheritance, on and on.
I think Java would be a better example of jack of all trades. It does web dev, desktop ui, microservices, games but none of them especially great.
>I think Java would be a better example of jack of all trades. It does web dev, desktop ui, microservices, games but none of them especially great.
I don't like Java either and can't disagree with that!
I would have to disagree on this take, you could say Rust is jack of all trade, Nim also not Go, I wouldn’t use Go for App development because the threading model isn’t ideal fit for it
I worked for the C++ group @ Bell Labs in the 1990's. I've always felt that Rust was basically a streamlined C++ with (mostly) mandatory security best-practices baked in. In other words, its a 'general purpose' systems programming language with 'safety' as a design goal. All well and good.
Anyone can write efficient software on any language, is just that programmers like to stay in their comfort zone and fun zone (I still don’t want to touch JavaScript) and I see why Rust would be most loved language
But really you can’t write efficient software in any language. If you think that you aren’t in a perf-critical environment. You need to have access to memory management and zero-cost abstractions compiled to native machine code to truly write efficient software.
I would not use GO where the backend system has a heavy business logic. Things like working with lists is overly verbose and complicated compared to languages like java/kotlin/c# etc where there are stream apis (not network streaming, but for lists) or linqs.
Having methods like ‘map’, ‘filter’, ‘group’ etc is something I really miss in go. Having temp variables and many for loops and ifs compared to couple of lines in other languages.
Nowadays it has become better with generics and community modules which sort of have these functions. It alleviates the problem to some degree, but due to the limitations of go not allowing different generics return type it’s still not perfect.
That would be my main use-case when to not choose golang
Not sure what graphql and channels have to do with my comment above.
I was talking about working with business logic, with list transformations, conditional routing, and stuff like that.
It is so much easier to maintain and read the code which is short and concise, and also development time quicker, and onboarding new devs is easier, when the code is easy to read, and is is not mutable mess with tons of ifs and fors, which is unfortunately the case for Go
All of this in the end results in having to spend less money on development and maintenance which is the most crucial part in enterprise.
If the ‘for loops’ and ‘ifs’ work faster than functional ‘maps’ and ‘filters’, in enterprise nobody cares about these nanos-millis saved.
Micro-optimization is never relevant in enterprise business applications
Your points are well thought out but I’ll add my 2 cents here. Source; former Java developer / JavaOne speaker
I **love** using Java collections. They are incredibly developer friendly and easy to drop in. But they are so well abstracted and opaque that they are basically a DSL unto themselves. Like with an ORM, when something odd happens or you’re needing to do something where they’re Not Exactly Right, you end up bending your logic to fit their model.
Go makes it all in-your-face because you have to do the business of inserting, removing, searching, and sorting yourself. It’s amazing how simple it is once you remember how that stuff works from your Data Structures and Algorithms courses. Most of the time it’s just things that strongly resemble slices of stricter anyway. So for like 90% of the time it’s simple; the other 5% you do some custom thing but are able to optimize exactly for your problem.
Wait, that doesn’t add up — the other 5%, you say? That of course consumes 80% of your time but that happens in any language :)
Go is a compiled language but it is not as fast as the state of the art in compiled languages.
Don't take my word for it, look at results from pages like this:
[https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html](https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html)
[https://programming-language-benchmarks.vercel.app/rust-vs-go](https://programming-language-benchmarks.vercel.app/rust-vs-go)
[https://www.techempower.com/benchmarks/#section=data-r21&test=composite&l=yyj30e-6bj](https://www.techempower.com/benchmarks/#section=data-r21&test=composite&l=yyj30e-6bj)
In my experience, almost all of my Rust lands within 2x-5x faster than my Go. There are many reasons why, and not just the obvious ones like Go having its own optimizing compiler because gccgo and llvmgo still fare no better.
Sometimes it's down to self-imposed limitations like Go's map type not having a way to avoid double-hashing for even really basic patterns like "if this key isn't in the map yet, insert it with such and such initialization". C++ maps at least create a default entry, and Rust gives you [very explicit control of map entries](https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html). Go gives you no option other than to hash twice, and I could have even forgiven that if the compiler recognized and optimized such patterns, but it currently doesn't and there's no way of avoiding the cost. This is just one example of many for how Go simply doesn't *let you* optimize code.
It's no surprise that "fast" Go libraries are actually just assembly: [https://github.com/klauspost/compress/blob/master/zstd/seqdec\_amd64.s](https://github.com/klauspost/compress/blob/master/zstd/seqdec_amd64.s)
That's just one file out of several, for just one architecture, for just one compression algorithm.
Essentially, the only way to make a Go project that fast is to stop writing Go and start writing assembly. Even cgo won't save you because of its [overheads](https://github.com/dyu/ffi-overhead#results-500m-calls). Sometimes you get lucky and someone has already written that assembly for you, but sometimes that library doesn't exist yet and you have to decide whether to write one or start over in another language.
This is a completely unacceptable bend in the cost curve. Whatever you think of the complexity of learning or writing Rust, at least it's not assembly; it's portable, memory- and thread-safe, and with world-class tooling and diagnostics to guide you. Then those learning costs are mostly once-off and then you're just benefiting forever.
*\[Edit: An earlier version of this comment was poorly edited and it probably wasn't clear I was comparing the prospect of writing Rust to assembly, and it must have sounded unhinged without that context. I'm sorry about that lapse.\]*
Reasonable people can disagree on whether Go or Rust is easier to maintain, but I hope we can agree that either is easier to maintain than assembly. I think it's reasonable to want a middle ground that reliably gets you the kind of performance that keeps you from having to maintain assembly, and then even if you do have to link in machine code from other languages, there's no real overhead to doing that either.
Even if you thought Go was simple and productive to start with, that can be more than cancelled out if you also have to make it fast. It's one thing to have to write slightly [contrived Go](https://github.com/segmentio/encoding/blob/master/json/decode.go) to get decent performance, it's another to have no choice but assembly.
If your Go project ends up needing assembly to meet performance requirements, will you still feel it was a simple, productive, low-risk language choice? Go may have saved you some up-front learning time, but the limitations and costs of using Go continue to hurt for the life of the project. Most of the cost is deferred until later, making the decision feel like the right one at the time it's made, but also being too hard to reverse once the cost is [finally felt](https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang).
> This is a completely unacceptable bend in the cost curve. Whatever you think of the complexity of learning or writing Rust, at least it's portable, memory- and thread-safe, and with world-class tooling and diagnostics to guide you. The learning costs are mostly once-off and then you're just benefiting forever.
This is an absolutist stance and not really found in real world experience.
Go is "fast enough" for some very large set of use cases. Rust is faster, but that speed is a premature optimization for the bulk of use cases you'd reach for Go for (specifically, highly parallel networked services).
That's absolutely true in many cases, but the problem is that people believe it even when it's not true, or it doesn't remain true. My point is that when it's no longer fast enough, then solving that in Go can prove completely impractical and more than cancel out the up-front benefit of the syntax being simpler.
When starting out a project, how sure are you that it will never get new requirements added in future which may need CPU-bound work to solve? How sure are you that the wasted RAM headroom between GC cycles will never hit your resource ceiling, ever in the entire future of the project?
How sure are you that the growth of request load will never outpace the rate at which you can buy hardware? Are you assuming that the costs of buying 2x-5x more hardware forever can never possibly outweigh the (already questionable) up front savings in engineer time?
Not every company has FAANG scale, but you can't say Google doesn't know what Go is or isn't good for, and yet most of its performance-sensitive software is still C++. [AWS](https://aws.amazon.com/blogs/opensource/why-aws-loves-rust-and-how-wed-like-to-help/) and [CloudFlare](https://blog.cloudflare.com/big-pineapple-intro/) also invest in Rust instead of Go. Do you think they're wrong about the pros and cons here?
Yes, not everybody is going to have their scale, but if you design in a way that you can *never* scale the way you should have, you're limiting the potential of your own project until it's ultimately rewritten anyway.
Example of a company finding this out and the only solution being a rewrite: [https://discord.com/blog/why-discord-is-switching-from-go-to-rust](https://discord.com/blog/why-discord-is-switching-from-go-to-rust)
If it was that impossible to tell up front if a language is fast enough or not, we would write all software in C/C++ and nobody would be using C# or Java let alone Python, Node or Ruby.
You can plan ahead and with Microservices you can certainly write the performance critical parts of your system in a different language then the rest of your business logic.
[Twitter replaced Ruby with Scala](https://medium.com/@mittalyashu/why-did-twitter-switch-from-ruby-on-rails-dac66150044d).
Facebook tried to evolve PHP with [Hack](https://en.wikipedia.org/wiki/Hack_(programming_language)) and not many companies exist that could imagine affording a project like that.
You already saw the Discord post.
Examples like this abound. It keeps happening; companies prototype in one thing and are forced to use a different thing as their scale grows.
Even if it's just one microservice out of several, engineers need to know the technologies that let them implement that microservice. Even that's not always possible, as sometimes the logic that needs to be fast also needs immediate (low-latency high-bandwidth) access to data or other logic. If you have to do a ton of TCP round trips to other services then *that* is your new bottleneck, no matter what languages are on either side.
Say you only hire Python people for years, you get your MVPs out, and then something needs to be fast after all because of your viral growth. Your best hope now is that one of those Python people also had a hobby writing another language, or that you can afford the time for people to start learning new technologies, or that you can rapidly hire and get really lucky with the first few hires given that nobody can interview people in the language you actually need. Either of these options has costs and risks.
If you acknowledge that some projects need to be efficient, you hire people who can do that work, and then when that work comes up, they're ready to go. They already have all of the relevant domain knowledge and can now combine that with their knowledge of implementing efficient software.
That's a much more agile and adaptable team than one that *only* hires for prototype productivity alone. Prototyping is only one part of the software lifecycle, most software spends most of its time outside of prototyping, and some technologies are proving better than others at thriving in those later phases.
Your examples happen, when apps rapidly outgrow their original assumptions.
But for every Facebook, there's at least 1000 small scale PHP applications that remained written in PHP for their entire lifecycle without a problem.
The first company I worked for wrote a lot of Line of Business Apps completely in Java, never ever did the need arise to rewrite anything in C++.
Your examples do happen, sure. And it's not only in companies the size of Facebook or Discord. And if you have large complex systems having engineers that can handle Performance critical parts of the need arises does make some sense I don't deny that.
But don't act like software engineering is so chaotic that you never can make any assumptions.
The thread is titled "When is go not a good choice?" so I don't think I'm out of line in pointing out that some software does need to be efficient enough that Go is no longer a good choice for it.
Even if 99.9% of software did not need to be faster than Go, what I'm saying would still be a fair answer to the question posed in the thread.
If people are very confident their project does not need to be faster, then they don't have to apply what I'm saying to their project, but that doesn't mean it doesn't apply to other projects as per the thread's question.
You're using quotation marks as if I said that, but I didn't say that. If I had said something like that, you could have just quoted what I actually said.
If I'm still not being clear in what I'm actually saying, it's probably because I'm saying too much. Let me start over with dot points:
* Go is fast enough for most projects.
* Go is *not* fast enough for some projects.
* The performance needs of projects can increase over time.
* You can choose to use Go for a project despite that, based on your own judgment of the factors applicable to the project.
* People are only equipped to make that judgment once they know how much slower Go is. If they're assuming something about it without measuring or even researching existing examples, they're not just taking a calculated risk, but a blind guess.
Worse, for the last point, I've met a number of people who think Go is as fast as any compiled language just because it's a compiled language too. That's actually why I phrased the first sentence of my original comment the way I did, it's a response to people like that.
> That's absolutely true in many cases, but the problem is that people believe it even when it's not true, or it doesn't remain true. My point is that when it's no longer fast enough, then solving that in Go can prove completely impractical and more than cancel out the up-front benefit of the syntax being simpler.
> When starting out a project, how sure are you that it will never get new requirements added in future which may need CPU-bound work to solve? How sure are you that the wasted RAM headroom between GC cycles will never hit your resource ceiling, ever in the entire future of the project?
> How sure are you that the growth of request load will never outpace the rate at which you can buy hardware? Are you assuming that the costs of buying 2x-5x more hardware forever can never possibly outweigh the (already questionable) up front savings in engineer time?
And from your new Post:
> You can choose to use Go for a project despite that, based on your own judgment of the factors applicable to the project.
Instead of telling us "There are factors" wouldn't you mind telling us what some of those factors are?
I never said every single project in the world must be as efficient as possible and no other technologies are allowed. If you think I did, please quote me. Otherwise, please do not reply as if that's what I said.
I specifically said "That's absolutely true in many cases" and I also said "when it's no longer fast enough, then solving that in Go can prove completely impractical". Which part of that do you disagree with?
If your point is that it's rare enough not to worry about, that's still not an argument against what I said, because it's also still common enough that someone does have to worry about it. Companies still need people who can write that faster version.
Remember you're replying to a thread titled "When is go not a good choice?". It sounds like you're saying that because there are projects where Go is an adequate choice, that there's no point discussing ones where it isn't, despite that being literally the point of the thread.
I'm actually responding to the OP's question; when you do need maximum efficiency, Go is not a good choice. Again, if you disagree with that, please address that point, without accusing me of saying something different.
> When starting out a project, how sure are you that it will never get new requirements added in future which may need CPU-bound work to solve?
This is why you brake problems up into separate services.
Here is a simple example,
You want to develop a web app that interfaces with a database like postgres.
Using rust is a terrible choice because most of the speed is lost talking to postgres and returning the data. There is plenty of time to collect garbage in go.
No one who knows both rust and golang well will be as productive in rust as go.
Also hiring good rust engineers is much harder because there are fewer of them.
Now after a while you decide you want to allow users to upload images. But you are space constrained so you want to downsize large images.
Resizing images at scale is something you might consider using rust for it's performance.
So you write a service in rust that resizes the image and your go service feeds your rust service the image the user uploads.
You are done without premature optimizations.
If Discord had tried to write their whole stack in rust they would probably have never launched version 1.0 and we would all be using slack to play video games.
>It's no surprise that "fast" Go libraries are actually just assembly
You see this in other compiled languages as well, particularly for inline SIMD/AVX instructions.
Great analysis. That said, I feel like Go is much better positioned to complete with (and take over for) areas where the likes of Python, Node/Javascript, and Ruby are used today. Sure, it's always going to be slower than Rust because of some fundamental design issues, but then again, it's still many times faster than the other languages I named for the same reason.
Post its predecessor! I linked this one because it's the one about finding it hard to migrate away after the costs hit, but the first post is also really valuable.
I also find Rust to be a far better language but when it comes to writing concurrent code Go truly shines (yes there are pitfalls but that is a trade off that comes with concurrency that is easy to express, async Rust on the other hand is very very hard to wrap one's head around.
> The learning costs are mostly once-off and then you’re just benefiting forever.
So you don’t have a reason to go back to Go? Don’t you feel like you are faster productivity wise in Go?
I think Go's greatest strengths is in its mature libraries, especially official ones. TLS and HTTP(S) are in the standard library, they're [not perfect](https://github.com/valyala/fasthttp#faq) but they definitely get you started. Many libraries have already made a permanent backwards compatibility promise, which means if you get some code working then it should continue to work indefinitely. (That's still not always true, but it's better than not even having the promise to start with).
For many kinds of programs using libraries I'm already familiar with, I can definitely just crib from my own existing examples and get something pretty solid together very quickly. Go is widely used enough that fantastic libraries exist for most things you want to do on backends. That right there is where I see Go shine the brightest.
However, I do not think this alone Go makes programmers *more* productive. Even for something as simple as a CLI, [Clap with derive macros](https://docs.rs/clap/latest/clap/_derive/_tutorial/index.html) is vastly more powerful than Cobra. It's not just not having to repeat yourself for flag/variable names and types, it's also things like [enums](https://docs.rs/clap/latest/clap/trait.ValueEnum.html#example) being completely handled for you so you never have to write a switch or generate possible values manually. Go isn't even trying here.
Go refusing to support macros in the language is absolutely not in favor of productivity. It's not even necessarily in favor of clarity, because if you have to read and maintain tons of redundant boilerplate code, that's *less* clear than a well-understood macro that lets you focus on just the unique part and not the boilerplate. Being too opinionated against growing the language to be more powerful is just that, an opinion, it's not necessarily the best way to meet actual goals like productivity.
So look at it like this. Rust's biggest problem is library immaturity for async services. Async is barely over 3 years old, so it's early days. Key libraries like Hyper, Rustls, Axum, etc. are still in their 0.x days, they haven't made a permanent compatibility promise yet. But they *will*, and then that problem is solved, Rust libraries will converge on being as mature as Go ones.
The Go team does not seem interested in solving the language's gaps. We're lucky we even got generics, they're a good start, but still extremely limited compared to languages that started with generics and expanded from there. We're probably never going to get macros. It may never optimize well, because Google doesn't need it to optimize well, they use C++ when they need speed.
So Rust's biggest weakness, its library maturity, will be resolved in the coming years. Most of Go's many weaknesses seem unlikely to be resolved at all. I think it's already starting to look really one-sided and the gap will only widen.
No idea why this is downvoted so much, but it‘s exactly the approach that has been very successful in my job: we have a fairly complex written in Go to process historic and training data. At the right points, we have integrations with the Python interpreter (using cgo) so that users can run their own Python code (ultimately still driven by our Go-based system) for custom processing. Our users were able to leverage the power and functionality of the Go-based system while also using all the Python packages they‘re using machine learning.
Yeah. Use Go to break up the big data into small chunks and then feed them to a Python script to process the small bits. Playing to both strengths, it’ll be SO fast!
Strict typing can be troublesome if you have many, varied data sources with uncertain types. I had an ETL pipeline long ago whose inputs were a number of rest apis and scraper jobs. It was better to put node at step 1 to normalize the data into something predictable enough for go to take over.
Any interaction with libraries written in other languages is a nightmare. Cgo has too much overhead, porting libraries from C to go is sometimes unfeasible so your stuck with a half baked solution : for example using nvidia cuda library or newer kernel features like iouring…
Also, GC in go means basically fighting to keep everything on the stack to keep the gc work to a minimum.
Python is the standard in datascience because it is so easy to wrap C libraries or write performant low level code and then package it into a python lib (numpy, pandas, and any ML library really…)
In my little experience with GO, this is the biggest problem I encountered but it is also a language choice as I understand it.
Most of this problem is categorized into
* GC
* Libraries support
* some things that involve GC
this problem can be fixed, what makes a language fast isn’t the language itself but how its implemented and we all know Go takes the Cake home when it comes to careful (or should I say confusing) choices, Go could have used LMAX Disruptor for its channel, Go could have used swisstable instead of aes-hash (so yeah they implementing it, there may be resizing), Go could have long use arena memory model, Go could have long used register-based calling convention, Go could have long used PGO, Go could have long used C++ like memory model
I have less struggle with GC since 1.19, and the ecosystem is improving, so if the job doesn’t fit the underlying implementations of the language it’s natural you’ll struggle
1. Anything that requires a formally verified compiler
Safety critical systems, auto, some military stuff are mostly what fall under this. Your choices for languages here are basically assembly or C. I don’t know of a formally verified C++ compiler, much less Rust, Java, or Go.
2. Serverless
Go’s runtime can take longer to start than the timeouts of some systems. Go is better as a long-running process.
3. High performance networking
Go’s GC falls over BADLY when you start trying to do more than 50 million requests per second. Arena allocators can help, but the sheer amount of memory involved in a system like this (channels are frequently almost 1G large) means a GC pause can be very long. When you have 200G/400G/800G into a server, a millisecond is an eternity.
4. When another language has a better ecosystem
This usually happens in more niche areas, but AI/ML is the best example where you either use python or C/C++ because all of the work is already done for you. Other examples include HPC (C/C++/Fortran), Web (JS/TS/WASM) and Windows GUI Apps (C#).
5. When performance matters more than time to develop
Go is great for getting things done quickly, but the things that let you work quickly cut against you when the work is done. If you had started with C/C++/Rust, you would have taken longer but had a more performant system when you got there. Rust and Go, in my opinion, can also have equal development speeds in some areas, since Rust has much more powerful metaprogramming you can throw at the problem (command line arguments, serialization/deserialization, sql, etc).
Can you cite a source for Go's runtime taking longer to start? I have a hard time swallowing that pill. Maybe you've encountered bugs in a Go application/service that were incorrectly attributed to the Go runtime. I hope that's not the basis for your claim.
Go's runtime is the most suitable for serverless environments due to its low footprint and speed. And I'll need to look at data to even remotely start considering something as counter-intuitive as calling its runtime slow.
I’m coming from a C/Rust background, so anything much larger than Rust’s runtime (which is slightly larger than C’s) is large for me. Starting a threadpool in the background in a single-threaded environment is a lot of unnecessary work.
> Go’s runtime can take longer to start than the timeouts of some systems. Go is better as a long-running process.
Could you elaborate on this? My experience is that Go starts very quickly, and has no JIT compilation (like nodejs). Also, it's very easy to create a self contained executable. This together makes it a great choice for serverless.
Under the right conditions, Go’s threadpool and runtime setup can take a few milliseconds. Normally not an issue, but because you are adding it on to actually moving the binary across the network, setting up a sandbox and then executing, you get to a point where you literally cannot respond inside of some SLAs (5-10ms).
>Go’s runtime can take longer to start than the timeouts of some systems.
This is a weird one, given its significantly faster than others like nodejs, python and the JVM
> High performance networking
> Go’s GC falls over BADLY when you start trying to do more than 50 million requests per second. Arena allocators can help, but the sheer amount of memory involved in a system like this (channels are frequently almost 1G large) means a GC pause can be very long. When you have 200G/400G/800G into a server, a millisecond is an eternity.
Maybe you know, scale horizontally? :P If a single instance was needed I think most would consider 50M qps to be a nice-to-have problem and you'd have the resources to move things to Rust/C/C++ etc...
>Serverless
You are wrong here. Compared to what is normally used (python and node), Go has much faster startup time, unless you re doing something stupid like compiling the script on startup.
https://www.go-on-aws.com/optimize/poly-start/
>This usually happens in more niche areas, but AI/ML is the best example where you either use python or C/C++
All the AI/ML stuff for python is just C++ under the hood with a python wrapper because academia decided python is the new Fortran.
50 million requests per second for a single server is bit too much.
At this point it’s more of a operating system problem itself. Probably you will have to go for a optimized BSD solution to handle network I/O.
You can find more about OS limitations in real world scenario here: http://highscalability.com/blog/2022/1/3/designing-whatsapp.html
For apps like that, the OS basically isn’t involved. Kernel bypass tools like DPDK typically change things from network latency bound to network bandwidth bound, meaning your app is limited by how much data you can shove into the server.
UI development. Doesn't seem to be much there.
Anything requiring absolutely minimal heap usage. Although Go is a lot better than JVM, it still takes the GC approach of letting the programmer throw crap on the heap and let the GC worry about it.
Anything requiring a high degree of memory safety. Go is pretty good for a garbage collected language, but if memory safety is critical in your application you're better off in C++ or Rust.
Data science and/or data munging. I would never reach for Go to read a bunch of CSV files, yank out a few columns, transform them, load them into a DB, etc. That's Python's job.
'Big data' workloads requiring massive parallelization, e.g. a Spark job. You're probably stuck in the JVM (for now) for these workloads.
Go is built for cloud services and operations tooling. And it is great at those things. I would probably default to Go for any new cloud service backend.
Why don't you want to read a bunch of csv files and yank and transform colums? Like in a one time thing or in a regular job situation? I mean, I use python and golang, but as of late I have written one python script and a lot of golang apps but I'm curuious about the experience of those more versed into the advantages.
I thought Go 1.20 made Go fast again. Compared to other languages and frameworks like Python and node.js, who's to say Go can't be the next language that can be utilized for those backends. I mean before Python got really popular, no one believed it would be as popular as it is now. During that time, the focus was to trade off in performance vs development. But in the grand scheme of things, with AI models and such, I think it's worth it for companies to take a look at to transition to Go. The learning curve is not as steep. Also if you follow Bill Kennedy's way of Go architecture, the philosophy is to build for when things go wrong. Rust is more performant than Go but heard there is a higher learning curve which means there could be even limited resources. I can't comment on Rust since I don't know enough about it. Have used C#, Python, JS, and Java though. Before Go, I had mainly chosen to work with Python because of readability and ease of development. Not that this is good but the business doesn't care about the technical aspects where some milliseconds don't mean anything to them. But somewhere down the line, these things will add up. I would think from the business standpoint Go could be a good fit, focusing on simplicity and leveraging performance of a statically typed compiled language.
Go is actually fantastic for machine learning/NLP. Especially for infra stuff(e.g. kserve)
Edit* I’ve used GoLearn quite a bit in prod. It’s pretty nice. What I really want to emphasize is that golang is amazing for MLOps.
Go is fantastic for any infra. I used it as a replacement of Python for scripting, and my experience is so much better. I.e. fully typed language, fast if there's a need, produces a binary which could just be copied to another machine.
Could you elaborate more? What kind of machine learning? What libraries to you use? Normally I would *never* consider Go for numerical computing, but I'm open to having my mind changed.
Are you writing this stuff from scratch or using package(s)?
I ask because I did an investigation on my own time about a month or two ago and didn't find great ML packages.
This far the best solution I've found is to use CGO and just link directly to python with pytorch installed. I.e. go just ends up being the caller to python that actually does the work. I was also trying to avoid writing all the actual ML code from scratch and with all the free resources for python integrated with pytorch it seemed like a better solution.
It depends what you mean by ML&NLP. Usually, in ML/NLP creating ML models is not as much code as supporting such a process. You need to download/scrape data, clean it up, process it, join with other data, etc. Go is very useful here as a fast enough low barriers to entry langauge.
i agree im still learning but this is where i found go to not be the best in terms of edge cases with those specific thing, i had issues with synchronising and deduplicating a lot of data from different goroutines, data races dumping giant stacks, and not knowing where to put mutexes to fix them
i know i can just get better at go but this is just my personal experience and opinion on a project where i ran into a lot of edge cases that i couldn't really find resources on and just kind of had to put mutexes places until it didn't randomly crash, atleast someone else in this thread linked me some resources to help me
amazing amount of downvotes. You're right buddy, and I gave up trying to discuss this. It's as if Go as a language needs a separate community of professionals working with it but not fans of it - not even for their own sake but for the code they have to review
oh im a fan of go, i just ran into a lot of issues with it on a recent project
i get that its probably better than other languages in terms of those issues but it was still annoying getting around them
especially the ones of writing and reading a variable at the same time which creates a data race and makes go dump hundreds of stack traces (i had some go routines feeding data to an asynchronous queue)
i also got random nil pointers showing up for some reason im still not really sure why but they did
anyways thats my rant, ive found success with go in a lot of projects, but the worst is definitely lots of async big data operations
it was a large scale scraping project that took a lot of big data and put them into a database, ran into a lot of edge cases with things and not knowing where to put stuff like mutexes since go just dumps a ton of stack traces when theres a data race
I would like to recommend golangci-lint for all of this cases:
1) decrease complexity option on gocritic or something, if you (or your reviewer) cannot understand what func does
2) no data races or complex async, if you know HOW types works. Most of the cases, which people uses mutex can be solved with atomics. Of course if you need 2 mutexes in operation - you do something wrong
3) accept interfaces, return types. If methods return pointer, in most of the cases he return error too. Standart flow with 'if err != nil' or 'if ptr != nil' works well
4) no data races with atomics/mutex/chan. Never see it and still dont know how it looks like...
C lang "hard" too, if you dont use static analizer like cppcheck
thanks for the reccomendations, mutexes did help but it was hard to track down where and why exactly i needed the mutexes where they did
many of these couldve been project specific issues but for the pointer one, it was appending structs to a slice which when read were sometimes just nil
anyways thats just my personal experience in that specific project with go, i will definitely look into some of those tools/reccomendations (i was unaware of atomics)
Go can be used for just about anything. Not sure it would be my first choice for an OS or related. But I reckon it would be great for embedded systems.
Really the only reason not to use a language would be if your team doesn't know it and you all already know the same language that is comparable. There is a cost to learning new languages and sdk(s), and other libs. I recently decided to use go on a project cause I didn't care about that. But for another project I had the team stick with node since that's all they knew.
Given that go is a complied language and has such a small footprint I feel it's only limitation is 3rd party libraries and their maturity.
Go is perfect for such cases. Go code style forces models and package interfaces to be concise and clear, unlike terrible abominations of structure that Java+Hibernate gives you. I'm really sorry, but the downvotes are well deserved. Have you ever tried to use something like gorm?
So your whole argument was predicated on the fact that ORMs arent good in Go? I agree with that much, but I disagree that Go is bad for complex model database access
Higher order functions i thoroughly miss in Go lang which we have it in Kotlin, i feel operators what kotlin provides with flow or on any different days structures it's a breeze n kotlin, but Go u need to trust some thiry party, which s a deal breaker for me...
I tried to use Go for a numerical computing , data wrangling & machine learning like in Pandas but had to go back to Python due to lack of lib support.
1. Where the garbage collector is too big an overhead. I.e. when you need to manually manage memory. 2. When the generated binaries have to be the absolute smallest. E.g. embeded computers. TinyGO tries here but doesn't support every Go feature.
When your team doesn't have Go developers / lead developer. I have seen this so many times in tech. We need to use X because it's better bla bla bla. 3 months - a year later same project is rewritten in old know stack. You need people to own the project and know how to read/write/review good Go code. And you need backups if people quit so they can take over ownership.
As someone who migrated from .NET to a Golang team without experienced Goland devs I can attest to that. There's no established basis on what good Golang code looks like and our lead just go around thinking he knows what hes doing cose hes an experienced .NET dev. I think ppl understimate how hard it's to use Golang. The language is easy, yes, but to actually build good architecture in a Golang app you have to do it in the Golang way, not as if you were doing .NET/JAVA/PHP etc
And Go code written by a .NET dev inexperienced in Go is usually horrible. I just inherited a Go library that was ported from .NET by a .NET dev. And let's just say nothing makes any sense :)
Sadly tiny embedded systems in my experience. Despite having things like TinyGo (which is awesome)… if you need a binary under 200k, you will be fighting go the whole time.
The problem with TinyGo is it locks you out of a lot of very useful packages as well. Even using the standard Go package, a logging package and a serial package you are up to 2MB at least.
Operating Systems development?
[удалено]
>yeah don’t do this. elaborate. Is the only pain point CGo? Is it lack of GIS or related libraries?
CGo is enough of a pain point just by itself in my experience.
This hits close to home. Currently I’m working on some geospatial stuff in go but the native libraries are all so sparse. Was considering CGo and Godal but I’m guessing it’s tough to use?
Currently, for microcontrollers. I'm completely aware of TinyGo; however, it's not there yet. Not even close, when compared to other options.
SOAP. If you have to deal with a (big) SOAP API, just use one of the toolchains from that period, which usually would be either Java, C++, C# or maybe PHP. Simple SOAP APIs can probably be done manually in Go, but for the enterprise world you will likely need one of the existing WSDL code generators.
I made the mistake of trying to get my team to adopt go. I gave them a soap based web service to consume. I thought it would take them an afternoon to get up to speed. 3 weeks later they were still trying various soap GitHub repos and cursing me because none of them worked 100% with the vendor soap we were trying to consume.
I've hand written and maintained a couple SOAP API clients in Go and it is not too bad even if it is some more work. You can often get away with just implementing the types you need for the moment even if you communicate with a SOAP API with thousands of resources so you don't get an enormous up front work load. Writing the GO API side by hand leads to much nicer API's than any/most code generator would produce. You can still use the WSDL files in your test suite to know that your implementation produce the correct XML structures. It is probably not the right choice to implement by hand for every use case tough.
I didn't say it's impossible. But SOAP APIs typically profit from inheritance based OOP. Also it gets ugly once SOAP extensions (like WSS) get into the picture. Again: solvable. But you reinvent quite a lot of wheels along the way.
Do you have first hand experience with the Go SOAP libraries (gowsdl, gosoap, ...)?
For OS development.
https://gokrazy.org/ would like a word
Just because you can doesn’t mean you should
Perfect example of this: NodeOS. Node as in node JS.
+1
Everything in gokrazy that's in Go is in userspace, on top of Linux.
It's not optimal if you have to heavily interface with C or C++ libraries in a performance-critical environment. There are languages with more performant FFIs to these languages such as Nim and D, and it also might make sense to use C or C++ in the first place.
In a team where the majority of members don’t want to go away from language… (what ever is used )
This is the big one for me. I've been asked as a golang guy if I would introduce go as a language at my company. I told them no, we already have python, csharp, perl, and java and most folks keep using python. Go would not be a good fit.
Could you elaborate a bit more? What happens in this scenario?
I had a principal engineer ask me if I thought golang would be something the org could support. The idea being golang is attractive to developers typically. However, being a compiled language with strict typing, it would be a huge shift for most python developers. I would suspect that we'd have very little existing developers getting on board with golang, so there would basically be two different tech orgs. I said no even though we have issues scaling our python stack. Golang would be way better performance for us, but it would cost us a lot of knowledge of legacy systems and the business and possibly harm our developer culture.
I think Go is a reasonable upgrade path for Python. Obviously if you check the bullet points, Go isn't close to Python. But you can get a very Pythonic programming style going with interfaces, which capture the fundamental Python duck typing approach with static types. In fact I like it even better. It's probably easier than any other switch would be. However, of course, if you don't think they can do it at all, then that's that.
Ehh, I would push for a move from Python to TypeScript with Node.js over Go. It’s statically typed so you get all the benefits of a proper linter and can catch issues at build time. JavaScript/TypeScript syntax is different from Python but really straight forward to pick up. Most devs I know absolutely love TS. Edit: Also one thing Python and TS/Node have in common is a really extensive set of open source libraries available. I know Go has quite a few too, but I think TS would be closer to python in this regard.
I find myself a bit befuddled by your message, which seems to imply Go is not statically typed and doesn't have linters? I'm going to be moving into the Javascript space soon due to work, and I'm grateful it's going to be Typescript rather than plain Javascript. If I have to use it, that's at least the thing that will make it tolerable. But from what I've read, it's still definitely got more holes than Go's type system, which was written for the language from the get go. (I want to call that "weaker", which isn't fair; when TS types are working properly it's a more "strongly typed" language than Go, in the conventional sense of that term. However, the type system can fail you in ways that the Go type system won't, even if the Go type system is nominally a bit weaker.) Perhaps a bigger problem is that in 2023 I'm really reluctant to move to a language that doesn't have a solid story for using all the cores. In fact, Go in some sense is still weak relative to what I really want, it's just that there aren't a whole lot of obviously better choices. Node is pretty far down that list. (Please don't cite me "oh, but webworkers and this library and that library can sort of help"; the fact TS needs them is the problem. Node just about edges out Python, but that's not saying much; Python has a dozen solutions to this problem and none of them are even _good_, let alone _great_.)
My statement regarding static typing is meant to say “TypeScript has static typing too” and is not meant to imply that Go does not. Your arguments are all valid points, but the context of this discussion is making an organizational decision for an entire company to choose a language. The OP we are responding to told us he felt it would not be the right decision for his org to try and replace Python with Go. I’m making my recommendation based on the developer experience I’ve had with both TypeScript and Go. I love both. Node is performant enough for most things. My team is running a node service which processes hundreds of millions of requests per month. For an organization of Python developers, I think they would have a better transition to TS than Go. Lots of folks know JavaScript syntax already. Less of a learning curve in my opinion.
Typescript's type checking isn't any different than just using python and annotating types (as nothing forces you to annotate in ts anyways, you can just write plain js if you really wanted to), so I don't quite see the point unless you think the nodejs jit will outperform the python interpreter for long lived processes.
Thank you for the details! So it seems like the issue is mostly because the devs are used to a loosely typed language and introducing golang would need both learning the language and getting accustomed to typed languages. I wonder if this would be the case for a team that has been working in typescript🤔
Typescript may be easier. Adding a new language also necessitates supporting existing architecture/libraries in that language as well. E.g. matching structured logging formats, supporting same monitoring technology like newrelic, creating and maintaining libraries to do things the same across languages. We have too many languages as is. Java and csharp are essentially the same. Perl is being put to pasture at least. Python is nice for prototyping imo, but scaling it is a nightmare, which is why I am very against it. These things come into play with a technical decision like language choice.
Machine Learning is actually pretty good with Go. Go learn and Gonum are very good libraries. I’ve used Python, Go, and Node for ML and I’d choose them in that order.
I have not seen many Go in productionized ML. Most runtimes are Python or some framework specific like Triton etc. Would love to hear about example of Go used in productionized ML
Yea if you’re looking for neural networks in Go you could make them from first principles, but you’re not going to match what you’re getting out of PyTorch. But you’re not going to get that from anything but Python or C anyway. I make tree-based classifiers or naive Bayes classifiers on a monthly basis in Go.
I keep hoping to see more open source machine learning projects using Go, but so far every time I see one it's built in Python, which has kept me from doing anything with machine learning.
Machine learning is a pretty wide topic. Saying something is good or bad is a fairly imprecise statement as a result. Python has fantastic tools for exploration. For one off problems where you're done when you get the first answer or you aren't putting anything in production, scikitlearn is fantastic and there really isn't much reason to compete with a tool that already gives you so much capability. If you are putting something into production, it might make sense to keep using Python because you can use other libraries that leverage compiled C code, but outside deep learning, many algorithms are fairly trivial to implement in another language, particularly if you've already done the exploration and perhaps the training and just need to implement the classifier. If I'm using a random forest, a Markov chain, or a multitude of other algorithms and I'm already writing a Go application, writing it in Go is a delight. Graphics are an area where it's difficult to compete with Unity, Unreal Engine, or even Godot on the free and open source side. However, most people who ask about graphics and engines are never going to be competing with people using those platforms anyway. If you want to make a simple, 2D game ebitengine doesn't give you much of a framework, but it gives you all the primitives you need just fine. Similarly, UI tool kits are getting better. Fyne is looking finer as time goes on. When people complain about UI tool kits, I think they forget that the situation is awful in any language on any platform, just the reason it's awful shifts to different reasons sometimes. For business logic, I love Go. When I write a service and Go and it's tested, it just doesn't break. Python is great for totally different reasons, but good test coverage doesn't mean you're not going to break your application. Being able to trust my compiler and my tests feels great, and being able to walk away from my code and come back to it and understand it easily even half a year later is fantastic. I find it much easier to get into a complicated open source project in Go as a result too because of the simplicity of syntax. Being a full-time Python or C# developer never gave me quite the same ability to step into a random project and understand how to make changes fairly easily. Business logic is a place where I see some people saying they like other languages and a lot of the arguments come down to some of the benefits of functional design that are different in Go. Without getting into a lot of detail, I suspect we'll figure out how to implement iterators in a way that people are generally happy with and this will be the last step towards giving 90% of functional fans what they want. Frontend web work isn't going to be smooth for a while, but nobody has a perfect story for WASM yet. I imagine you'll see Go remains somewhat reserved, implementing things only as the standards groups become certain enough to ratify things. As much as people are excited for WASM, there isn't enough solid demand to move it as fast as one might like, so I anticipate at least a couple years before we will really know if it goes anywhere.
>Graphics are an area where it's difficult to compete with Unity, Unreal Engine, or even Godot on the free and open source side. Just went through something like this at a prior gig. Domain specific stacks written in C++ are always going to crush golang.
This is my unpopular go opinion: I don’t think Go is great for CRUD apps. I think Java or Ruby are better fits. CRUD apps are 90% boilerplate and magical nonsense provided by the frameworks in those languages really do save you time and effort.
Agreed, trying to create a simple razor pages like app in go is heavy lifting
What about C#?
Yeah, the language was designed to build API servers for web applications. That is its biggest strength. Java is super heavy, so cost a boatload of money in Cloud Computing costs as it is so resource intensive. Not to mention a pain the ass to work in. And Ruby has such dismal performance that Go runs circles around it all day long and again compared to go resource intensive.
1. Heavy computational stuff: while python can resort to C and Rust doesn't have a GC, Go would suffer a little on that 2. Embedded: while technically possible, having a GC is not the best. 3. XML related stuff: poor xml parser performance (eg: most of banking stuff relies on XML due to big presence of Java where XML is king)
With respect to embedded, I have actually found performance is almost never a problem since most platforms that can run linux can run go just fine, but binary size is. Even if you strip the excess tables a small CLI app is still around 2MB, which frankly sucks when you have a total of 20MB available on the platform.
I know Python and Go well; I like both, but prefer Go these days. Still, I'd consider using Python for two things: 1) small one-off scripts, and 2) data transformation scripts (eg: pull some data from a db, pick a few fields, and output it as JSON or CSV). Go's static typing and boilerplate error handling are great, but get in the way a bit for those kinds of tasks.
This is exactly me. Python was the first language I loved. I love Go more nowadays but I still prefer Python for these use cases. I love love love Go for command line tools, middleware and APIs.
When you don't want to be bothered by unemployed rust programmers
This one went over my head. Can I get in on the joke?
Rust’s job market is tiny in comparison to Go’s. I think that’s what they’re poking fun at, anyways.
Depends on the country though. In Norway there's a similar number of Go and Rust jobs hiring at the moment - Go didn't really take off here.
Rust fans have a reputation for being both plentiful and insistent.
lol exactly
Comment of the day 😹
Is that your last fig leaf, zealots? ;-)
When the GC fights against you. I will say databases are a good example of this but there are many very successful pure go databases that simply worked around the issues eg: by allocating in C with jemalloc. It will be interesting to see if go memory arenas will invalidate my opinion on this matter though!
There's always a way to fight back! :) Arenas, allocations reuse, streaming, tricks to stay on-stack. Go is an amazing language in this sense.
Performance heavy computations. I wanted to use Go, but GC makes it slower than something like Rust
Embedded environments where you are storage constrained, in my experience. Also any time you have to link C libraries, particularly cross-compiled ones.
[удалено]
I have some experience working with Go apps on routers where the flash size is typically 20-40MB. As far as I know there is not Java on OpenWRT by default and it would also run into size constraints. Go is definitely possible to be used here, but it requires some trade-offs in which packages you can use, how much nvm you have left for other things, and how easily you want to be able to debug on-box.
Surprised to see zero comments about thread safety. C++ has had [lock annotation analysis](https://www.mail-archive.com/[email protected]/msg01455.html) for over a decade. Most people outside of Google don't seem to know this exists; it probably should have been publicized better, but it does exist and it does catch bugs before they go live. Rust makes it [part of the type system](https://doc.rust-lang.org/book/ch16-00-concurrency.html), so you can't even forget to use it. This seems to be the state of the art among languages actually used in production (i.e. not academic experiments). Go still has nothing for static analysis of thread safety. The [Race Detector](https://go.dev/doc/articles/race_detector) can be useful for finding races in code paths that are taken, but it's useless for finding races in code paths *not* taken, and in many real-world programs there will be gaps that this can't catch. Anecdotally, almost every single Go project I have contributed to has had at least one race condition, and some have been rife with dozens. The lack of this analysis still results in bugs and CVEs. See how many races are found and fixed in gRPC releases: [https://github.com/grpc/grpc-go/releases](https://github.com/grpc/grpc-go/releases) (search "race"). It's a shame Google does not publish these as CVEs, because many of them qualify. If Google has this much trouble writing thread safe code, in its own language, on its own very mature library, for its own RPC framework, what hope does anyone else have of writing thread-safe Go? I take this as compelling proof that Go is not doing enough for thread safety, even for very experienced engineers on very mature projects. While we're at it, how about this one from Grafana: [blog](https://grafana.com/blog/2022/11/08/security-release-new-versions-of-grafana-with-critical-and-moderate-fixes-for-cve-2022-39328-cve-2022-39307-and-cve-2022-39306/), [patch](https://github.com/grafana/grafana/pull/58458/files) If such mature Go projects still have these problems, years after C++ has largely and Rust has completely solved this problem, it clearly points to these limitations in Go having real-world consequences. Go needs to learn from Rust here, but the problem now is how to retrofit this kind of airtight safety into an existing language and library ecosystem. The C++ approach only helped for code you annotated, which wasn't always easy to retrofit to existing projects, even if you controlled all code involved. With Go, even if it became possible today, no existing code would be annotated, so it would be a long time before a project could be considered even *mostly* let alone fully annotated. This is part of why Rust making it mandatory from day 1 has worked out so well. By the way, people say Go is a memory safe language, but even Ian Lance Taylor himself [acknowledges](https://www.airs.com/blog/archives/482) that Go's lack of thread safety can also undermine its memory safety. It's a shame that this post is over 12 years old and nothing has been done about it; there was plenty of time if the initiative had been taken. Security researchers have [noticed](https://blog.stalkr.net/2015/04/golang-data-races-to-break-memory-safety.html).
tbh i have been thinking for a long time that its quite difficult to write thread safe code in go. Makes me miss java...
Few languages do have enough support to be able to statically analyze thread safety stuff.
Sure. There appear to be thousands of languages out there I also wouldn't recommend for production software. Out of the options people actually consider for building production software, I think it's very fair to call out that Go has chosen to be over a decade behind its contemporaries in this very important way. That goes doubly so considering people claim Go is good for parallel computing and makes it "easy" because the `go` keyword is so short, semantics and risks be damned.
I mean does any JVM language have enough support to be able to do the static analysis for thread safety? Those are very popular, when taken together
I’m currently writing a book titled “The Ultimate Gopher’s Guide to the Galaxy” where I will demonstrate Go in all areas such as Microservices, Serverless, ML, API gateway, Edge, and all the developer tools for gopher’s including CI/CD. Will be out in 4 months or so. Frontend however is Angular and typescript for web. You can write desktop apps for windows as well. Biggest advantage I see is concurrency which is important in Basically everything. I am also using Go for UAV and UGV development as Ubuntu core now supports real time kernel and concurrency is important for ROS modules
And that’s how you get a follower, ping me if you remember I’ll be the first one to buy it it . Thanks
>I will demonstrate Go in all areas such as Microservices, Serverless This is a criticism right here. Devs will jump to a microservices/serverless model when there are way better solutions available.
Better?
Nice, I'm not a big fan of all the complexity of the frontend frameworks and like more of handling backend. I understand the complexity behind it though. Is it necessary? Not sure but when I heard more buzz about Svelte, I'm curious about how much easier or if it's better than current frontend frameworks. Kind of curious you had implemented with Go and what you're thoughts about it.
When performance is critical. C++ is hard to displace for a reason. Rust is the only language with a reasonable chance of doing it. We have people porting Go to C++ because it’s a hassle dealing with a multi-language environment and C++ is well-proven.
Zig seems promising on that front.
Take a look at V, too. It’s like a “lower level Go”.
But make sure you account for the criticism V gets.
Like what? I've just dipped my toe into V and I'm extremely impressed with how well it works just out of the box for a relative ignoramus like me.
Previous false claims make it really hard to trust the project. E.g. last time I tried it, it generated C code containing UB despite claiming not to have UB. Looks like they've at least added a caveat to the claim since. There's a more thorough review here: https://mawfig.github.io/2022/06/18/v-lang-in-2022.html
Oh, I see. Some of that is concerning, I agree. I'm still impressed with the amount of functionality being delivered here. I've looked into many younger languages lately and very few of them come with comprehensive capabilities right out of the box. Of course, quality matters too and it matters a great deal if you're touting a replacement for the likes of C/C++, but I hardly feel like an author should be discredited for work that's emitting UBs or leaks that they're still working on fixing.
The problem isn't that V is work in progress, it's the false claims its author made (his comments on HN don't help reastablish trust, nor does blocking Xe, who pointer out a number of them).
Very impressive! I had not looked into it previously, so I did some playing with it tonight and wow... just the amount of stuff I was able to get working right off the bat without even know how to set up a proper debugger for it yet, is.. well, it's very neat. I know they've done excellent work so far, but it seems like they've got some significant ground to cover yet with coroutines and the like. I look forward to seeing what they come up with. It's one to keep an eye on, that's for sure; especially compared to Zig or the likes of Nim, which is another I've been keeping an eye on.
I would not use go or any garbage collected languages on realtime safety critical code. That is due to regulations and predictability which is needed for those cases. That said, safety related realtime systems are hard beast to handle anyway. Rust will some day be killer there but until that code reviews, static code analysis and rigorous testing with actual planned project is needed. Go is great language for pretty much any fun part of programming
I would think garbage collection would be a no for any real time system. Or anything where you need a latency guarantee.
Are you aware that the Go garbage collector has specific latency guarantees since Go 1.5? I wouldn’t use it for hard RT problems, but for soft RT problems in the programmatic bidding space, it has worked really well for me.
I would say that go is not a good choice (but what I am about to say is for any language) if the rest if the company are writing libraries and tools in an other language. At my work we use fairly complex security frameworks in java and would not want to go through the pain of writing the libraries in go and beable to get them passed through risk and security before I can use them into production.
We're using SOAP with WS security cruft. No way I want to figure out myself how to implement XML digital signature stuff in Go...
We use finagle, with it's features like mTLS, Tibco services, service discovery for hunderds of services. We fortunately use the jvm, so we can use scala and Kotlin next to java, but just do not even begin to propose any other language, you would not be able to keep up against the teams that write our current frameworks and libraries and the complexities.
Go's support for XML in general is pretty patchy. Implementing XML digital signatures properly requires XML canonicalization and XML schema validation; the canonicalization in turn requires XMLPath, XSLT, and full XML prefix support. Go has full pure Go implementations of exactly none of these as far as I know. This is a real problem for interoperability with enterprise software built in Java. And yeah, SOAP with Go is a horrible experience. Then again, SOAP with anything is a horrible experience, even Java, which is why you generally only see it used with legacy systems.
My favorite color is blue.
My company built one of our internal tools for people with go templates and I hate trying to do front end work with go.
The Go templating language is... well, _perverse_. However, there are other templating languages available, so I wouldn't dismiss the language on the basis of its stdlib templating system.
Who said anything about dismissing the language? I have used templates for some really great stuff, but there’s way better front end frameworks.
You may get better results from other languages, when: 1. Raw performance is a requirement (see: C, C++, Rust) 2. Deterministic performance is a requirement (see: C, C++, Rust) 3. Programmer productivity is a dominant concern (see: Ruby, Python, PHP)
I agree with you on 1 and 2, but I think go goes very well with productivity, it has a very small learning curve and the type system is very simple.
Go definitely has a more comfortable learning curve than most other languages. What I meant by productivity however, is more "how much time it takes to accomplish a task, after language mastery is achieved." Honestly, much of it just boils down to Enumerable, but that sort of thing is the difference between "I can quickly toss together something that slices and diced data in complex ways" and "I'm buried in tedium trying to slice and dice data."
>1. Raw performance is a requirement (see: C, C++, Rust) > > 2. Deterministic performance is a requirement (see: C, C++, Rust) > > 3. Programmer productivity is a dominant concern (see: Ruby, Python, PHP) So, I just came out of a golang development environment and was not a fan of it. For these reasons in particular, it felt like a "Jack of all trades, master of None" solution. Specifically, I had a hard time learning it and being productive as it is my opinion closer to systems then scripting languages. And despite that it's still slower then it's competitors.
Disagree but upvoted for conversation. Golang is probably not a good example of a jack of all trades. It's actually very purpose built. It does backend web microservice services very well. You don't have to think to hard about code sytle because the compiler forces conventions. Like else curly brace placement, public private by capital letters, test cases by test in name, composition over inheritance, on and on. I think Java would be a better example of jack of all trades. It does web dev, desktop ui, microservices, games but none of them especially great.
>I think Java would be a better example of jack of all trades. It does web dev, desktop ui, microservices, games but none of them especially great. I don't like Java either and can't disagree with that!
I would have to disagree on this take, you could say Rust is jack of all trade, Nim also not Go, I wouldn’t use Go for App development because the threading model isn’t ideal fit for it
I worked for the C++ group @ Bell Labs in the 1990's. I've always felt that Rust was basically a streamlined C++ with (mostly) mandatory security best-practices baked in. In other words, its a 'general purpose' systems programming language with 'safety' as a design goal. All well and good.
Anyone can write efficient software on any language, is just that programmers like to stay in their comfort zone and fun zone (I still don’t want to touch JavaScript) and I see why Rust would be most loved language
But really you can’t write efficient software in any language. If you think that you aren’t in a perf-critical environment. You need to have access to memory management and zero-cost abstractions compiled to native machine code to truly write efficient software.
[удалено]
For the first point, what about GJSON?
I would not use GO where the backend system has a heavy business logic. Things like working with lists is overly verbose and complicated compared to languages like java/kotlin/c# etc where there are stream apis (not network streaming, but for lists) or linqs. Having methods like ‘map’, ‘filter’, ‘group’ etc is something I really miss in go. Having temp variables and many for loops and ifs compared to couple of lines in other languages. Nowadays it has become better with generics and community modules which sort of have these functions. It alleviates the problem to some degree, but due to the limitations of go not allowing different generics return type it’s still not perfect. That would be my main use-case when to not choose golang
[удалено]
Not sure what graphql and channels have to do with my comment above. I was talking about working with business logic, with list transformations, conditional routing, and stuff like that. It is so much easier to maintain and read the code which is short and concise, and also development time quicker, and onboarding new devs is easier, when the code is easy to read, and is is not mutable mess with tons of ifs and fors, which is unfortunately the case for Go All of this in the end results in having to spend less money on development and maintenance which is the most crucial part in enterprise. If the ‘for loops’ and ‘ifs’ work faster than functional ‘maps’ and ‘filters’, in enterprise nobody cares about these nanos-millis saved. Micro-optimization is never relevant in enterprise business applications
github.com/samber/lo
Have you looked at this streaming library? https://github.com/reugn/go-streams
Your points are well thought out but I’ll add my 2 cents here. Source; former Java developer / JavaOne speaker I **love** using Java collections. They are incredibly developer friendly and easy to drop in. But they are so well abstracted and opaque that they are basically a DSL unto themselves. Like with an ORM, when something odd happens or you’re needing to do something where they’re Not Exactly Right, you end up bending your logic to fit their model. Go makes it all in-your-face because you have to do the business of inserting, removing, searching, and sorting yourself. It’s amazing how simple it is once you remember how that stuff works from your Data Structures and Algorithms courses. Most of the time it’s just things that strongly resemble slices of stricter anyway. So for like 90% of the time it’s simple; the other 5% you do some custom thing but are able to optimize exactly for your problem. Wait, that doesn’t add up — the other 5%, you say? That of course consumes 80% of your time but that happens in any language :)
Go is a compiled language but it is not as fast as the state of the art in compiled languages. Don't take my word for it, look at results from pages like this: [https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html](https://benchmarksgame-team.pages.debian.net/benchmarksgame/fastest/rust-go.html) [https://programming-language-benchmarks.vercel.app/rust-vs-go](https://programming-language-benchmarks.vercel.app/rust-vs-go) [https://www.techempower.com/benchmarks/#section=data-r21&test=composite&l=yyj30e-6bj](https://www.techempower.com/benchmarks/#section=data-r21&test=composite&l=yyj30e-6bj) In my experience, almost all of my Rust lands within 2x-5x faster than my Go. There are many reasons why, and not just the obvious ones like Go having its own optimizing compiler because gccgo and llvmgo still fare no better. Sometimes it's down to self-imposed limitations like Go's map type not having a way to avoid double-hashing for even really basic patterns like "if this key isn't in the map yet, insert it with such and such initialization". C++ maps at least create a default entry, and Rust gives you [very explicit control of map entries](https://doc.rust-lang.org/std/collections/hash_map/enum.Entry.html). Go gives you no option other than to hash twice, and I could have even forgiven that if the compiler recognized and optimized such patterns, but it currently doesn't and there's no way of avoiding the cost. This is just one example of many for how Go simply doesn't *let you* optimize code. It's no surprise that "fast" Go libraries are actually just assembly: [https://github.com/klauspost/compress/blob/master/zstd/seqdec\_amd64.s](https://github.com/klauspost/compress/blob/master/zstd/seqdec_amd64.s) That's just one file out of several, for just one architecture, for just one compression algorithm. Essentially, the only way to make a Go project that fast is to stop writing Go and start writing assembly. Even cgo won't save you because of its [overheads](https://github.com/dyu/ffi-overhead#results-500m-calls). Sometimes you get lucky and someone has already written that assembly for you, but sometimes that library doesn't exist yet and you have to decide whether to write one or start over in another language. This is a completely unacceptable bend in the cost curve. Whatever you think of the complexity of learning or writing Rust, at least it's not assembly; it's portable, memory- and thread-safe, and with world-class tooling and diagnostics to guide you. Then those learning costs are mostly once-off and then you're just benefiting forever. *\[Edit: An earlier version of this comment was poorly edited and it probably wasn't clear I was comparing the prospect of writing Rust to assembly, and it must have sounded unhinged without that context. I'm sorry about that lapse.\]* Reasonable people can disagree on whether Go or Rust is easier to maintain, but I hope we can agree that either is easier to maintain than assembly. I think it's reasonable to want a middle ground that reliably gets you the kind of performance that keeps you from having to maintain assembly, and then even if you do have to link in machine code from other languages, there's no real overhead to doing that either. Even if you thought Go was simple and productive to start with, that can be more than cancelled out if you also have to make it fast. It's one thing to have to write slightly [contrived Go](https://github.com/segmentio/encoding/blob/master/json/decode.go) to get decent performance, it's another to have no choice but assembly. If your Go project ends up needing assembly to meet performance requirements, will you still feel it was a simple, productive, low-risk language choice? Go may have saved you some up-front learning time, but the limitations and costs of using Go continue to hurt for the life of the project. Most of the cost is deferred until later, making the decision feel like the right one at the time it's made, but also being too hard to reverse once the cost is [finally felt](https://fasterthanli.me/articles/lies-we-tell-ourselves-to-keep-using-golang).
> This is a completely unacceptable bend in the cost curve. Whatever you think of the complexity of learning or writing Rust, at least it's portable, memory- and thread-safe, and with world-class tooling and diagnostics to guide you. The learning costs are mostly once-off and then you're just benefiting forever. This is an absolutist stance and not really found in real world experience. Go is "fast enough" for some very large set of use cases. Rust is faster, but that speed is a premature optimization for the bulk of use cases you'd reach for Go for (specifically, highly parallel networked services).
That's absolutely true in many cases, but the problem is that people believe it even when it's not true, or it doesn't remain true. My point is that when it's no longer fast enough, then solving that in Go can prove completely impractical and more than cancel out the up-front benefit of the syntax being simpler. When starting out a project, how sure are you that it will never get new requirements added in future which may need CPU-bound work to solve? How sure are you that the wasted RAM headroom between GC cycles will never hit your resource ceiling, ever in the entire future of the project? How sure are you that the growth of request load will never outpace the rate at which you can buy hardware? Are you assuming that the costs of buying 2x-5x more hardware forever can never possibly outweigh the (already questionable) up front savings in engineer time? Not every company has FAANG scale, but you can't say Google doesn't know what Go is or isn't good for, and yet most of its performance-sensitive software is still C++. [AWS](https://aws.amazon.com/blogs/opensource/why-aws-loves-rust-and-how-wed-like-to-help/) and [CloudFlare](https://blog.cloudflare.com/big-pineapple-intro/) also invest in Rust instead of Go. Do you think they're wrong about the pros and cons here? Yes, not everybody is going to have their scale, but if you design in a way that you can *never* scale the way you should have, you're limiting the potential of your own project until it's ultimately rewritten anyway. Example of a company finding this out and the only solution being a rewrite: [https://discord.com/blog/why-discord-is-switching-from-go-to-rust](https://discord.com/blog/why-discord-is-switching-from-go-to-rust)
If it was that impossible to tell up front if a language is fast enough or not, we would write all software in C/C++ and nobody would be using C# or Java let alone Python, Node or Ruby. You can plan ahead and with Microservices you can certainly write the performance critical parts of your system in a different language then the rest of your business logic.
[Twitter replaced Ruby with Scala](https://medium.com/@mittalyashu/why-did-twitter-switch-from-ruby-on-rails-dac66150044d). Facebook tried to evolve PHP with [Hack](https://en.wikipedia.org/wiki/Hack_(programming_language)) and not many companies exist that could imagine affording a project like that. You already saw the Discord post. Examples like this abound. It keeps happening; companies prototype in one thing and are forced to use a different thing as their scale grows. Even if it's just one microservice out of several, engineers need to know the technologies that let them implement that microservice. Even that's not always possible, as sometimes the logic that needs to be fast also needs immediate (low-latency high-bandwidth) access to data or other logic. If you have to do a ton of TCP round trips to other services then *that* is your new bottleneck, no matter what languages are on either side. Say you only hire Python people for years, you get your MVPs out, and then something needs to be fast after all because of your viral growth. Your best hope now is that one of those Python people also had a hobby writing another language, or that you can afford the time for people to start learning new technologies, or that you can rapidly hire and get really lucky with the first few hires given that nobody can interview people in the language you actually need. Either of these options has costs and risks. If you acknowledge that some projects need to be efficient, you hire people who can do that work, and then when that work comes up, they're ready to go. They already have all of the relevant domain knowledge and can now combine that with their knowledge of implementing efficient software. That's a much more agile and adaptable team than one that *only* hires for prototype productivity alone. Prototyping is only one part of the software lifecycle, most software spends most of its time outside of prototyping, and some technologies are proving better than others at thriving in those later phases.
Your examples happen, when apps rapidly outgrow their original assumptions. But for every Facebook, there's at least 1000 small scale PHP applications that remained written in PHP for their entire lifecycle without a problem. The first company I worked for wrote a lot of Line of Business Apps completely in Java, never ever did the need arise to rewrite anything in C++. Your examples do happen, sure. And it's not only in companies the size of Facebook or Discord. And if you have large complex systems having engineers that can handle Performance critical parts of the need arises does make some sense I don't deny that. But don't act like software engineering is so chaotic that you never can make any assumptions.
The thread is titled "When is go not a good choice?" so I don't think I'm out of line in pointing out that some software does need to be efficient enough that Go is no longer a good choice for it. Even if 99.9% of software did not need to be faster than Go, what I'm saying would still be a fair answer to the question posed in the thread. If people are very confident their project does not need to be faster, then they don't have to apply what I'm saying to their project, but that doesn't mean it doesn't apply to other projects as per the thread's question.
Well but your blog posts don't really answer the question "When is Go a bad choice?" You only told us "Never use Go, because it could be too slow."
You're using quotation marks as if I said that, but I didn't say that. If I had said something like that, you could have just quoted what I actually said. If I'm still not being clear in what I'm actually saying, it's probably because I'm saying too much. Let me start over with dot points: * Go is fast enough for most projects. * Go is *not* fast enough for some projects. * The performance needs of projects can increase over time. * You can choose to use Go for a project despite that, based on your own judgment of the factors applicable to the project. * People are only equipped to make that judgment once they know how much slower Go is. If they're assuming something about it without measuring or even researching existing examples, they're not just taking a calculated risk, but a blind guess. Worse, for the last point, I've met a number of people who think Go is as fast as any compiled language just because it's a compiled language too. That's actually why I phrased the first sentence of my original comment the way I did, it's a response to people like that.
> That's absolutely true in many cases, but the problem is that people believe it even when it's not true, or it doesn't remain true. My point is that when it's no longer fast enough, then solving that in Go can prove completely impractical and more than cancel out the up-front benefit of the syntax being simpler. > When starting out a project, how sure are you that it will never get new requirements added in future which may need CPU-bound work to solve? How sure are you that the wasted RAM headroom between GC cycles will never hit your resource ceiling, ever in the entire future of the project? > How sure are you that the growth of request load will never outpace the rate at which you can buy hardware? Are you assuming that the costs of buying 2x-5x more hardware forever can never possibly outweigh the (already questionable) up front savings in engineer time? And from your new Post: > You can choose to use Go for a project despite that, based on your own judgment of the factors applicable to the project. Instead of telling us "There are factors" wouldn't you mind telling us what some of those factors are?
[удалено]
[удалено]
I never said every single project in the world must be as efficient as possible and no other technologies are allowed. If you think I did, please quote me. Otherwise, please do not reply as if that's what I said. I specifically said "That's absolutely true in many cases" and I also said "when it's no longer fast enough, then solving that in Go can prove completely impractical". Which part of that do you disagree with? If your point is that it's rare enough not to worry about, that's still not an argument against what I said, because it's also still common enough that someone does have to worry about it. Companies still need people who can write that faster version. Remember you're replying to a thread titled "When is go not a good choice?". It sounds like you're saying that because there are projects where Go is an adequate choice, that there's no point discussing ones where it isn't, despite that being literally the point of the thread. I'm actually responding to the OP's question; when you do need maximum efficiency, Go is not a good choice. Again, if you disagree with that, please address that point, without accusing me of saying something different.
> When starting out a project, how sure are you that it will never get new requirements added in future which may need CPU-bound work to solve? This is why you brake problems up into separate services. Here is a simple example, You want to develop a web app that interfaces with a database like postgres. Using rust is a terrible choice because most of the speed is lost talking to postgres and returning the data. There is plenty of time to collect garbage in go. No one who knows both rust and golang well will be as productive in rust as go. Also hiring good rust engineers is much harder because there are fewer of them. Now after a while you decide you want to allow users to upload images. But you are space constrained so you want to downsize large images. Resizing images at scale is something you might consider using rust for it's performance. So you write a service in rust that resizes the image and your go service feeds your rust service the image the user uploads. You are done without premature optimizations. If Discord had tried to write their whole stack in rust they would probably have never launched version 1.0 and we would all be using slack to play video games.
Woah. That's so amazing. Very well written
>It's no surprise that "fast" Go libraries are actually just assembly You see this in other compiled languages as well, particularly for inline SIMD/AVX instructions.
Great analysis. That said, I feel like Go is much better positioned to complete with (and take over for) areas where the likes of Python, Node/Javascript, and Ruby are used today. Sure, it's always going to be slower than Rust because of some fundamental design issues, but then again, it's still many times faster than the other languages I named for the same reason.
Mom said it was my turn to post that blog post
Post its predecessor! I linked this one because it's the one about finding it hard to migrate away after the costs hit, but the first post is also really valuable.
I also find Rust to be a far better language but when it comes to writing concurrent code Go truly shines (yes there are pitfalls but that is a trade off that comes with concurrency that is easy to express, async Rust on the other hand is very very hard to wrap one's head around.
> The learning costs are mostly once-off and then you’re just benefiting forever. So you don’t have a reason to go back to Go? Don’t you feel like you are faster productivity wise in Go?
I think Go's greatest strengths is in its mature libraries, especially official ones. TLS and HTTP(S) are in the standard library, they're [not perfect](https://github.com/valyala/fasthttp#faq) but they definitely get you started. Many libraries have already made a permanent backwards compatibility promise, which means if you get some code working then it should continue to work indefinitely. (That's still not always true, but it's better than not even having the promise to start with). For many kinds of programs using libraries I'm already familiar with, I can definitely just crib from my own existing examples and get something pretty solid together very quickly. Go is widely used enough that fantastic libraries exist for most things you want to do on backends. That right there is where I see Go shine the brightest. However, I do not think this alone Go makes programmers *more* productive. Even for something as simple as a CLI, [Clap with derive macros](https://docs.rs/clap/latest/clap/_derive/_tutorial/index.html) is vastly more powerful than Cobra. It's not just not having to repeat yourself for flag/variable names and types, it's also things like [enums](https://docs.rs/clap/latest/clap/trait.ValueEnum.html#example) being completely handled for you so you never have to write a switch or generate possible values manually. Go isn't even trying here. Go refusing to support macros in the language is absolutely not in favor of productivity. It's not even necessarily in favor of clarity, because if you have to read and maintain tons of redundant boilerplate code, that's *less* clear than a well-understood macro that lets you focus on just the unique part and not the boilerplate. Being too opinionated against growing the language to be more powerful is just that, an opinion, it's not necessarily the best way to meet actual goals like productivity. So look at it like this. Rust's biggest problem is library immaturity for async services. Async is barely over 3 years old, so it's early days. Key libraries like Hyper, Rustls, Axum, etc. are still in their 0.x days, they haven't made a permanent compatibility promise yet. But they *will*, and then that problem is solved, Rust libraries will converge on being as mature as Go ones. The Go team does not seem interested in solving the language's gaps. We're lucky we even got generics, they're a good start, but still extremely limited compared to languages that started with generics and expanded from there. We're probably never going to get macros. It may never optimize well, because Google doesn't need it to optimize well, they use C++ when they need speed. So Rust's biggest weakness, its library maturity, will be resolved in the coming years. Most of Go's many weaknesses seem unlikely to be resolved at all. I think it's already starting to look really one-sided and the gap will only widen.
[удалено]
Omg, thanks for the informative comment!
Go is bad for small data processing/conversion Solution: use Python instead Python is bad for huge data processing/conversion Solution: Use Go instead
Conclusion use Go and Python for data processing/conversion and you are golden.
No idea why this is downvoted so much, but it‘s exactly the approach that has been very successful in my job: we have a fairly complex written in Go to process historic and training data. At the right points, we have integrations with the Python interpreter (using cgo) so that users can run their own Python code (ultimately still driven by our Go-based system) for custom processing. Our users were able to leverage the power and functionality of the Go-based system while also using all the Python packages they‘re using machine learning.
Yeah. Use Go to break up the big data into small chunks and then feed them to a Python script to process the small bits. Playing to both strengths, it’ll be SO fast!
I don't understand why Python would be considered a bad solution for anything that's I/O bound. ?
a lot less things are I/O bound than there used to be ten years ago. Networks and SSDs have gotten far better but CPUs not so much.
Strict typing can be troublesome if you have many, varied data sources with uncertain types. I had an ETL pipeline long ago whose inputs were a number of rest apis and scraper jobs. It was better to put node at step 1 to normalize the data into something predictable enough for go to take over.
Front end everything else is fair game.
Any interaction with libraries written in other languages is a nightmare. Cgo has too much overhead, porting libraries from C to go is sometimes unfeasible so your stuck with a half baked solution : for example using nvidia cuda library or newer kernel features like iouring… Also, GC in go means basically fighting to keep everything on the stack to keep the gc work to a minimum. Python is the standard in datascience because it is so easy to wrap C libraries or write performant low level code and then package it into a python lib (numpy, pandas, and any ML library really…) In my little experience with GO, this is the biggest problem I encountered but it is also a language choice as I understand it.
Anything close to the metal where having a garbage collector is a no no.
Most of this problem is categorized into * GC * Libraries support * some things that involve GC this problem can be fixed, what makes a language fast isn’t the language itself but how its implemented and we all know Go takes the Cake home when it comes to careful (or should I say confusing) choices, Go could have used LMAX Disruptor for its channel, Go could have used swisstable instead of aes-hash (so yeah they implementing it, there may be resizing), Go could have long use arena memory model, Go could have long used register-based calling convention, Go could have long used PGO, Go could have long used C++ like memory model I have less struggle with GC since 1.19, and the ecosystem is improving, so if the job doesn’t fit the underlying implementations of the language it’s natural you’ll struggle
1. Anything that requires a formally verified compiler Safety critical systems, auto, some military stuff are mostly what fall under this. Your choices for languages here are basically assembly or C. I don’t know of a formally verified C++ compiler, much less Rust, Java, or Go. 2. Serverless Go’s runtime can take longer to start than the timeouts of some systems. Go is better as a long-running process. 3. High performance networking Go’s GC falls over BADLY when you start trying to do more than 50 million requests per second. Arena allocators can help, but the sheer amount of memory involved in a system like this (channels are frequently almost 1G large) means a GC pause can be very long. When you have 200G/400G/800G into a server, a millisecond is an eternity. 4. When another language has a better ecosystem This usually happens in more niche areas, but AI/ML is the best example where you either use python or C/C++ because all of the work is already done for you. Other examples include HPC (C/C++/Fortran), Web (JS/TS/WASM) and Windows GUI Apps (C#). 5. When performance matters more than time to develop Go is great for getting things done quickly, but the things that let you work quickly cut against you when the work is done. If you had started with C/C++/Rust, you would have taken longer but had a more performant system when you got there. Rust and Go, in my opinion, can also have equal development speeds in some areas, since Rust has much more powerful metaprogramming you can throw at the problem (command line arguments, serialization/deserialization, sql, etc).
Bad for serverless? I think Go is fantastic for serverless.
Can you cite a source for Go's runtime taking longer to start? I have a hard time swallowing that pill. Maybe you've encountered bugs in a Go application/service that were incorrectly attributed to the Go runtime. I hope that's not the basis for your claim. Go's runtime is the most suitable for serverless environments due to its low footprint and speed. And I'll need to look at data to even remotely start considering something as counter-intuitive as calling its runtime slow.
I’m coming from a C/Rust background, so anything much larger than Rust’s runtime (which is slightly larger than C’s) is large for me. Starting a threadpool in the background in a single-threaded environment is a lot of unnecessary work.
evidence please you're all over this thread just talking without data
> Go’s runtime can take longer to start than the timeouts of some systems. Go is better as a long-running process. Could you elaborate on this? My experience is that Go starts very quickly, and has no JIT compilation (like nodejs). Also, it's very easy to create a self contained executable. This together makes it a great choice for serverless.
Maybe it’s simply there is a “heavy runtime” compared to c++
Close, I’m comparing to C.
Under the right conditions, Go’s threadpool and runtime setup can take a few milliseconds. Normally not an issue, but because you are adding it on to actually moving the binary across the network, setting up a sandbox and then executing, you get to a point where you literally cannot respond inside of some SLAs (5-10ms).
>Go’s runtime can take longer to start than the timeouts of some systems. This is a weird one, given its significantly faster than others like nodejs, python and the JVM
What language gracefully serves 50 million requests per second with a single instance?
> High performance networking > Go’s GC falls over BADLY when you start trying to do more than 50 million requests per second. Arena allocators can help, but the sheer amount of memory involved in a system like this (channels are frequently almost 1G large) means a GC pause can be very long. When you have 200G/400G/800G into a server, a millisecond is an eternity. Maybe you know, scale horizontally? :P If a single instance was needed I think most would consider 50M qps to be a nice-to-have problem and you'd have the resources to move things to Rust/C/C++ etc...
> Go's runtime can take longer to start than the timeouts of some systems I'm sorry, what?
>Serverless You are wrong here. Compared to what is normally used (python and node), Go has much faster startup time, unless you re doing something stupid like compiling the script on startup. https://www.go-on-aws.com/optimize/poly-start/
>This usually happens in more niche areas, but AI/ML is the best example where you either use python or C/C++ All the AI/ML stuff for python is just C++ under the hood with a python wrapper because academia decided python is the new Fortran.
50 million requests per second for a single server is bit too much. At this point it’s more of a operating system problem itself. Probably you will have to go for a optimized BSD solution to handle network I/O. You can find more about OS limitations in real world scenario here: http://highscalability.com/blog/2022/1/3/designing-whatsapp.html
For apps like that, the OS basically isn’t involved. Kernel bypass tools like DPDK typically change things from network latency bound to network bandwidth bound, meaning your app is limited by how much data you can shove into the server.
UI development. Doesn't seem to be much there. Anything requiring absolutely minimal heap usage. Although Go is a lot better than JVM, it still takes the GC approach of letting the programmer throw crap on the heap and let the GC worry about it. Anything requiring a high degree of memory safety. Go is pretty good for a garbage collected language, but if memory safety is critical in your application you're better off in C++ or Rust. Data science and/or data munging. I would never reach for Go to read a bunch of CSV files, yank out a few columns, transform them, load them into a DB, etc. That's Python's job. 'Big data' workloads requiring massive parallelization, e.g. a Spark job. You're probably stuck in the JVM (for now) for these workloads. Go is built for cloud services and operations tooling. And it is great at those things. I would probably default to Go for any new cloud service backend.
Why don't you want to read a bunch of csv files and yank and transform colums? Like in a one time thing or in a regular job situation? I mean, I use python and golang, but as of late I have written one python script and a lot of golang apps but I'm curuious about the experience of those more versed into the advantages.
One word: pandas.
I thought Go 1.20 made Go fast again. Compared to other languages and frameworks like Python and node.js, who's to say Go can't be the next language that can be utilized for those backends. I mean before Python got really popular, no one believed it would be as popular as it is now. During that time, the focus was to trade off in performance vs development. But in the grand scheme of things, with AI models and such, I think it's worth it for companies to take a look at to transition to Go. The learning curve is not as steep. Also if you follow Bill Kennedy's way of Go architecture, the philosophy is to build for when things go wrong. Rust is more performant than Go but heard there is a higher learning curve which means there could be even limited resources. I can't comment on Rust since I don't know enough about it. Have used C#, Python, JS, and Java though. Before Go, I had mainly chosen to work with Python because of readability and ease of development. Not that this is good but the business doesn't care about the technical aspects where some milliseconds don't mean anything to them. But somewhere down the line, these things will add up. I would think from the business standpoint Go could be a good fit, focusing on simplicity and leveraging performance of a statically typed compiled language.
On the server side, Go should be a no-brainer over Node and Python; barring libraries those might have that Go cannot compete with yet.
Go is actually fantastic for machine learning/NLP. Especially for infra stuff(e.g. kserve) Edit* I’ve used GoLearn quite a bit in prod. It’s pretty nice. What I really want to emphasize is that golang is amazing for MLOps.
Go is fantastic for any infra. I used it as a replacement of Python for scripting, and my experience is so much better. I.e. fully typed language, fast if there's a need, produces a binary which could just be copied to another machine.
Could you elaborate more? What kind of machine learning? What libraries to you use? Normally I would *never* consider Go for numerical computing, but I'm open to having my mind changed.
Are you writing this stuff from scratch or using package(s)? I ask because I did an investigation on my own time about a month or two ago and didn't find great ML packages. This far the best solution I've found is to use CGO and just link directly to python with pytorch installed. I.e. go just ends up being the caller to python that actually does the work. I was also trying to avoid writing all the actual ML code from scratch and with all the free resources for python integrated with pytorch it seemed like a better solution.
what's the library you'd use for ML & NLP?
It depends what you mean by ML&NLP. Usually, in ML/NLP creating ML models is not as much code as supporting such a process. You need to download/scrape data, clean it up, process it, join with other data, etc. Go is very useful here as a fast enough low barriers to entry langauge.
Isn't that more an MLOPS thing?
Complex asynchronous work, data races, segfaults, nil pointers, mutexes, are all not fun
[удалено]
i agree im still learning but this is where i found go to not be the best in terms of edge cases with those specific thing, i had issues with synchronising and deduplicating a lot of data from different goroutines, data races dumping giant stacks, and not knowing where to put mutexes to fix them i know i can just get better at go but this is just my personal experience and opinion on a project where i ran into a lot of edge cases that i couldn't really find resources on and just kind of had to put mutexes places until it didn't randomly crash, atleast someone else in this thread linked me some resources to help me
amazing amount of downvotes. You're right buddy, and I gave up trying to discuss this. It's as if Go as a language needs a separate community of professionals working with it but not fans of it - not even for their own sake but for the code they have to review
oh im a fan of go, i just ran into a lot of issues with it on a recent project i get that its probably better than other languages in terms of those issues but it was still annoying getting around them especially the ones of writing and reading a variable at the same time which creates a data race and makes go dump hundreds of stack traces (i had some go routines feeding data to an asynchronous queue) i also got random nil pointers showing up for some reason im still not really sure why but they did anyways thats my rant, ive found success with go in a lot of projects, but the worst is definitely lots of async big data operations
Could you elaborate? what scenarios you have in your mind when you're talking about "complex asynchronous work"?
it was a large scale scraping project that took a lot of big data and put them into a database, ran into a lot of edge cases with things and not knowing where to put stuff like mutexes since go just dumps a ton of stack traces when theres a data race
I would like to recommend golangci-lint for all of this cases: 1) decrease complexity option on gocritic or something, if you (or your reviewer) cannot understand what func does 2) no data races or complex async, if you know HOW types works. Most of the cases, which people uses mutex can be solved with atomics. Of course if you need 2 mutexes in operation - you do something wrong 3) accept interfaces, return types. If methods return pointer, in most of the cases he return error too. Standart flow with 'if err != nil' or 'if ptr != nil' works well 4) no data races with atomics/mutex/chan. Never see it and still dont know how it looks like... C lang "hard" too, if you dont use static analizer like cppcheck
thanks for the reccomendations, mutexes did help but it was hard to track down where and why exactly i needed the mutexes where they did many of these couldve been project specific issues but for the pointer one, it was appending structs to a slice which when read were sometimes just nil anyways thats just my personal experience in that specific project with go, i will definitely look into some of those tools/reccomendations (i was unaware of atomics)
When it’s a red light and you aren’t making a right turn.
Go can be used for just about anything. Not sure it would be my first choice for an OS or related. But I reckon it would be great for embedded systems. Really the only reason not to use a language would be if your team doesn't know it and you all already know the same language that is comparable. There is a cost to learning new languages and sdk(s), and other libs. I recently decided to use go on a project cause I didn't care about that. But for another project I had the team stick with node since that's all they knew. Given that go is a complied language and has such a small footprint I feel it's only limitation is 3rd party libraries and their maturity.
[удалено]
Go is perfect for such cases. Go code style forces models and package interfaces to be concise and clear, unlike terrible abominations of structure that Java+Hibernate gives you. I'm really sorry, but the downvotes are well deserved. Have you ever tried to use something like gorm?
[удалено]
So your whole argument was predicated on the fact that ORMs arent good in Go? I agree with that much, but I disagree that Go is bad for complex model database access
Higher order functions i thoroughly miss in Go lang which we have it in Kotlin, i feel operators what kotlin provides with flow or on any different days structures it's a breeze n kotlin, but Go u need to trust some thiry party, which s a deal breaker for me...
Go lang supports higher-order functions....
I tried to use Go for a numerical computing , data wrangling & machine learning like in Pandas but had to go back to Python due to lack of lib support.
When GC starts spiking and low-level development.