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

421–430 of 511 posts

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

#421

Post by argv_empty »

kyllo wrote: post #236
chadcf wrote: post #224

Earlier quoted context omitted.

Me too (well, ok, my first programming class was in Fortran taught by a 85 year old man who spent most of the time telling us about how much harder it was back when you had to use fortran). I hated C++. I still think it's a fairly terrible language. But, for fun I took the Harvard CS50 course to refresh my knowledge of C and I found that WAY better than my C++ course. I think C is brilliant for introducing programmin…

C++ is terrifying, and teaching an introductory programming course in C++ is an awful idea. Using plain C would make much more sense. C is also a better choice than Java because Java doesn't force you to learn about pointers, or memory in general, really. Countless Java bugs are introduced by programmers who don't understand what operations give you a copy of something, and which ones give you a reference to somethin…

Java doesn't force you to learn about pointers, or memory in general, really.

Countless Java bugs are introduced by programmers who don't understand what operations give you a copy of something, and which ones give you a reference to something

These two statements seem to be at odds with each other.

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

#422

Post by paddyforan »

drivebyacct2 wrote: post #216
jlgreco wrote: post #212

Earlier quoted context omitted.

I think there is honestly something wrong with that guy in a mild "losethos" sort of way. He started spamming me trollish nonsense in PMs because I dared utter a single line while he was active. Something about golang just seems to attract a certain flavor of nutters.

He stalked me too. Mocked my parents, my sexuality (lolironic), my job, etc. Classy fella.

I'm starting to feel so left out. Why do crazy Go-haters never harass me? Am I not good enough?

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

#423

Post by tiwazz »

rosser wrote: post #114
edwinnathaniel wrote: post #91

Earlier quoted context omitted.

I've seen C/C++ programmers failed in writing good readable code. C/C++ programmers tend to do premature optimization (habit) due to the culture and the problem domain (past experience): device driver, kernel code, game development. How important Pointer is for say learning any high-level programming language that don't have pointers (pretty much everything outside C/C++/Objective-C)? Sometimes I felt that knowing Po…

https://en.wikipedia.org/wiki/Hasty_generalization

I feel like this article on generalization could be a biography of my life based solely on the introductory paragraph, but I don't have enough time to finish reading it to be certain.

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

#424

Post by Symmetry »

azakai wrote: post #77
DASD wrote: post #71

Earlier quoted context omitted.

Do you have a citation for Mozilla using Go? I would be a bit surprised given their(Mozilla) development of Rust.

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.

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

#425

Post by pnathan »

nkohari wrote: post #158
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…

> 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- Are you studying for the SATs, or just trying to make your argument sound more compelling through the use of unnecessarily complex words?

On a forum like HN, where the audience spends a great deal of time reading and engaging in self-improvement, choosing words that are not simplistic should be fine.

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

#426

Post by tjgq »

ralph wrote: post #415
tjgq wrote: post #397

Earlier quoted context omitted.

Okay, I think I get it now. The check you refer to is done inside the BINARY_ADD implementation. That's why the bytecode is the same for both cases. Am I right?

Yes, as you say, it's not known at compile-time and is checked at interpretation time, each time. http://hg.python.org/cpython/file/b49971a1e70d/Python/ceval....

Thanks. And wow, the CPython source code seems to be very much readable. I've been meaning to dive further into Python internals for a while, maybe this is the time to do so.

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

#427

Post by pnathan »

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…

You could have linked to Occam[1,2]...

[1] http://pop-users.org/occam-pi/

[2] https://en.wikipedia.org/wiki/Occam_%28programming_language%...

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

#428

Post by Symmetry »

microtonal wrote: post #401
Ziomislaw wrote: post #373

Earlier quoted context omitted.

> I am interested how Go gave you one or two orders of magnitude speedup, while rewriting hot spots in C didn't... paralellization

One can easily do that in C with OpenMP.

If you can get away with only parallelizing the C code that'll work, but if you're replacing individual Python functions calls it won't so much. You could use a lot of Python processes, but that might be awkward depending on how much they need to coordinate and might lead to too much memory usage.

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

#429

Post by lifeisstillgood »

philh wrote: post #403
lifeisstillgood wrote: post #366

Earlier quoted context omitted.

I think there is a fine line between using a library and writin your own to understand better the domain It's something to do with how critical the library functions are to you / your system. I would never write my own compression software, but I can see why people would just to learn about the trade offs.

Okay, but if I had known about the alternatives I would have used them, so I'm not sure how that's relevant.

philosophising really. I guess on the "actually helpful advice" level, I'm all out if the googles cant help.

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

#430

Post by rdtsc »

masklinn wrote: post #321
rdtsc wrote: post #213

Earlier quoted context omitted.

> irrelevant in Erlang world Exactly. That is a subtle distinction but for cases where responsiveness and low latency is important that is key. Another thing Erlang has is isolation of process heaps. If one process crashes, it won't affect others. No shared data structures between processes. It all goes to fault tolerance but also a major win for a completely concurrent garbage collection.

> If one process crashes, it won't affect others. Unless they're linking or monitoring one another, an other important property of tolerant and distributed system.

But that is on purpose. Sometimes you do want that. In other words they are explicitly set up to monitor/link each other.
Post reply on HN