We moved from Pony to Rust • Hacker News Board

Re: We moved from Pony to Rust

#151

Post by kjeetgill » Thu, Oct 07, 2021, 5:13 PM UTC

int_19h wrote: post #131

dleslie wrote: post #129

Earlier quoted context omitted.

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…

> Anyway, this is really a matter of implementation, not a language issue.

That's kind of what people are getting at in this whole conversation though isn't it, ecosystems around languages matter. They can't be an afterthought.

Re: We moved from Pony to Rust

#152

Post by wyager » Thu, Oct 07, 2021, 5:17 PM UTC

kaba0 wrote: post #123

wyager wrote: post #67

Earlier quoted context omitted.

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

> No, complex programs by definition don’t fit into human working memory.

If you write your code in the right way they don’t have to. That’s the point.

You shouldn’t need to comprehend your entire program at once to work with it.

> Even with best practices, FP, whatever, function composition alone can’t always elevate the complexity to the requirement’s level

Function composition isn’t the pinnacle of abstraction. We have many other abstraction techniques (like rich types, lawful typeclasses, parametric programming, etc.) which allow for any given subcomponent of a program to be conceptualized in its entirety.

Re: We moved from Pony to Rust

#153

Post by hardwaregeek » Thu, Oct 07, 2021, 6:16 PM UTC

pjmlp wrote: post #110

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…

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

I'm curious about these early IDEs. My knowledge of 90's programming is solely from secondary sources. What features did they have? Did they do stuff like automatic renaming or goto definition? Were those features done syntactically or semantically? How fast were they? A common complaint I've read is that people could type faster than an IDE could keep up, which is something I rarely encounter these days.

Re: We moved from Pony to Rust

#154

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

kjeetgill wrote: post #151

int_19h wrote: post #131

Earlier quoted context omitted.

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…

> Anyway, this is really a matter of implementation, not a language issue. That's kind of what people are getting at in this whole conversation though isn't it, ecosystems around languages matter. They can't be an afterthought.

Of course - which is exactly why Zig is not ignoring this. But we still have to compare apples to apples, and oranges to oranges. My original comment was about languages - specifically the ability of the language to consume libraries from another language with minimal hassle, and the response was that Nim somehow does it better.

I'm not even sure why arch support was brought up in this thread, to be honest, because it's not relevant at all? If your problem is unsupported architecture, it's a blocker long before you need to use any libraries...

Re: We moved from Pony to Rust

#155

Post by int_19h » Thu, Oct 07, 2021, 8:00 PM UTC

Zababa wrote: post #143

int_19h wrote: post #131

Earlier quoted context omitted.

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…

> Anyway, this is really a matter of implementation, not a language issue. I think separating the two is a bit artificial. Python being slow is partially an implementation issue but the fast implementations can't run everything. When you compare languages, you have to compare implementations, otherwise it's meaningless.

You have to compare ecosystems, but when doing so, you still have to compare PL design and PL implementation separately, because they have different implications. A quality-of-implementation issue means that something can be done, but isn't done by this particular implementation. A language limitation applies to all implementations.

Re: We moved from Pony to Rust

#156

Post by Zababa » Thu, Oct 07, 2021, 8:01 PM 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.

I think you can compile Zig to WASM, and then it's just a matter of finding a WASM interpreter/JIT in C.

Re: We moved from Pony to Rust

#157

Post by throw868788 » Thu, Oct 07, 2021, 10:29 PM UTC

scns wrote: post #140

throw868788 wrote: post #115

Earlier quoted context omitted.

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.

Agreed; especially since it didn't have it originally. I'm sure some compromises were made to do it in a way that fits into the execution model/doesn't cause regressions to older code. They are both good languages for sure which makes sense because one is derived from the other.

F# through itself and .NET has had the equivalent functionality for many years however (Threads, Tasks, Async's, Channel libraries, etc) being the one of the first languages (before C#) to have an Async construct. I would imagine it would take some time I think for OcAML's ecosystem to catch up API wise with this where it matters for application development. Looking at OcAML's recent release notes I see work to slowly migrate multicore into OcAML but the feature itself hasn't landed yet? Think it comes in 5.0.

I have to say though F# performance is quite good too those days from working/dabbling with both languages + the ecosystem is bigger. I would like to see/understand where the OcAML perf advantage is there is any for evaluation. The CLR has really good performance these days; its has features to optimise some things (e.g. value types make a big difference to some data structures, hot loops vs the JVM) from my experience especially if you don't allow Unsafe code for many algo's/data structures. For example I just looked at the benchmarks game (I know has its problems including bad contributed implementations for niche ecosystems) but it shows .NET Core (and therefore F#) performance is within the same scale as OcAML at times beating it (https://benchmarksgame-team.pages.debian.net/benchmarksgame/...).

Re: We moved from Pony to Rust

#158

Post by mbrodersen » Thu, Oct 07, 2021, 10:55 PM UTC

It is absolutely batshit crazy to start a business with new but immature tools like Pony. Unless investors are throwing money at you and you don’t care about building a long term successful business. All developer tools take years to become solid and well supported. And most of them fail to get any major developer mindshare. If you think your unicorn snowflake project needs a new immature but oh so shiny programming language to be successful then you are simply wrong. Not even “likely to be wrong” but 100% guaranteed to be wrong.

Re: We moved from Pony to Rust

#159

Post by mbrodersen » Thu, Oct 07, 2021, 11:01 PM UTC

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…

PG seems to be the only person who has built a successful business using Lisp. While thousands of successful companies are using C++/Java/.. etc. why do you think so few companies have succeeded with Lisp?

Re: We moved from Pony to Rust

#160

Post by mbrodersen » Thu, Oct 07, 2021, 11:06 PM UTC

wyager wrote: post #18

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…

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

My experience as well. I worked in industries (Games development) where no open-source or proprietary solutions existed for what we needed. So we built it ourselves. It wasn’t that hard and we never had problems with it because it did 100% exactly what we needed and nothing else. If any new feature was needed we simply added it. I would routinely get an ask from a programmer, artist, musician or game designer and would have it implemented and a new version ready for them within a day or two. The productivity gains were immense.