tophercyll

You can make user level systemd instances run at startup and stick around regardless of login/logout.

  loginctl enable-linger <username>

Not a brag--just wanted emphasize how straightforward and fun something like this can be.

It would probably be worth it to temporarily define one of the reserved opcodes as putchar.

Sure.

I aim to have our interview cycle take under a week, although in honesty, I think it takes about 10 days. I often take on a little more work myself (especially in the phone screen) if I believe it helps speed up the process and saves others time. Speed is important. Keeping momentum during hiring really makes the experience better for everyone.

For background, I work for a startup lab in Boston (we build prototypes that we spin out into companies). We're about 35 employees.

Oh, and let me start by saying that while all the pre-interview work you've listed above does take some time, the real time cost to hiring is from the interview process itself since it involves multiple people.

1.) Resume review: 3 minutes. It took longer when I first got started. I used to agonize over "call/dont-call." But you'll usually have a gut reaction to the resume, and you'll eventually learn to trust that (for better or worse ;-)

2.) Code samples/Exercises: I don't bother with them, although another manager I work with uses them to good effect. Unfortunately, they can add between several days to a week to the process, so I do a more involved phone screen instead to keep things moving.

3.) Phone screen: I spend up to 90 minutes in the phone screen. This seems to be fairly unusual. 90 minutes is a lot of time to invest, but the key is, I only spend that long with the candidates I think I'd like to bring in. The call is setup so that I can cut it short at any point. Even still, I spend a lot of time here. I get to know the candidate, feel out their passions, and actually have them write code, live in an EtherPad derivative while talking to them.

4.) Almost 6 person-hours. Our amazing director of talent greets the candidate, and spends 15 minutes giving them the lay of the land, paperwork, etc. Then two different two-person teams interview the candidate for an hour each getting to know the candidate, sharing what life here is like, and working on one large technical problem. Then our CTO and I spend 45 minutes with the candidate answer questions, talking about the direction and strategy of the company, and gauging their interest in what we do here. Interestingly, the interview process we've been using on the UX side of things spends more time working on a single practical exercise (using computers, not whiteboards) and finishes with a broader meet-and-greet. Since I'm constantly experimenting with this process, I'm planning on trying a variant of this on the software engineer interviews as well.

But I aim to have the whole process from resume review to offer letter done in a week.

LuaJIT adds another massive speed-up on top of the already healthy Lua performance.

http://luajit.org/performance_x86.html

http://luajit.org/performance.html

That said, I do agree that Lua can be more cumbersome than Python or Ruby.

Could be the result of an earn out.

Basically: deal is X, but if condition Y holds true for the next year, we'll given you an additional Z.

Let me start by asking $15k/month in revenue or profit? Do you have capacity to hire?

Courting investors is a full time job, but so is hiring if done right. You probably can't do both with just two of you. If the goal of raising money is to hire more people, and you've already got enough cash to hire even one, do that first.

Just make sure you hire into a position you believe can increase your profit. Spend time thinking about it.

Companies your size grind to a halt while raising capital and it can take months. Once you've expanded a little, multitasking becomes easier. If you're lucky (and this is what you're trying for), you may find that your new hire increases your profit enough while you were looking for investors that you can afford to hire again.

If the new hire doesn't increase profit, you can still take investment (especially if you've been doing the leg work after maxing out your headcount), but you're going to have to figure out how to hire effectively eventually, you'll just have more money in the bank.

We often (jokingly) measure time in kiloseconds around my office. As rue points out, that's just a bit over fifteen minutes, so its actually a useful unit.

"See you in the conference room in 2 ksecs..."

Put a bunch of geeks together too long and this is what happens.

Perhaps you're thinking of a different phone? I believe the Optimus T/S/V line all have capacitive screens.

I have an LG Optimus T on T-Mobile. I got it a while back for $200 with no contract.

My $60 plan through T-Mobile is more expensive then the Virgin one mentioned in the article, but because T-Mobile reduces your bill if you don't take the phone subsidy, it is a lot cheaper than the other options I looked at when buying.

