Live data from Hacker News

We moved from Pony to Rust

wallaroo.ai

61–70 of 178 posts

Re: We moved from Pony to Rust

#61
post #59
post #35

Earlier quoted context omitted.

> 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…

I guess you mean 2000 dev dependencies because for production that would be crazy.

I'll have to check but at least half of those are for production.

Re: We moved from Pony to Rust

#62
post #9

Earlier quoted context omitted.

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 y…

Maybe they should have used a horse, they are much more reliable than camels and more mature than ponies.

Maybe they should have used a horse, they are much more reliable than camels

Unless you are in a dessert.

Re: We moved from Pony to Rust

#63
post #18
post #16

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…

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 *…

I think Jane Street is a big exception. It's like when PG espouses lisp. Back in the 90's[1] language ecosystems were very sparse. An ecosystem was a few big libraries and a syntax highlighter. Now stuff like IDEs, linting, packages, etc. have made people's standards quite high for ecosystems. On the flip side, back in the day languages like OCaml and Lisp had stuff other languages could only dream about. Functions as arguments! Macros! Type inference! But now, barring macros, these features are all in mainstream languages.

If you were to do a similar company now, you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE. Except you now have a significantly smaller advantage because a lot of the languages have caught up and while your god tier programmers can write their own custom serialization library, that's still more developer time than using serde.

Which is why a lot of people are moving to Rust I suppose. You still get the hip factor but responsibly. It's the Foo Fighters of languages. Cool, but not irresponsible.

[1]: I was in a very famous tv show: https://www.youtube.com/watch?v=FBw-Z8ULwcc

Re: We moved from Pony to Rust

#64
post #3

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.

It sounds like no other technology (including Rust 1.0) met their performance and concurrency requirements at the time though.

Surely there was C++ and Java.

Re: We moved from Pony to Rust

#65
post #2

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

I remember becoming curious about Pony because of how much they talked it up, though I never got around to trying it. Feels weird to see the pivot, though I've felt for a while Rust or Rust-inspired languages will become a larger and larger part of the future of software so I guess I shouldn't be surprised.

Re: We moved from Pony to Rust

#66
post #18

Earlier quoted context omitted.

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 *…

I think Jane Street is a big exception. It's like when PG espouses lisp. Back in the 90's[1] language ecosystems were very sparse. An ecosystem was a few big libraries and a syntax highlighter. Now stuff like IDEs, linting, packages, etc. have made people's standards quite high for ecosystems. On the flip side, back in the day languages like OCaml and Lisp had stuff other languages could only dream about. Functions a…

The big difference between Rust and OCaml is that a company the size of Jane Street can influence OCaml development, while it takes one the size of Amazon (according to the recent accusations) to do the same with Rust. I think OCaml has one of those "ancient" communities that seem to value independence more than consensus. Rust is very hard to build without cargo, OCaml works fine with make or dune. I'm not sure if focusing on independence is the right tradeoff for most companies, but I can see some cases where it might be.

> If you were to do a similar company now, you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE.

IDE support is getting there with OCaml. In VSCode, it's not as good as TypeScript but it's usable.

> Except you now have a significantly smaller advantage because a lot of the languages have caught up and while your god tier programmers can write their own custom serialization library, that's still more developer time than using serde.

There are a few libraries that you can use. Serde also tends to make the already long compilation time blow up.

Re: We moved from Pony to Rust

#67
post #18

Earlier quoted context omitted.

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 *…

I think Jane Street is a big exception. It's like when PG espouses lisp. Back in the 90's[1] language ecosystems were very sparse. An ecosystem was a few big libraries and a syntax highlighter. Now stuff like IDEs, linting, packages, etc. have made people's standards quite high for ecosystems. On the flip side, back in the day languages like OCaml and Lisp had stuff other languages could only dream about. Functions a…

A couple points:

These days, you don’t need to build an IDE from scratch - you can just build some language server support for your language and plug into existing IDEs. It’s much less work!

Also, as an aside that’s not really germane to the argument, it’s possible (and IMO preferable) to write code without using an IDE. It forces you to write code that’s broken up into contexts small enough to fit in human working memory. This pays off in the long run. However, once people in your company start writing code with an IDE, it requires more context and becomes almost impossible to edit without an IDE.

Haskell is another language besides OCaml that doesn’t have a ton of MEGACORP backing but nonetheless forms the basis for several very successful companies and groups within MEGACORPs, and where many developers prefer the experience of using it despite not having a $10M IDE like you would for Java. And speaking of that, all the ludicrously expensive and complicated IDEs mostly suck anyway!

> you'd have to recruit people who still write code like in the 90's: emacs/vim hackers who can write their own libraries and don't need no stinking IDE

I wasn’t writing code in the 90s, but I’ve worked at places like this and I would take it any day over “people who copy/paste from stack overflow and get lost without autocomplete” - unless the novel alternative you have in mind is something better than that?

> Which is why a lot of people are moving to Rust I suppose. You still get the hip factor but responsibly

Rust does seem to be in the schelling point of “better enough than C++ to get us off our asses, but no so much better as to scare the devs”. Not sure I’d say it’s especially “responsible” though.

Re: We moved from Pony to Rust

#68
post #16

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…

It's not just the libraries, it's the tools, and those are a much bigger lift. I noticed it with Scala dropping Eclipse support and some users shifting to Kotlin; you couldn't have a clearer example of a strictly worse language, but JetBrains and Google are supporting it, and the difference between a good IDE and not is huge. And when I tried to step up and fix the Scala Eclipse plugin myself and saw what kind of byzantine tower of confusion goes into making an IDE I started to have a bit more sympathy for that kind of decision.

Re: We moved from Pony to Rust

#69
post #47
post #18

Earlier quoted context omitted.

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 *…

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.

Yes, it's not free in the sense that this is paid developer time, and also a delay before actual production deployment.

As long as learning the basics of a 3rd-party library takes a relatively short time, those who use it have an advantage: they ship faster. Certainly mastering it may take as long as writing one's own. But you can do that while writing more production code and shipping features. Also, you get improvements made by other people for free (because likely you're using an OSS library anyway).

Re: We moved from Pony to Rust

#70
post #64

Earlier quoted context omitted.

It sounds like no other technology (including Rust 1.0) met their performance and concurrency requirements at the time though.

Surely there was C++ and Java.

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

Post reply on HN