Hacker News Reader

Comment by nobleach | Hacker News Reader

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.

View on HN

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.

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.

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 [1] https://crates.io/crates/lazy_static

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.

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.

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.

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.

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.

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.

Reply on news.ycombinator.com