We're really lucky also to have one of the main `rkt` developers joining us soon to work on the container side.
753 karma · joined March 31, 2011
We're really lucky also to have one of the main `rkt` developers joining us soon to work on the container side.
However, the work also includes a runtime platform that is more low-level, including building our own container system, talking to the Linux kernel, using cgroups/resource management, and distributed message passing - areas where languages such as Go have found a niche, and may be classified as Real World. However for us, Haskell's type-safety, runtime performance, and extensive ecosystem has been a boon even in this domain. We effectively use it as an (incredibly powerful) general-purpose language here, and it's worked more than fine.
We're currently at around 15,000 lines of code with a team of 5 Haskellers, and it hasn't really been a problem regarding performance, understanding the codebase, or with newcomers to the team.
(plug - we're at https://www.github.com/nstack/nstack and are hiring more Haskellers)
NStack lets data analysts to do sophisticated data work in the cloud without a team of engineers. To accomplish this, we’re a building a platform for composable, data-driven microservices, using a mixture of Haskell and low-level Linux systems tech (including containers, systemd, IPC, with some typed DSLs, systems code, and distributed systems thrown in). Our aim is to use the fundamental lessons of programming languages and operating systems to provide an abstraction over infrastructure - think Bash for containerised microservices.
We’re looking for both talented backend/systems programmers -- preferably with some knowledge of typed functional languages and *NIX systems programming -- and smart generalists / full-stack developers to join our team to make this a reality. It’s a challenging role, working on hard problems, and offers the chance to work with a top technical team and shape a company and product from an early stage.
NStack is funded by top-tier investors from the West Coast, the founders are both technical and ex-YC / academia, and our team is lucky enough to include world-class talent for the problem we're solving. Salaries are competitive and include generous stock options. We're generally hiring onsite, however remote within Europe is also possible for the right candidate. We’re looking at a range of positions and experience levels - whether you’ve just left uni or been hacking for 20 years, if you’re interested please get in touch.
Any questions please comment, reach out via jobs@nstack.com, or https://angellist.com/nstack/jobs Cheers!
NStack lets data analysts to do sophisticated data work in the cloud without a team of engineers. To accomplish this, we’re a building a platform for composable, data-driven microservices, using a mixture of Haskell and low-level Linux systems tech (including containers, systemd, IPC, with some typed DSLs, systems code, and distributed systems thrown in). Our aim is to use the fundamental lessons of programming languages and operating systems to provide an abstraction over infrastructure - think Bash for containerised microservices.
We’re looking for both talented programmers -- preferably with some knowledge of typed functional languages and *NIX systems programming -- and data scientists to join our team to make this a reality. It’s a challenging role, working on hard problems, and offers the chance to work with a top technical team and shape a company and product from an early stage.
NStack is funded by top-tier investors from the West Coast, the founders are both technical and ex-YC / academia, and our team is lucky enough to include world-class talent for the problem we're solving. Salaries are competitive and include generous stock options. EU applicants welcome for onsite, and remote is also possible for the right candidate. We’re looking at a range of positions and experience levels - whether you’ve just left uni or been hacking for 20 years, if you’re interested please get in touch.
Any questions please comment, reach out via jobs@nstack.com, or https://angellist.com/nstack/jobs
Cheers!
Thanks for the ping, your email hasn't been lost! :) Sorry for the delay, my fault, was at a conference at the end of last week, and unfortunately caught a cold after :(
Check your inbox - cheers!
We’re a London-based startup working on a microservices-based “CloudOS” using a mixture of Haskell and Linux systems technology (containers, minimal distros, init systems, etc.) - with some DSLs, systems code, and distributed systems thrown in. We want developers to spend more time writing core business-logic and less time thinking about infrastructure.
We’re looking for our first technical hires, who will be working with us to design and implement the core platform that will make this a reality. We have a MVP in Python (https://github.com/StackHut/stackhut); it gives a feel for what we’re trying to build, although is only a start.
We’re implementing this in Haskell, and are looking for talented functional programmers preferably with some knowledge of Linux/Unix systems programming. It’s a challenging role, working on hard problems, but the chance to work with a top technical team and shape a company and product from the get-go.
We’re funded by top-tier infrastructure investors from the West Coast, and the founders are highly-technical and ex-YC / PhD. Salaries are competitive and include stock options. EU applicants welcome, although relocation would be required. Any questions please comment, reach out on email (jobs at stackhut dot com) or at https://stackhut.com/#/careers. Cheers!
I'm hoping increases usage by Jane Street, Facebook and Bloomberg, along with the Unikernels/Docker tie-up will lead to increased uptake and visibility. I personally find it more suitable to systems space than Go, but with far more features to help build correct code.
(shameless plug - we're using OCaml for our microservices platform in London and are now hiring - https://www.stackhut.com/#/careers)
ps - shameless plug but we're hiring talented OCaml devs (http://stackhut.com/#/careers)
pps - Congrats to @amirmc and the Mirage OS group!
The overall work ratio is lower (75% vs ~83%) but it's hard to put an qualitative efficiency metric when programming anyway so I'm not so worried.
This ratio also worked super well when writing my dissertation - the 5m break never felt like enough of a reward after.
(there is also a great Pomodoro extension for Gnome if you're running Linux).
And this is slightly off-topic but I have tried several times to fully embrace the Windows way, learnt PowerShell (ISE rocks), and even spent significant time building a startup using F# in VS and hosting it on Azure. In retrospect it was nice but there were just too many rough edges for me,
* Setting up a nice console environment means using a 3rd-party system like cmder/conemu + Cygwin/Msys/etc.
* Getting git working along with ssh-agent is still hit & miss
* Installing, for instance, Python packages that rely on C bindings requires extra trickery to set up,
* Chocolately isn't bad, but it is just downloading and running installers for you, it doesn't really have a dependency solver like yum or other Linux package managers do (NuGet does but don't think Chocolately uses those features). Plus it's more for packaged software than libraries/tools. OneGet may fix that in the future.
These are all surmoutable issues, for sure, but in the end it was just easier to move back to Linux. Not just for familiarity, but also convenience and ease - for me Windows was like death by 1000 papercuts. A shame, as I much prefer the Windows/PowerShell data model of communicating objects to text. I just wish MS would spend some time working on the overall dev experience outside of VS.
(I'm sure enough people will say desktop Linux has it's fair share of issues and I totally agree. Wireless drivers, Wayland still not quite there, battery usage, and much more. Which is why I'd be happy to pay for Windows if the dev experience was improved.)
Although the latest Fedora 23 is perhaps the most polished version yet ;)
Updates would crap out with random errors like 80074005 - which a casual user should never see. I got it working again by stopping the update services from the console (net stop ...), deleting the cache and re-running.
The store would be running, then you'd Alt-Tab out and back again and it would be gone. Same happened with other Universal apps, OneNote in particular.
It certainly got more reliable over time, and I have tried the insider builds on a spare laptop and they're better - but the initial 10240 release was sub-par.
You can run Linux natively on the Surface, SecureBoot isn't a problem, but the bigger issues are drivers and a touch-unfriendly UI.
(I went with an Acer Aspire E11 - $150, 8hr battery, and fanless - it may be the best Linux netbook every made!)
I just gave Windows 10 another try with a view to purchasing a Surface 4 if successful (OneNote + Stylus = :)) - but after a few weeks reverted back to Linux (Fedora).
Apart from the inferior development experience (outside of VS - which is top-notch), there are just too many bugs, unfinished pieces and a general lack of polish. Updates wouldn't install, the Store kept crashing/disappearing, Modern Apps would interact badly with virtual desktops.
Win 10 should never have been released in such a state. I'm hoping the Threshold release out this week will go some ways to repairing the damage and presume will be a better fit for the Surface Book.
Maybe I'll look at the Surface line again in a few months.
We've tried to make it as simple as possible to get your code into the cloud. You write your classes and they're deployed as entrypoints into a lambda-esque service that you can call over JSON-RPC - making it trivial to write and deploy a backend.
As described in the blog, the great thing we think it has over tools like lambda is that you can describe your system declaratively, specifying any dependencies you may need, using a simple YAML file and it takes care of packaging your code. You can run this locally or deploy it to our hosted platform where it scales as needed.
Currently support JS and Python atm, and open-source at https://www.github.com/StackHut. We're super early but would love to hear your thoughts.
Most code is open-sourced at http://www.github.com/StackHut and we're working on making it easily deployable on your own hardware.
We're adding support for more languages (JS & Python currently) but also have an entire build chain that let's you specify any Linux OS and language packages you want, and it's also trivial to embed your binaries and shell out to them if needed.
Feels like such a step back when I have to use a Python 2.x codebase - so many little annoyances.
Hmm, yep recursion not supported atm, although we are thinking of extending the basic system shortly - there are a lot of other features we'd like to add - true sum types, a dynamic operator, and more.
Python annotations are nice, and a lot of users have asked for a way to annotate RPC functions in their code. Doing this all in a cross-language way will be hard and so we're thinking of keeping the external definition in the meantime.
--
Thanks so much for your advice. We're certainly looking at past attempts, and the research in transferring data is vast - I think it boils down to a trade-off between expression and usability - and for now JSON seems to have found pretty good sweet spot. Perhaps with just a simple schema layer on top that will be suitable for most use-cases. I imagine Thrift, ProtoBufs, etc will always beat it on speed, XML (+XML Schema) on expressibility, etc.
For us, as you have guessed, we are just trying to make it as easy as possible for the majority of users – particularly web and mobile developers. This does also mean we're trying to stay language agnostic and find a type subset that works across most languages - JSON primitives let us get some of the way there.
Thank you so much for all your advice - it's been so helpful and we're really happy you took the time out to try it all and record your thoughts. Would love to chat further - please feel free to drop me an email at HNusername @stackhut.com.
Yes! I wish there was a way to really define and lock-down exactly what communication/serialisation primitives are required to aid communication between systems. Though I imagine you are right in that we've come quite far with common practices.
Haha - yes the Barrister docs can be a bit confusing - we are getting around to writing a simpler version of them with common examples and use-cases. We really like the schema itself as it does map onto JSON semantics quite nicely.
1) Yep, the messaging format could def be simpler! We just felt that as we're starting out it would be better to stick with standards, even if, as you say, they are nascent. This reduces the amount of things we have to do but also we hope that people much smarter than have thought about the issues involved! Hopefully the client-side bindings will hide most but if needed it's nice to now you can drop down to the JSON format.
2) Hmm, JSON by example, this is super interesting!! I fully understand where you are coming from and it seems so much simpler than JSON-Schema (I was never a fan) Using values as types is quite elegant, and reminds me of some of the type-level programming stuff in the functional circles.
The use of multiple entries in a JSON object seems like a nice way to express sum types - something we are really keen to add to the Barrister IDL (you can extend from an object but I believe there is only a single tree). As you note, although this valid JSON, it may require a custom parser to extract. I'd love to hear more about this technique tho, has it been used elsewhere or is there any further documentation?
3) Primitives - yes, it'd certainly be possible to specify other primitives by encoding them in the JSON string value. Could be risky, as you suggest, when you start looking at regexes and so on - I've not been the biggest fan of defining these as types in the past. Also, how would one go about defining a user-defined type at the equivalent level of a primitive? Super interesting tho, if you have any more thoughts on this I'd love to read them.