Should I actually learn this? Is it a good language? I don't understand if LULZ is trolling or being serious about hating it.
Should I actually learn this? Is it a good language?
Should I actually learn this? Is it a good language? I don't understand if LULZ is trolling or being serious about hating it.
How do you get money?
Nah. Just learn typescript + some shitty web framework and make money
Just go try it yourself, if you know C++ you probably gonna like it or hate it
>I don't know who's opinion I should adopt as my own and unquestionably belive
>should I form my own opinion or continue being unknowledgable
>guys it's really important I participate in this topic I have no information of, what do I do?
Yeah and?
why not just start learning it and see if you like it?
>Should I actually learn this?
If you have a use for it or you think it might be fun or educational.
>Is it a good language?
Yes.
>I don't understand if LULZ is trolling or being serious about hating it.
Most of the posts both for and against are serious. 10-20% are trolling.
Don't trust LULZ.
>Most of the posts both for and against are serious. 10-20% are trolling.
You have this backwards. Maybe 10% are serious. Almost all of the shills are trolls and most of the critical posts are just repeating stupid memes without any first hand knowledge of actual technical problems with Rust. In particular, the people saying that lifetimes make Rust more difficult than C++ are either joking, or so incompetent they can't segfault their way out of a paper bag.
Those people don't know what they're talking about but they're not trolling.
Why don't you just read the book and decide for yourself?
Don't waste time with meme languages. I am an expert in C++, I gave them a chance and it was a complete waste of time. You get nothing from learning that. I was expecting something better than C++, but it was worse in every aspect: syntax harder to learn, code harder to read, slower compilation times, slower at runtime. Only if you give up on safe mode is only slightly slower. That language is complete waste of time.
>if you give up on safe mode
What specifically did you do?
Not that anon but most of libc is unsafe, you need unsafe to use malloc, this is unironically true
NTA but he's not using malloc, the core library authors are. He's using a safe API that makes use of the malloc under the hood instead.
Not a problem on my machine. Rust has incremental builds so it wouldn't matter anyways. Why are you talking like a nocoder?
>Why are you talking like a nocoder?
projecting much? It's obvious to anyone who has actually used both languages that Rust compilation times are way way way worse.
yes it has nothing on a language like C++ known for speedy compilation
I used and still use both Rust and C++ and their compilation times are similar.
And rust has INCREMENTAL BUILDS, which I know you don't know, does not build the entire project every time.
It's only nocoders like you who think we are building the entire project in either C++ or Rust every time we add code. NGMI.
And it works on your machine too, unless you are using a computer from the previous decade.
>rust has INCREMENTAL BUILDS
Did they reenabled them already?
Mostly I hear stories like "yeah, our Rust build times are a little bit worse than our C++ build times" or "our C++ build times are a little bit worse than our Rust build times". Maybe it's different if you never use templates or maybe modules and import std; will immanentize the eschaton but C++ isn't known for compiling fast
>Rust compilation times are way way way worse.
Not in practice, Rust has built-in support for parallel and incremental builds.
C++ has support for it with vcpkg, CMake and Meson.
Unless if you are clean-compiling every time, or globbing the source code in CMake or Meson lmao
no one asked how fast it is on your machine, it's completely irrelevant
That's mostly about functionality rather than efficiency, and even if you need raw heap memory you shouldn't be calling malloc() from Rust unless you're doing weird FFI and C code will free() it
What I was poking at was that that post makes it sound like there's a switch you can toggle and then you get less safety and more speed and that isn't really how it works
>syntax harder to learn
It's pretty similar to C++. Are you getting filtered by expression based syntax?
>harder to read
Rust is harder to write, not harder to read.
>slower compilation times
Again, it's pretty similar to C++.
>slower at runtime
Rust has the same optimizer as C++, namely LLVM.
You are LARPing. You are not even a programmer.
>Again, it's pretty similar to C++.
no, it's not. Rust is extremely slow to compile, try something more than a hello world
> similar to C++
> not harder to read
LMAO
> same optimizer as C++
and still slower
C++ has implicit conversions and its templates are not trait constraint. It's harder to read, yes. Learn programming.
If you learned programming, you would've mastered metaprogramming instead of crying for a compiler to hold your hands, YWNBARW
It's not about mastering metaprogramming. Rust traits are maximally constrained. C++ on the other hand is not, it emulates constrained generics with C++17 concepts. Most C++ code just throws a template <class T> like C++98, making it difficult to predict the functions or traits that T implements, everything is implicit and less predictable.
You literally either
1. cannot argue this
2. will argue this because you don't know TMP yourself.
I'm betting on the latter. Learn programming.
Yeah no it isn't. Your statement is driven by pure emotions and hyperbole.
Hyperbole isnőt an emotion numbnuts
>not harder to read
Rust syntax is the most atrociously ugly syntax I have ever seen. Yes, even more than C++ metaprogramming soup. APL is more comprehensible.
>don't waste time with meme languages
>I waste my time with a meme language called C++
Do you want or have a career that benefits from C/C++? Sure, worth a slim at least. If not, you're better off getting a job as a janitor cleaning up spicy poop spills in computer offices.
>a career that benefits from C/C++?
Career benefits from real languages like Python, C# and JavaScript. Not meme languages.
A significant amount of the std lib (basically anything that uses std::mem) relies on unsafe.
Rust procedural macros involve parsing the ast (lmao), and any flaw in the compiler can lead to vulnerable code being emitted.
A ridiculous amount of crates use this "feature"
The attack surface is fucking huge on rust and its a moving target so its not formally verified.
Its likely that many zero days will be found in just the compiler let alone the tooling.
Not to mention the logic errors.
Speaking of, rust suffers from the problem of static dependency management, like python and nodejs
Basically its trivial to create malicious crates and or exploit unmaintained ones. Most popular rust crates pull an obnoxious amount of dependencies. One GUI library pulled something like 216 crates. Sorry rust sisters, but no matter how fast rust is at a language level, it will never be faster than C simply because of the sheer amount of extra code that's running.
Also this shit lang STILL can't make a fucking GUI.
The irony is that in the end all the native code for GUI is running in C.
Rustroons will cope with the following idiom: "safe api for unsafe implementation" but ask yourself how is that any different from a well seasoned and widely used C library
>A significant amount of the std lib (basically anything that uses std::mem) relies on unsafe.
Practically all of it does, std::mem isn't even the place to look.
>Rust procedural macros involve parsing the ast (lmao)
Yeah? What do you expect?
>and any flaw in the compiler can lead to vulnerable code being emitted.
This is true for every single compiler. Except CompCert I guess, but not a lot of people use that one. What's your point?
>The attack surface is fucking huge on rust and its a moving target so its not formally verified.
Parts of it are formally verified, though most of it isn't. But again, I bet your system wasn't compiled using CompCert.
>Its likely that many zero days will be found in just the compiler let alone the tooling.
When do you expect this to happen? Why hasn't it happened yet?
>Rustroons will cope with the following idiom: "safe api for unsafe implementation" but ask yourself how is that any different from a well seasoned and widely used C library
The difference is simple. If I feed bad input into a C library I get undefined behavior. If I try the same thing with a Rust library I get an error, usually at compile time, if necessary at runtime. C doesn't have the ability to e.g. enforce that an argument is a non-null pointer that points toward the start of a string that will not be modified or freed before mylib_terminate() is called. All it sees is a pointer argument. But in Rust that sort of thing is easy, it's just part of the type system.
C++ is far ahead of C of course, but unlike Rust its type system can't express lifetimes or thread safety so you have to track those manually. And instead of adding a cheap runtime check it makes it undefined behavior to e.g. pop an empty vector, so there are lots of holes.
Zero days were not found in C until it was about 20 years old, maybe the same will happen to Rust...
(checked)
I'm pretty sure they knew gets() was fucked the day they wrote it. Safety just didn't matter then and there.
> C simply because of the sheer amount of extra code that's running.
You don’t understand how dead code elimination works. I noticed that people who have such a strong opinion about Rust are not too knowledgeable. Why is Rust so polarising that even these people get invested?
>A significant amount of the std lib (basically anything that uses std::mem) relies on unsafe.
stdlib authors worry about unsafe code, you don't. That's the point.
>Rust procedural macros involve parsing the ast (lmao)
What's so funny?
>any flaw in the compiler can lead to vulnerable code being emitted.
That's not unique to Rust.
>The attack surface is fucking huge on rust and its a moving target so its not formally verified.
Not a single software you use or will ever use has been written follows any formally verified specification. Not a single one. Zero.
>Not to mention the logic errors.
Actually single ownership prevents a lot of logic errors (ie trying to change a container while iterating though it)
>rust suffers from the problem of static dependency management, like python and nodejs
What is the problem?
>Basically its trivial to create malicious crates and or exploit unmaintained ones
Not unique to rust. lib-ffmpeg bug has been exploited for decades and nobody noticed.
> it will never be faster than C simply because of the sheer amount of extra code that's running.
That's not how compiler works.
>Also this shit lang STILL can't make a fucking GUI.
There is literally an entire OS
https://www.redox-os.org/
Why are you lying? What motivates you to lie?
>The irony is that in the end all the native code for GUI is running in C.
People like native UIs, which is why there are wrappers of the native UI like Win32 or GTK. If you are okay with non-native UI, you can use stuff like egui (pic related).
Again, why do you post straight up lies? How does it benefit you?
>safe api for unsafe implementation
Yes? What's wrong with it?
>that any different from a well seasoned and widely used C library
Of course yes.
C by default does not understand problematic ownership, which is why you end up with buffer overflow, double free, dangling pointers, data race etc.
And not only that, C lacks useful abstraction like generics, modules etc.
>Is it a good language
It has some good ideas but questionable implementation. The "community" being more cancerous than the elephant's foot in Chernobyl is the main reason I avoid it
>Most popular rust crates pull an obnoxious amount of dependencies.
https://github.com/mTvare6/hello-world.rs
it depends on if it solves the problems you have. if you have a need for a fast language and want it memory safe, then rust will do it fine. if you just want to play around with a new language, it's also worth checking out too. if the current languages you know serve you well, then you might just get frustrated with rust being different.
the language is wonderful in my opinion. there aren't any nulls nor exceptions, and the match statements are great. it just takes time to get used to the way rust wants you do things. keep in mind that all of the things that the borrow checker enforces are the exact same things that Bjarne wants people to do with c++, but there just aren't any enforcement by the c++ compilers, so don't get memed by retards saying that you if just git gud c/c++ will be fine.
If you want to do system-level work, you absolutely should learn Rust. You don't have to like it. But the industry has spoken, and Rust is the future.
I started it and I like it. It's a steep learning curve if you come from a non C/C++ background, but once you get over that, the eco system is nice. The cross-platform executables are nice, and it's very fast.
I just bought the book. There are no jobs that use rust, it seems to be a hobby language.
C++ is already perfect.
If one were to compare them to languages, C is like French, C++ is English and Rust is Esperanto.
Rust and Go are both dominating performance critical backend services.
It's over.
Only Go, there is no Rust being used in backend because there are no jobs
Go is mid.
>Go
>perfomance critical
Please
rust programmers be like
Driver is a struct with two generic members namely db and clock. They abide by a certain set of traits (interfaces) that are explicitly outlined in the where clause.
This filters the cnile.
It's a struct, but you're putting types in it that aren't int or float?
WITCHCRAFT
>These where declarations where repeated 44 times in 37 different files (that is, almost all files)
To avoid this, you can make a marker trait that requires those traits.
trait A<D: Db>: AbusePolicy<D::Db> + Clone + Send + Sync + 'static {}
// similar traits for the rest...
Is this ideal? No, which is why trait aliases are in development to make this easier.
You can try it on nightly with the `trait_alias` feature.
#![feature(trait_alias)]
trait Foo = std::fmt::Debug + Send;
trait Bar = Foo + Sync;
// Use trait alias as bound on type parameter.
fn foo<T: Foo>(v: &T) {
println!("{:?}", v);
}
pub fn main() {
foo(&1);
// Use trait alias for trait objects.
let a: &Bar = &123;
println!("{:?}", a);
let b = Box::new(456) as Box<dyn Foo>;
println!("{:?}", b);
}
https://doc.rust-lang.org/unstable-book/language-features/trait-alias.html
PS, almost forgot.
The big difference between marker traits and trait aliases is that you would need to implement the marker trait for types before using.
You can use a blanket impl, but this could prove to be inflexible later on.
The trait alias avoids this issue, since it isn't a new trait but merely an alias for a collection of them.
As a zoomer who uses windows, i dont want to deal with compilers, build systems, and package managers all independently. C++ is nice to write in but rust seems less of a headache. You may say use linux, but i dont want to. If only there was an all in one c++ development environment that was free and cross platform.
I started learning it and I really like it. It's very intuitive. I like the memory safety feature. Finally I dont need to be scared of knowing if the end user will use ecc or not.
Well lads, I'm gonna start reading this. Not sure if I'm going to transition from C++ or not, but I can be fluid and non-binary, it doesn't have to be one or the other. If it matters, Microsoft groomed me.
Christ, I'm joking around but even one of the authors is a troon.
Why does it matter? Rust is popular among younger devs and 40% of young americans are LGBT.
>Why does it matter?
Why not just say that about anything?
>Rust is popular among younger devs
This author isn't young, looks to be late 30s
>and 40% of young americans are LGBT.
No, they're not.
Ok why does it matter? Why does it matter if a book is written by Hitler or a Tranny? Is the book lying about anything? Is it not doing its job? What's wrong?
Did I imply that it was wrong with regard to the subject matter? The point you missed was that you can barely shake a stick in the Rust community without hitting a troon, and it's bizarre. I'm sure "Leonora" is a smart guy when it comes to tech, it's just sad to see people suffering with mental illness as the community of friends gives them superficial encouragement.
>The point you missed was that you can barely shake a stick in the Rust community without hitting a troon
Leonora happens to be the person who is equipped with the knowledge and determination to write the book. Nobody chose Leonora to write the book.
Move past identity politics, it's boring and detrimental.
>Nobody chose Leonora to write the book.
Of course someone did, he wasn't an author for the first edition.
The author of the first edition has still co-authored the book. What's the matter? Are you jealous you didn't make the cut?
This conversation isn't going anywhere, so I'll just leave you with YWNBAW, and I'm going to go read the book.
And I'm sure when we examine the poll, we're going to find either very leading questions or a sample group consisting of pride parade attendees.
Just start with the Rust docs.
https://doc.rust-lang.org/book/foreword.html
Any reason why?
Very well written, good examples. It gradually builds you up from the bottom with the core concepts and a few projects.
Someone also recommended to read that first, and instead of the O'Reilly book, another called Rust in Action, because of the projects.
NTA but the O'Reilly book is very effective for someone who is familiar with C++. It's basically "Rust for C++".
That does have appeal. I think I'll speed through the official docs, and then see what those two books cover that I've missed. Since I know C++, I should already be able to compare and contrast on my own.
also not in the conversation before, but that's how i recommend it. the rust book then the blandy book if you want more. too many people skip sections and don't write code then bitch about things the book covers. some chapters you can get by just reading if you know the material, others you should write code and compile it as you go like the projects.
no, its deader than dead.
Yeah just 2 more weeks, and nobody will even talk about it. Trust the plan.
tell me anything ov value that uses it.
go ahead I'll wait.
Android.
Let me hear your cope.
so you're retarded. yeah I figured.
Chrome, the Windows kernel, AWS Lambda, the list goes on
Firefox, Dropbox, Shopify
all trash, thanks
6 years ago I was deciding between Go and Rust for an important project. I chose Go because I could immediately read and understand most of it, Rust seemed too experimental, introducing some new concepts about memory management. Looking back, it was one of the best decisions I made, since I see things haven't changed. It still has no multi-threading built-in and HTTP client/server in stdlib, I don't know what they are even doing.
>It still has no multi-threading built-in
https://doc.rust-lang.org/std/sync/mpsc/index.html
I stand corrected. It looks like Rust gives you more low-level control, since Go forces you to use its runtime. I guess I'm just filtered by Rust's syntax. I don't need that much control, 99% of my job is piping data through TCP connections.
For what its worth, this level of granularity comes with less productivity. Hence Go is more productive at a high level.
On that note I'll leave you with NGMI. Good chat.
>For what its worth, this level of granularity comes with less productivity. Hence Go is more productive at a high level.
false. you can't build abstractions for shit in go
I noticed that, the web frameworks aren't too abstracted. Why do you think that's the case?
Rust has multithreading built in, just not async. That means you can swap in your own runtime, so there's more flexibility. There are low-powered options as well as fancy upscale runtimes, and if you don't need async you don't pay for it at all.
It's a sensible option for the kind of language Rust is. Go is a different kind of language.
dunno man have they fixed the garbled text bug yet?