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

471–480 of 511 posts

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

#471

Post by SomeCallMeTim »

gems wrote: post #324
SomeCallMeTim wrote: post #223

Earlier quoted context omitted.

>Any serious programmer should be a polyglot by default. My own experience is that there are PLENTY of programmers who have used, say, PHP and Python, but who you wouldn't want to touch your C codebase in a pair-programming session. If you've used C++ and C, then sure, you can probably jump to just about any language. Someone who's only used Python (or worse, Java or PHP) will likely be a danger to themselves and oth…

>My own experience is that there are PLENTY of programmers who have used, say, PHP and Python, but who you wouldn't want to touch your C codebase in a pair-programming session. There are plenty of programmers that wouldn't want to touch C to begin with, regardless of past experience. Anyway, why would you ask somebody with no experience in C to develop your C codebase? >If you've used C++ and C, then sure, you can pr…

>why would you ask somebody with no experience in C to develop your C codebase?

The message I replied to said:

>It's quite strange to me that people would identify as or look for a "[language] programmer".

So what I was saying was that you would want a C programmer to develop in a C codebase.

>There are plenty of programmers that wouldn't want to touch C to begin with, regardless of past experience.

I wouldn't want to do a lot of original development in C myself. I have used C -- and assembly language -- to do nontrivial things in the past. But I'm ready to be done with C myself.

>>If you've used C++ and C, then sure, you can probably jump to just about any language.

>Nope.

Umm...[citation needed].

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

#472

Post by ColinWright »

willvarfar wrote: post #470
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?

I can't see how it could mean anything else, but I find that, well, bizarre. Oh well, different point of view, I guess.

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

#473

Post by ssmoot »

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…

Scala fan here. But still, I can sympathize with Go developers on getting rid of exceptions.

I don't know if Go would quite feel the same, but Scala's Try, Pattern Matching and Curried functions are stupid nice and make handling errors without exceptions feel very natural.

Took me a couple months to get there, but there you go. "Folding" out different state feels like I'm writing more robust code. Where I'm coding for a range of possibilities instead of just the golden path.

Even when I _am_ focusing on the Golden Path, features like Try[A] force me (well, warn at least) to at-least stub out the other options so I get to feel like instead of having to hammer in robustness, it's something composed instead. I can focus on making the ideal X, and handle the possibility of needing a notX as alternative realities, instead of trying to build a cyborgXYZ that can handle every potential state. If that makes any sense.

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

#474

Post by smosher »

rektide wrote: post #462
smosher wrote: post #395

Earlier quoted context omitted.

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…

> but that implies a movement away from stock standard core [...] never [etc.]

I wouldn't have said anything if I didn't disagree very strongly with these sentiments (see below about growing your own CSP/etc, and later about Coro in particular.) But first, about Node: let's not look at Node (unless you really want to, but as long as you understand it has nothing to do with my comment.) Problems with JS are usually founded on people complaining they don't like callbacks (translation: "Go is better because I like it better"—in which case please dispense with the cognitive dissonance and just be honest and say as much♯) and are inapplicable to other most other languages regardless.

♯Edit: That's not necessarily directed specifically at you, but people often vilify every aspect of things they don't like. I'm not convinced that's what you're trying to say about JS.

I don't view concurrency as this mysterious thing, if you know CSP you can write it in any language, usually fairly naturally. In languages like JavaScript, Perl, Tcl, you can even make it look like it was already part of the language, tucking away calls to the scheduler so the user doesn't need to write them explicitly (heck, you can do that part in C... but... don't), like in Go (save for pure-computation loops, also just like in Go.) All Go really does over the general case is adding implicit calls to the scheduler (not nicely possible in some languages) and treats the scheduler as a second-class primitive feature.

To go on about a unified implementation reaches my ears much like an argument that you'd better use `for` loops and never `map`s (guess what you can't do in Go.)

I wasn't going to bring this up, but since you're familiar with Perl you will be less likely to assume limitations. The lib is Coro. People do use it, but it is controversial because of #dramaintheperlcommunity (#whatelseisnews.) I don't know how popular it is overall, but if popularity is an issue for you let me know because it's a stupid argument to get into and I don't want to have it without realizing it. People rarely pay attention to concurrency anyway, but it's been around forever.

It is not a parallel library, for which I am thankful. (It's not incompatible with parallelism, and importantly: it doesn't make Go's mistakes in that area.) It amounts to a scheduler, facilities for spawning coroutines, wrappers to make calling the scheduler implicit (eg. at IO points), do async IO and every single thing you would need to make Perl automatically do the things Go automatically does. It will look exactly like Perl with Go's concurrency model, in broad strokes you do the same things, in the fine details you use Perl modules and methods and a new keyword or two.

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

#475

Post by valyala »

donebizkit wrote: post #17

Last month I picked NodeJS and build couple of sites with it. This month, I want to pick up something new. I was hesitating between Python and Go. Can you answer couple of questions about Go from someone coming from NodeJS: 1- What is the state of the external Go libraries, especially DB (MySql), caching libraries (memcached), protocol libraries (Oauth). Are they stable 100% 2- How easy is logging and tracing in go?…

I'm the author of memcache client and server in go [1]. The client is much faster than bradfitz's client when serving hundreds of simultaneous workers - try comparing them with go-memcached-bench [2]. There is also memcache server [3] written in go, which can cache much more data comparing to the original memcached thanks to ybc library [4].

[1] memcache client and server library https://github.com/valyala/ybc/tree/master/libs/go/memcache [2] go-memcached-bench https://github.com/valyala/ybc/tree/master/apps/go/memcached... [3] go-memcached https://github.com/valyala/ybc/tree/master/apps/go/memcached [4] ybc library https://github.com/valyala/ybc

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

#476

Post by kragen »

trungonnews wrote: post #277
tptacek wrote: post #262

Earlier quoted context omitted.

Comments like this are weird. Go does not like exceptions. They've built a whole idiom around error returns. When you said, "I need exceptions", what did you expect them to say? "Oh, sorry, we forgot that, we'll get right on it"? I also don't understand what you mean by "interactive debugger". What is gdb if not an interactive debugger? Gdb is my go-to debugger for Ruby as well.

Something like RubyMine IDE debugger or Firebug javascript debugger. If you are a Ruby developer then I highly recommend trying out RubyMine. I promise that you will never debug Ruby code using gdb again!

I got all excited when I saw your comment and went and checked out the latest RubyMine video on YouTube, because having something like Firebug for Ruby would be awesome. But it looks just like what gdb gives you when being driven by a graphical frontend like DDD or Emacs. Actually it looks a lot less powerful than DDD. What am I missing?

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

#477

Post by kragen »

Shamharoth wrote: post #454
kragen wrote: post #452

Earlier quoted context omitted.

Ada gives you neither the performance of C nor the abstraction- and boilerplate-removing power of Lisp nor the provability of Agda. This is why it is not used.

The performance is pretty close, actually (far more than Go, for example) : http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... And yes, it is not used, only in some obscure and low profile projects : https://www.adacore.com/customers

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... might be a better link to show how Ada performance compares to C: ranging from twice as fast to three times as slow, with a median in favor of C. It's true that it's pretty close. I don't know if those numbers are representative of how performance works out in the real world; any insights from your experience?

Golang, it's true, is in the 3×–10× ballpark.

https://github.com/languages/Ada shows Ada as the #52 most popular language on GitHub. The #10 most popular is Objective-C at 3%. Using R:

    summary(lm(log(c(25, 13, 8,8,8, 7, 6, 4, 4, 3)) ~ log(1:10)))
I derive that the Nth most popular language on Github is used in 24% * N -0.81 of projects, with an R² of 0.93. This suggests that Ada should be in use on about 0.98% of projects on Github, which makes me wonder why https://github.com/languages/Ada/updated?page=10 can only find 200 Ada projects that have been updated in the last nine months. (JS, the #1 language, has 200 projects updated in the last 22 minutes.)

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

#478

Post by eru »

qznc wrote: post #287
eru wrote: post #222

Earlier quoted context omitted.

> I like how Lisp and Assembler at the top of the hierarchy capture the two extremes. Not really. I'd place Agda or Coq above Lisp.

That is somewhat orthogonal. Lisp is better at abstraction than Agda or Coq or Isabelle or any of those ML/Haskell theorem proofers. To maintain the theme: C if you are terrified about performance Lisp if you are terrified about boilerplate Agda if you are terrified about correctness If you are terrified about all of these, then welcome to the world of engineering.

If you wrote an S-Expression syntax on top of Agda (or Haskell), you gain all of Lisps anti-boilerplatitude for free. There's of course also Template Haskell.

As it is, the static typing helps to avoid some boilerplate, too, indepedent of macros. In some sense, static typing removes, among other things, boilerplate tests.

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

#479

Post by kragen »

kragen wrote: post #477
Shamharoth wrote: post #454

Earlier quoted context omitted.

The performance is pretty close, actually (far more than Go, for example) : http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... And yes, it is not used, only in some obscure and low profile projects : https://www.adacore.com/customers

http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te... might be a better link to show how Ada performance compares to C: ranging from twice as fast to three times as slow, with a median in favor of C. It's true that it's pretty close. I don't know if those numbers are representative of how performance works out in the real world; any insights from your experience? Golang, it's true, is in the 3×–10× ballpark…

That should be 24% × N ^ -0.81. The double asterisk I was using for exponentiation got eaten.

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

#480

Post by socceroos »

flyinRyan wrote: post #416
virmundi wrote: post #404

Earlier quoted context omitted.

I've moved away from ORMs in Java because they don't really solve the problem faced. Hibernate could be a really good solution to providing a blanket system for SQL interaction except for the performance issues. If one was really using Domain objects (not pojos, or dumb DTOs) the typing ability of Hibernate would be great. Unfortunately for simple CRUD apps the issues presented by Hibernate (like loading it in an EAR…

Well, I can't speak to Java here but NHibernate works fantastic. I've checked the generated SQL on complex joins and it always ended up writing what I would have by hand. In C# the session management is no big deal: you access everything via the Repository pattern, turn on trait injection and just make sure any repository method that will need a session has a transaction attribute. If you need to do a series of read/…

That's a helluvu lot of abstraction for writing to a database.
Post reply on HN