5 ms·

While I do get annoyed at JS often, I get just as annoyed by Rust. Sometimes, I really just want to read a CSV and create a Map<String, String> from a few of th

While I do get annoyed at JS often, I get just as annoyed by Rust. Sometimes, I really just want to read a CSV and create a Map<String, String> from a few of the columns. But oh my god if Rust doesn't make that a nightmare. Is it a String? an &str? Do I want to allocate that string on the stack? I won't know the size of it at compile time, so of course not... right? So no to 'static? Give me a nice middle of the road like TypeScript, Kotlin, OCaml/Reason... Rust just goes SO FAR in the other direction that I don't find it a pleasant experience. I get that it's the ULTIMATE in performance, I just always question if I really need it for doing web work.

crazypython 6y ago
Dlang let's you write GC code at first-- let's you allocate a string however you want-- and later convert that into @nogc code, or into GC code with manual deletions. The generational garbage collector will help with deleting strings. Best of both worlds-- fast prototyping, with the ability to drop down for faster code. Furthermore, like interpreted languages, Dlang compiles very fast because the language implementers believe fast compilation is a core goal.
- eloff 6y ago
  I always rather thought D had a lot of good ideas. But it hasn't caught on, and I don't see that changing. If you can't get a job in it ( comparatively), can't find quality libraries for common tasks, and don't have a large user base running into painful edge cases before you do, it's going to be a rough ride.
kgraves 6y ago
To me this is a non issue here, I find Rusts strings far easier than many other languages. (and also safer) Overtime this knowledge becomes second nature to get used to and less of a pain point to grok.
bluejekyll 6y ago
Rust wants the things that are expensive to be obvious. Going from &str to String allocates, so that requires an upfront conversion before use. On the other-hand String has a Deref impl to &str, so you can call any method defined on &str directly from a variable of type String. That doesn’t require any cast, and those methods can be called directly on the variable making it very easy. To me this feels like a good trade off in ergonomics vs. performance.
Yxven 6y ago
I think this Rust complaint is just inexperience. You wanted a Map<String, String>, and that's exactly what you should have made. A String is a convenience wrapper for storing a &str on the heap, so storing a String on the heap is redundant. The other options are for performance concerns, which you haven't mentioned any.
- eloff 6y ago
  Now make it a global thread safe hash map where the keys are references into a mutable memory map that can move it's address (be remapped.) That's currently where rust is making my life miserable today. In C++ this is quite straightforward, albiet full of footguns. Every time I need a static mutable thread safe map in rust for a cache or registry or some such thing, I groan. I have a love hate relationship with rust. I love a lot of things about it, but sometimes I get so fed up with the borrow checker I drop into unsafe and just write the problem off as something better not done safely.
  - Ankhers 6y ago
    Maybe I am misunderstanding your needs, but could you not just use a RwLock[0]? For being global you will need to use the lazy_static[1] crate. Admittedly, I have not tried doing this directly though. [0] https://doc.rust-lang.org/std/sync/struct.RwLock.html https://doc.rust-lang.org/std/sync/struct.RwLock.html [1] https://crates.io/crates/lazy_static https://crates.io/crates/lazy_static
    - eloff 6y ago
      That's part of the solution I'm working towards. I'm using 'static references for the map keys, but they're not really 'static, so I use unsafe transmute to create them and I rebuild the map when the memory map changes to a different address.
kccqzy 6y ago
Rust was originally designed to be a systems programming language to replace C++. When you have experience in languages like C++, all of the questions you asked have extremely obvious answers, to the point of being an automatic decision.

crazypython 6y ago

Dlang let's you write GC code at first-- let's you allocate a string however you want-- and later convert that into @nogc code, or into GC code with manual deletions. The generational garbage collector will help with deleting strings. Best of both worlds-- fast prototyping, with the ability to drop down for faster code. Furthermore, like interpreted languages, Dlang compiles very fast because the language implementers believe fast compilation is a core goal.

eloff 6y ago
I always rather thought D had a lot of good ideas. But it hasn't caught on, and I don't see that changing. If you can't get a job in it ( comparatively), can't find quality libraries for common tasks, and don't have a large user base running into painful edge cases before you do, it's going to be a rough ride.

kgraves 6y ago

To me this is a non issue here, I find Rusts strings far easier than many other languages. (and also safer) Overtime this knowledge becomes second nature to get used to and less of a pain point to grok.

bluejekyll 6y ago

Rust wants the things that are expensive to be obvious. Going from &str to String allocates, so that requires an upfront conversion before use. On the other-hand String has a Deref impl to &str, so you can call any method defined on &str directly from a variable of type String. That doesn’t require any cast, and those methods can be called directly on the variable making it very easy. To me this feels like a good trade off in ergonomics vs. performance.

Yxven 6y ago

I think this Rust complaint is just inexperience. You wanted a Map<String, String>, and that's exactly what you should have made. A String is a convenience wrapper for storing a &str on the heap, so storing a String on the heap is redundant. The other options are for performance concerns, which you haven't mentioned any.

eloff 6y ago
Now make it a global thread safe hash map where the keys are references into a mutable memory map that can move it's address (be remapped.) That's currently where rust is making my life miserable today. In C++ this is quite straightforward, albiet full of footguns. Every time I need a static mutable thread safe map in rust for a cache or registry or some such thing, I groan. I have a love hate relationship with rust. I love a lot of things about it, but sometimes I get so fed up with the borrow checker I drop into unsafe and just write the problem off as something better not done safely.
- Ankhers 6y ago
  Maybe I am misunderstanding your needs, but could you not just use a RwLock[0]? For being global you will need to use the lazy_static[1] crate. Admittedly, I have not tried doing this directly though. [0] https://doc.rust-lang.org/std/sync/struct.RwLock.html https://doc.rust-lang.org/std/sync/struct.RwLock.html [1] https://crates.io/crates/lazy_static https://crates.io/crates/lazy_static
  - eloff 6y ago
    That's part of the solution I'm working towards. I'm using 'static references for the map keys, but they're not really 'static, so I use unsafe transmute to create them and I rebuild the map when the memory map changes to a different address.

kccqzy 6y ago

Rust was originally designed to be a systems programming language to replace C++. When you have experience in languages like C++, all of the questions you asked have extremely obvious answers, to the point of being an automatic decision.