| ▲ | whatyesaid 18 hours ago |
| Rust is slow to develop and prototype in. It's good if you're a big company not the average Joe. We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled. |
|
| ▲ | rtpg 17 hours ago | parent | next [-] |
| Is C++ easier to prototype in? Of course there's the borrow checker, but I feel like Rust at least shows up with some expressiveness niceties that gets you some productivity wins in the prototyping stage. Though really I suppose "comfort with a language " is such a big factor, seeing people really belt out stuff in C is always a bit impressive to me (yeah yeah, bug filled etc) |
| |
| ▲ | actionfromafar 17 hours ago | parent | next [-] | | C forces me to do the barest minimum and avoid prematurely astronaut architect everything. That often makes it faster to prototype in. Not because I can do more. But because I have to reframe the problem so it fits. But large codebases in C are tedious to work with and slow to refactor. | |
| ▲ | catlifeonmars 17 hours ago | parent | prev [-] | | > Is C++ easier to prototype in? Maybe if you’ve already got the toolchain set up and boilerplate templates etc. |
|
|
| ▲ | devnullbrain 18 hours ago | parent | prev | next [-] |
| If the borrow checker slows you down, the C++ you write instead would just be buggy |
| |
| ▲ | etyp 17 hours ago | parent | next [-] | | Safe programs extend beyond those that Rust's borrow checker accepts though. There is more than one way to make a program safe, not all of them would be valid Rust. | | |
| ▲ | goku12 14 hours ago | parent [-] | | There are more than one way to achieve safety in Rust. Two more, infact - runtime safety and fully manual (unsafe with some additional work). Runtime safety is a very fast way to overcome the resistance offered by the borrow checker. While it does slowdown the code a little bit, that should be pretty fine for prototyping. A more careful use of runtime checks will still give you a program more performant than in most other languages. | | |
| ▲ | dzaima 11 hours ago | parent [-] | | Runtime safety still comes with a good amount of complication source-wise, having to spam RefCell/Arc everywhere, and whatever derefs/.get()s they necessitate, and probably a different approach to passing references. Refactoring either that or unsafe away after being done with prototyping isn't trivial, if even possible without entirely rethinking the approach. | | |
| ▲ | goku12 8 hours ago | parent [-] | | Isn't that a bit dramatic? How much extra code or care do you need to implement runtime safety checks? This isn't the first time I hear these sort of arguments either. It gives the impression that a crowd is making up one exaggeration after another to drive the perception that Rust is somehow not suitable for general purpose programming. | | |
| ▲ | dzaima 7 hours ago | parent [-] | | It is a bit dramatic, though less so for some approaches to programming. And of course prototyping is very different from general purpose programming. With Rust, if you really want the borrow checker to actually never bother you, you really do just have to spam the dynamically-checked wrappers everywhere; when in the groove, having to stop and wrap some existing field (or its holder) and all its usages just to be able to mutate it because you previously didn't think you'd need to is just completely awful if you don't find that "fun". Whereas in C, if you want to mutate a thing, you can always do so whenever with no concerns (whereas using unsafe to mutate a field of a &Thing in Rust is just UB, though maybe you can get away with using unoptimized builds for a bit) and deal with previous code that may have been written with the assumption it wouldn't change Later™ (but, importantly, still allowing properly testing the modified thing, and perhaps the entire project). Want to change the lifetime of a thing? Just move where you free it, no need to ever change lifetime args across a dozen functions. And in Java the most anything may take is removing a "final" on a field. |
|
|
|
| |
| ▲ | tylersmith 18 hours ago | parent | prev [-] | | [flagged] | | |
| ▲ | mkipper 17 hours ago | parent | next [-] | | If you remove "develop" from the OP and stick to "prototype", it's a totally valid criticism, and you come across as a condescending jerk if you suggest that software can't be "working" unless it's bug-free. I can't count the number of times I've wanted to try out some library and whipped up a quick prototype app in an hour or two to play around with it. I don't give a damn if that app is memory safe, handles signals safely, satisfies arcane aliasing rules or deals with any of the other million footguns in C/C++. I'm happy if it compiles and does what I want it to. I deal with that stuff when I inevitably rewrite it from scratch the next day and have an actual design in mind. FWIW, I'm comfortable enough with Rust that I would personally choose it over C or C++ for most stuff like this these days since the standard library makes a lot of boilerplate prototyping stuff (e.g. setting up a project, pulling in dependencies, handling files and I/O) much more pleasant. But suggesting that anyone who writes unsafe C/C++ in any context doesn't know what they're doing is ridiculous. | | |
| ▲ | truculent 17 hours ago | parent [-] | | What trade-offs are you typically evaluating with the prototype? Have you ever found that decision harder to make because of shortcuts etc taken during prototype? | | |
| ▲ | mkipper 16 hours ago | parent [-] | | Like everything, “it depends”. I used to work on a product that handled video, and I would regularly spin up prototypes where I’d stitch together gstreamer pipelines with different plugins to try things out. For reasons that aren’t important, it was easier to use an app linked against the gstreamer libraries than to use its CLI. There were all sorts of ways I’d evaluate some plugin I was trying out. Maybe I’d look at some test pattern for artifacts. Maybe I’d measure latency. Maybe I’d profile its resource usage. But I can confidently say that in all of those cases, the memory safety of the 100 lines of C++ code that told gstreamer how to plug things together had absolutely no impact on what I was evaluating. Sometimes the code you’re writing is basically unrelated to what you’re interested in from a prototype. |
|
| |
| ▲ | catlifeonmars 17 hours ago | parent | prev [-] | | Working software doesn’t always have to be correct or safe. This is highly use case dependent. Rust’s guarantees aren’t free, it comes with a handful of tradeoffs, such as learning curve, implementation speed, (this one is personally annoying) compilation speed, and portability. I’m a huge proponent of using the right language for the job. Sometimes rust is the obvious choice, sometimes it’s Python, Go, Lua, Java, Prolog, C, brainfuck etc. | | |
| ▲ | pdimitar 16 hours ago | parent | next [-] | | > Working software doesn’t always have to be correct or safe. I feel like I am missing some very obvious point of yours because that statement in isolation I cannot agree with (I've read the rest of your comment and still can't find the extra context). Can you clarify? | |
| ▲ | tylersmith 17 hours ago | parent | prev [-] | | [flagged] | | |
|
|
|
|
| ▲ | AlotOfReading 18 hours ago | parent | prev | next [-] |
| Isn't that just D? No one uses D not because it's a bad language, but because the actual language isn't nearly as important for adoption as the community behind it. |
|
| ▲ | redman25 17 hours ago | parent | prev | next [-] |
| Rust isn’t too bad if you throw clones everywhere. Otherwise, you might as well use a garbage collected language. |
|
| ▲ | Philpax 18 hours ago | parent | prev | next [-] |
| If it's optional, people are unlikely to use it, and we'll be back at square one again regarding pervasive memory safety issues. That being said, keep an eye on Carbon. |
|
| ▲ | dralley 16 hours ago | parent | prev | next [-] |
| Prototype, sure. Develop? Debatable. At a certain scale of project, all the static guarantees become quite helpful. And a "prototype" written in Rust is often much closer to production-ready than you might think. Rust makes it easier to see which corners you've been cutting than most languages. |
|
| ▲ | stephen_g 17 hours ago | parent | prev | next [-] |
| Apple is positioning Swift as this (and are also moving it from Apple's space on Github etc. into its own and gradually trying to build more of a community), so I wonder if it will catch on more. If people are already using it in the app space, it might be able to branch out into other areas. Over the last year and a bit they've also been working on strong C++ interop to be able to start using it in their own projects without having to do rewrites, and also better cross-platform and static linking support on Linux which could all make it a lot more attractive. (For context, like Rust, Swift is both memory safe and data-race safe) |
| |
| ▲ | n144q 17 hours ago | parent [-] | | Swift uses garbage collection (I know, arc, but that's still garbage collection), so it more or less is in the same category as Go. And I don't see people choosing Swift over Go any time soon. C++ and Rust are a different thing. | | |
| ▲ | mikestew 13 hours ago | parent [-] | | Swift uses garbage collection (I know, arc, but that's still garbage collection) That’s simply not true, starting with ARC being compile-time and GC being run-time. |
|
|
|
| ▲ | linhns 16 hours ago | parent | prev [-] |
| > We need a better C++ ("systems") base language that could have an optional borrow checker or bounded model checker enabled. Are you describing Rust? |
