[HN Gopher] We (Wallaroo) Moved from Pony to Rust
___________________________________________________________________
We (Wallaroo) Moved from Pony to Rust
Author : aturley
Score : 84 points
Date : 2021-10-06 19:34 UTC (3 hours ago)
(HTM) web link (www.wallaroo.ai)
(TXT) w3m dump (www.wallaroo.ai)
| Fiahil wrote:
| > However, in the meantime data science and machine learning
| continued to explode, and we found that customer interest in
| deploying machine learning models far outstripped demand for more
| conventional stream processing data algorithms.
|
| My experience is quite similar : I either end up working with
| clients who are already using Spark etc, or they don't have a
| mature data engineering lab. In both cases, deploying a model to
| production is always the most challenging.
|
| I hope their MLOps strategy is better, than just binding to
| MLFlow. This tool is absolutely not ready for prime time, and
| plagued by bad product decisions.
| latenightcoding wrote:
| There are people commenting that Pony was the wrong choice from
| the get go, but many of us have only heard of this startup (which
| operates in a saturated market) because they were using Pony.
| Thaxll wrote:
| Shocking that using a language that no one use was a mistake on
| the long term. It made 0 sense what so ever to use it in the
| first place.
| mynameisash wrote:
| I don't read this as "it was a mistake to use Pony." They state
| that:
|
| > in the meantime data science and machine learning continued
| to explode ... With the increasing focus on MLOps, Rust became
| a better fit
|
| This sounds like, "Our business goals shifted, as did the
| industry around data science, and Rust's maturity improved such
| that it made sense for us to migrate our stack."
| zamadatix wrote:
| Mistake or not is hard to quantify without presenting what
| qualifies as success first. Is "it was able to achieve our
| initial goals" success or is "it was able to grow with our
| business" success? For each of those how much ability is
| enough to call it "not a mistake"?
|
| I think it's fair to say looking back it was a mistake to
| pick Pony on the assumptions it provided marginal benefit for
| the exact needs of the business day 1 but at the same time I
| think it's fair to say that picking Pony was not a mistake as
| it allowed them to get where they are today.
| OJFord wrote:
| I think that might be more obvious today than it was five years
| ago? In 2016 rust was already ahead of pony in adoption, sure,
| but they were both young interesting languages. The five years
| since have widened the gap considerably in maturity (of the
| core language as well as community/ecosystem) I think.
| eej71 wrote:
| Making bad choices happens all the time. Learning to correct
| them is a good skill to build up.
| noiddicle wrote:
| Sure, but if you take the time to actually read the article
| you'll learn that Pony was at the time the only language and
| runtime capable of meeting their needs.
|
| You'd also learn that this is a different product with
| different requirements.
|
| There's no such thing as the "best language" - there's the
| "best language that fits your problem domain".
| mcintyre1994 wrote:
| It sounds like no other technology (including Rust 1.0) met
| their performance and concurrency requirements at the time
| though.
| continuational wrote:
| Somebody has to be first.
| pabl8k wrote:
| OTOH an interesting language can be a recruiting draw. It
| probably helped them recruit engineers who were interested in
| the distributed systems and concurrency problems they were
| trying to solve. See for example Jane Street with OCaml.
|
| [edit: oops, thanks for the heads up on the spelling :)]
| Zababa wrote:
| OCaml is old and reliable, and I think it was already proven
| to work in the industry when Jane Street chose it. Even if it
| wasn't the best programming language ever, it was still a
| strong choice at the time, and still is. Pony on the other
| hand was and still is very young. I'm not saying it's a bad
| choice, but it's definitely not the same risk profile as
| OCaml.
|
| It's just OCaml by the way, for Objective Caml. Unless you're
| talking about the secret Irish fork /s.
|
| There's a nice page on the official website about the
| history: https://ocaml.org/learn/history.html.
| wk_end wrote:
| > I think it was already proven to work in the industry
| when Jane Street chose it.
|
| Not really. Outside of Jane Street OCaml has scarcely been
| proven to work in the industry _now_. As a big OCaml fan
| and former OCaml professional, I say this lovingly: it was
| (and remains) popular in academia and that 's mostly it.
| And Pony is roughly as old now as OCaml was when Jane
| Street started using it.
|
| The _actual_ reason OCaml 's risk profile was much lower
| was because it effectively has the backing of the French
| government and academy, which is quite the boon.
|
| IIRC Jane Street chose OCaml basically because Yaron Minsky
| was brought on as CTO, he had worked with it in school and
| was a fan of it, and they knew that for the sort of work
| they were doing OCaml would give them an edge (speed of
| development and runtime efficiency) and they calculated
| that its relative obscurity and poor community support
| wouldn't be a liability for the sort of work they were
| doing. And remember that it was the year 2000 - Perl was
| basically the only language with the sort of library
| ecosystem (CPAN) that is expected of languages now: poor
| community support was much less of a liability then.
| Zababa wrote:
| > Outside of Jane Street OCaml has scarcely been proven
| to work in the industry now.
|
| I think it depends on what you're working on. If you're
| building anything that looks like a interpreter/compiler,
| it's probably one of your best bets. If you're working on
| stuff that needs a lot of libraries, and relatively
| obscure ones, it's probably one of your worst bet. If you
| need good interaction with Windows, it's probably not a
| great choice either. The businesses I know, which are
| mostly SaaS, would probably fall under "not the best
| choice, use with caution". If that's the general case, I
| agree with you.
|
| > The actual reason OCaml's risk profile was much lower
| was because it effectively has the backing of the French
| government and academy, which is quite the boon.
|
| I wonder how much Jane Street benefited from that. The
| classes preparatoires are still using OCaml to this day
| (or at least were 3 years ago), and that's usually the
| best students of France. I've also heard that Facebook
| recruited quite a lot, for Hack and Flow.
|
| > And remember that it was the year 2000 - Perl was
| basically the only language with the sort of library
| ecosystem (CPAN) that is expected of languages now: poor
| community support was much less of a liability then.
|
| That's a good point. I think OCaml still has a better
| package manager and build tool than some really popular
| languages (I'm thinking specifically about Python), but
| it's hard to beat the ecosystem.
| openfuture wrote:
| Maybe they should have used a horse, they are much more
| reliable than camels and more mature than ponies.
| Zababa wrote:
| I'm not sure, AoE2 taught me that camels always win
| against horses. And if you consider Rust to be OCaml's
| child (which is kind of true if you really stretch
| things), it seems like young camels win against young
| horses too.
| steveklabnik wrote:
| For every widely used technology, someone had to be the first.
| And then some small group had to be the early adopters.
| zitterbewegung wrote:
| If you are a startup it's best to focus on the product and
| not necessarily the implementation
|
| Groupon was prototyped in Wordpress.
| Zababa wrote:
| And Rails was extracted from Basecamp. I think startups
| depend so much on the few firsts individuals that it's hard
| to have a hard rule about what to use.
| steveklabnik wrote:
| For some startups, that makes sense, yes. For other
| startups, it may not. See pg's classic essay (that I'm not
| 100% sure I agree with, but, we're on hacker news) for one
| example of why you may want to use a more niche langauge:
| http://www.paulgraham.com/pypar.html
|
| Ruby on Rails was created for Basecamp.
| spooneybarger wrote:
| Wallaroo started as a company that was building high-
| performance data processing infrastructure for real-time
| trading and adjacent systems. Wordpress wouldn't really cut
| it.
| kgraves wrote:
| I find it a strange trend, as if it is some sort of competitive
| advantage.
|
| very strange and odd.
| Zababa wrote:
| This feels like the same pattern as Dark leaving OCaml for F#:
| https://blog.darklang.com/leaving-ocaml//. Ecosystem matters a
| lot these days. Outside of these two specific cases, I wonder if
| we're, as an industry, too afraid of writing this kind of stuff
| now I feel like it was done a lot before, and not at all these
| days. Sure, NIH syndrome is a fallacy, but having to write one
| library may not be so bad. I would be glad to hear about any
| experience with that.
| travisgriggs wrote:
| How depressing. Probably true. But depressing nevertheless.
| Bigger frameworks, more complicated libraries, deeper multi
| tiered tooling, all of these things that we call ecosystem,
| reduce access to general purpose programming and creativity.
| We've created a bureaucracy of execution so complicated that we
| need vast amounts of funding to keep us at the tiller doing the
| biddings of e-commerce apps. It's like the founding fathers of
| programming have been reborn as Sir Humphreys.
| Zababa wrote:
| If you're doing things on servers that you manage yourself
| and not using lots of saas, you can probably still do things
| in an obscure programming language.
| crdrost wrote:
| Kind of, but like OCaml-to-F# is like "Dark goes from the Prius
| of languages nobody uses, to the Tesla of the .NET ecosystem."
| The aims (ecological in the car case) of the purchaser are
| similar, but the car [at least in its ecosystem] is sleeker and
| now the roads are a bit different.
|
| On the other hand this is like "Wallaroo moves from the
| Cadillac of languages nobody uses, to the Chevy Equinox of
| languages nobody uses." Like, totally fine, you grew older and
| had kids and needed an SUV to keep up with home life, no shame
| in that... but there is a wistful "ah when we were young" to
| the transition, no?
| Zababa wrote:
| I don't know anything about cars and don't understand your
| metaphor at all, sorry.
| _dwt wrote:
| I know a little about cars and I'm still confused - I think
| I just have a very different view of the relative "it
| factors" between each pair of languages. De gustibus...
| crdrost wrote:
| Yeah I mean that's fair too. My impressions are poorly
| formed but the analogy is that both F# and OCaml are
| based on functional programming, which to my mind takes a
| step back from the "imperative programming -> OOP ->
| shared state multithreading" history into an alternative
| history, I'm phrasing this as them being "electric cars"
| for the first half. OCaml is not really the swankiest of
| swank in the alt-languages community, so I chose a Prius
| to be like "what's a car that folks know as eco-friendly
| but it's not very prestigious?" ... meanwhile F# is like
| "we are THE functional programming of the .NET world,
| come over here we're cool and slick and all-electric"
| hence the Tesla comparison.
|
| Pony is like the far-off "ah maybe someday I'll be able
| to use that at work, maybe for some little experiment"
| thing and it reminded me of going to a dealer and being
| like "let me drive the Caddy, you know I'm not gonna buy
| it, I know I'm not gonna buy it, but I just wanted to
| live a little today." I don't have any particular
| experience with Chevy SUVs so I just chose one at random,
| the point was that Rust is like a "look we're just trying
| to be C with explicit contracts between parts that allow
| for memory safety" type of language, very practical and
| chunky and like people love it don't get me wrong...
| just, it's an SUV. It's less opinionated and more just
| "let's get from point A to point B safely."
| pjmlp wrote:
| Except the O in OCaml stands for Objective Caml, and F#
| has plenty of OOP features to interoperate with .NET
| ecosystem.
| Zababa wrote:
| I think it's one of those cases where using metaphors
| doesn't help clarify the thought, and instead obscure it.
| Rust shares a lot with OCaml, and so with F#. F# is "the"
| functional programming language of the .NET world, but
| it's also because it's the only one, and it's a second
| class citizen.
|
| I will also add that Rust is not trying to be C (and
| neither trying to "replace C"). It's here to offer an
| alternative, that in some cases makes more sense than
| sticking with C. C code means a lot of thing. For
| example, some people code in C89 because they find some
| kind of purity in it. You're never going to get that from
| Rust. For some people, it means fast and secure code,
| like with Python's cryptography. That's a place where
| Rust can be used. For some other people, it's C because
| that's the only thing that's allowed by some authority.
| Again, Rust isn't going to fit here until/if it's
| allowed. I think in general, trying to reason in terms of
| use case leads to better comprehension than trying to
| think in languages.
|
| But outside of that, the move was basically the same.
| They found another language that's very similar, but that
| has a way bigger ecosystem.
| wyager wrote:
| I used to work at an OCaml company and it wasn't nearly as much
| of an issue as one might predict. You can (it turns out) build
| a very successful business even if there aren't a lot of
| existing libraries, or if the language lacks certain basic
| features like native multithreading (same with Python of
| course). I don't have a great model for _why_ this isn 't
| devastatingly expensive, but it's probably some combination of
|
| * Most existing libraries are kind of bad anyway so you're not
| missing out much by not using them
|
| * If you write everything yourself you get system expertise
| "for free", and gaining expertise in something that already
| exists is hard
|
| * You can tailor everything to your business requirements
|
| * Writing libraries is "fun work" so it's easier to be
| productive while doing it
| Zababa wrote:
| That's interesting, thanks for sharing your experience.
| Sometimes I wonder how much interesting experience I miss by
| mostly using things people already built. Sure, if you're
| just trying to get something done it's probably faster, but
| on the other hand spending more time gives you experience.
| brundolf wrote:
| It would probably depend a lot on what you're building
|
| Though I think the "fun work" point is really interesting and
| worth a broader discussion
| pbiggar wrote:
| I don't agree with this at all.
|
| While it's true that there are lots of bad libraries and many
| libraries are easy, you really isolate yourself from the
| broader ecosystem by doing this. Vendors and 3rd party
| solutions are now much harder to use, and when you use them
| you'll probably only use them at a surface level instead of
| using all the features.
|
| And some things are so mature and vast you don't have a
| chance of building them yourself. If what you are doing can
| be done well in very mature ecosystems like React or PyTorch,
| the effort to recreate them will dwarf the time spend on
| important work.
| Zababa wrote:
| > If what you are doing can be done well in very mature
| ecosystems like React or PyTorch, the effort to recreate
| them will dwarf the time spend on important work.
|
| Sometimes that's effort that's not really necessary. At
| work we had a team build a dashboard with React and a few
| graphs recently. It clocks at 2000 unique dependencies.
| That's not a typo, it's two thousands dependencies for a
| few graphs. Reimplementing all of that would take many man-
| years of work, but I think it wouldn't be necessary in the
| first place. Chart.js doesn't use any runtime dependencies,
| and could probably fill most of our needs. Chart.js is 50k
| of Javascript, which is a lot but probably more than we
| need. I don't know how much time it would take to make a
| reimplementation to have the API we need, but I think it's
| doable. Why would we want to do that? Because those 2000
| dependencies are a liability. Last time I checked 165 were
| looking for funding. It would be easy to imagine a
| malicious actor paying a few people to contribute to low
| profile but widely used JS libraries, and take over the
| maintenance when the original maintainer becomes tired. I
| don't know if this is a worse liability than developing our
| own chart library. I don't know much about security and the
| tradeoff involved.
|
| All of that to say, isolation from the broader ecosystem
| may be a good thing.
| jokethrowaway wrote:
| I know plenty of companies not using third parties for
| security or ideological reasons.
|
| Code is code: both models (3rd party vs no 3rd party) can
| work and the time spent reinventing the wheel is not
| necessarily business breaking.
| ch4s3 wrote:
| The "for free" is doing a lot of work there! :) I've been
| there, and you do develop the valuable human capital, but it
| costs time and salary.
|
| That said, you're right it is fun, and people like doing it
| so its good to keep your work mixed up and you team
| motivated.
|
| It's a good lever to pull IMHO, but not always.
| pbiggar wrote:
| That was my thought (I wrote the Dark post).
|
| It also makes me think of CircleCI where they stayed in Clojure
| for quite some time - it really didn't have that much need for
| libraries (and the ones it did need, such as AWS, were provided
| by Java).
|
| When evaluating whether to use a non-mainstream language, the
| rule I use now is:
|
| - will I need to interact significantly with the outside world
| in a way that can only be done with libraries?
|
| - if not, do I gain a lot with this non-mainstream language?
|
| That contrasts against how I used to do it, where I viewed it
| as a trade-off between the ecosystem and the advantage of the
| non-mainstream language.
| Zababa wrote:
| Thank you for the posts, the follow up posts and your
| perspective.
| pjmlp wrote:
| That is why when comparing languages we should always look
| beyond grammar and semantics.
|
| This is nothing new, it is also a reason why languages like C
| and C++ won the systems programming wars from the 1990's.
|
| After a while one gets tired to write wrapper libraries, or
| having to pay extra for an additional compiler that isn't part
| of the platform SDKs.
|
| Hence why successful languages always need some kind of killer
| feature, or a company with deep enough pockets willing to push
| it into the mainstream no matter what.
|
| Same applies to new OS architecture ideas as well.
| shrubble wrote:
| Wasn't there a big brouhaha, many years ago, when Reddit switched
| from Lisp to Python?
| guu wrote:
| Last year they discussed why they didn't choose rust (predicted
| 12-18 months to build a runtime that met their requirements) or
| erlang (performance too slow):
|
| https://corecursive.com/055-unproven-with-sean-allen/#consid...
| spooneybarger wrote:
| That's me. I discussed why we (I am no longer at Wallaroo) made
| the decision about 5 years ago to use Pony to build a product
| that is no longer what Wallaroo is selling.
| debarshri wrote:
| Just a thought. Rewriting the core platform from one language to
| another just takes huge resources for orgs who are in high growth
| path. It feels like a side mission, derailed from core value that
| is solving the problem statement. Rewrites are generally a red
| flag for me, especially early in an orgs history.
| spooneybarger wrote:
| This article is about how Wallaroo when they started a NEW
| product chose a different language than what was used to write
| the original product.
|
| There's no rewrite here.
| ZeroCool2u wrote:
| The product Wallaroo is building sounds really interesting, (It's
| so appealing I honestly checked out their open positions), but
| it's really difficult to get a feel for what exactly it's like to
| use their product now.
|
| The description and outcome statistics make it sound _excellent_
| and their technology stack makes their claims seem viable.
| However, and I say this as someone that is currently running an
| MLOps RFP, after looking at every page of their site and all
| their open job postings I have no idea what it's actually like to
| use their product.
| aturley wrote:
| 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`.
| secondcoming wrote:
| > Our new Rust-based platform recently handled millions of
| inferences a second of a sophisticated ad-targeting model with a
| median latency of 5 milliseconds, and a yearly infrastructure
| cost of $130K.
|
| Were these run on CPUs or GPUs? How many of them? Last I looked
| at running Tensorflow models on CPUs it was really slow, so slow
| we had to abandon it.
| btheshoe wrote:
| That font is so thin it's almost uncomfortable to read.
|
| I've never heard of Pony before - is it any good, or worth
| playing around with?
| pjmlp wrote:
| I guess it makes sense from business point of view, although it
| is a pity that Pony is losing what is probably the only
| commercial user (that I am aware of).
___________________________________________________________________
(page generated 2021-10-06 23:00 UTC)