NanoVMs | Kernel Engineer, Virtualization Engineer, Go Infrastructure Engineer | Full-Time | ONSITE | San Francisco | https://nanovms.com
* Kernel Engineer
* Virtualization Engineer
* Go Infrastructure Engineer
About: We're building out unikernel based infrastructure. If you haven't heard unikernels are super light-weight (ours weighs in around 200k + application) secure (single process - no popping a shell and wget'ng your way to freedom) virtual machines that are faster than containers and in some cases bare metal. We've been building out our own unikernel runtime lately and have other non-public projects we are working on. We're funded, have paying customers, and doing all sorts of interesting low level stuff.
If you miss hacking in assembly or haven't gotten a chance to do what you learned in school you know you belong here.
Location: We're only filling full-time on-site (SF, CA) roles at the moment.
Sponsor: We can sponsor or do transfers for the right people. Note: For H1 transfers we've had RFEs so ymmv. F1s are going to be hard too cause we prefer candidates with at least a few years under their belt.
Interview Process: 20-30min Phone Screen, 1-2hr onsite (comp. sci. fundamentals a must, *nix skills a must) - offer same day
Stack: Go, C, ASM
Also - I know this post is heavily geared towards engineers (it is HN) but if you happen to be a SDR/AE we're hiring those too!
NanoVMs | Kernel Engineer, Virtualization Engineer, Go Infrastructure Engineer | Full-Time | ONSITE | San Francisco | https://nanovms.com
* Kernel Engineer
* Virtualization Engineer
* Go Infrastructure Engineer
About: We're building out unikernel based infrastructure. We're funded, have paying customers, and doing all sorts of interesting low level stuff - a lot of it we don't publicly talk about yet.
If you miss hacking in assembly or haven't gotten a chance to do what you learned in school you know you belong here.
Location: We're only filling full-time on-site (SF, CA) roles at the moment.
Sponsor: We can sponsor or do transfers for the right people.
Interview Process: 20-30min Phone Screen, 1-2hr onsite (comp. sci. fundamentals a must) - offer same day
Stack: Go, C, ASM
Also - I know this post is heavily geared towards engineers (it is HN) but if you happen to be a SDR we're hiring those too!
Ready to hack unikernel infrastructure? Unikernels are widely considered the cloud of the future and we have large paying customers utilizing them in production right now.
Politicians talk about re-building bridges and roads but no one discusses the mess of what software infrastructure is today or the fact that is largely built by systems designed over 40 years ago. It's time to fix that.
The software stack today is completely ludicrous - please help us fix it.
We need both Go Engineers && Kernel Engineers. Whether it's hacking DMA drivers or figuring out what needs to be tweak to scale more than 2000 VMs on a single server we got really nice meaty engineering problems for you to solve. We're currently a small team of highly technical engineers complemented by a highly effective sales team.
We have a large existing Go codebase along with a growing base of C/ASM. Other languages you might find in our codebase - rust/lua.
The opportunity to level up your game is extreme as we are going off the deep end on the technical front.
We are looking for really smart driven engineers - eg: ones that can take charge and code like the wind.
We have quite a few really interesting secret projects going on right now - would love to tell you more when we chat.
We are all on-site in our Townsend office in SF, CA. We currently aren't doing remote. We're customer driven by engineering led.
We run traditional interviews.
Please email ian / nanovms.com and secure your spot in the systems company you always wanted to work in.
yes - specifically questions on computer science fundamentals - considering the work we do (osdev) it's extremely important and I can point at many places in our codebase where they pop up and we have to implement ourselves
Ready to hack unikernel infrastructure? Unikernels are widely considered the cloud of the future and we have large paying customers utilizing them in production right now.
Politicians talk about re-building bridges and roads but no one discusses the mess of what software infrastructure is today or the fact that is largely built by systems designed over 40 years ago. It's time to fix that.
The software stack today is completely ludicrous - please help us fix it.
We need both Go Engineers && Kernel Engineers. Whether it's hacking DMA drivers or figuring out what needs to be tweak to scale more than 2000 VMs on a single server we got really nice meaty engineering problems for you to solve. We're currently a small team of highly technical engineers complemented by a highly effective sales team.
We have a large existing Go codebase along with a growing base of C/ASM. Other languages you might find in our codebase - rust/lua.
The opportunity to level up your game is extreme as we are going off the deep end on the technical front.
We are looking for really smart driven engineers - eg: ones that can take charge and code like the wind.
We have quite a few really interesting secret projects going on right now - would love to tell you more when we chat.
We are all on-site in our Townsend office in SF, CA. We currently aren't doing remote. We're customer driven by engineering led.
We run traditional interviews.
Please email engineering @ deferpanic.com &&|| ian@ and secure your spot in the systems company you always wanted to work in.
1) What languages right now - Go, php, javascript, ruby through the rumpkernel project - rumpkernel.org.
2) We are implementing support to support user supplied images which will let you run mostly anything in the very near future. We plan to be completely agnostic.
Most of our stuff is plain old net/http w/some gorilla doing things we didn't want to code at the outset and never bothered to replace later on.
While our main datastore is postgres we have 3 custom datastores that are starting to take a very active role. We have a lot of time-series data, very little relational, a bit of 'document' style and micro-service traces are living in their own.
Not sure if this answers your question but maybe that gets you going in the right direction.
I'd just like to point out that most of our customers have webapps written in go - not just JSON apis so this argument that go is not for webapps is at best incorrect. I talk to gophers around the world everyday that are using it just for that.
They much rather hack on a webserver that they can use in 15 LOC from stdlib than some beefy JVM framework.
From the conversations I've had I strongly believe most webapps are going to be written in go in the coming years.
I'm a full-time Golang developer, the last product I shipped was a Rails app, and my career started in the 90s as a shrink-wrap C software developer. Golang is an unpleasant environment in which to build web applications:
* Good SQL persistence abstractions aren't there yet, so realistic SQL-backed applications depend on writing tons of raw SQL and (worse) parsing results. Like a savage.
* Golang's built-in templating is good for self-contained full templates but not great for hierarchies of templates and partials.
* Golang's net/http library is so good that it's a gravity well for other request handling abstractions, so that sessions, CSRF tokens, and access control either have to be built directly on Golang's equivalent of Rack, or inevitably get put into libraries that conceal too much of net/http.
"Going with the flow" and writing idiomatic Golang code feels a lot like writing those Sinatra apps where you get 1/3rd of the way through and regret not just using Rails.
You can totally write a good web app in Golang, especially if you're doing minimal serverside HTML generation and leaning on something like React or Angular or Ember instead. But it's not what Golang is best at.
Meanwhile, Scala is both a language designed in part for serverside web apps and built on the JVM.
If you're writing a web application, where your functionality is exposed by a port 443 that Firefox connects to directly and asks for "/" from, I'd prefer Scala to Golang.
Reasonable people can disagree or object to any of this, but I'm not going to waste time sugarcoating.
Agreed:
1) SQL is not solved in an ORM sense. Yes you will have to write sql statements. I'm not so sure this is a bad thing.
Beg-to-differ:
1) Templating works very well for me. You can pass variables to embedded template "partials" within a template. You can define your own functions for the templating engine to use etc.
2) net/http + gorilla (or something similar) and you have all of net/http exposed with some sugar on top.
3) csrf tokens are just a simple library. Yes you do have to be sure to put them into your templates.
If you are having difficulty with a middle-ware concept in terms of golang there are plenty of resources online.
So I would say that I have a different feeling about making websites in golang :) I enjoy it.
Those are a lot of the same things a Sinatra programmer could have said about using Sinatra instead of Rails. And it's true, you can, and in some cases you might even enjoy it (if nothing else, the code is more transparent in Sinatra or Golang).
If, however, you've had the experience of starting a project in Sinatra and ruefully finishing it in Rails, my advice is: don't do full-featured web apps entirely in Golang.
Thanks. This is really helpful advice, and the ORM-related comments you made resonate with me, because the use of abstracted data backing services is sort of the meat and potatoes in just about any web app I can think of, and this was a real pain point in my initial research of Go. All of the ORM-ish things I've found are mediocre, at best, IMHO.
You can get around it by using more recent databases; Rethink for instance might close the gap. But then you're using an idiosyncratic database for kind of a weird reason. Personally, I want to preserve a default of using Postgres, and I don't like that Golang pulls me away from that a little.
That said: I really like Golang a lot.
For Microcorruption, we did the overwhelming majority in Golang, exposing it as a JSON RPC endpoint, and then did the UI in a very small amount of Rails. It worked quite well.
One thing you can for sure say about Golang: it is fast. We deployed 3 app servers but if we had deployed only 1 it still wouldn't have broken a sweat.
I agree 100% about your Postgres point. I don't want to ever be in a situation where I can't use Postgres, unless we're in a situation wherein Postgres has taken the back seat to some other database that is A) ACID compliant, B) really fast and scalable and B) fairly widely adopted.
> I'd just like to point out that most of our customers have webapps written in go - not just JSON apis so this argument that go is not for webapps is at best incorrect.
The fact that your customers are using Go for webapps does not mean that tptacek's statement that he would give the nod to Scala for webapps but consider Go in the running with Scala for web APIs. Advice is not "incorrect" because some people make different choices.
> From the conversations I've had I strongly believe most webapps are going to be written in go in the coming years.
I'll be surprised if that ever happens. There's plenty of languages that have a good story for webapps -- Go certainly isn't the worst choice, but the advantages it has over some alternatives aren't all that unique, nor are they without tradeoffs. I wouldn't be surprised to see Go continue to make gains for a while (and then be passed up by newer things), but I don't see it ever being most webapps.
As for metrics - we've been working precisely on that @ https://deferpanic.com . To some extent logging as well. This means (exactly as OP mentioned) - memory, gc, go-routines, request durations, db query latency, logging errors/panics, etc.
We are extremely open to suggestions/feedback.
One key point I'd like to point out though, is that OP specifically mentioned the go kit being targeted towards a company with "100–1000+ engineers". I think this is highly on point - if you have less engineers than this you probably don't have enough resources to maintain these sorts of systems yourselves and this is where we think we can help out.
* Kernel Engineer
* Virtualization Engineer
* Go Infrastructure Engineer
About: We're building out unikernel based infrastructure. If you haven't heard unikernels are super light-weight (ours weighs in around 200k + application) secure (single process - no popping a shell and wget'ng your way to freedom) virtual machines that are faster than containers and in some cases bare metal. We've been building out our own unikernel runtime lately and have other non-public projects we are working on. We're funded, have paying customers, and doing all sorts of interesting low level stuff.
If you miss hacking in assembly or haven't gotten a chance to do what you learned in school you know you belong here.
Location: We're only filling full-time on-site (SF, CA) roles at the moment.
Sponsor: We can sponsor or do transfers for the right people. Note: For H1 transfers we've had RFEs so ymmv. F1s are going to be hard too cause we prefer candidates with at least a few years under their belt.
Interview Process: 20-30min Phone Screen, 1-2hr onsite (comp. sci. fundamentals a must, *nix skills a must) - offer same day
Stack: Go, C, ASM
Also - I know this post is heavily geared towards engineers (it is HN) but if you happen to be a SDR/AE we're hiring those too!
Email us (ian@) or ping here.