7 ms·

I disagree. Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want. This situation is slowly improving with t

by fooker 4y ago

I disagree. Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want. This situation is slowly improving with the compiler getting better and better. Then there is some annoying macro usage. Some Rust code looks truly alien.

hamilyon2 4y ago
Is rust code heavily seasoned with unsafe keyword really that hard to prototype in? Is it meaningfully harder than c++ in this regard?
- spoiler 4y ago
  I assume they didn't mean compared to C++. If anything, saying prototyping in C++ is easier than Rust is beyond ludicrous even if you're a seasoned C++ developer. I'd have an easier time prototyping in Rust than C++, and I've been writing C++ for 10 years and Rust for a little over a year. However, prototype in something like Ruby (or even TypeScript, and some people mentioned Elixir) is in a different universe compared to C++ or Rust. Like, it's not even a "fair fight" to compare it meaningfully.
  - cozzyd 4y ago
    Well there are C++ repls available. Maybe there are rust ones too?
  - GuB-42 4y ago
    What makes Rust better at rapid prototyping? Cargo? I find that modern C++ "kitchen sink" approach to features makes it good for rapid prototyping, a bit like Perl on the dynamic side. It won't force you into a specific approach, pick the one that gets you there the fastest. Use raw pointers and malloc(), or use fancy smart pointers and RAII, your choice, you can also do both, you have exceptions, you have goto, you can write(), printf() and cout, you have classes and lambdas and (multiple) inheritance and traits. More options are better for rapid prototyping. Also, C++ is the most popular language for competitive programming, you can't get more "rapid" than that.
- craftit 4y ago
  From what I've experimented with so far the biggest barrier to using rust was having a mature ecosystem of libraries to use. This is changing though!
- oconnor663 4y ago
  If I wanted to just blast out something quick and dirty, I don't think I'd reach for `unsafe`. It's syntactically inconvenient, with lots of `(*foo).bar` and `MaybeUninit`. And I don't think I could be happy with a prototype that's blatantly full of UB, so for me it would take more effort rather than less. Now that I say that, I guess someone could write an "unsound helper functions" library that helps you write code full of UB conveniently. It could be an interesting thought experiment. But I don't think the community would be very happy about it...
lubesGordi 4y ago
Rust isn't a prototyping language.
- jjnoakes 4y ago
  Says who? I love prototyping things in Rust.
  - deleted 4y ago
    [deleted]
  - verdagon 4y ago
    Both viewpoints make sense; whether Rust is good for prototyping depends on the domain. If it fits the borrow checker well (like in CLI apps, stateless servers, data transformation) then the borrow checker fits beautifully and seamlessly. In other settings (complex turn-based games, some compilers, GUI), the borrow checker can cause some artificial complexity and prototyping slowdowns compared to other paradigms.
    - jjnoakes 4y ago
      I guess it depends on your point of view. For me, having Rust catch issues even when prototyping makes me enjoy prototyping more. I absolutely hate (even when prototyping) when I try to run something, it chugs along for a bit, and then hits a runtime error due to some stupid typo. In fact I like Rust for prototyping precisely because I don't yet have tests, and the extra compiler diligence frees me to focus on the prototype.
      - menaerus 4y ago
        > and then hits a runtime error due to some stupid typo. I don't think that the parent comment implied prototyping in dynamic languages but rather in statically compiled ones. FWIW in C or C++ you don't have to do as much code gymnastics to satisfy the compiler so consequently prototyping is both faster and easier when compared to Rust.
xiphias2 4y ago
I agree with the macro part. I have seen people use macros instead of functions as a way to escape the type system. But it's not a problem that comes up with C++ programmers.
- goatlover 4y ago
  Don't templates provide similar functionality in C++?
  - xiphias2 4y ago
    Templates are needed in C++ for compile time polymorphism. Rust is able to do that without macros with generics.
qalmakka 4y ago
It does because it repays you with extremely fast and safe code. Prototyping and performance are two concepts that do not mix. I've seen way too many half baked attempts at making prototypes fast that do end up in complete rewrites.
pantulis 4y ago
"Some Rust code looks truly alien." Go tell that to a C++ programmer! ;)
gpderetta 4y ago
>Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want. I'm not a rust programmer, but I guess that's an issue if you come from a dynamic language, not from c++.
- pdimitar 4y ago
  Yeah, sadly it is. With e.g. Elixir I can literally get into a REPL and prototype my solution in minutes, right there on the spot, and then just copy a few lines from it and have the solution be 90% done (minus tests, of course). With Go and Rust I have to make a dedicated function somewhere and then have it be called after starting the program. Ain't exactly rocket science but the difference in time to do it and the convenience is still very stark. I love working with Rust for the stability and speed it gives me but the value proposition and daily coding flow are VERY different compared to a dynamic language. With Elixir I am mostly just brain-dumping and stuff happens extremely quickly and fluidly, with Rust I kind of sigh and accept that the next 10 minutes I'll just be writing and writing. Might even zone out and make a dumb mistake because I have to spend more keystrokes and more time to do something I'll do in a minute in Elixir. Maybe it's time to look for snippets support in my editor. Or start asking ChatGPT for them.
  - dhbradshaw 4y ago
    Try using a test -- can stick anywhere and just run code there (push of a button with analyzer in vscode). Almost like embedding a repl into a module for experimentation.
    - pdimitar 4y ago
      Haven't tried but definitely will, thank you!
  - serverholic 4y ago
    See this is what I’m scared about in my current job. We have some people who want to use dynamically typed languages and some who want to use static. I don’t think being able to brain dump code is a good thing and it leads to an unmanageable mess when you have a large codebase. Types are essential as far as I’m concerned, but I constantly have to get into arguments with the dynamic type fans because their “flow” Is being restricted.

