251–260 of 283 posts
" When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. " Yeah... On my last C++ project, one very productive co-worker kept disabling -Wall, etc., be…
He-he
" When you implement an algorithm using C++, you can write it down without one second of pause, but you can’t do that in Rust. As the compiler will stop you from borrow checking or something unsafe again and again, you are being distracted constantly by focusing on the language itself instead of the problem you are solving. " Yeah... On my last C++ project, one very productive co-worker kept disabling -Wall, etc., be…
Depending on the situation a write unsafe fast fix later maybe the more economic approach. Especially if the code is more exploratory, changes a lot and large parts will be finally discarded.
Earlier quoted context omitted.
> As the author points out, if you’re used to writing C or C++, it’s going to take a while before responding to the borrow checker is second nature I see these comments and it feels so foreign to my experience. The borrow checker was second nature to me because of my C++ experience. These were things I already had to juggle mentally. On rare occasions, it complained about something that I could prove was valid but I…
Were you trying to write GUI code? Because of my experience it was also plain sailing, while doing the tutorials and exercises from the books I bought. Then I tried to make a GUI application in Gtk-rs and had lots of fun with event handler callbacks, which are the main reason why Relm was created.
But I find the standard approaches to GUI broken: inheritance and shared mutable state. i think Rust does a service by highlighting the brittleness of this pattern via syntax / libraries.
I've not dealt with elm-like GUIs. Probably my natural inclination would be to use an actor framework. And to be clear, I am speaking from having written non-trivial GUIs with both GTK and Qt (I miss the Maemo days).
This is why I gave up on Haskell. Code is still (currently) written by humans. Sure the code was more terse, but I had to expend more time thinking about every tiny piece of that terse code. I've been programming for 36 years. Just as some people think out loud, I think by shaping and reshaping code. Top-down doesn't work for me, although I know there are other developers for whom it does. I like to build bottom-up b…
Even with a top down approach you can end up with insane type level machinations or group/category theory that only the best Haskell developer can decode. Sure it's elegant, but damn near indecipherable.
Yeah, Rust seems to have an ergonomics problem and the only response we are seeing is "you're holding it wrong". I would rather work on interesting projects than use interesting tools for not-so-interesting projects. So far, for things I am interested in, C++ seems to be the tool of choice.
We had such a huge push last year for ergonomics that there's a segment of the community that's still upset about it. We're very interested in improving them; if you have good ideas about it, you'll get heard out.
Earlier quoted context omitted.
That's a decent attempt at suppressing OP's message, but the thing which makes all of the above irrelevant is that C and C++ developers are the main groups of developers Rust is targeting. If they can't use the language, the Rust community should perhaps listen to them. Or should have listened to them 10 years ago, because let's be frank: the friction is coming from the fact that Rust can't be changed any more so tha…
> the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. What is your proposal, specifically? It's not that we weren't listening to C++ programmers 10 years ago. We put a ton of effort into making Rust as easy to use as possible. Rather, it's that the problem of memory safety without GC is fundamentally hard. If I could wave a ma…
Earlier quoted context omitted.
Yet Julia and Chapel are winning hearts of HPC researchers. Java is not the only language with GC, there are others which offer control over NUMA, SIMD, cache locality, like .NET Native with C# 7/8, or D as two possible examples.
But the GC is frowned upon a lot in the D community. A lot of D programmers try to make everything they write @nogc.
A vocal sub-community of D programmers argue for @nogc due to GC phobia, as ex-C++ devs, and a GC implementation found lacking. A situation that might improve with the recently released GC pluggable API and a new precise tracing GC.
Many devs that prototype their apps in D without doing premature memory optimizations, end up realizing that for their use case it actually good enough.
Earlier quoted context omitted.
> the friction is coming from the fact that Rust can't be changed any more so that it becomes as ergonomic as other languages people are used to. What is your proposal, specifically? It's not that we weren't listening to C++ programmers 10 years ago. We put a ton of effort into making Rust as easy to use as possible. Rather, it's that the problem of memory safety without GC is fundamentally hard. If I could wave a ma…
Speaking out of genuine ignorance here...if the only ways to get memory safety without GC, how does Swift or Objective C do it with ARC?
Yeah, Rust seems to have an ergonomics problem and the only response we are seeing is "you're holding it wrong". I would rather work on interesting projects than use interesting tools for not-so-interesting projects. So far, for things I am interested in, C++ seems to be the tool of choice.
> the only response we are seeing is "you're holding it wrong". We had such a huge push last year for ergonomics that there's a segment of the community that's still upset about it. We're very interested in improving them; if you have good ideas about it, you'll get heard out.
/r/rust thread: https://www.reddit.com/r/rust/comments/b0erei/why_i_rewrote_... You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community..
> You'll notice the top rated comment, & majority of comments, agrees with their decision to switch to C++. Yet we'll persist that Rust is an elitist community. Having read those comments, many of them can be best characterized as politely dismissive, e.g. from the top rated comment " If the author is more comfortable writing this code in C++ it makes sense to use it, but I feel like there is a long way to go to make…