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

How We Went from 30 Servers to 2: Go

blog.iron.io

Post reply on HN
Print view View original

461–470 of 511 posts

Re: How We Went from 30 Servers to 2: Go

#461

Post by swah »

pjmlp wrote: post #311
trungonnews wrote: post #244

I was originally very excited about Go when I first learned about it. But then I got tired and frustrated quickly after having to listen to the other Gophers telling me that I don't need this or that feature because there is a better way to do it in Go. Like. I don't need exceptions because Go function can return multiple values. I don't need a mocking framework like Mockito because Go has interfaces. I don't need an…

Same thing happen to me, I even did some small contributions around 2010. Then I discovered D and Rust are better languages for my purposes.

D syntax is nicer than Go's, but its also dead compared to Go. Where are you going to put your chips?

Re: How We Went from 30 Servers to 2: Go

#462

Post by rektide »

smosher wrote: post #395
rektide wrote: post #112

Earlier quoted context omitted.

I'm very sympathetic to your tech-on-tech-on-tech-on-tech hogwashery promulgated by open sourcers & vendors prosteltyzing their wonderful solutions and the other acculturation factors that permits developers approaches other than trying & seeing & exploring- That said, you are wrong. I'm not a Go user and I don't care for it, but Go is fundamentally different and better than most runtimes. Go has it's own green threa…

Go is... fundamentally different than most runtimes? Probably. Better? Maybe. Better than the comparable ones? I think it's losing that war. You don't even need a special runtime, it can help, but I think the amount it helps is overstated in Go's case. Concurrency isn't that hard in practice. If you're willing to forgo automatic multiplexing Perl will give you Go's concurrency model in a library written ten years ago…

Go's standard lib is built around it's communications and concurrency primitives. Sure one can extend other languages with new capabilities to take them into Go's realm, but that implies a movement away from stock standard core, whereas Go users, at their core, share a common massively concurrent message passing beast of a runtime and a concurrency friendly standard library that they are all unified behind. One will never mobilize behind a concurrent library in the kind of ways doing it up front will accomplish. Go has a large community of practitioners all writing massively concurrent code. That is huge and has never been done before.

But let's go look at patterning: look at Node: everything is hinged around re-using Node's core patterns, callbacks and every now and then slower events. There is promises work abound, but it's not used heavily: indeed it'd be hard to, with intermodule work, because A) it's not the standard lib B) nor are promises standardized. People seem to prefer something I loath- the horrible Async library- which gives them a bunch of composition tools to make worse the awful awful crime that is callbacks: because callbacks are what Node is, people pick up tools to do it more, to a further extreme, rather than going to the foundation & reshaping the landscape. (PS: Callbacks are A) awful B) actually & entirely the right decision.)

I was reasonably seriously into Perl, but I don't know what perl CSP style library you seem to be alluding to that A) you seem to indicate people used & B) got on par with Go 10 years ago. But I'm interested to hear of it! <3 me some CSP.

Re: How We Went from 30 Servers to 2: Go

#463

Post by codygman »

rmoriz wrote: post #418
codygman wrote: post #310

Earlier quoted context omitted.

What makes you say it doesn't have a testing culture? I think you're just trying to justify not using Go and sticking to your choice. I haven't came across any Go libraries without tests.

* as far as I can see very few go projects use CI (e.g. travis) * gospec seems to be dead/not widely used * I don't see projects measuring their code coverage * As pointed out in my first comment, I couldn't find high level testing tools and none of the repliers could name one, too. If you don't have tests to measure function and performance, any new technology is just playing another round of Roulette and/or "bike-s…

Agreed, but something you also have to worry about is your stack becoming unmaintainable. Sometimes it's worth re-engineering your stack. For instance, even the simplest programs have a "time until too complex to safely be maintained".

I suppose you have to make that time far enough away that it won't affect your business. If you go past it, your good developers will leave and you'll likely only get lower class devleopers who have to take the job.

As a result your entire stack will suffer. The business side is important, but the entire engineering side can die if you neglect it too much.

Complexity must be managed.

That said, you are correct about:

* Few projects use CI. I think this is due to the fact that most of the libraries being developed are done by very small teams that see it as too much overhead.

* Same with code coverage.

* Most find the testing that Go uses for the language itself to be more than enough.

I think that Go has a much different attitude towards development than you are used to.

I can't quite quantify why and I could be wrong, but I suspect not all of the testing methodologies you talk about are necessary.

