7 ms·
"Developer productivity and not getting too creative" is NOT a point in favor of Go. Go does not have a lot of batteries included. Things like error handling, l
by papito 4y ago
"Developer productivity and not getting too creative" is NOT a point in favor of Go. Go does not have a lot of batteries included. Things like error handling, logging, test bootstrapping, etc, require consensus on the team and tight coordination. Every project is basically its own framework. Most teams are not that well-oiled.
They are going to find this out the hard way.
And fast? Please. If your database queries are a mess, or if you have no discipline elsewhere, it doesn't matter what language you use - you will blow right past the "superfast" baseline.
- rat9988 4y agoReason 2 – Language Performance Matters For many applications, the programming language is simply the glue between the app and the database. The performance of the language itself usually doesn’t matter much. Stream, however, is an API provider powering a feeds and chat platform for 700 companies and more than 500 million end users. We’ve been optimizing Cassandra, PostgreSQL, Redis, etc. for years, but eventually, you reach the limits of the language you’re using. Python is a great language but its performance is pretty sluggish for use cases such as serialization/deserialization, ranking and aggregation. We frequently ran into performance issues where Cassandra would take 1ms to retrieve the data and Python would spend the next 10ms turning it into objects.
- steve_adams_86 4y agoThe last time I was on a team using Go, we ended up ditching it for these reasons. We realized it took about as much specialization and wheel reinventing as Rust, which offered way better developer ergonomics in ways that mattered to us and wouldn’t panic over things that weren’t easy to predict or caught by the compiler. There were still tons of trade offs, but it worked well for us. Go is cool but I still can’t seem to figure out where and when I’d prefer it most of all… Especially the poor error handling and lack of safety. These things really drive me crazy.
- uh_uh 4y agoI prefer Go when I want more safety/performance than Python but less ceremony than Rust.
- stayfrosty420 4y agoI think the latter point about "less ceremony" is extremely debatable especially on a larger project.
- uh_uh 4y agoHow does Go have more ceremony than Rust without a borrow checker, lifetime annotations and all?
- SideburnsOfDoom 4y agorelated, how does having no unit tests have more ceremony than a full test suite? (and yet it will do so, as you try to find other ways to make your code safe to release)
- adolph 4y agoThis is why languages like Go offer automatic dynamic memory management, or more simply, garbage collection. https://medium.com/safetycultureengineering/an-overview-of-memory-management-in-go-9a72ec7c76a8 https://medium.com/safetycultureengineering/an-overview-of-m...
- mynegation 4y agoI think the point is not that Rust has less ceremony (it certainly has more), but that you want the “ceremony” for larger scale projects.
- steve_adams_86 4y agoFair enough, there are certainly cases where Go is an awesome tool to use.
- bbkane 4y agoDoesn't Rust also have competing nonstandard ways to handle errors? Right now I think they recommend 3rd party libraries for it (anyhow, one other I don't remember), and those library recommendations have changed over time
- steve_adams_86 4y agoI’ve been content with the error handling the language offers, but maybe there are scenarios where it isn’t sufficient that I haven’t encountered.
- s17n 4y agoGo provides error handling and logging. It's true that if what you're writing is an application server consisting of business logic and glue code that delegates all the "heavy lifting", performance won't be the first concern. However, even in this case, I think you'll find its easier to get sub-second response times in Go than in a language like Python.
- stayfrosty420 4y agoVery surprised this is getting downvoted, I think in two years from now everyone will be singing this exact song when the next flavour of the month arrives.
- sliken 4y agoHeh, flavor of the month ... for a 12 year old language.
- kabdib 4y agoRecent-ish experience: - Wrote a distributed app in Python (it aggregated a few GB / day of info from several thousand servers). Performance was terrible, though I was doing all the right things (async I/O, etc.). - Rewrote it in Go. That worked really well, and took just a few days. But management freaked out, forbade Go in engineering, and so: - Spent several months rewriting the whole thing in C++. What a fucking misery. Just getting HTTPS working was a depressing experience. Package manager? No, you get to trawl the internet for semi-busted projects that sorta kinda maybe work, and then bend them to fit. Go is the sweet spot between "Python isn't fast enough and never will be" and having to reinvent the wheel in C++.
- huac 4y agoDid you have prior Go experience to the rewrite? My experiences line up with this quite closely, similar tasks are much better suited to Go, concurrency management is night and day vs Python. But Go can seem scary to folks without previous experience and that turns lots of folks off - even though the language and syntax don't feel _that_ different and there is a similar batteries included approach, though Go's batteries are generally better.
- dgb23 4y ago> But management freaked out, forbade Go in engineering It pains me to read this, especially since Go seems to be a language that is extremely easy to adopt.
- AnimalMuppet 4y agoManagement forbade the use of Go? But they allow both Python and C++? So their rationale for forbidding Go is... what? Is this just cluelessness and management by familiarity with buzzwords?
- sliken 4y agoHeh, imagine you have 8 C++ programmers, then one rewrites some critical piece in Go ... and then leaves. Now you have to find a go programmer (from a much smaller pool). How do you find a good one? It's not going to be easy without some good Go developers on the interview panel. Say you hire one, he goes on vacation for 2 weeks, something important breaks and you need a 2nd go programmer, etc.
- tgv 4y ago> If your database queries are a mess This is a "wut?" moment for me. Why add this external factor, when it's totally irrelevant and the article doesn't even mention it?
- KhalPanda 4y agoI wouldn't say totally irrelevant. I've worked on many line-of-business applications and websites where the database is the bottleneck. People love to obsess over "what language?", happily ignoring the fact database access is 90% of the request time.
- corrral 4y ago> If your database queries are a mess, This has been the cause of basically all of the slowness in Rails projects I've worked on, at least. I've seen queries taking tens of thousands of times longer than they should. I don't think I've ever seen a Rails codebase that didn't have speed problems, but every single time it's been because DB access is being done very inefficiently. I've yet to see one actually bound by the computational speed of Ruby (I'm sure it happens, though) and it's considered way on the slow end of popular languages. The problem's always 1) Doing shit in Ruby that the DB can do a thousand times faster (joins[!], calculating things based on a huge number of rows, mashing together pieces of data, et c.) with a better query, or 2) firing tons of identical-but-for-some-values queries in a loop(!?) [EDIT] Actually, just as I hit post, it occurred to me that 2 is really just a flavor of 1.
- papito 4y agoThe "query in a loop" thing happens a lot. This is the danger of hiding databases behind magical frameworks and ORMs. Some developers don't understand the basic idea that a single database query with execution time and the network roundtrip can destroy your app performance. They literally treat all ORM code as "free".