Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We moved from Pony to Rust

wallaroo.ai

Post reply on HN
Print view View original

101–110 of 178 posts

Re: We moved from Pony to Rust

#101

Post by dleslie »

int_19h wrote: post #92
pjmlp wrote: post #23

Earlier quoted context omitted.

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

Nim does it better, it can be used anywhere C can; zig cannot.

Re: We moved from Pony to Rust

#102

Post by gpm »

smallstepforman wrote: post #91
devit wrote: 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…

> 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

Rusts compilation model is projects (called crates) that compile source files in batches.

But also, this feels like a minor implementation detail...

Maybe I'm missing your point?

Re: We moved from Pony to Rust

#103

Post by vips7L »

d3nj4l wrote: post #78
lmm wrote: post #68

Earlier quoted context omitted.

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

Why can’t you just use IntelliJ CE? You won’t get some of the web programming features, but otherwise it’s perfectly capable.

There’s also the Scala Metals language server and bloop. Plenty of options outside of eclipse.

Re: We moved from Pony to Rust

#104

Post by mst »

thaumasiotes wrote: post #72
Zababa wrote: 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?

They're both ML family languages, and both add OO, so they're not quite that closely related but they're definitely part of the same family tree.

Re: We moved from Pony to Rust

#105

Post by pjmlp »

int_19h wrote: post #92
pjmlp wrote: post #23

Earlier quoted context omitted.

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

Yes, a lesson that TypeScript also took into account.

Re: We moved from Pony to Rust

#106

Post by pjmlp »

davidw wrote: post #53
pjmlp wrote: post #23

Earlier quoted context omitted.

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…

I wrote about the economics of programming languages a while back: https://www.welton.it/articles/programming_language_economic...

Thanks for sharing, spot on.

I like the Tcl example, that is how we worked at a .com startup I was part of.

Re: We moved from Pony to Rust

#107

Post by staticassertion »

smallstepforman wrote: post #81

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…

> - no mechanism for synchronous access to actors

That is presumably intentional, since if you could access actor state synchronously it wouldn't really be much of an actor. This sounds a lot like a "doing it wrong" kinda problem.

> (but without compiler validation of resource sharing at this point in time)

Not sure how you'll do this without garbage collection (like reference counting, which is what Pony uses iirc).

Honestly I suspect if you continue forward you'll probably walk away with much more appreciation for Pony's design decisions.

Re: We moved from Pony to Rust

#108

Post by pjmlp »

closeparen wrote: post #74
hardwaregeek wrote: post #63

Earlier quoted context omitted.

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…

Clojure has access to the Java library ecosystem and works beautifully in IntelliJ. That may be one of the best ratios of language properties to tooling quality.

Cursive brings it some Lisp Machines development workflow love as well.

Re: We moved from Pony to Rust

#109

Post by pjmlp »

wyager wrote: post #67
hardwaregeek wrote: post #63

Earlier quoted context omitted.

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

I would call Microsoft Research part of a MEGACORP.

Re: We moved from Pony to Rust

#110

Post by pjmlp »

hardwaregeek wrote: post #63
wyager wrote: 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…

I was writing code in the 90's, and my first IDE was Turbo Basic in 1990 precisely, followed by Turbo Pascal alongside Turbo Vision and Object Windows Library.

Eventually I also got into Turbo C, Turbo C++, and then upgraded myself into Borland C++, used Visual Basic 3.0 in 1994, and a couple of years later Visual C++ 5.0 was my first MS C++ IDE.

Mac OS MPW was an IDE and stuff like AMOS and DevPac were IDEs as well.

Java IDEs started to show up around 1998, like Visual Cafe and the first Eclipse, after being ported from IBM's Visual Age.

Visual Age, which were the IDEs for Smalltalk and C++ from IBM for OS/2 and Aix.

The only group that wasn't using IDEs were the UNIX folks, thankfully XEmacs was around to bring some back sanity when I had to code in UNIX.

Post reply on HN