Would be great for someone else also experienced with Go and experience with the type of testing environments rmoriz describes to chime in!

Re: How We Went from 30 Servers to 2: Go

#464

Post by gregors »

rmoriz wrote: post #418
codygman wrote: post #310

Earlier quoted context omitted.

What makes you say it doesn't have a testing culture? I think you're just trying to justify not using Go and sticking to your choice. I haven't came across any Go libraries without tests.

* as far as I can see very few go projects use CI (e.g. travis) * gospec seems to be dead/not widely used * I don't see projects measuring their code coverage * As pointed out in my first comment, I couldn't find high level testing tools and none of the repliers could name one, too. If you don't have tests to measure function and performance, any new technology is just playing another round of Roulette and/or "bike-s…

Hmm I see a lot of opportunity

Re: How We Went from 30 Servers to 2: Go

#465

Post by gregors »

burntsushi wrote: post #93
rmoriz wrote: post #62

How about BDD, test-driven development and quality insurance? Does Go provide an ecosystem that supports agile refactorings that are common in lean startups? You can say anything bad about the performance of Ruby and Rails etc. but rspec, cucumber, capybara, vcr, factorygirl are really important features to start from zero and reach a viable product.

> test-driven development `go test`. > Does Go provide an ecosystem that supports agile refactorings that are common in lean startups? Go has a compiler and is staticly and strongly typed. Which automatically makes it at least an order of magnitude easier to refactor safely. Not really sure about the other stuff you mentioned. I've never even heard of BDD before.

I've heard this argument before e.g. we don't need to test because the compiler catches errors. The compiler catches the mot trivial of error conditions. Unfortunately it doesn't address faulty logic/behavior.

Re: How We Went from 30 Servers to 2: Go

#466

Post by pjmlp »

swah wrote: post #461
pjmlp wrote: post #311

Earlier quoted context omitted.

Same thing happen to me, I even did some small contributions around 2010. Then I discovered D and Rust are better languages for my purposes.

D syntax is nicer than Go's, but its also dead compared to Go. Where are you going to put your chips?

> D syntax is nicer than Go's, but its also dead compared to Go.

Because it is full of Google PR and happens to have some cool names on the team?

> Where are you going to put your chips?

In languages that the designers don't throw away the last decades of improvements in language design.

Re: How We Went from 30 Servers to 2: Go

#467

Post by steveklabnik »

Symmetry wrote: post #424
azakai wrote: post #77

Earlier quoted context omitted.

Rust and Go are not similar or competing. They are both new, but aside from that the differences are huge. So if a project uses one, that doesn't mean the other was a possibility for that project too.

The way I would put it is that Go was designed to incorporate some of the simplicity and speed of C as well as the ease of use of Python, while Rust was designed to combine the speed and flexibility of C++ with the safety of Haskell.

... and the concurrency of Erlang. (and OCaml might be more apt than Haskell).

Re: How We Went from 30 Servers to 2: Go

#468

Post by jamesaguilar »

rektide wrote: post #112
zobzu wrote: post #41

It's not really "go" that makes the difference. it's how the runtimes and frameworks are used and/or made. frameworks on top of frameworks, all being over engineered, with poor understanding of what the system actually does, result in super slow apps on top, that you generally go to aws to scale. It's not the first time that I see people reducing a dozen servers that were "always maxed out" by a couple of servers "th…

I'm very sympathetic to your tech-on-tech-on-tech-on-tech hogwashery promulgated by open sourcers & vendors prosteltyzing their wonderful solutions and the other acculturation factors that permits developers approaches other than trying & seeing & exploring- That said, you are wrong. I'm not a Go user and I don't care for it, but Go is fundamentally different and better than most runtimes. Go has it's own green threa…

They went from a language with a factor of forty cost compared to C++ to one with a factor of four cost. They saw a factor of ten improvement in CPU utilization. Seems like all Go really brought to the table here was speed. I don't see any evidence that its unusual features were a factor, besides its base-level increased efficiency.

Re: How We Went from 30 Servers to 2: Go

#470

Post by willvarfar »

ColinWright wrote: post #469

I know I'm late to the party, and no one will read this, but ... "... Java derivatives like Scala and Clojure ..." Someone help me out here: In what way is Clojure a Javav derivative?

Perhaps in the sense that they are languages that target the JVM and that rely on interoperability with the Java standard library to bootstrap people making apps with them?
Post reply on HN