Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

New case studies about Google’s use of Go

opensource.googleblog.com

Post reply on HN
Print view View original

131–140 of 269 posts

Re: New case studies about Google’s use of Go

#131

Post by nedsma »

rizpanjwani wrote: post #111
nedsma wrote: post #94

Go is super productive. My day-to-day responsibilities include development in .NET and Go. A full day working in Go is like a having a pleasant day off. On the other hand, .NET is so cumbersome, complex and verbose (I've been using it since its inception), that I'd rather abandon it for good if possible.

What kind of development do you do if you don't mind me asking?

Of course not. Nowadays it's pretty much about implementing HTTP REST APIs and consuming APIs (HTTP, SOAP, gRPC). We have both monoliths and micro services in production.

Re: New case studies about Google’s use of Go

#132

Post by smt88 »

bengalister wrote: post #105
piazz wrote: post #84

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to res…

I still find the Typescript compilation time to be annoying. I rediscovered using Typescript for backend development on NodeJs and was very unpleasantly surprised by the compilation time (my only complaint). For a project with 20-30 files and around 8 dependencies, it took 10-20 seconds to compile and 4Gb of RAM (yes I checked with tsc --listFiles that no other files were parsed). The same in Go to compile to native…

> or a project with 20-30 files and around 8 dependencies, it took 10-20 seconds to compile

Something is very wrong here. If you use `tsc -w`, you should get incremental compilation. Small changes should compile almost instantly.

For me, even without using `-w` on pretty large projects, my compile time is never more than 5s.

I have to wonder if you have bottlenecks elsewhere.

Regardless, TypeScript's type system is much, much more expressive than Go's, so compile time will theoretically be slower. For me, it's worth it because compile time is an inexpensive way to save lots of maintenance time in the future.

(Note that I would never use TypeScript and Go for the same type of project, but that's my mindset in theory.)

Re: New case studies about Google’s use of Go

#133

Post by throwaway894345 »

candiddevmike wrote: post #123
mabbo wrote: post #75

While I do trust Rob Pike to not let personal biases sway his writing, I do have to wonder if the case studies weren't selecting because they were positive. So I'm curious: does anyone have a case study where using Go was a disaster? Every language has things it's good at, and things it's bad at. Where does Go not do well?

Anything that has to do with UI in my opinion. Go's lack of classes (factories, inheritance, etc) and verbosity make graphical layouts very, very tedious.

I think this is only true for OOP-style "widget-based" UI toolkits. I've had a very good time writing console UIs using a reactive style; obviously console UIs are simpler, but I think when people want inheritance in UIs, it's for things like 2D layout (in typical OOP toolkits, every widget type is derived from some base Widget class that does layout things) which are also present in console UIs.

I would be interested to hear rebuttals or other thoughts.

Re: New case studies about Google’s use of Go

#134

Post by nvarsj »

yandrypozo wrote: post #110
piazz wrote: post #84

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to res…

the key is simplicity, you're complaining about language features that allow you to write "fun" code, but remember that we spend around 80% of the time reading or debugging code, the main focus of Go is about writing code that's easy to read which will allow you to scale a project or source code with more people, also remember that easy doesn't mean simple, I think these 2 talks will make you understand my idea a lit…

I love go but the OP is completely right. Lack of basic collection functions is incredibly aggravating and slows down productivity substantially. At least it's not as bad as Java.

Re: New case studies about Google’s use of Go

#135

Post by qaq »

bengalister wrote: post #105
piazz wrote: post #84

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to res…

I still find the Typescript compilation time to be annoying. I rediscovered using Typescript for backend development on NodeJs and was very unpleasantly surprised by the compilation time (my only complaint). For a project with 20-30 files and around 8 dependencies, it took 10-20 seconds to compile and 4Gb of RAM (yes I checked with tsc --listFiles that no other files were parsed). The same in Go to compile to native…

TypeScript has way more advanced type system so there is a price you pay for that.

Re: New case studies about Google’s use of Go

#136

Post by c-cube »

mjevans wrote: post #103
piazz wrote: post #84

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to res…

The use of an Interface type in Go is a good sign that either the data or the logic flow isn't optimized for static analysis and optimizations. The most common case I happen to have run across is the result of parsing data or configuration files; situations where there might be structure, but all of it is optional. PS: Your "algebraic data types / sum types" sounds very much like interface composition, a ReaderWriter…

This is a product, not a sum. It's just a pair of Reader and Writer. Sum types would also give you the ability to say "reader or writer" and use pattern matching to find out which one you were given.

C-like languages traditionally give only the 'product' half of types (C also gives union but they're super low level, and Go just eschewed them). A _modern_ language would give both products and sums.

Re: New case studies about Google’s use of Go

#137

Post by cmrdporcupine »

mabbo wrote: post #75

While I do trust Rob Pike to not let personal biases sway his writing, I do have to wonder if the case studies weren't selecting because they were positive. So I'm curious: does anyone have a case study where using Go was a disaster? Every language has things it's good at, and things it's bad at. Where does Go not do well?

Let me just say that I've been at Google for almost 9 years, and have recently started looking for work elsewhere and it seems that Go is far more popular outside of Google than inside it. Which disappoints me because my experiences with the language internally have biased me such that I have no desire to go use it elsewhere.

I've said this before, but I think it's a bit dishonest to sell this as a "Google language." It is an accepted language here, along with Python, Java, JS/TS, Dart, and C++. But it is by no means dominant.

To put it another way, it seems if the goal is to avoid working in Go I am better off staying @ Google than leaving. And that's weird, and maybe revealing.

Re: New case studies about Google’s use of Go

#138

Post by kyrra »

zerr wrote: post #92
mabbo wrote: post #75

While I do trust Rob Pike to not let personal biases sway his writing, I do have to wonder if the case studies weren't selecting because they were positive. So I'm curious: does anyone have a case study where using Go was a disaster? Every language has things it's good at, and things it's bad at. Where does Go not do well?

Go is officially banned by Google for Fuchsia: https://fuchsia.dev/fuchsia-src/contribute/governance/policy...

There was discussion about this 6 months ago, such as this comment.

https://news.ycombinator.com/item?id=22412475

Re: New case studies about Google’s use of Go

#139

Post by Xavdidtheshadow »

bengalister wrote: post #105
piazz wrote: post #84

I played around with Go a while ago, and while I appreciated the approach to concurrency, I was really put off by both the boilerplate + how primitive the type system felt. Not having map and filter due to lack of generics meant writing for loops all over the place just to filter and modify arrays. Appending elements to slices felt clumsy. The type system didn't feel expressive, and I often found myself having to res…

I still find the Typescript compilation time to be annoying. I rediscovered using Typescript for backend development on NodeJs and was very unpleasantly surprised by the compilation time (my only complaint). For a project with 20-30 files and around 8 dependencies, it took 10-20 seconds to compile and 4Gb of RAM (yes I checked with tsc --listFiles that no other files were parsed). The same in Go to compile to native…

That's a fair complaint, but I find that during development, I use `tsc --watch`, which makes incremental compilation very fast.

Of course, that doesn't affect the slow production build time, but I care a lot less about that (since it usually happens off in CI land somewhere and I'm not sitting waiting for it to happen.

So ultimately, this is a non-issue for me.

Re: New case studies about Google’s use of Go

#140

Post by Spivak »

geodel wrote: post #117
naikrovek wrote: post #102

Earlier quoted context omitted.

This is a puzzling decision on Discord's part, because they found the single line of code causing their problem and they didn't think to change that line of code for their own needs. Go distributions include the source for Go itself, so building your own Go binary with your own changes incorporated is dead easy. And, the change they needed is a single-line change, which means it's easy to bring that change forward as…

Besides all you said, Discord client is electron based bloated software. So it just seems a case when some engineers itching to write Rust and decided to make virtue out of it.

But they’re specifically talking about a server component here. Using Electron on the client doesn’t magically make their need for a high performance backend disappear. They’re still having to make all those clients work and deliver voice chat to millions of simultaneous users.
Post reply on HN