I can't stress enough how great a phone is for the price. The CPU is only 600MHz, but with Android 2.2 it doesn't feel sluggish to me (perhaps because I don't know how fast a phone like the Nexus S feels).

The best part of having no contract is in a year I can just buy a new low end phone with dramatically better specs and hand this one down.

The biggest loss here is the Mac specific GUI bits. Not only does Apple Java use native drawing primitives for ui (instead of requiring X11 like some ports), it also doesn't look completely horrible.

Unlikely as it is, I wish Apple would upstream that code to Oracle.

I guess there's potentially still SWT on top of a ported, open source Java7 from Unix/Linux if you need to do non-X11 UI on Mac.

Well, some Googling suggests that might work anyway...

Remember, it's basically only Linux distros that have the capability to upgrade a third-party library like that (ironically, distro maintainers actually have the source code required to recompile everything if they wanted!).

Mac and Windows applications ship bundled versions of third party libraries all the time. Managing a complex web of name+version based dependencies is much harder in a decentralized software ecosystem, so bundling starts to look attractive.

For our purposes, the benefit of a system where software is more reliable, predictable, and accountable is greater than the cost of asking developers to recompile in unusual circumstances.

Every process has "my-actor" defined in its global environment. It provides methods related to basic actor functionality. In this case I'm calling the "announce" method to say something to all of the process' subscribers.

user-interface and discovery-system are two hypothetical processes whose pids (process identifiers) are passed in to this process as arguments. user-interface would be responsible for creating a window with a text display area and a text entry box. discovery-system would use our remote service discovery model to find others chatting in the same "room."

We don't build any in, but the same strategies (ie, requiring a license key, etc) that work for regular applications like Microsoft Word also work for fluid applications. The bits can be copied easily, but the same is true for traditional software.

Crazy strategies, like CDs that physically can't be copied and must be in the drive or kernel extensions obviously won't work, but that's probably a good thing. =)

Ignoring user interface and the mechanics of peer discovery...

  user-interface, discovery-system |
  # This process is spawned with two pids as arguments
  
  # If either pid halts, I halt too.
  user-interface.link
  discovery-system.link
  
  user-interface.subscribe(when(
    text-entered: { message |
      # I entered a message in the UI, announce it to everyone subscribed to me
      my-actor.announce('exclaimed, message)
    }
  ))
  
  discovery-system.subscribe(when(
    peer-discovered: { name, peer |
      # Discovery system located another user in the chat room
  
      # Send message to user-interface showing a Growl style notification.
      user-interface << ('notify, "{name} arrived.")
  
      peer.subscribe(when(
        # This guy went away - "halted" is announced when a process stops
        halted: { result | user-interface << ('notify, "{name} left.") }
  
        # This guy said something
        exclaimed: { message | user-interface << ('text-append, "{name}: {message}") }
      ))
    }
  )
  
  main.loop

Here's some basic syntax.

  values = '[1, 2, 3]
  incremented = values.map({ n | n + 1 })
  summary = incremented.join(", ")

  summary.starts-with?("1").then({
    fail("Increment failed.")
  })

What sort of examples would you be most interested in seeing?

You can build message passing code that suffers from race conditions. In practice, though, it's almost always obvious if you're about to do something dangerous.

On p.173 Joe writes:

  When we say things such as this:
    Pid = register(...),
    on_exit(Pid, fun(X) -> ..),
  there is a possibility the process dies in the gap between these two statements.

So in Spin you wouldn't be tempted to write something like above (probably not Erlang either?).

Hi nivertech,

I'm sharing one of the lessons we learned building our own programming language. I love how many language designers there are on HN!

We're working on an invite system, so everyone can benefit from Skynet! Skynet is better when you use it with others, so the invites will work for groups of friends.

True, the nice things about libraries is that they can compete and make your ecosystem stronger. But the nice thing about building it into the language is that it becomes a common layer of compatibility.

We've gotten comfortable enough with our concurrency model, that we felt it deserved to be in the language.

As an aside, some features that benefit parallelism can be tricky to add retroactively, although possible (like an N:M threading model).

I actually spent some time reading that spec yesterday while hunting a bug. I was trying to figure out if maybe we were violating the protocol in some way.

I'm not enough of an expert to weigh in, but the spec did make me chuckle. Super verbose with a dash of paranoia.

This is pretty funny (although gregw has written many longer and more detailed essays about websockets as well):

https://bugs.eclipse.org/bugs/show_bug.cgi?id=294563

In the end, we located the bug within our code connecting jetty's websocket support to our message passing system. You can bet that was an adventure to sort out. =)

I loathe source code templates. To use web (newspaper?) terminology, it puts the content below the fold.

It also raises the cost of factoring code out into its own file. Even a simple code header can easily be double the amount of code I consider worth extracting.

I know many IDEs add them automatically, so it doesn't feel like much of a cost to the writer, but as the reader, you pay it every time. Why waste brain power thinking "Ok, ignore everything above, this down here is the real source code"?

And in fact they almost certainly will choose a different host. Our plan is to just buy an extra IP for one of our VPS machines and leave it unused.

We're experimenting with this technique in our peer-to-peer software. Unfortunately we probably won't have data on what percentage of the time it works for a few weeks.

Provided everything goes okay, I'll try to post our data as a follow up.

Chapter 7 of Essentials of Programming Languages (EoPL) has a nice introduction to some basic topics including type checking and type inference.

It's a nice gradual introduction, and help me get started with TaPL (although I wish I could say I'd made much progress).

Consider a bicameral legislature where newly elected representatives serve a four year term in the lower body. Their sole responsibility is the review/renewal of existing laws. Every law must be renewed every four years.

After completing their term in the lower body, the representatives graduate to serve a four year term the higher house. Here, they are entrusted with the power of making new laws.

Elections are staggered (similar to the US sentate), so every year one fourth of the members are elected, one fourth move up, and one fourth retire. This way, the chambers have institutional memory and transitions are smooth.

Both houses have the power to change the legislative topography of the nation. Because newly elected representatives serve in the lower house, when citizens vote to change the direction of the country, the first response to public opinion is the removal of existing laws. Only after serving a term in the lower house can laws be added.

To make this kind of system successful, there might need to be a legal review process that demands small, unbundled laws. Or perhaps a simple word count like @derefr and @mseebach suggest.

I guess the fact that we even think about this stuff pretty much means we're geeks. =)

Haha, well, we were also in a pool with a ton of other brilliant, driven applicants! That might have had something to do with it too. =)

I don't have a "YC missed out on investing in our insanely profitable company" story, but I did get rejected before finding myself at a YC company anyways.

Evan Miller (emiller) and I applied for Summer 06. Evan had to do most of the work on our application because I had deadlines with my publisher on my Ruby book. I was proud that I was writing a book, so I mentioned it in my bio.

In retrospect, I wonder if that doomed us. Sorry, Evan. If I was reading applications, I'd have been like, "This guy thinks he's writing a book and starting a company? Fuggedaboutit."

But another one of my friends got into Winter 07 and he's very persuasive. A year after their session ended he convinced me to leave the corporate world and join him and his cofounder.

Wish I could finish the story by saying we're insanely profitable already, but hey, we're still alive, we've got a great product, and that's awesome.

There are a ton of ways to get a business off the ground, so one rejection from one incubator is really just the beginning. To everyone in that situation, don't give up. And if this one doesn't pan out, maybe you'll go even further with the next one!

I'm not sure why you say it's "BS in terms of engineering."

The tick/tock is done for both business and engineering reasons. Debugging new silicon is hard enough without landing a new microarchitecture and a new process simultaneously.

While the ticks (new process) aren't quite as exciting as the tocks (new architecture), they bring real benefits in cost, power, and increased perf, not to mention usually a few microarchitectural enhancements. These chips are the best of their uarch, and they pave the way for the next tock, as you point out.

Disclaimer: I used to work for Intel's Oregon CPU Architecture Team in the performance group, but that was more than three years ago, so take what I say with a grain of salt. And, of course, I don't speak for Intel in any way.

Yeah, we definitely had to trim down how much info we were storing. Obviously that was a sacrifice, but the upside was a lower barrier to entering a new feature or bug. We really do just treat it like a digital whiteboard (even to the point of posting pictures of our actual whiteboard until we can transcribe them). And the realtime collaborative editing kills a traditional wiki.