Rust isn't great for prototyping?
I disagree, but I'd love to hear people's thoughts.
https://corrode.dev/blog/prototyping/
[#]rustlang #rust
=> More informations about this toot | More toots from mre@mastodon.social
@mre There is one thing missing in Rust- give me faster compile and link times and I will be happy. Especially linking is taking too long on Windows for incremental builds. The most annoying part of working with bevy for me.
And yeah- when in prototyping phase don't worry too much and use expect and clone where you want, identify later when you need to change it ;) This is why I have this sticker on my mac :P
=> More informations about this toot | More toots from MevLyshkin@mastodon.gamedev.place
@MevLyshkin oh, that's a nice sticker!
Yeah, the compile times... I agree. Tried Bevy lately, and it's been an issue. I'm assuming you already optimized compile-times?
I.e. removed unused features, split up your code into separate crates (if possible), etc.?
Did you profile the build? It's pretty easy: https://corrode.dev/blog/tips-for-faster-rust-compile-times/#find-the-slow-crate-in-your-codebase
=> More informations about this toot | More toots from mre@mastodon.social
@mre Nice list! I did know about most of it, next thing I am going to do is setup sccache, but from that article I see that also it can be a small difference for my case.
=> More informations about this toot | More toots from MevLyshkin@mastodon.gamedev.place
@MevLyshkin yeah, that might be worth a try.
Bevy is very heavy on generics. If monomorphization turns out to be a bottleneck for your use-case, you can try to wrap the hot generic in a non-generic function.
Here's what I mean: https://users.rust-lang.org/t/whats-the-name-of-this-technique-for-cutting-down-compile-times-from-monomorphization/89172
=> More informations about this toot | More toots from mre@mastodon.social
@mre Great post, I read some parts and skimmed over others. I happen to agree on. I also avoid references, and instead use structs with String, i32, Vec, ... avoid life times, and use also that type-hinting in VSCode. Even in my tiny libraries I avoid life-times if I can, owning the data isn't huge problem if you target is desktop machines and not embedded systems.
=> More informations about this toot | More toots from Ciantic@twit.social
@Ciantic yup, I agree. Basically this: https://corrode.dev/blog/lifetimes/
=> More informations about this toot | More toots from mre@mastodon.social
@mre
Well, you shouldn't use languages that are good for prototyping, you should write the prototype in the language you intend to use in the end. The prototypes tend to get more and more advanced and suddenly they have become the product... only written in a language suitable for prototyping (which is rarely languages that are suitable for stable products you need to maintain).
=> More informations about this toot | More toots from snaggen@mastodon.nu
@snaggen yup, I touch on that in the article.
=> More informations about this toot | More toots from mre@mastodon.social
@mre So, you say I should actually read the article... is that what you are saying 😀
=> More informations about this toot | More toots from snaggen@mastodon.nu
@snaggen At least I'd be thankful for feedback, yes. 🙃
=> More informations about this toot | More toots from mre@mastodon.social
@mre I agree to disagree.😜
See my experience in this thread:
https://floss.social/@janriemer/112151726590695992
=> More informations about this toot | More toots from janriemer@floss.social
@mre Very nice article!
However I think your comparison with Python is not fair since you haven't taken into account the optional static typing Python now has.
It used to be crude and clunky, but in newer Python version it is simply a total blessing (this and the introduction of Rust style match)
In fact optional static typing is even better for prototyping since you can just unplug it for the 1% dark-magic-bit-convenient part of your code ;-)
=> More informations about this toot | More toots from touilleMan@mastodon.gamedev.place
@mre on top of that the dynamic feature of Python makes its debugger much better than what Rust has (e.g. a UUID in Rust appears in gdb as an array of U8, while in Python __repr__ trivially displays a hex representation as you would expect)
So I would say you definitely want to prototype in Python as long as you can get away with it!
This is especially true since, should you need performances (spoiler: you likely won't ^^), PyO3 allows you to write extensions in Rust very easily 🦀
=> More informations about this toot | More toots from touilleMan@mastodon.gamedev.place
@mre However there are cases when Python is a no go from the start 😭
For instance mobile application (though this is improving) or library aimed at being used from multiple languages or constrained environments
For those cases Rust definitely shines compared to the alternative (basically C/C++), and I find the advices in your article spot on regarding the philosophy ones should have to avoid the constant low-level language pitfall of leaning toward optimisation at every design choice 👍
=> More informations about this toot | More toots from touilleMan@mastodon.gamedev.place
@touilleMan thanks for the feedback and for sharing your thoughts. Gradual typing is certainly a great improvement. Last time I used it, I couldn't express all constraints that I wanted, but it's been a while. The tooling was also still a bit rough around the edges. Has that changed?
=> More informations about this toot | More toots from mre@mastodon.social
@mre the biggest changes for me are:
In a nutshell it is very close to the level of expressiveness Rust offers ;-)
In the end the only thing I miss from Rust is the fact exceptions are outside of the type system
=> More informations about this toot | More toots from touilleMan@mastodon.gamedev.place
@touilleMan that's amazing. I didn't know about any of that, but may I suggest to put it into a blog post? Perhaps it would help others.
=> More informations about this toot | More toots from mre@mastodon.social
@mre
(I can't speak concretely about Rust in particular because I'm just starting to learn it, but I do have a lot of experience with another extremely strongly typed language that heavily prioritizes integrity (Ada) so I feel I can speak in general.)
The ease of writing has been a perennial debate between static and dynamic typing but for the most part I think it's a bit fallacious. If you actually understand the type system of a static language then it's really not hard at all to prototype things, since you can pretty reliably predict ahead-of-time what the best way to structure the types and code is in a way that's extensible/refactorable. And I think the benefit of seeing many issues at compile-time rather than being pushed to only showing up at runtime when that specific codepath runs.
And I think a lot of it really has mostly to do with editor support and tooling (which is a few of your points) rather than the language itself. Ada definitely got more convenient to write once an LSP server was written for it.
=> More informations about this toot | More toots from nytpu@tilde.zone
@mre
Although I will say that prototyping (or general development) in any language static or dynamic pales in comparison with Common Lisp.
I'm convinced that the REPL workflow—specifically in Lisp with its tooling, even though other languages nominally have “a REPL”—is just about the most convenient and clean experience that is possible to have with how modern computers and programming languages are expected to work (I can elaborate excessively more if anyone cares). And like with your point about using an IDE with Rust, most of that is from Lisp's editor support (SLIME/SWANK) rather than the language itself.
Although the SBCL implementation of CL has type declarations and good type inference so it will warn you at compile time if it sees you using a value in a way conflicting with its declared/inferred type.
=> More informations about this toot | More toots from nytpu@tilde.zone
@nytpu that's nice to hear. I only once played around with CL. I have some limited Haskell experience, though. Can't really say if the prototyping experience is similar.
What would hold me back in a purely functional programming environment would be my way of thinking that is still rooted in OOP.
So modeling things would take longer, but I assume some training and better tooling would help alleviate that.
=> More informations about this toot | More toots from mre@mastodon.social
@mre great post! I actually used to believe Rust was bad for rapid development of new projects (avoiding prototype since in some circles that explicitly means disposable; for that I’d say Python absolutely wins). But I’ve changed my mind in the past 6 months or so. (I’ve been writing Rust since 2018 professionally for context.)
=> More informations about this toot | More toots from ianthetechie@fosstodon.org
@ianthetechie yeah, same here. It's an acquired taste. ^^
It takes some time to sink in, but the goal of rapid prototyping is not to type out a prototype as quickly as possible, but to make sure that it reflects the real-world problem. It's a good thing to catch issues early (i.e. thanks to a stronger type system or a helpful compiler). Python didn't give me the same developer experience while working on new projects beyond a certain stage.
=> More informations about this toot | More toots from mre@mastodon.social
@mre
I've been doing some prototyping in Rust recently and I mostly agree.
One challenge is that it just feels wrong having a bunch of Clone, unwrap, Arc etc. that I know could be avoided. Of course rationally, this is no less efficient than its Python alternative.
=> More informations about this toot | More toots from tschundler@leds.social
@tschundler yeah, exactly, but that's the point: since all of these can be grepped for (i.e. they are explicit), you can later go and clean them up. I do that all the time.
In Python, I would have to know when a function throws an exception; I cannot grep for that. The result is a false sense of security because nothing screams "danger".
=> More informations about this toot | More toots from mre@mastodon.social This content has been proxied by September (3851b).Proxy Information
text/gemini