5 ms·
To add to your valid statements, Go has easily outperformed any other language we have compared it to in modern backend development. We are using it for our ne
by Mo3 4y ago
To add to your valid statements, Go has easily outperformed any other language we have compared it to in modern backend development.
We are using it for our new API iteration and see consistent performance improvements of over 40-50x the performance of Python and at least 5x that of Node, not to mention the 2x reduced cold start times of cloud functions and much smaller binary sizes.
We use it in a hexagonal architecture pattern which it is just perfectly suited for and couldn't be happier. I personally believe it is the best choice these days for business and backend logic.
Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good.
- whoevercares 4y ago> Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good. With python binding? Or pure Go? It seems impossible for data scientists to all switch to Go
- Mo3 4y agoI don’t expect them to switch at all, quite honestly, Python is still an excellent language and super suitable. I’d just love to see at least mature alternatives be present for the likeminded. I also have a lot of trouble with Pythons inconsistency now after spending all my time in Goworld quite honestly, and seeing how we have managed to move to Go completely yet we still run a queued Python environment exclusively to send data jobs to from the Go environment.. I can’t help but wish for at least mature dataframes
- pphysch 4y ago> Here's to hoping the Pandas alternatives for Golang become mature soon enough so we can ditch Python for good. I thought that Go might take more territory from Python, especially with generics, but now I'm settling on Python<->gRPC<->Go backends for the foreseeable future. Go will never be as expressive as Python -- for good reasons -- which is important for high-level data science (ORMs, DataFrames, viz, NNs, etc).
- pjmlp 4y agoYou mean the domains that make use of Fortran, C++, Chapel, Julia? Yep no place for Go there.
- Phrodo_00 4y agoI was expecting a comparison in development effort rather than performance, since that's the strength of Python. System performance is not necessarily a priority of Python, and no one would expect it to be comparable to a language that compiles to machine code without using something like pypy, and even then it'd be likely to lose. If we're comparing it for system performance I'd expect comparisons to other high level compiled languages like Rust, D or C++.
- Mo3 4y agoEven that is highly questionable. Try implementing hexagonal patterns with Python.. the first thing you get to read is about how that is not the pythonistic way. Nothing against Python, it is favorable for beginners and engineers in different fields, but at the point where even Node starts outperforming Python by 10x and you actually want to implement bigger systems you might wish for something different. I don’t see the need to specifically compare Go to either high or low level languages. It sits comfortably right between them and is perfect like that. (This might be an opinionated comment, but I’d love to see anyone try implementing a public API with a dozen of adapters and ports in C++.)
- pkaye 4y agoNever heard of hexagonal patterns (architecture?) but it look like a lot like what my go project architecture at work looks like. Time to learn more about it...
- pjmlp 4y agoWell, that is how we used to do, when servless was known as CGI, Apache modules or ISAPI extensions, or microservices where known as SunRPC, CORBA or DCOM endpoints.
- Mo3 4y agoPoint taken, that was before my time. I can't imagine many of these being around any more though
- pjmlp 4y agoGo wins in performance against languages whose runtime was never about performance, and are usually interpreted, what a surprise.
- Mo3 4y agoGo's runtime was never specifically about performance either. The runtime scheduler main intentions were - Parallel execution / multiple threads. - Handling of blocking system call and network I/O. - Handling of blocking user level (on channel) calls. - Scalability.
- pjmlp 4y agoYou're still comparing apples to oranges, doesn't matter what Go's runtime goals were, when it is AOT compiled and the others aren't.
- Mo3 4y agoI'm not trying to argue with you about that point, of course its AOT compiled.
- pjmlp 4y agoWhich naturally makes it faster than Python or nodejs, what a wonder!
- Mo3 4y agoThat was not the point that I am trying to make. Of course it's faster. It's also much closer to Python or nodejs in its use-cases than C++, while still being faster. It's not meant as a replacement for other compiled languages, it is intended for backends.
- gsuphosdown 4y agoYeah Go is basically a scripting language. Most users are coming from Python, Ruby, etc. The original idea that people at Google would migrate to Go from C++ never happened. It’s used as a logs analysis tool that non-CS data scientists can write, with no fancy features at all, to prevent them from crashing batch dataflow pipelines that are running offline, seamlessly scale horizontally, and have no direct production impact if they miss deadlines. The application code for real time serving is all in C++ because Go is too slow and unpredictable at runtime, and the teams are staffed by people with strong software backgrounds. The whole “Go as a systems language” or “Go as a cloud services language” is kind of laughable. It’s like those Tik Toks that say No One: and then it’s Go fans claiming the language has a strong suit other than keeping people who haven’t passed CS 101 from crashing the batch job, productivity speed and control for concurrent real time services be damned.