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: andy@wallaroo.ai

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 andy@wallaroo.ai.

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 andy@wallaroo.ai.

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).

This article provides some insight into the hardware and software of the MarCO cubesats. It doesn't go into a great deal of depth, but it gives a fun overview of the kinds of engineering work that go into building something that works in space.

Jobs basically reinvented Apple when he came back. The "power law" company that you're talking about was created by a person in his 40s. Before that it was a has-been that had to be bailed out by its biggest competitor.

Leaving that aside, can give any more detail as to why you think power law companies matter and "average" companies don't? There's a lot of "average" companies out there that are making tidy profits for lots of folks.

I first ran into this in one of AK Dewdney's books (probably "The Tinkertoy Computer") when I was in high school. I actually took some classes with Tommaso Toffoli as an undergrad but I had totally forgotten that he invented this, so it was only years later when I came back across it that I made the connection.

I've always enjoyed mechanical implementations of digital logic.

Sadly no, lost to the dusts of time.

I wrote Blank back in the spring of 1997 when I was a senior in high school. I had gotten kind of into a programming language called Befunge (https://esolangs.org/wiki/Befunge), and I decided to write my own weird programming language. I'll admit that it was highly derivative of Befunge, but I threw in my own little twists. For example, Befunge programs were written and executed in a fixed 2 dimentional grid, while my language was 1 dimensional and you could add and remove segments from the program. It was the first C program of any size that I had ever written.

Blank lacks the inspired audacity of languages like Brainfuck and Whitespace. It has almost none of the playfulness of Befunge. Missing, too, is the outright user-hostily of INTERCAL. It was bad, but so mediocre in its badness that it wasn't really worth remembering for most people. But it was mine.

I had never taken a programming class and I'd never really had any sort of adult who could help me much with programming at that time, so this was basically something that I did through sheer stupid stubbornness. The folks on the Befunge mailing list were nice to me and were very polite in the face of my teenage ignorance and over-confidence. In retrospect I probably could have spent the time doing something better, but one of the wonderful things about being young is that you can waste some time exploring.

You can mostly do this by making all of your objects "ref", meaning you can have multiple readers and writers but you can't share the objects between actors. However, you can run into multithreading quickly because so much of the system is built on top of actors. For example, you can have a mutable (ref) string, but you can't easily print it out because the stdout stream is managed by an actor and you can't send a ref object to another actor.

Once you get used to reference capabilities they aren't really a big deal, but it can be hard at first, especially if you aren't thinking about your program executing thing concurrently.

Even after years of programming, most people (myself included) still instinctively think of concurrently executing code as the exceptional case, rather than as the common case. Pony makes it easy to write concurrent programs, but it makes you be explicit about how to do it safely. So I guess I see it less as a premature optimization and more as a different way of thinking about problems.

That's a tough one. Python's dynamic typing means that you can write concise code as long as everything is of the correct type. But the consequence of this is that it is easy to accidentally express the wrong thing and only find out about it at runtime.

Pony's type system requires that you be a bit more explicit, but the tradeoff is that you get better guarantees about the correctness of your program. As your program grows in size these guarantees become more and more useful, or at least that's what I've found.

One part about Pony that can seem like an impediment to expressiveness in Pony is reference capabilities. Pony forces you to think about how objects can be accessed from different actors, which can sometimes make it hard to do things that seem like they would be simple, especially if you are new to the language. The payoff for this is that once you get the reference capabilities correct the compiler guarantees that your program will not have race conditions. In some ways, I'd say that if you're writing multi-threaded code then expressiveness that doesn't offer any safety guarantees is a false economy, because you'll probably end up rewriting the "expressive" code many times to get things right.

Python's a great language, and I don't mean to disparage it. I've used it quite a bit in my career, and for certain types of problems it is still the first tool that I reach for. In my mind, Pony excels in some areas where Python is somewhat weak, so they can live comfortably together in your programming toolbox.

I'm the author of this blog post. If you have any questions, comments, or feedback, please feel free to drop them in here.

This is a talk I gave based on the paper "The Relationship Between COBOL and Computer Science". I also work in some references to Sammet's "The Early History of COBOL", which is sadly behind an ACM paywall.

Oh god that's embarrassing. Thank you for pointing that out.

edit: fixed.

I'm glad it was useful! As far as the naming of pony-stable goes, we've had some conversations about that. We use Pony where I work, and sometimes we can confuse ourselves when someone says "Pony stable" (especially back when we were maintaining our own fork of Pony).

That's great! We're collecting stories about peoples' first impressions of Pony (https://www.ponylang.org/categories/my-first-pony), so if you're interested in contributing to that please get in touch.

I'm an engineer at Wallaroo Labs and I've been learning Go so that I can add a Go API to Wallaroo. Your analysis looks pretty spot-on based on my experience.

The buildmodes is go definitely make it easy to call Go from other languages. The trickiest thing I've run into so far with calling Go is that you aren't supposed to hold on to Go pointers outside of Go code, so I'm having to jump through some hoops to hold on to objects between calls.

I have an RFC for Pony that I need to finish up that will let you call Pony function from C. I'm planning on getting around to that soon, as I think it will help improve our FFI story.

Sorry to hear that. As far as I know the documentation should be up to date, but it's entirely possibly you've found an issue.

If you like you can hit up the mailing list (https://groups.io/g/wallaroo) or the IRC channel (#ponylang on freednode, https://webchat.oftc.net/?channels=wallaroo) to see if anybody can help, or if you think you've found a bug you can file an issue in github (https://github.com/ponylang/ponyc/issues).

UPDATE: I'm glad to hear you got it working!