Hacker News Reader

Comment by papito | Hacker News Reader

"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.

View on HN

Recent-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++.

Did 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.

> 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.

Management 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?

Heh, 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.

I have a bit of a different take on this.

They mentioned it was a rewrite that happened in a couple of days in a shop that uses C++ and Python (at least). We can assume it was a small to medium utility program.

Someone who can write C++ and Python professionally will get up to speed with Go in a few days. This shouldn't be a hiring issue. The cost of rewriting it again in C++ can easily be higher and apparently was a huge PITA. Go is not some obscure language, it is literally designed to be accessible by anyone with basic programming experience.

As a programmer I agree, but as management that's a hard thing to tell. If you were the boss would you allow Lisp? Scheme? Erlang? It sounded like a pretty important piece of code, even if small. The complaints about being forced to do C++ and how painful that process was shows that it's at least non-trivial.

I disagree. If you're managing programmers, you might be expected to have a bit of a clue about programming languages. If you can't tell how easy it would be for your people to pick up Go versus how easy it would be to pick up Lisp, you have no business managing programmers.

Well you can still manage programmers but you certainly shouldn't micromanage their technological choices then.

You can argue about whether enforcing language consistency across an organization is a good idea or not, but it isn't "micromanagement".

The 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.

I prefer Go when I want more safety/performance than Python but less ceremony than Rust.

I think the latter point about "less ceremony" is extremely debatable especially on a larger project.

How does Go have more ceremony than Rust without a borrow checker, lifetime annotations and all?

This is why languages like Go offer automatic dynamic memory management, or more simply, garbage collection.

https://medium.com/safetycultureengineering/an-overview-of-m...

I think the point is not that Rust has less ceremony (it certainly has more), but that you want the “ceremony” for larger scale projects.

related, 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)

Fair enough, there are certainly cases where Go is an awesome tool to use.

Doesn'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

I’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.

Reason 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.

Go 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.

> 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.

The "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".

> 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?

I 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.

Very 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.

Heh, flavor of the month ... for a 12 year old language.

Reply on news.ycombinator.com