by fooker 4y ago

hamilyon2 4y ago

Is rust code heavily seasoned with unsafe keyword really that hard to prototype in? Is it meaningfully harder than c++ in this regard?

spoiler 4y ago
I assume they didn't mean compared to C++. If anything, saying prototyping in C++ is easier than Rust is beyond ludicrous even if you're a seasoned C++ developer. I'd have an easier time prototyping in Rust than C++, and I've been writing C++ for 10 years and Rust for a little over a year. However, prototype in something like Ruby (or even TypeScript, and some people mentioned Elixir) is in a different universe compared to C++ or Rust. Like, it's not even a "fair fight" to compare it meaningfully.
- cozzyd 4y ago
  Well there are C++ repls available. Maybe there are rust ones too?
- GuB-42 4y ago
  What makes Rust better at rapid prototyping? Cargo? I find that modern C++ "kitchen sink" approach to features makes it good for rapid prototyping, a bit like Perl on the dynamic side. It won't force you into a specific approach, pick the one that gets you there the fastest. Use raw pointers and malloc(), or use fancy smart pointers and RAII, your choice, you can also do both, you have exceptions, you have goto, you can write(), printf() and cout, you have classes and lambdas and (multiple) inheritance and traits. More options are better for rapid prototyping. Also, C++ is the most popular language for competitive programming, you can't get more "rapid" than that.
craftit 4y ago
From what I've experimented with so far the biggest barrier to using rust was having a mature ecosystem of libraries to use. This is changing though!
oconnor663 4y ago
If I wanted to just blast out something quick and dirty, I don't think I'd reach for `unsafe`. It's syntactically inconvenient, with lots of `(*foo).bar` and `MaybeUninit`. And I don't think I could be happy with a prototype that's blatantly full of UB, so for me it would take more effort rather than less. Now that I say that, I guess someone could write an "unsound helper functions" library that helps you write code full of UB conveniently. It could be an interesting thought experiment. But I don't think the community would be very happy about it...

lubesGordi 4y ago

Rust isn't a prototyping language.

jjnoakes 4y ago
Says who? I love prototyping things in Rust.
- deleted 4y ago
  [deleted]
- verdagon 4y ago
  Both viewpoints make sense; whether Rust is good for prototyping depends on the domain. If it fits the borrow checker well (like in CLI apps, stateless servers, data transformation) then the borrow checker fits beautifully and seamlessly. In other settings (complex turn-based games, some compilers, GUI), the borrow checker can cause some artificial complexity and prototyping slowdowns compared to other paradigms.
  - jjnoakes 4y ago
    I guess it depends on your point of view. For me, having Rust catch issues even when prototyping makes me enjoy prototyping more. I absolutely hate (even when prototyping) when I try to run something, it chugs along for a bit, and then hits a runtime error due to some stupid typo. In fact I like Rust for prototyping precisely because I don't yet have tests, and the extra compiler diligence frees me to focus on the prototype.
    - menaerus 4y ago
      > and then hits a runtime error due to some stupid typo. I don't think that the parent comment implied prototyping in dynamic languages but rather in statically compiled ones. FWIW in C or C++ you don't have to do as much code gymnastics to satisfy the compiler so consequently prototyping is both faster and easier when compared to Rust.

xiphias2 4y ago

I agree with the macro part. I have seen people use macros instead of functions as a way to escape the type system. But it's not a problem that comes up with C++ programmers.

goatlover 4y ago
Don't templates provide similar functionality in C++?
- xiphias2 4y ago
  Templates are needed in C++ for compile time polymorphism. Rust is able to do that without macros with generics.

qalmakka 4y ago

It does because it repays you with extremely fast and safe code. Prototyping and performance are two concepts that do not mix. I've seen way too many half baked attempts at making prototypes fast that do end up in complete rewrites.

pantulis 4y ago

"Some Rust code looks truly alien." Go tell that to a C++ programmer! ;)

gpderetta 4y ago

>Rust is not difficult because of lifetimes, it just gets in the way of freely prototyping what you want. I'm not a rust programmer, but I guess that's an issue if you come from a dynamic language, not from c++.

pdimitar 4y ago
Yeah, sadly it is. With e.g. Elixir I can literally get into a REPL and prototype my solution in minutes, right there on the spot, and then just copy a few lines from it and have the solution be 90% done (minus tests, of course). With Go and Rust I have to make a dedicated function somewhere and then have it be called after starting the program. Ain't exactly rocket science but the difference in time to do it and the convenience is still very stark. I love working with Rust for the stability and speed it gives me but the value proposition and daily coding flow are VERY different compared to a dynamic language. With Elixir I am mostly just brain-dumping and stuff happens extremely quickly and fluidly, with Rust I kind of sigh and accept that the next 10 minutes I'll just be writing and writing. Might even zone out and make a dumb mistake because I have to spend more keystrokes and more time to do something I'll do in a minute in Elixir. Maybe it's time to look for snippets support in my editor. Or start asking ChatGPT for them.
- dhbradshaw 4y ago
  Try using a test -- can stick anywhere and just run code there (push of a button with analyzer in vscode). Almost like embedding a repl into a module for experimentation.
  - pdimitar 4y ago
    Haven't tried but definitely will, thank you!
- serverholic 4y ago
  See this is what I’m scared about in my current job. We have some people who want to use dynamically typed languages and some who want to use static. I don’t think being able to brain dump code is a good thing and it leads to an unmanageable mess when you have a large codebase. Types are essential as far as I’m concerned, but I constantly have to get into arguments with the dynamic type fans because their “flow” Is being restricted.