aturley

Wallaroo.ai | Senior Frontend, Backend Engineers, Platform Architect | Perma-REMOTE / EST core hours

Want to help define what painless MLOps at scale looks like? Want in on the ground floor of a paradigm-defining company in the artificial intelligence / machine learning space? Wallaroo is hiring!

We're looking for:

* Senior Frontend Engineer - Fluent in React.js, you'll work with product designer to build out our system dashboard.

* Senior Backend Engineer - Build out our ultrafast Rust-based ML model execution engine and support environment.

* Platform Architect - Provide architectural guidance and product direction.

Full job descriptions are at https://wallaroo.breezy.hr/.

Feel free to reach out: [email protected]

C++ and Java did exist, and rejected for the following reasons:

"Furthermore, the existing Apache tools depended on Java - specifically the JVM - where it's really hard to get predictable, very low latency results."

"From a purely performance perspective, C or C++ would have been a good choice. However, from past experience we knew that building highly distributed data processing applications in C/C++ was no easy task. We ruled out C++ because we wanted better safety guarantees around memory and concurrency."

Thanks for checking us out. We're working improving our website and our explainer materials. Would you be interested in a quick conversation? I'd be happy to do a demo and get some feedback on ways we could improve the first impression. you can reach me at `andy at wallaroo dot ai`.

Wallaroo | Frontend Software Engineer | Remote (10AM - 4PM US Eastern Time core hours) | Full-time | salary dependent on experience | https://wallaroo.ai

We’re looking for an experienced frontend software engineer excited about joining a small, dynamic startup where you can have a major impact on the company's success in the red-hot machine learning field. You're passionate about UX design: you excel at turning complex, rapidly evolving problem spaces into intuitive, empowering user interfaces.

We’re building a high performance and ergonomic machine learning inference platform. You’ll build the React.js web interface that our customers use to deploy, test, and monitor high volume production ML models. No prior ML experience is needed, but you should be ready to come up to speed fast on the product space and the user stories.

You have experience writing complex production-grade React.js systems interacting with backend system APIs. You’ve got a good intuitive grasp of usability and ergonomic UX/UI design principles -- UI paper cuts drive you crazy. You know your way around modern web frameworks and build tools. You understand the pain involved in interacting with systems that contain many related components and process large volumes of data. You thrive in an environment where the long-term goals remain stable but day-to-day needs may change quickly. And more than anything, you are committed to continual learning and value sharing your knowledge with the team.

You'll work with our backend engineering team to extend the APIs that power the UI, and work with our customer-facing teams to understand the users' needs. You might be creating charts and visualizations to quickly highlight changes in important model metrics, coming up with useful visual groupings of information to enable new insights, or building a novel way of displaying A/B test results to clearly emphasize the outcome.

For more information or to apply go here: https://wallaroo.breezy.hr/p/4c960b57e0e7-frontend-software-...

If you have any questions you can contact me at [email protected].

Wallaroo | https://wallaroo.ai | Lead Client Software Engineer && Hands on Client Architect | REMOTE | cannot sponsor H1B

Wallaroo provides a platform for production AI that helps turn data into business results faster, simpler, and at lower cost. We enable data science teams to get models live against production data, while giving them visibility into how the models are performing, and the power to make quick and easy iterations. We run as a service inside a client’s environment.

We're looking for engineers and architects who will help our clients use our software to achieve their goals. These are client facing roles where you will work together with the client to understand their needs and their environment, then architect and build the software and systems required for success.

You should have cloud computing experience, familiarity with ML/AI frameworks, and experience working directly with clients. Our software is based on Kubernetes and Rust, so experience with related technologies is also highly desirable.

This job will require work with the US Department of Defense, so applicants must be US citizens who are willing to obtain a DoD Common Access Card.

If you're interested in either position, please apply here: https://wallaroo.breezy.hr. If you have any questions please contact me (Andrew Turley) at [email protected].

There are some cool new features in this release, including a streamlined Python API. If you have any questions or want to talk about stream processing in Python I'm happy to do it here.

Most of the code is pretty monstrous, especially when I was writing the scripting language and it just kind of ... grew. Anyway, this has been a fun project for getting me to do some slightly weird things with Pony and giving me an excuse to use my Cricut a little more.

I'm an engineer at Wallaroo labs. I've done a lot of work on our Python API and I wrote the blog post. If you want to discuss stream processing, or Python, or Pony (the language that the core of Wallaroo is written in), I'd be happy to do it here.

This book provides an approachable view of the history and practice of granular synthesis.

So, I actually thought about including "enough of a cash buffer to survive a few bad hires", but the more I thought about it the more I remembered how much time was wasted on folks who made it through the interview process but didn't work out. Lots of companies are wasting money hiring folks with no plan for how to retain them or get them to work effectively. If you've solved this problem then good for you.

I've half joked about doing this for technical positions. I think to make it work you'd need:

1. A strong management system in place that's committed to helping folks succeed. 2. A willingness to honestly evaluate people and let them go if they aren't working out.

I've seen enough bad hires even in places that have well planned hiring processes that I'm having trouble believing this would be any worse.

I didn't build the playground website so I can't comment too much on it, but I can try to answer your question since I don't think it is specific to the website (but if my answer doesn't help please let me know, I may have misunderstood the question).

Actors in a Pony program all run within the same operating system process, so in theory there shouldn't be a limit to how many are run. In practice each actor takes up some memory so if you start enough of them you'll crash the process when you run out of memory.

Pony has a scheduler that schedules actors to run on threads. By default a Pony application starts with as many threads as there are CPUs in the system, but that's adjustable so the playground may tune that down. So all the actors are free to be available to be scheduled, but the number that are running at the same time is dependent on how many threads the scheduler has, and how many actors are processing messages at a given time.

Output in Pony is done via two actors: `env.out` is for stdout, `env.err` is for stderr. If you want to print a string you send that string to the actor via a `print(...)` message. Actors only process one message at a time, so each string will be printed in the order in which the output actor received the `print(...)` message.

Hopefully that helps a little. I'm happy to try to clarify or answer other questions.

I'm giving a Pony workshop at ICFP this year (https://icfp18.sigplan.org/event/icfp-2018-tutorials-writing...), this repo represents the material that I'll be covering. I've given early versions of it twice in NYC. I think it kind of works as a stand-alone thing (but you miss the thrill of hearing my voice and asking questions).

I'd love to get some feedback if anybody has any thoughts.

This book details how to implement a Forth-like language/environment. It gets down into the nitty-gritty of some 1980s processors so it may feel a little dated, but the thinking behind it is really interesting.

I've been rereading "Thinking Forth", which is a great high-level book on software engineering that happens to use Forth as it's language for discussion. "Threaded Interpretive Languages" is a nice trip in the other direction, to the low level details of how to efficiently implement a system that follows Forth's ideas.

Pony uses a queue for storing messages that have been sent to an actor, so that's probably a reasonable way to start thinking about it. I'm not sure how far I would stretch this comparison, though. :)

Pony's model is different than Erlang's, so trying to think of it in terms of Erlang's model ("entering receive loop") may not be helpful when trying to understand it.

The Pony runtime takes care of scheduling an actor to run when there is a message for that actor. The actor runs through the behavior and then waits to be scheduled again by the runtime when another message is available. If you want to filter messages you need to arrange a way to do that in your code. There's no way to inspect the message queue.

I put together a cheat sheet for the Pony programming language (https://ponylang.org). It provides a quick reference to some things that I think are useful for folks who are getting started with the language. It isn't meant to be a stand-alone resource, rather it should be used in conjunction with other learning materials like the Pony Tutorial (https://tutorial.ponylang.org).