Live data from Hacker News

We moved from Pony to Rust

wallaroo.ai

91–100 of 178 posts

Re: We moved from Pony to Rust

#91
post #87

I evaluated Pony 4 years ago, and walked away due to 2 technical issues: - garbage collection - no mechanism for synchronous access to actors We ended up building a C++ actor model, with it's associated headaches. Yes, we still have race conditions and some developers invoke the function directly instead of using messages, and yes, sometimes we will grab a locking mechanism to do synchronous access, but at the end of…

Why not use Rust? It can do what you want.

With 21st century developer workstations having >= 8 cores, >= 2Ghz, >= 16Gb memory, it is ridiculous to have the scaffolding that Rust, Zig and other modern languages have. Source files dont live on their own and shouldn't be compiled as isolated units, they live in projects and need to be compiled as a batch. I'm stunned to see that so many developers are used to needing scaffolding, they just accept it as being necessary, but when you step back and think about it, it no longer makes any sense to require it. C and C++ get a pass here since they were designed in the 70/80's, but languages that have been designed from 2010 onwards must be ridiculed for targetting a PDP-11 era development machine where each compiler unit has limited access to resources. The end language I'm designing has smaller source files, however the compiler is a lot more complex since it auto generates the scaffolding (header files, forward declarations, etc).

It's still a fair bit away, I just got the proof of concept compiler which outputs C++ working (and the compiler is written in the language itself, so I'm dog fooding the project).

Re: We moved from Pony to Rust

#92
post #23
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…

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

It's also why C++ won - for the most part, you could just reuse C libraries as is by including the header inside an extern "C" block.

These days, Zig seems to be explicitly trying to do the same thing, but without paying the backwards compatibility tax:

https://ziglang.org/documentation/master/#Import-from-C-Head...

Re: We moved from Pony to Rust

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

Heh, that's a good reference I hadn't read before. I feel like maybe Clojure and OCaml were strike one and two followed by a home run with the F# and dotnet call. Prob feeling real smug right now with aot, wasm, and hot reload being first class citizens haha.

Re: We moved from Pony to Rust

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

> Ecosystem matters a lot these days.

and having a big ecosystem doesn't mean it's a good or a healthy one either.

Re: We moved from Pony to Rust

#95
post #45

Earlier quoted context omitted.

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…

> 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 thought F# was OCaml?

F# at its heart is OCaml without functors, and with its original structurally typed OO model replaced by .NET's.

Re: We moved from Pony to Rust

#96
post #77
post #43

Earlier quoted context omitted.

Except the O in OCaml stands for Objective Caml, and F# has plenty of OOP features to interoperate with .NET ecosystem.

While it is true that OCaml does support a kind of OOP, even the OCaml manual outright states that it isn’t used much: https://ocaml.org/manual/objectexamples.html I think the biggest use for objects is to have a kind of row polymorphism? I don’t know too much because I haven’t used them at all.

OCaml object system is better than what .NET offers, IMO. On one hand, it enforces clear interface/implementation separation ("classes aren't types"), while structured typing for objects makes this arrangement easy to use in practice. But then there are also powerful features such as multiple inheritance.

The biggest quirk coming from something like Java or C# is that you can't downcast. But classes can still opt into this ability (by using virtual methods + extensible variants) where it makes sense; and in most cases, the presence of downcasts means that a discriminated union is probably a better fit to model something than a class.

Re: We moved from Pony to Rust

#97
post #87

Earlier quoted context omitted.

Why not use Rust? It can do what you want.

With 21st century developer workstations having >= 8 cores, >= 2Ghz, >= 16Gb memory, it is ridiculous to have the scaffolding that Rust, Zig and other modern languages have. Source files dont live on their own and shouldn't be compiled as isolated units, they live in projects and need to be compiled as a batch. I'm stunned to see that so many developers are used to needing scaffolding, they just accept it as being ne…

What is the cost of having that scaffolding?

Re: We moved from Pony to Rust

#98
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.

For every widely used technology, someone had to be the first. And then some small group had to be the early adopters.

Sure, but what is the advantage of being first to a new language? I’d rather be the 50th than the first.

Re: We moved from Pony to Rust

#99
post #6
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.

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 :)]

There is a downside to using an interesting language as a recruiting draw; you are going to get people people who are more interested in the particulars of how you solve a problem than in actually solving the problem.

Re: We moved from Pony to Rust

#100
post #33
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…

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

Was pony really a Cadillac? Cadillacs are supposed to be comfortable and large (and not fast). Part of the design (if you believe Robert virding) of erlang's process system is that it makes error handling (an important part of being a developer) very comfortable because it just does the sane thing with little or no effort. Pony, by contrast, obsessively required you to handle errors and shoehorned you into a theory-inspired actor system , missing the point that erlang processes are practical units of composable failure domains, not theoretical actor concurrency units
Post reply on HN