-
-
Most of these aren't even true, and were written by people who are not familiar with Rust (outside observers).Originally posted by Master5000 View Post
> Borrowing rules are more strict than what’s possible to safely do.
By definition, possibly safe means unsafe, and you are able to do unsafe things, it just takes more effort.
> LLVM's optimizer considers undefined behavior a license to kill. Of course, that only matters in unsafe code, but you need unsafe code for anything complicated.
Undefined behaviour isn't allowed in safe or unsafe Rust. You also don't need unsafe for anything 'complicated'. The Redox kernel is written without requiring unsafe. The Doom viewer was written without unsafe. Everything can be written without unsafe. I have yet to see a problem that requires unsafe to be solved. The unsafe keyword is merely used to cut corners in areas that we know are safe.
> Overly terse named types and keywords that don't communicate their purpose, like Vec and Cell.
This is an opinion, and a bad one at that.
> Rust has two main string types and four other string types, for a total of six. There are String and its slice equivalent str (“native” Rust UTF-8 string types used most of the time); CString and CStr (when compatibility with C is required); OsString and OsStr (when working with the OS’s String).
This is not an issue, and these types make perfect sense.
The `String` type is the universal standard string type that all Rust libraries and applications use, and it is UTF-8 regardless of what OS the program is running. The `String` type contains an internal type known as `str`, which is basically an array of characters of varying sizes. This type will never be interfaced directly by the programmer. The String type dynamically creates, destroys, and updates it's internal `str` array. When you reference a `String`, it will automatically return a reference to the internal str (&str) by default, because a `String` type that cannot be modified is useless. Therefore, the Rust programmer will only ever have to think about `String` and it's associated `&str` at any given point in time.
The `CString` type is merely used to convert to and from a String when interfacing with C. C strings are character arrays that are ended with an '\0' character. It's pretty basic so it's useless to a Rust programmer.
The `OsString` type is merely a string of the OS's native encoding (UTF-16 on Windows and UTF-8 on Linux). This type will also never be interfaced by a Rust programmer directly because there is no reason to, unless you are writing an OS-level library, like writing your own standard library.
> Not smart enough coercion means that sometimes, you must use things like `&*some_var` (which will convert a smart pointer to a reference).
This is also false. Given enough information, the compiler knows what type to reference to. This has only been observed with trying to use an `&mut String` as an `&str`. If you're passing an `&mut String` to a function that takes an `&str`, the compiler knows to do just that. Otherwise, in the event that you are pattern matching an `&mut String`, you can just use the `.as_str()` method to tell the compiler that you want an `&str` and not an `&&mut String`.
> You cannot use non-Sized types (like str and [T]) in several places, because every generic requires Sized unless you opt out by requiring ?Sized.
They start out by saying that you cannot use non-Sized types, and then mention that yes, you can use non-sized types. It is important for the compiler to know if a generic type is Sized or Not Sized. It makes perfect sense when you start writing generic code that depends on knowing the size of the type, or when the size could be completely random. It's also a compiler tip that can enable extra optimizations.
> rustc is slow.
This is not true anymore. This was already fixed a few releases ago. I can compile a 100K LoC project release build in 3 minutes or less.
> Because it statically links everything, you get outdated copies of several libraries on your computer.
This doesn't even make sense, and it's false. The default linker on Linux is glibc, which does not statically link external libraries. If a library is outdated, it's because your distribution is providing an outdated library -- not the fault of Rust.
You can only get a fully static library if you use the musl target, but then the argument also falls apart because statically-linked libraries do not ship with 'several libraries on your computer'.
> Actually, it statically links almost everything. It dynamically links your program to libc, so your executables aren't really self-contained.
I compile my software with musl, and I can use ldd to verify that they are fully static. Dynamic linking only applies when using glibc.
> Modifying a file in your project or updating a dependency requires you to recompile everything that depends on it.
This is false. Waaaaay back in the distant past, this was fixed. If I update a file in my project, only that module needs to compile.
> Every executable, by default, contains a copy of jemalloc, making “hello world” approximately 650 kilobytes in size.
Only applies to Linux, and it can be disabled. This can actually be a good thing though because jemalloc is more efficient at allocations and deallocations than the sytem allocator.
it's also false that a hello world application is 650 KB in size. I have a very elaborate parallel application and my binary size is ~200 KB with MUSL.
> Type-ahead auto-completion is still a work in progress, because rustc is slow.
This is also false, badly false. Racer is used for type-ahead auto-completion, not rustc. It can run as a daemon in the background for your IDE to efficiently interface with, only requiring that you have the source code of Rust installed via Rustup. I have been getting sub-50ms completions in both Atom and VSC via Racer.
> IDE support is lacking.
IDE support is better than most languages in existence, even C. There's a lot of IDEs that support Rust right now. I've only experienced Atom and VSC though, and Atom is by far the best.
> Generic types are very popular, and they're essentially copy-and-pasted for every concrete type they're used with. Compiling essentially the same code over and over again is painful when rustc is slow.
This is pretty much false. Generic traits was resolved by Macros 1.1, and the upcoming ATC work will only make this more convenient.
> The optimizer will break your program and it will run dog slow if you turn it off.
Will is a very strong word. I have never encountered the issue, and the linked issue is a bug with LLVM rather than Rust.
Comment
-
Actually doing the exact same thing in C requires a lot more work if you account for provability. It's harder than just learning a safer language.
This would not make a point if developers wrote bug-free code, but they don't. And an insane amount of time is spent debugging.Comment
-
The Rust community has developers exclusively working on IDE support, and has been working on IDE support since day one. There are a lot of IDEs that support Rust. There's a webpage dedicated to listing IDE support on various IDEs. Visual Studio Code is their primary platform of development right now. The great thing about Visual Studio Code is that it's lightning fast and has most of the features of Atom, in addition to VCS integration, debugging, and documentation tooltips. Although I favor Atom overall as it has better Clippy linting (<100ms versus VSC's 3000-6000ms) and proper support for automatically correcting indentation when you copy a block of code from one level to another.Originally posted by Master5000 View Post
Every technology that has ever been invented has had luddites mocking it, like you. Electricity will never take over! We're perfectly content with our oil lamps! Telephones will never take over! Face to face conversations are better. Computers will never take over! Nothing can replace a human. The Internet will never take over! The Internet is for nerds.Rust will never take over. It's in your interest to stop bothering to learn something that will either be dead or be a niche in 5 years.
Nobody said anything about Microsoft or Linux rewriting their OS in Rust.Do you really think Microsoft and Linux will rewrite their OSes in this shit language? Do you think people will write websites in it? No? Well then...
Comment
-
fixed.Originally posted by Master5000 View Post
Btw, there are rust plugins for Jetbrains's IDEs https://plugins.jetbrains.com/idea/plugin/8182-rust and Jetbrain's IDEs rock.
1. MS has traditionally eaten their dog food so it's irrelevantRust will never take over. It's in your interest to stop bothering to learn something that will either be dead or be a niche in 5 years. Do you really think Microsoft and Linux will rewrite their OSes in this shit language? Do you think people will write websites in it? No? Well then...
2. Linux is a kernel and that makes more sense written in plain C (also because Torvalds), the userspace on the other hand...Comment
-
While I already made a comment about Rust itself... the quoted text is not a valid argument for anything... "if ___ manages to become the best ___, it will be better than ___!" you can use that argument for nearly anything.Originally posted by nomadewolf View PostComment
-
Yes. And i'm very well aware that it's mostly wishfull thinking.Originally posted by Holograph View Post
It would be great even for Linux to have such fierce competition.
And even if it manages to be better, it doesn't mean it'll take over the Desktop by storm.
So, yeah. This is just me expressing what i whish to happen.
Not holding my breath though...Comment
-
Originally posted by mmstickYou might just be one of the dumbest people on the Internet.Originally posted by Master5000 View PostComment
-
Qt has basically no mature wrappers for any language AFAIK, because C++ semantics (not to speak of Qt-specific constructs) are pretty complicated and don't really port well to most languages. Name me one language that can use Qt well and isn't C++ …Originally posted by vasusreeComment
-
given the link, and the fact that the statement is copied from earlier in the thread, I'm 90% certain vasusree is a spambotOriginally posted by CrystalGamma View PostComment
Tweet
Comment