I would be more worried about the costs of licensing as a startup. What kind of sprawl will your architecture have? Do you have to pay for SQL server? Acquisition is sooo far ahead of where you are.

awesome, ok, then you try to go reconstruct a vtable and want to kill yourself

OP here. Hah! I was totally planning to follow up with a vtable example soon. :)

vtables for shit with inherited classes and interfaces \o/ sometimes I love reverse engineering. Keeps your mind active ;)

so... you want customizable metrics/views for your github page?

how far til this becomes `myspace for code`?

the gotos actually make sense in this case. unless you'd prefer some insane tree of if/else?

I agree, I was thinking about what this situation would look like in other langs and when I turned to Go, I realized:

While Go has goto for tricky situations like this, because it has defer you don't have to use it often, assuming the free calls were needed (and the vars were not going to be GC'd):

    defer SSLFreeBuffer(&hashCtx)
    defer SSLFreeBuffer(&signedHashes)
    if err = SSLHashSHA1.update(&hashCtx, &serverRandom); err != nil {
      return err;
    } else if err = SSLHashSHA1.update(&hashCtx, &signedParams); err != nil {
      return err;
    } else if err = SSLHashSHA1.final(&hashCtx, &hashOut); err != nil {
      return err;
    }
    return nil;
  }

I would probably flag the code above in a security review because it hides the key part at the end of a complex line. Unless you're coding on VT100 terminal it's worth the extra line to make the test logic incredibly obvious:

err = SSLHashSHA1.update(&hashCtx, &serverRandom); if (err != nil) { return err; }

In actual code things would not be named as they were above and it would be shorter, I was just trying to make it look reasonably like the C for HN.

True, but I've definitely noticed that particular style of writing if tests using a one-line assignment and obscured test condition seems to be pretty common in the Go community and it's a bad habit for understanding code.

>>it's a bad habit for understanding code.

Is there objective evidence for this? As a Go programmer a semicolon in an if statement screams to me. I can see it possibly being in issue for new Go programmers- but I don't remember it being one for me.

I didn't do a survey but I remember that and frequently punting on error handling (`res, _ = something_which_could_error()`) showing up enough in the projects I saw on Github to stand out as a trend when I was writing a few first programs. I certainly hope that's just sampling error.

The `else if` is useless here, since you return anyway. It only adds noise.

I rarely use the one-line `if err := ...; err !=nil ` idiom because its quite a mouthful. However when I do, I try to make sure it's not too much to grasp at once. Here the extra `else` goes against that.

Alright, I know this is just a quick snippet on HN and all, I just thought I'd mention it anyways. Maybe next time you actually write that in code you'll think about my point. ;)

Couldn't you just set a 'failed' boolean and wrap the fail: statements in a conditional check on it? Not that I'm saying all uses of goto, particularly this one, are necessarily absolute evil.

No need for that. Just return early. Plus one should split up this gigantic function into several smaller ones.

not true if they are taking on money. any investor will require a vesting period over 4 yr w/ usually a 1 yr cliff (which resets every time you take money)

It's missing some key features (Generics anyone?) that put it somewhere in terms of usability between C and Java, and it has nowhere near the same tooling or performance characteristics as the JVM. So, it has a while to go yet I think but would love to see a serious JVM competitor here.

Once you write a decent amount of Go code, you won't miss generics.

In terms of ecosystem and performance only .NET.

I would be interested in the stats of 'successful' startup investments (for YC and otherwise), how many of those technical founders actually started programming at age ~13 (vs 17 or 18).

Would also be interested in seeing what the relative success/failures of investments with startup founders at 23 w/ 10 years experience (started programming in teams), vs 28 (who started programming at 18).

+1. If you want threads, build a node c++ addon that manages your threads/high performance work (and try not to pass too much back and forth with your Javascript, because of the performance overhead of marshaling described above). Which means you are just writing a lot of C++, and your javascript simply becomes a convenient interface to start/stop the processing and script actions on values emitted from your c++ addon.

Or, like everyone else recommends: use processes and ipc (e.g., the cluster module).

Note that on Linux, the performance difference between processes and threads is an awful lot smaller than it was when threads first came into the world. This is another case where someone invented a better idea for performance reasons, and the people in charge of the old idea (processes) realized that they could do a lot better. So they did. And nowadays few people have a real need to squeeze every bit of performance out of a server. For most of us it is a question of buying one or two more servers. Only the Googles of the world really need to deal with this kind of performance tweaking, and if you look at what they are doing, it does not include Javascript.

Crashes (that can be reliably reproduced) should be way easier to debug than memory leaks.

a) build a `debug` version of node (building node from source creates a node_g version which is a debug version)

b) build a `debug` version of all of the c++ addons in your node_modules folder (node-gyp build -d for each addon)

c) start gdb with the debug version of node: `gdb ./node_g`

d) in gdb, run your node script using `run <script.js>` -- add any other options

e) wait for it to crash, and then type `bt` - you'll see the location of the crash which should give you a good starting place.

Yeah I got this far, but the stack trace doesn't have the symbols. The guy I'm working with said it might be because the addons use dynamically linked libraries instead of statically linked libraries...

By the way, I think a jenandre used to work at my company.

What library is missing the symbols? You may be able to tell by the stack trace. You should get symbols for something at least before it's lost. Examine that frame to see what it's doing. Linking some non-debug library w/ a debug executable just means that gdb won't display the symbols when it enters code for that library. But if your addons are built with -g you'll get the symbols for the addon before it starts calling the other library it is using.

Btw, people often write javascript wrappers that manually refer to the build/Release/.node version instead of the debug version (which will get added to build/Debug/.node). Check that first.

Even if you are using dynamically linked libraries (like the zmq addon does), you can always build debug versions of those to get all of the symbols (try CFLAGS=-g when ./configure).

We never make it to symbol-land in the bt, so I'm assuming it's because we never get into a debug library at all. I will make sure the js is referring to the correct version of the addon though.

My next step is probably going to be to try and figure out how to get every library to build with symbols. Thanks for the help. :D

I don't know, plenty of cities are flat.. NYC is mostly flat?

Biking in .nl was actually quite arduous for me the few times I've been. One word: wind. No mountains or anything to break it, it's like being on an endless hill. I did a few short out of town trips (<15km) and I highly underestimated how long it would take because of the wind...