4 ms·
I also think the logic is flawed. Usually I see comments like this from people who think "Frontend is easy, backend is hard" and then you look at the frontend
by lampe3 5y ago
I also think the logic is flawed.
Usually I see comments like this from people who think "Frontend is easy, backend is hard" and then you look at the frontend code and you scream in pain.
Its not like you can not write bad code in Rust. Rust has for example 6 String types. You can also write unsafe rust code. There were example in the past were major Lib's did it just to make it faster.
Also the rust frontend eco system has a very low maturity. So you probably will be writing a lot of stuff on your own (what script kiddies do because they think they can do it better).
If for you it is important to have someone which is not a script kiddie then you could also go for someone who understands RxJS and Angular. This would also "filter".
I'm not sure how many people you will find with good rust skills and good UI/UX skills. If this is not important then go for it.
- iudqnolq 5y agoSix? I can think of String (owned bag of utf-8 bytes), &str (reference to utf-8 bytes), and OsString (potentially non utf-8 depending on your platform, used for ffi). Some people say Cow<str> is a string type, but I think it's better thought of as a genetic type you often use with strings.
- steveklabnik 5y agoPeople say "Rust has six string types" but what they mean is "the standard library has six string types". Rust-the-language has one string type: str. The standard library also has: * String * OsString / OsStr * CString / CStr if people really want to make it look big, they also include PathBuf/Path and Cow<str>.
- deleted 5y ago[deleted]
- iudqnolq 5y agoThanks! I'm definitely often guilty of conflating the stdblib and the language. I prefer to think of it as programers have used strings to represent too many non-string things in the past. It's nice to look at a function sig and see Path/camino::Utf8Path/bytestr::ByteStr and see what they actually plan on doing with it.
- lampe3 5y agoAre there people who don't use the stdlib? and then start to implement things that are in the stdlib?
- steveklabnik 5y agoYes, for example, I am doing embedded development and do not use the standard library at all. There's not a lot of reason to re-implement it, because if you can use it, there's not a lot of reason to not just use it. There are people who make even more string types as packages, and use those. smallstr and bstr are two examples of those.
- lampe3 5y agoSure fair point on embedded devices I can see it. In the context of Backend/Frontend development I would question it. I had a colleague who rewrote some string functions in Java which are part of the stdlib. He called them "Arne Tools". Arne is a name in Germany. We were doing Java Applets back then. I always have to think of that example :D
- steveklabnik 5y agoSure, but just because it’s in the standard library doesn’t mean you use it all the time. 95% of my usage on non-embedded targets is String and &str. The “six string types” makes things seem far more complex than they are.
- iudqnolq 5y agoIt's commonly called no_std, after the attribute #![no_std]. People use it in embedded devices, and they're considering using it in the Linux kernel
- deleted 5y ago[deleted]
- whatshisface 5y agoUnsafe Rust is not automatically bad. The main reason all of those major libraries got switched to safe Rust is that progress in language features made it possible to do the same operations safely.
- lampe3 5y agoI don't wanted to imply that unsafe rust is bad. The argument was that you can disable it easily. For good and bad reasons.
- capableweb 5y ago> Unsafe Rust is not automatically bad Correct me if I'm wrong, but isn't one of the main selling points of Rust that's it's "safe"? If you're using "unsafe" Rust, you might just go for more established languages straight up.
- Kinrany 5y agoThe unsafety is localized to the rare `unsafe` blocks, which are not allowed to compromise the safety of the rest of the program.
- jokethrowaway 5y agoYou can still have the compilers check a few things, even in unsafe code. Besides, having 95% safe code and 5% unsafe code is still going to help when working on the rest of the codebase
- akiselev 5y agoRust's main selling point is a type system that allows safe wrappers around unsafe code by encoding invariants in the types themselves. Stuff that lives in the documentation like "you need to call foobar_free" becomes an unsafe block in a safe Drop implementation that only needs to be extensively tested once to validate the safety of the wrapper. Once the safe-unsafe interface is tested, downstream code doesn't have to worry about the unsafe implementations at all. Without unsafe, Rust programs would be useless since the Rust compiler can't verify the safety of external libraries that provide critical functionality like memory allocation and syscal interfaces (I/O). It would also go against one of Rust's main goals which is C FFI compatibility, which is something that the Rust compiler can't verify.