We moved from Pony to Rust • Hacker News Board

Re: We moved from Pony to Rust

#131

Post by int_19h » Thu, Oct 07, 2021, 7:57 AM UTC

dleslie wrote: post #129

int_19h wrote: post #127

Earlier quoted context omitted.

Can you give some specific examples?

SH2, which lacks llvm support but has C compilers available.

Oh, you mean target architectures. But stuff like SuperH is used only for embedded these days, where even C is often rather idiosyncratic. For most coders, Zig is comparable to other mainstream languages in terms of supporting mainstream platforms.

Anyway, this is really a matter of implementation, not a language issue. There's nothing about Zig that makes it inherently impossible to support SH2 or any other platform - indeed, as others have noted, they already have a C backend in the works, so the endgame is to support everything that has a C compiler.

Also, as far as C interop goes, if I remember correctly, Nim can't just take a C header and expose everything declared in it - you still have to manually redeclare the functions and types that you want in Nim, no? You can use c2nim, of course, but that's not really any different than generators for other languages, and requires extra build steps etc. Zig handles it all transparently.

Re: We moved from Pony to Rust

#132

Post by Zababa » Thu, Oct 07, 2021, 8:27 AM UTC

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.

As I've said somewhere else, don't think in terms of languages but in terms of use cases. Nim can make a lot of sense for some cases where C is used, and not much for others. The same is true for Zig. There is no and there will never be a "C replacement", just other options depending on what you are doing.

Re: We moved from Pony to Rust

#133

Post by scns » Thu, Oct 07, 2021, 9:07 AM UTC

brabel wrote: post #122

closeparen wrote: post #74

Earlier quoted context omitted.

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

Free for personal use IIRC.

Re: We moved from Pony to Rust

#134

Post by pjmlp » Thu, Oct 07, 2021, 9:08 AM UTC

FpUser wrote: post #112

dleslie wrote: post #101

Earlier quoted context omitted.

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

The first thing I look when working with any language excluding shell scripts is interactive debugging from IDE.

And in languages that try to replace C++, better offer nice IDE tooling as well.

https://devblogs.microsoft.com/cppblog/edit-your-c-code-whil...

https://uecasts.com/courses/unreal-engine-5-introduction/epi...

With VC++ and Unreal catching up with Lucid Energize[0], others will have to up their game.

[0] - https://www.youtube.com/watch?v=pQQTScuApWk

Re: We moved from Pony to Rust

#135

Post by pjmlp » Thu, Oct 07, 2021, 9:13 AM UTC

emodendroket wrote: post #130

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…

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

That strategy always falls apart when the ecosystem goes into a direction that the guest languages did not forsaw, or already created incompatible concepts, and then get the dilema of what to expose from the underlying ecosystem.

Using Kotlin as example, its initial selling point was Java compatibility, now it wants to be everywhere, and its Java compatibility story is also constrained for what Android Java is capable of.

So the tooling attrition increases, with KMM, wrapping FFI stuff to be called from Java like coroutines, and everything that is coming with Loom, Panama and Valhala.

Re: We moved from Pony to Rust

#136

Post by jedisct1 » Thu, Oct 07, 2021, 9:44 AM UTC

dleslie wrote: post #128

kaba0 wrote: post #118

Earlier quoted context omitted.

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.

Zig's stage2 compiler has a C backend https://github.com/ziglang/zig/blob/master/src/codegen/c.zig

Re: We moved from Pony to Rust

#137

Post by forgotpwd16 » Thu, Oct 07, 2021, 10:16 AM UTC

Pony is a younger than Rust and has far smaller exposure. It isn't strange that it didn't worked out. Using the shiny new thing is rarely a good choice.

Re: We moved from Pony to Rust

#138

Post by southerntofu » Thu, Oct 07, 2021, 11:00 AM UTC

FpUser wrote: post #112

dleslie wrote: post #101

Earlier quoted context omitted.

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

The first thing I look when working with any language excluding shell scripts is interactive debugging from IDE.

My two cents as a non-professional programmer: i've found hacking on someone else's codebase to be very hard with/without a debugger in dynamic languages like JS/Python where most things are untyped and you get runtime exceptions upon eg. trying to call a method on a nil object.

BUT back on the thread's topic, since i started programming in Rust, the only time i've felt it was hard to wrap my head around the compiler's output was with complex async programming. Otherwise, every single time i felt like a simple text editor was more than enough with rustc's output to understand what's going on, because in Rust everything is very explicit and statically typed with clear lifetimes, and the compiler has very helpful error messages often including suggestions on how to fix the error.

For me, everything (non-async) Rust is a clear win in terms of understandability/hackability, compared to all other languages i've tried before (admittedly not a lot of them). I think complex IDE tooling can ease the pain, but proper language design can help prevent the disease in the first place.

EDIT: i should add, since i started programming in Rust, i've only once or twice seen a runtime panic (due to array indexing error on my side). Otherwise, literally all of the bugs i had written were caught by the compiler before the program ran. For me it was a huge win to spend one more hour to please the compiler in exchange for spending days less debugging stuff afterwards.

Re: We moved from Pony to Rust

#139

Post by nuerow » Thu, Oct 07, 2021, 11:35 AM UTC

pkulak wrote: post #117

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…

Kotlin is strictly worse if you value language features above all else. In that, there are several (several!) features it doesn't have.

> Kotlin is strictly worse if you value language features above all else. In that, there are several (several!) features it doesn't have.

Could you please elaborate on that? It was my understanding that Kotlin did everything that Java did (or any JVM-based language) but actually added first-class support for basic features missing from Java that required magic sauce like Lombok to fill in the gaps.

Re: We moved from Pony to Rust

#140

Post by scns » Thu, Oct 07, 2021, 11:41 AM UTC

throw868788 wrote: post #115

chillfox wrote: post #73

Earlier quoted context omitted.

Multi-threading can often be handed off to the OS in the form of just run more processes. So in most cases there is really no need for the language to handle it.

Its still nice to have shared memory especially in a functional language where due to lots more immutability it isn't as big of a price (i.e. more concurrency safe). Especially if your sharing in-memory caches and the like. I've seen this save tons of dollars in cloud setups (100,000's) in my career in more than one place. Safe multi-threading was marketed as part of the advantage of functional programming to many pe…

It took so long because they wanted to ensure the performance OCaml is known for.