|
|
Log in / Subscribe / Register

Are those languages really more suitable for fast prototyping?

Are those languages really more suitable for fast prototyping?

Posted Oct 29, 2024 8:51 UTC (Tue) by taladar (subscriber, #68407)
Parent article: The performance of the Rust compiler

> The Rust compiler's design causes slow compilation, Li said, when compared to languages with implementations suitable for fast prototyping such as Python or Go.

I question this commonly made statement.

When fast prototyping you usually do not have huge programs.

You also do not know the structure of your program very well so a compiler that checks for you that you don't use your data structures or functions wrong saves a lot of time when compared to only figuring that out when you reach that point in the code at runtime, even if the compiler run is slow compared to other languages.

When prototyping you also want to later be able to read the resulting code to turn it into the actual production implementation, spamming copy&paste code all over the place a la Go error handling or similarly verbose, less expressive languages seems counter-productive to that goal.

And last but not least, you wouldn't want to prototype in a language that is fundamentally very different from one suitable for the final implementation, so the whole idea to prototype in one language and then write the actual implementation in another is questionable at best.


to post comments

Are those languages really more suitable for fast prototyping?

Posted Oct 29, 2024 10:07 UTC (Tue) by aragilar (subscriber, #122569) [Link] (2 responses)

It naturally depends on what you are prototyping, but as far as I know no-one has written a rust REPL, so being able to get instant feedback (because you just ran the code you're going to run) is much better than waiting some amount of time for the compiler to finish. I've done this numerous times in Python, and if you're willing to install tools like bpython or ipython where you can dump your session to a file, and with a bit of cleanup you have an initial working version.

As for prototyping in one (slow, interpreted) language and then implement the core algorithms (or all of it) in a fast language, this is pretty common in the scientific computing space, as it helps with testing and validation of the fast code.

Are those languages really more suitable for fast prototyping?

Posted Oct 30, 2024 9:15 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

> as far as I know no-one has written a rust REPL

There are a few projects for that kind of thing but I haven't tried them, just came across them the other day when looking for something unrelated.

https://lib.rs/crates/irust

https://lib.rs/crates/thag_rs

Are those languages really more suitable for fast prototyping?

Posted Oct 31, 2024 9:50 UTC (Thu) by moltonel (subscriber, #45207) [Link]

I sometimes use https://github.com/evcxr/evcxr, it even has a jupyter kernel. Another option is https://play.rust-lang.org/ (which can be run locally as well), it's not a repl but it's great for quick experiments.

Are those languages really more suitable for fast prototyping?

Posted Oct 29, 2024 10:09 UTC (Tue) by farnz (subscriber, #17727) [Link] (2 responses)

It matches my experience of working in Rust and Python; I prefer to write in Rust, because I'm rarely genuinely writing a prototype, but rather writing "version 0" of a program, and I will not normally be given time to rewrite in another language later. But if I was genuinely allowed to prototype things most of the time, I'd be writing the prototype to throw away in Python, and writing "version 0" in Rust.

Yesterday, I wrote a short Rust program (10 lines of my code, plus dependencies) to create a PNG representing squared paper. It took about 15 minutes computer time (and about 30 minutes elapsed time), of which about 5 was spent waiting on the compiler to compile my code as the person I was doing this for changed their mind about what the PNG should look like (colour/greyscale, line thickness, square size).

Today, after reading your comment, I redid the same work in Python, including making the same changes; it took under 10 minutes, because changes to my code were near-instant.

Neither program did a significant amount of compute (after all, when prototyping, you don't work on large data sets if you can avoid it), both came up with the same result. The Rust program uses significantly less CPU time when compiled in the debug profile, but neither of them used enough CPU time to make a difference to me as the person running the code. And the Rust program is more robust against errors if I come back round to it - e.g. instead of using a naming convention, as in Python, Rust's type system will prevent me from modifying constants, or assigning to the wrong thing - but I'm very unlikely to ever run this code ever again.

I still used Rust first, because I'm habituated to working in environments where "never run this code again" is a dangerous statement, but if Rust could build faster, it'd also have been the faster language to use. Recompiling my code, there are two things that would speed it up considerably:

  1. Python used precompiled dependencies for PyPNG, and thus didn't cost me 20 seconds just building dependencies.
  2. Python's runtime was about 1 second for each experiment; Rust in dev profile took about 250 ms to determine that no building needed to take place, and about 1 second (according to cargo build) to build and link my program after a change to a constant. On the other hand, Rust takes about 800 ms to run in dev profile, where Python took 1 second - and just for fun, I rebuilt in release profile, which ran in 11 ms, but increased the "change to a constant" time to about 2 seconds.

If Rust could get the wall-clock time for a small change down below 200 ms, it'd be faster than Python for prototyping here on this laptop. And that's not impossible with parallelism; for most of the build time, I have only one CPU thread of the 16 on this laptop saturated; if Rust in dev profile could saturate 5 CPU threads on average, then Rust in dev profile (1 CPU-second) would have a faster edit/compile/run loop than Python does.

And note that I'm mostly ignoring the time it takes to build dependencies here; at least in theory, Rust could eliminate that 20 seconds of highly parallel work by downloading pre-compiled artefacts instead of building from scratch.

Are those languages really more suitable for fast prototyping?

Posted Oct 30, 2024 9:19 UTC (Wed) by taladar (subscriber, #68407) [Link] (1 responses)

Okay, a batch program like that where you run it and it immediately does what you want is about the optimal case for Python though since it minimizes runtime for testing.

If you have some sort of GUI or web app where you need to navigate to your functionality to test each time those few seconds of compilation time are quickly dwarfed by that repetitive walltime-overhead during the test run.

Are those languages really more suitable for fast prototyping?

Posted Oct 30, 2024 13:41 UTC (Wed) by farnz (subscriber, #17727) [Link]

But by the time I'm putting together a GUI that needs testing, and navigation to functionality, Python is still faster because I run the prototype inside pdb or similar, and tweak it "live", instead of having to recompile and navigate again. Once I've finished prototyping, I might have to restart and re-navigate a few times, but that's when I'm going from the prototype to version 0.

Are those languages really more suitable for fast prototyping?

Posted Oct 29, 2024 18:11 UTC (Tue) by Paf (subscriber, #91811) [Link] (1 responses)

I regularly prototype small changes to a large program, so compiler speed is a concern (or at least an annoyance) for me. I think lots of folks who work on large projects are the same?

Are those languages really more suitable for fast prototyping?

Posted Oct 30, 2024 9:21 UTC (Wed) by taladar (subscriber, #68407) [Link]

I don't think changes to existing programs are the type of prototyping people mean when they say they would choose one language or the other for prototyping. That sort of implies that you do not have to stay compatible with an existing code base.


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds