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

171–178 of 178 posts

Re: We moved from Pony to Rust

#171

Post by wyager »

kazinator wrote: post #166
wyager wrote: post #152

Earlier quoted context omitted.

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

What if the program is a hundred million floating-point values, produced by learning? Can you look at them in small chunks to understand what they are contributing to the result? It looks like there is such a thing as complexity that is not functionally decomposable.

Do you write your programs like a neural network? I would consider that a major red flag when hiring.

Re: We moved from Pony to Rust

#172

Post by Zababa »

dleslie wrote: post #161
Zababa wrote: post #156

Earlier quoted context omitted.

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

... That would be terrible on, say, the Sega Genesis or 32X.

I don't see how it's more terrible than using Nim.

Re: We moved from Pony to Rust

#173

Post by Zababa »

int_19h wrote: post #155
Zababa wrote: post #143

Earlier quoted context omitted.

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

That's not really true, you can go around language limitations. Go has codegen for generics, JavaScript has TS for static types, Babel for """macros""". Lots of propositions that are not in JS now can be used with Babel. Python has C extensions.

Re: We moved from Pony to Rust

#174

Post by int_19h »

Zababa wrote: post #173
int_19h wrote: post #155

Earlier quoted context omitted.

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.

That's not really true, you can go around language limitations. Go has codegen for generics, JavaScript has TS for static types, Babel for """macros""". Lots of propositions that are not in JS now can be used with Babel. Python has C extensions.

TypeScript is a different language from JavaScript, and C is a different language from Python, so I don't think those are good examples. Similarly, various macro languages that sit on top of something else are also languages in their own right.

And sure, you can always "fix" a language by designing a derivative higher-level language that transpiles into the old one. In fact, this is a time-honored tradition - C++ was originally just such a transpiler (to C). But the very fact that you have to do this points at the original design deficiencies.

Re: We moved from Pony to Rust

#175

Post by Jweb_Guru »

wyager wrote: post #170
Jweb_Guru wrote: post #167

Earlier quoted context omitted.

> If you write your code in the right way they don’t have to. That’s the point. I recommend you try working through some equality proofs in Coq, first with and then without coqtop / Proof General. I think you may change your mind about this rather rapidly. And many proofs get much more complex than that.

I’ve used (and developed) plenty of proof assistants. Proofs are one very narrow domain where automation is basically a no-brainer. You don’t really lose out from the proof having high semantic arity. With normal code, you do lose out.

I dunno. I think the line between "normal code" and proofs is a lot blurrier than many people make it out to be, and I don't think there's a huge advantage to asking people to run a type checker or inference algorithm in their heads even if you have managed to encode all your program's invariants in the type system (which is impossible or impractical in many languages). I say that as someone who doesn't use an IDE except when I'm forced to: I know I lose out on a lot of productivity because of it, and I don't find that removing the IDE forces me to develop better or more concise code.

Re: We moved from Pony to Rust

#176

Post by crdrost »

notriddle wrote: post #90
sullyj3 wrote: post #84

Earlier quoted context omitted.

Rust is a language nobody uses?

“Nobody” is relative. Rust doesn’t have a lot of users, but it isn’t Pony .

Yeah I was worried about that part giving offense, but the sentiment became a lot longer when shifted from “language that nobody uses” to “language that I can't convince any employers to let me use because they are worried about hiring problems” lol

Re: We moved from Pony to Rust

#177

Post by dleslie »

Zababa wrote: post #172
dleslie wrote: post #161

Earlier quoted context omitted.

... That would be terrible on, say, the Sega Genesis or 32X.

I don't see how it's more terrible than using Nim.

Nim is elegant, relatively safe, and not interpreted; its performance is within a stone's throw of C, and roughly on par with Zig; but with better safety guarantees.

Re: We moved from Pony to Rust

#178

Post by southerntofu »

FpUser wrote: post #147
southerntofu wrote: post #138

Earlier quoted context omitted.

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…

While I use scripting languages when needed my main languages were always compiled with static typing. And I did not need debugger for hacking code. I need debugger mostly for tracing my own code when I have some bugs mostly related to algorithmic errors, not with the program blowing up on me. I did not program in Rust so I can not really judge the language but I doubt that it is so nice and expressive comparatively…

> I need debugger mostly for tracing my own code when I have some bugs mostly related to algorithmic errors, not with the program blowing up on me.

Then you're a much better programmer than i am! :)

For algo debugging i just use pen and paper. For more surprising results, print statements are usually all i need.

> suddenly the types of bugs I am hunting will magically disappear

Maybe not, but i'd recommend to give it a try, if only to offer a different perspective. For me personally, strict and expressive enums, mandatory error handling and Option/Result types as language core features (among others) have definitely eliminated most bugs i write. Well i still write those bugs, but at least the compiler doesn't compile like everything is fine, and instead lets me know why my program is flawed.

Post reply on HN