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

121–130 of 178 posts

Re: We moved from Pony to Rust

#121

Post by brabel »

lmm wrote: post #68
Zababa wrote: 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 byz…

> you couldn't have a clearer example of a strictly worse language...

A language that does NOT have as many features and limits more what you can do is NOT a strictly worse language. You can never say a language is worse than another, anyway, in general: it's always relative to what usage you have in mind. Your apparent disdain for a language just on the basis of the language features shows that you have a lot to learn about language economics, mentioned in other threads here.

Re: We moved from Pony to Rust

#122

Post by brabel »

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.

It doesn't work in IntelliJ unless you use Cursive, though?! Which is not free (has that changed??).

Re: We moved from Pony to Rust

#123

Post by kaba0 »

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…

> 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

No, complex programs by definition don’t fit into human working memory. Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the requirement’s level — so in the end you will end up with larger chunks of code for which you will have to use code navigation features - for which I personally prefer an IDE, but that is subjective.

Re: We moved from Pony to Rust

#124

Post by Zababa »

d3nj4l wrote: post #77
pjmlp wrote: 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.

It's things like that that makes OCaml what it is. It supports OO even if you don't use it all the time, it supports imperative constructs. I remember reading in "Le langage Caml", by Xavier Leroy, that you should use an imperative loop over recursion if the loop is simple, and keep recursion for complex use cases, where it makes sense. That's not something you often hear from functional programmers, probably because the ones we hear are more obsessed with purity than practicality. But it's a great way to show OCaml's values.

Re: We moved from Pony to Rust

#125

Post by carnitine »

abacadaba wrote: post #80
_dwt wrote: post #37

Earlier quoted context omitted.

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

tldr: Elm is a Cybertruck

More like a golf cart to Haskell’s Cybertruck.

Re: We moved from Pony to Rust

#126

Post by kaba0 »

travisgriggs wrote: post #49
Zababa wrote: 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…

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…

Let me refer back to Brooks’s famous paper: there are no silver bullets. There has been no order of magnitude increase since the appearance of the first managed languages, which is multiple decades now. According to him, the only way we can somehow “cheat” are way into more productivity is through ecosystems, that is standing on the shoulder of giants.

Like, the only reason are computers are remotely working fine is that great deal of abstractions.

Re: We moved from Pony to Rust

#127

Post by int_19h »

dleslie wrote: post #101
int_19h wrote: post #92

Earlier quoted context omitted.

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.

Can you give some specific examples?

Re: We moved from Pony to Rust

#128

Post by dleslie »

kaba0 wrote: post #118
dleslie wrote: post #101

Earlier quoted context omitted.

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

Why wouldn’t Zig be applicable anywhere where c is applicable? Afaik it can also compile to C as a target other than the many architectures it supports.

Zig did not compile to C, yet, and so is restricted to llvm's targets.

Re: We moved from Pony to Rust

#130

Post by emodendroket »

pjmlp wrote: post #23
Zababa wrote: 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…

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

There's a third strategy: hitching your wagon to an already-successful ecosystem, like languages such as Kotlin do.

Post reply on HN