All opinions are welcome. By "non-meme" I just mean to actually explain your opinion and not just give a 2 word meme post. This thread isn't about figuring out whose opinion is right or wrong, it's just to get an idea.
For example, the usual argument I hear against rust is "trannies" - so can you elaborate on that? WHO is the troony here and why? Are the developers actual trannies, or is it just a meme?
And if so are they just random trannies who've never harmed anyone, or are they the bad kind of troony who uses "woke" culture to cancel opposition or something?
If I sound ignorant of this topic it's because I am, and that's exactly why I'm making this thread.
Because I'm thinking about using Rust in a new project that will be heavily multi-threaded and I like the idea of Rust being "thread safe". So I started learning a bit, but I can't help thinking back to all the hatred I've seen on IQfy for rust.
Most of the time I see people hating on rust it seems like there's some event that happened in the past that made them hate it, but they never say what it was.
So if there's some history, or something that makes rust unlikable, or if the devs did something untrustworthy, or whatever, please actually explain what it was instead of assuming everyone already knows everything about the developers and the history behind it. Because we don't.
 |
 Shopping Cart Returner Shirt $21.68 |
|
Who are they? And what did they do?
I'm sure every language has been used by at least 1 troony before. Even C.
So why is it different for Rust?
I'm not trying to put you on the spot, but it's just surely you must know _something_ more about this than just
>some troony somewhere in the world used Rust at least once
Surely there's something more right?
>the usual argument I hear against rust is "trannies"
Chances are it's just a buzzword that people use because they can't point out actual flaws.
>expressions shouldn’t return values without a return keyword
>async results in frustratingly unmaintainable code
>ML-style lifetime syntax is aids
>stdlib is weak and you have to rely on 3rd-party crates
>stdlib can panic and kill your code
>functional programming is a meme
>pass-by-move by default is stupid - should be pass by value like every other fricking language
>no inheritance
>six different string types
>function chaining is inherently wasteful - should have used Dart .. operator instead
Thanks for this. I can understand technical dislike of a language far more than political dislike.
can panic and kill your code
May a brother get an elaboration on that quip?
if you choose to use methods that panic, they will panic
>expressions shouldn’t return values without a return keyword
For function returns or in general? Even in short anonymous functions?
>pass-by-move by default is stupid - should be pass by value like every other fricking language
Do you mean you want implicit copies?
>six different string types
How would you solve this? Do you fold owned strings and string views into a single type? Do you append null bytes everywhere just in case a string goes through C FFI at some point? Do you ignore or crash on invalid Unicode from the OS?
>function chaining is inherently wasteful
Not true thanks to move-by-default, right?
Am interested in what Dart does though.
#0B5E55ED
>>six different string types
I like the choice that gives to the programmer to optimize xeir code
xey never will be women so why do you care? are you threatened to get your dick sucked by them?
>expressions shouldn’t return values without a return keyword
Use a return if it bothers you then. It useful for short closures.
>async results in frustratingly unmaintainable code
Agreed. Just don't use async.
>ML-style lifetime syntax is aids
Meh?
>stdlib is weak and you have to rely on 3rd-party crates
Agree, hardly a deal breaker though.
>stdlib can panic and kill your code
Some things can panic. Use the non-panicking ones, or catch the panic.
>pass-by-move by default is stupid - should be pass by value like every other fricking language
Any copy type is pass by value. Obviously you can't copy a non-copy type.
>functional programming is a meme
>no inheritance
"Java style" OOP is a meme.
>function chaining is inherently wasteful - should have used Dart .. operator instead
Compiler easily optimizes that sort of stuff away.
You sound new to programming in general, and absolutely new to Rust.
If you want real arguments against Rust:
GATs aren't stable
Mutability can't be parameterized
Bad trait coverage in stdlib
Compile times
... I used to have twice as many, but they have all since been added/fixed
> ... I used to have twice as many, but they have all since been added/fixed
Then you can add lack of language stability to the list. I can still build C that I wrote 20 years ago no questions asked
Rust is backwards compatible. Adding features doesn't stop old code from compiling.
>six different string types
there are different types of strings
>>six different string types
C++ has like 20 of them.
>six different string types
c++ is obnoxious with 2, but std::string is useful when you want to append to and return a string and hand it to the caller
business is war
its not. its an application programming language. systems programming languages let you write libraries to call from other languages
>systems programming languages let you write libraries to call from other languages
extern "C"
>>pass-by-move by default is stupid - should be pass by value like every other fricking language
.... how moronic are you?
as opposed to what? do you even know what a move is? do you even know how copy works in rust? probably not because you're a moron with a worthless opinion.
rust will, without borrowing, will either move the value or copy it if it implements Copy. jesus christ.
holy frick I used to have that exact same card
AGP lads ftw
>expressions shouldn’t return values without a return keyword
I strongly disagree with this one. It's very useful to be able to have a block expression anywhere a normal expression can be used, it's nice to be able to make a short scope anywhere to clean up temporary variables, and it simplifies the syntax by unifying if statements and ternary expressions. I guess maybe you mean that block expressions are fine but they should still use a keyword to specify their value? That's fine, but I don't see the point and you'd need some mechanism to still allow for actual early returns.
>async results in frustratingly unmaintainable code
Not in my experience.
>ML-style lifetime syntax is aids
I can see why you would think that, but I do find it nice to be able to tell at a glance the difference between a lifetime parameter and a type parameter, especially because they're not elided in the same way and it's possible that you may need to provide explicit lifetime arguments but not type arguments or the other way around.
>stdlib is weak and you have to rely on 3rd-party crates
In some cases this is because those crates are actually first-party (part of the rust-lang-nursery project) but unstable. I do think there are other big cases like crossbeam and rayon that could probably be officially adopted and considered for future inclusion in std. A seemingly glaring omission here is async I/O - the std contains no actual async functionality - but that's because async libraries like tokio are fundamentally runtimes, which are supposed to be optional.
I actually think it would be better for the std to become smaller, but for more crates to be included in the nursery and possibly made available as part of a standard Rust distribution.
>stdlib can panic and kill your code
Panics are almost always reserved for situations that are programmer errors, where there is really no way (or good reason) to cleanly recover.
cont.
>pass-by-move by default is stupid - should be pass by value like every other fricking language
Moving IS passing by value. I assume you're referring more to how it is in C++, where the default behaviour is to clone the object when passing it around. It's much simpler and saner to make moving the default, as then cloning becomes a regular method call instead of being a special feature like in C++.
>six different string types
String, OsString and CString are completely different. String and str (OsString and OsStr, CString and CStr) are *similar* but still not the same - String is an entire heap allocation, but str can be anything, like a static string embedded in the binary or a slice anywhere within either of those things. 99.9% of the time you'll be using String or str anyway.
>function chaining is inherently wasteful - should have used Dart .. operator instead
I don't see how it's wasteful. It's not even a feature, it's just something you can do, and there is another way to update multiple fields of a struct simultaneously.
Like said I don't like how you can return value just by not typing the semicolon. Just have a shorter keyword for return if you don't want to type.
That is just a minor complaint. However, I think that procedures that don't return values should return exactly no value. I don't care what your gay "math" theories told you unit is not no value because variables should not be able to get no value. This is just like undefined in js but it's less of a problem thanks to type checking.
I think not needing return is nice in that function blocks work similarly to other blocks, e.g., omitting semicolon inside if means that the if block evaluates to that result.
To the contrary, I wish C++ had terser syntax for lambda expressions.
>However, I think that procedures that don't return values should return exactly no value. I don't care what your gay "math" theories told you unit is not no value because variables should not be able to get no value.
What are you even trying to say? That there should be no unit type and that there should be a special non-type like void in C? Why, what is the difference except for being more complicated and less unified (it's useful to be able to use unit in generics)? Also keep in mind that there is a big difference between a procedure that returns a value (like unit) and one that cannot return a value (e.g. of an empty enum or the never type).
Yeah, I'm not against having unit, in my mind functions and subroutines (and procedures that never return) should be distinguished. A value should not be used to express the lack of a value. I know that making most of the language expression based allows some elegant and simple design, maybe I just don't think that way.
programming is a meme
kys
>pass by move
really? rust snowflakes tryna find new snowflag terms when pass by reference was the term since the 80s
Can't tell if this is a troll post or if this guy is really dumb enough to confuse moving (which is in C++, too, so no excuses) with pass by reference.
... move isn't new, and it was never pass-by-reference at any point before Rust anyways.
An average Rust hater "with arguments"
>are they the bad kind of troony who uses "woke" culture to cancel opposition
why do /misc/ caricatures live in your head rent free?
ive worked as a front end developer for ten years now and literally never see a troony until i visit this board.
and even then that's only really happened lately with the amount of flags/trannies in denial coming from the containment board.
stop wasting your time making threads like this and just try the fricking language out to make your own opinion on it you worthless undergrad dipshit.
So ok, it just sounds like we're on the same side. Why are you directing your anger at me?
You said it yourself
>ive worked as a front end developer for ten years now and literally never see a troony until i visit this board.
That's my opinion too. And now I'm asking why. That's the point of this thread.
The fact that you sound a bit upset tells me you're probably also confused about it, so instead of taking it out on me why don't you see what replies we get here?
Normally I wouldn't care but there is some threshold where I think an answer is warranted, and for me that's when about 50% of IQfy will shit all over any post you make about X for vague reasons.
I think it's reasonable to ask for some clarification.
>why do /misc/ caricatures live in your head rent free?
What makes you think this? You also clearly know IQfy talks about this too. So the extent to which they "live in my head" is the same as the extent to which they live in yours.
I'm simply giving them a chance to explain the details, or to see if there's really nothing behind the hatred in the first place.
>still too new (changing)
>super noisy syntax
>package manager that promotes the idea of depending on random strangers code
>package manager that promotes the idea of depending on random strangers code
How is it different from package managers in any other language?
>Just don't use async.
Modern language, huh?
>you have to rely on 3rd-party crates
>hardly a deal breaker
And most crates have panic somewhere inside them, which requires very special measures for catching. It's "safe", but it's not really safe for me.
>How is it different from package managers in any other language?
I'll equally criticize any other language that does this, but rust gets few extra minus points because they are so vocal about safety.
>third party crates
There have been some high profile attacks against rust by typosquatting third party rust crates
Ofc you also have to worry the maintainer disappears or decides to break the crate if you have an IP from a country he dislikes
>There have been some high profile attacks against rust by typosquatting third party rust crates
I know of one (1) attack and it had no known victims.
I hate Rust because I like simplicity. I hate modern C++ too, just not as much.
C++ is way more bloated and complex than Rust. There is at least 3 different ways of doing every single thing.
On the other hand, it'd be very difficult to remove some of it's features and not weaken its guarantees or capabilities. It is much more minimal and simple.
>some of it's features
Some of Rust's features.
It doesn't matter if one is slightly less bloated than the other. I hate them both and the hate is mutual.
It's not slightly, C++ is way more bloated.
Rust is minimal for what it offers.
>C++ is way more bloated and complex than Rust
Trannies keep saying this but Rust is so bloated that it doesn't have a standard.
>Rust is so bloated that it doesn't have a standard.
That makes no sense.
>With that said, RAII is what you're supposed to use in C++
Yeah, and that's a good thing.
However one small benefit of Rust is that its stdlib is made with RAII in mind from start. There are of course ways ways of accessing memory and resources directly, but they are clearly marked as low level and in safe Rust you just use the safe abstractions such as RAII. It's not like when someone first learns the C way and then learns about the C++ way and not understand it so they revert to an abomination like "C with classes".
There is none lol.
Rust really is just great systems programming language. The only reason you might not like it is because you use it for something it's not made for(game dev, scripting, gui applications, etc), because it's hard or because you can't live without some paradigms like full-blown OOP or mutability by default or whatever.
Rust is supposed to be an alternative for modern C++, made from scratch, with much stronger guarantees and made with modern programming techniques in mind(utf-8, raii, dependency manager etc). It does that perfectly and there really isn't anything to complain about.
>modern
>raii
Lmao
compared to the current PLT state of the art, ya. RAII is basically "modern."
>raii
I don't have much beef with Rust other than it taking ages to compile. With that said, RAII is what you're supposed to use in C++ unless you follow Google's moronic guidelines of having no exceptions. If you have a resource that needs to be allocated and freed, you wrap it in a class, allocate it in the constructor and free it in the destructor. If the allocation fails, you throw an exception in the constructor and handle the problem.
This simple concept fixes what annoys me most about C where I have to sprinkle code with if (error) goto free;.
Syntax puts me off
It is ugly and hurts my eyes.
because it takes ages to emerge
What do you mean ages? It takes less than an hour to compile which is roughly comparable to gcc, llvm/clang and Firefox.
Wrong. You can compile both gcc and glibc in 20-30mins.
A full "proper" emerge of llvm+rustc (since rustc depends on llvm) can take up to 24 hours.
I install rust from ports on FreeBSD on my server running a 3100x, it takes about an hour and a half including its separate build of LLVM. The slowest thing I build, for sure, but nowhere near 24 hours and that's on an underpowered CPU. You're talking out of your ass.
b-but c best, 2500k still enough, don't need anything more
Slow complier and too much 3rd party dependencies.
kek
https://github.com/mTvare6/hello-world.rs
kek
https://www.gnu.org/software/hello/
I use musl+busybox/linux. nice try, troony
why do you think about troony wieners all day long?
who mentioned wieners? i think you're projecting, buddy.
i think about their butts, not wieners, anon
>musl+busybox
you'll cut off your dick any minute now
Prove it.
Dependency hell is real. Every crate likes to pull in 10 dependencies which also like to pull in 10 more.
Also in many areas, namely multimedia, you have to rely on c dynamic library wrappers which kill the cross platform aspect. Deploying it on musl systems you have to build with a dynamic then.
>unix philosophy bad
There is nothing wrong with cargo. Having small, specialized crates allows them to focus on what they actually do, instead of reimplementing same things over and over again. This allows much easier interop between libraries and the libraries can be much smaller, including stdlib. You no longer need to install bloated mess like Boost. Package manager makes it so much easier to install and update your dependencies as well.
And don't talk like cross platform support is better in C++ libraries. Barely anyone cares to make their C++ libraries cross platform, it takes too much work. While rust has cross platform build system built-in, you just write build scripts in Rust itself and there are crates like cc that make it trivial to locate and run necessary compilers in cross platform fashion.
Ok let me rephrase my complaint.
Many dependencies try to be complete so they support every feature that you probably don't even want. You want a simple web server? Guess you need json, multipart, xml, tls, gzip and http2.
If you are lucky they give you a feature to turn off some of those.
If you are lucky, some of them don't land in your release build because they use different code branches.
Otherwise you'll face long build times and gigantic bloated binaries.
>Many dependencies try to be complete so they support every feature that you probably don't even want. You want a simple web server? Guess you need json, multipart, xml, tls, gzip and http2.
That's not true? There are high level libraries that work as battery-included frameworks but there is tons of simpler, minimal libraries. The former often use the latter under the hood. If you want simple, minimal http server, you can just use hyper or tiny_http.
This is no different than any other language.
>Otherwise you'll face long build times and gigantic bloated binaries.
Unused functions, modules, and such are not included in final binary.
and?
"having dependencies" is not "dependency hell"
It's not "dependency hell" if dependencies are actually solvable, even if you might not like the number of them. Also, on any musl native system musl will be linked dynamically so I don't get your complaint.
i hate how you cant have a static cast, like passing an int value to float, no you need to first convert it to float with some shitty function that you need to search 3 stack overflow pages to find and then pass an int to a function that takes a float, this just a simple example of why i hate rust, tho the compiler is great
>can't have static cast
let foo = 4:
bar(foo as float);
>Non-meme reasons to hate rust?
It's still a low-level systems language. Not as easy to read and write as a dynamic GC language.
>And if so are they just random trannies who've never harmed anyone, or are they the bad kind of troony who uses "woke" culture to cancel opposition or something?
Reminder that nothing is wrong with canceling bigots. Anti-trans chuds are literally trying to murder and erase trans people and you're crying about them being banned from instagram for openly calling for it. They made you their useful idiot OP.
Do you think that religious Muslims should be allowed on Instagram? Super curious what your reply will be, lol
I see your trick question and raise you another. My religion says I have to aggressively pursue all IQfy users (except myself of course) and forcibly put them in a gulag to do slave labor for the rest of their life. Should my religion be allowed on IQfy?
The trick is that you forgive them for their violent homophobia because they're not white. There's a hierarchy, and trannies aren't at the top of it.
Cool strawman bro.
If you reflected, you would find that you have double standards. Do you think you have them for a good reason? Consider what your reasons are.
Or don't, that's more comfortable.
>If you reflected, you would find that you have double standards.
Please point out how. Or better yet, don't. Get in the gulag. You don't want to get in the gulag? Why are you against my religion, bigot? Why do you have double standards? Consider what your reasons are.
Or don't, that's more comfortable.
it should be and, in fact, it is.
did you think this was some sort of gotcha? moronic homosexual
Where does is say it's banned? I'm still here. By the way you need to get back in the gulag you pathetic worm, you're not supposed to be out here.
are you illiterate? i said it should be allowed, and it is allowed. get your head checked, homosexual.
>their violent homophobia
The Ottoman Empire decriminalized homosexuality in 1858.
In The United States of America, homosexuality was decriminalized in 2003.
They hate it because they're reactionaries who instinctively hate change, and because it hurts their little egos because it's so clearly superior to their pet language.
There you have it, OP. Trannies sexually identify with it. Why don't they compare Golang to their lifestyle choices?
Are you implying Golang has no nutcases? https://www.youtube.com/watch?v=ZACOc-NwV0c
I see no nutcases in that talk.
first post worst post
Weak type system.
You can't make generic monads or functions that take in any tuple type.
GATs solve some problems but the syntax is pretty bad, even though it's one of the prettier proposals.
>any tuple type
as in tuples of different types or tuples of different length?
Both.
If all its types were the same, it would be better to just use an array, no?
that's why I asked, you can have generics over tuples of different types
you can't have over tuples of different lengths since they're different types with different fields, a 3-tuple doesn't have a member "3", like 4-tuple does
Yes, different types with bounded length and same types with unbounded length work fine, but having both doesn't work.
Even std has a bunch of silly code repetition because of that limitation.
Slow to compile
Tons of build artifacts
Not amenable to dynamic linking because generics are monomorphized in the caller
Freestanding support is lacking
Async was rushed
GATs are unusable
Pin is unsound
No variadics
No namespaces in Cargo
panic!
also, c gets a lot of flack for cpp but cpp is dead simple. c++ templates are complained about but c++ templates are c++. rust macros are nuts
Rust macros get a pass because libraries wrap them nicely and most programmers don't have to think about them.
Currently, Rust circles are deliberating whether the equivalent of template<class T> using U=... is too complex to allow in the language.
It's already in the language...
type Alias<T> = ...;
It's half in the language.
Try putting that inside a trait in stable.
>moving goalposts
Even so, GATs are due to be stabilized in the next release.
I don't consider half-in to mean in.
And the stabilization isn't going too well, in case you haven't followed the PR.
>cpp
>dead simple
Did you mean c?
no Black person, i meant cpp. all ur c shilling is degrading your mental health. there is no reason to use a gimped language like c for anything, not even kernels or embedded.
nearly all projects use c++, stockfish, the best chess engine is open source and uses c++.
windows uses c++ even in the kernel
c++ us the de facto standard in game development
mlocate on ubuntu is a transitional package to plocate a better utility written in c++
face it Black person. your days are over.
rhe truth is son, you are a 12 year old, i bet for all your shilling you didn't even get past printf let alone implementing your own memory allocator.
He means the pre-processor.
>Pin is unsound
source?
>Slow to compile
yes
>Tons of build artifacts
yes
>Not amenable to dynamic linking because generics are monomorphized in the caller
yes, also no ABI, except C
>Freestanding support is lacking
agreed, no_std support is quite shit
>Async was rushed
not much experience there, but i've never heard anything good about Rust's async
>GATs are unusable
tell me more
>Pin is unsound
tell me more
>No variadics
true
>No namespaces in Cargo
true
>panic!
i assume you mean absence of things like fallible allocation, which is QUITE a fricking omission for a self-described ~~~SYSTEMS LANGUAGE~~~
i would also like to add pathetic bootstrapping to the list. https://guix.gnu.org/en/blog/2018/bootstrapping-rust/
finally, the community is cancerous as hell, and the syntax is ugly.
>if you are a experienced C dev memory bugs is not that big of a problem, so...
delusional cniles, i fricking swear
still beats learning what became of C++ lmao.
>absence of things like fallible allocation
Nope. vec has try_reserved now in stable, which can meet all requirements for fallible allocation.
Here's the best way I can think of to do an allocation-safe str::replace():
use std::collections::TryReserveError;
pub fn try_replace(orig: &str, from: &str, to: &str) -> Result<String, TryReserveError> {
let mut result = String::new();
let mut last_end = 0;
for (start, part) in orig.match_indices(from) {
result.try_reserve(start - last_end + to.len())?;
result.push_str(&orig[last_end..start]);
result.push_str(to);
last_end = start + part.len();
}
result.try_reserve(orig.len() - last_end)?;
result.push_str(&orig[last_end..]);
Ok(result)
}
(Does it work? Probably, but if I messed up a try_reserve() it'll be silently capable of panicking.)
There is no stable allocation-safe way to create an Rc or an Arc.
There is not even an unstable allocation-safe alternative to (e.g.) std::env::current_dir().
It's not totally absent any more, but it's hardly a solved problem.
Rust has a few POSIX APIs in the standard library under std::os::unix. I'd love if it had more, calling libc is unsafe and tedious while the nix crate is not very high-quality. I've used them for retrieving user info and creating pipes, for example.
>they would create inifinite-size types
Not if they're behind pointers. You can already have a &Self or Box<Self> as a member, but you can't parametrize a type with itself.
But like I said before I've never needed this or even noticed it before. It seems niche.
No point asking this on a board where almost none of its users know anything about the board subject.
>top-right
this is who represents you, rust anti-shills
Is something said in that video that you disagree with?
The ecosystem is just fricking awful. Half of it is unmaintained version 0.0.x shit made by people who ragequit back when the language was unstable, and the other half is full of "async creep". Way too many crates make async mandatory instead of being an optional feature. I'm not gonna play the npm card like an autist (javascript is on its own special level of shit), but crates.io is nonetheless a case study in how webshits should not be treated as first class citizens. Ever. Even the NEET manchildren on IQfy are more competent.
Less autistically, lifetimes can be a rabbit hole of complexity if you are making a library. They're working on this, but it feels like it'll be a while before it Just Werks for most cases.
I've never seen a library using async when it's not needed.
Async is superior way of dealing with any kind of I/O.
Not all applications are I/O bound. Sometimes I want my concurrency to be synchronous, or don't need my program to be concurrent at all.
Then just don't use a library? I don't understand, give me an example where you wanted to do something that is not concurrent but the library for that was async.
If you are doing something as simple as connecting a TCP socket or reading a file or http request, sure you do not need async and there are libraries/stdlib that allows you to do just that.
Async is used in places where you are actually bound by I/O, like a web server. If you do not make it concurrent then you are pretty much purposely borking your own solution. I never seen anything being async that had no reason to use it.
>Then just don't use a library?
Hence the "creep" complaint. I more or less stopped caring about Rust since the quality of the ecosystem is so poor overall, so it's not my problem anymore.
>Async is superior way of dealing with any kind of I/O.
hard to really say honestly. On loonigs, you don't really have many choices sans the spooky I/O at a distance shit like io_uring. But ya, for concurrent I/O, sure I guess. I still mostly do synchronous I/O and usually use mio and a custom event loop when I need it. too lazy to go all in on making my own futures or tokio mainly because I don't like having to pin everything to the heap. I get why futures are stackless and shit, but damn.
>but crates.io is nonetheless a case study in how webshits should not be treated as first class citizens. Ever. Even the NEET manchildren on IQfy are more competent.
Holy fricking KEK
From what I've seen of Rust, it's designed for the problem domain of replacing "modern' C++17 or newer code large-scale native applications, the kind that is full of std:: magic and unique_ptrs and the devs are anal about const correctness.
Chrome's code is a prime example of what sort of code is the best suited to be rewritten in Rust. This is unsurprising, since Moz developed it to write a browser in it.
For other kinds of code, like your typical backend, or moible app code, and other programming styles, it's either too much mental overhead, or is an awkward fit.
I like c
I like c#
I like vb6
Are rust
Simple as
Rust has been known to degrade the performance of your pc. It obliterates your components.This obviously leads to serious performance degrade. If you have rust any techie will tell you that it's time to either a) replace your machine or b) start cleaning your computer with some form of anti-rust lubricant. Popular brands are WD40 and Veslee.
can you index a string in rust yet
no, and that's a good thing
rust does things right from the start, even if it leaves brainlets confused because in their limited worldview something is valid when in reality it isn't
But Isn't a string fundementally just an array of characters? And shouldn't that array not be indexable?
It's an array of bytes. The bytes contain text encoded in UTF-8. A single character may take up multiple bytes.
If you want to index the bytes you can do that.
Ah, neat. Thanks for the info.
Rust always seemed to me like the program that everyone Is waiting for one another to use so they can see if people crash miserably with It or If you can actually use It at an industrial level.
it's an ordered sequence of characters (well, the order kinda breaks once you mix left-to-right and right-to-left languages, but let's ignore that)
but what is a character?
if you completely forget about the existence of computers, at it's core, it's an image
but what about font, or different people? your 'a' may look different to my 'a'
so it's not an image, it's some abstract concept that can be matched to a multiple images
but what makes 'a' a character as opposed to a drawing of a house, that house is also represented by some image on paper
which brings you to chracter sets, which are definition of what characters there are, there are 3 options:
>stuck in the 80s with ASCII
>codepages ale windows, which wouldn't give you a string type, but multiple flavours of a string, incompatibile with one another
>and unicode, which the right choice
but unicode is very, very complex
so you got your character set, and unicode defines nice binary representations for each of them in the form of codepoints (which at this time all fit in 32bits)
except not really, one codepoint is not always one character, it can be two, or more, so a character is represented by a grapheme cluster (1 or more graphemes aka codepoints)
then comes in encoding, 32 bits per character is a lot, you can cut down the memory usage significantly, if you use utf-8 which will take one or two bytes for most strings
but the problem is, utf-8 is variable sized
now, we want to use an array cause it's fast
cont.
an array, has to have a specific property
> An array is stored such that the position of each element can be computed from its index tuple by a mathematical formula.
Which means unless your array is fricking wacky it's O(1) access time.
To do this it requires each of it's addressable elements to be of fixed size, if all Things are length X, then 3rd thing is start+X*3
but, unicode characters aren't the all same length, a 2 codepoint character is different length than 1 codepoint character
so it can't be an array of characters, we go down a level
utf-8 codepoints aren't all the same length, they can be from 1 to 4 bytes
so we go down a level
and arrive at an array of bytes
which then can be interpreted as an ordered sequence of utf-8 encoded codepoints, which then can be interpreted as an ordered sequence of characters
which one of these would you want if you're indexing? a 2nd byte, codepoint, or character?
so in short, it's not just an array of characters
Yes.
String::from("abc").as_bytes()[0]
Do you want the nth byte or the nth codepoint or the codepoint starting at the nth byte or perhaps the nth extended grapheme cluster?
Rust will not let you index before you answer this because it's an extremely pedantic language
Better than dealing with a language that doesn't know what the frick unicode is.
Better to use unsafe in like 1-2% of your codebase than fricking all of it. Rust isn't to make things 100% safe, it's to make things safer overall.
>Better to use unsafe in like 1-2% of your codebase than fricking all of it
Thats how anyone with a functioning brain understands it but of course the moron you replied to is only interested in talking about trannies and he thinks Rust is still maintained solely by Mozilla.
"Hate" is a strong word, but the biggest change rust brings is the borrow checker, and if you are a experienced C dev memory bugs is not that big of a problem, so...
As an experienced C dev, memory bugs are probably my most common bugs. Combine that with a non-trivial piece of software that isn't allowed to crash, and mix in a few junior devs and interns, and you have a recipe for headache. Worse yet is that these bugs often show up in old code you haven't touched in months. C is only safe when you write it in the least performant, purest, highest way possible, which often defeats the point of using it.
> you are a experienced C dev memory bugs is not that big of a problem
It’s the other way around. If you’re an experienced C developer, memory bugs are your biggest problem. Beginners do not work on non-trivial projects and thus do not run into nasty memory issues.
Another LARP fail you got destroyed by the other 2 replies.
A pointless language to anyone who already knows C or C++ well. Also, pointless for beginners who actually want to do coding for living.
>other than being mostly used and shilled by trannies
Do you really trust trannies, who can't even figure out basic stuff like sex and gender, about what is a good programming language?
Ok, but who are they? It's not the developers is it?
So it's some group of users who are trannies? Who? Or is there some statistic that shows this?
Where does this claim that "it's used by trannies" come from?
>We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.
Go on any rustlang discuck server full of trannies. Even accounts on twitter that shill rustlang are trannies
https://cybre.space/@kinsey/103462588091845199
https://www.redbubble.com/i/sticker/Gender-is-a-String-Rust-Transgender-by-petra-the-kat/49198190.EJUG5
https://www.reddit.com/r/transprogrammer/comments/qo7k3k/let_trans_rights/
Take a break from the internet because your obsession with transexuals isnt normal.
Sorry you are too much of a brainlet to use google I guess. "You googled stuff to back up your point? Totally obsessed huh"
You are trying to make a point how a language with at least 2.4 million users is used only by transexuals because of some sticker some random person made and when you get called out go complete apeshit. Yes you are completely obsessed.
It's not some sticker you moron, all their community are a bunch of trannies are homosexuals like yourself, just look at the downfall of actix
You are literally so mad your sentences are broken and you forgot what a sticker is, the actix drama was a moronic MS dev who used unsafe blocks everywhere and when people made commits to fix his mistakes he took it personal and got pissed and actix works just as good now.
The Actix maintainer was 100% in the wrong. He got butthurt about people pointing out actual bugs.
Behold, the absolute state of rustgays. Thanks for proving my point, trannies. Go on dilating now and join the 40%
Not an argument.
Neither dogmatically being against unsafe is an argument. The guy created one of the fastest servers ever only to get his balls busted by fricking trannies and morons
It would be different if his code was unsafe but sound. This was not the case. Much of the unsafe code was also unsound, i.e. caused undefined behaviour. Even if it worked under certain conditions (which I'm sure it did, or it wouldn't have been checked in at all), it was still wrong - on a different machine or using a different compiler version, it could easily break.
>it doesn't matter if they were right or wrong, it hurt his feelings
I will never be a woman but you're acting like one already
You're the one acting like women by following blindly the herd of
>NOOOOOOOO YOU CAN'T USE UNSAFE CODE!!!
homosexual
But are they activists about it or something?
Are these the "cancel culture" type?
Or are they just random people who happen to be transsexual, but aren't doing anything to bother anyone, just keeping to themselves and working on their own projects?
Yes, you moron. Their license sucks, they're against privacy. Again, just look at the bullying done to the Actix maintainer. I hope all morons like you use Rust even more so I can enjoy watching them getting screwed over lol
The syntax is over-engineered.
Don't think about the technology. Forget the idea about implementing Rust through a compiler. Forget that engineering part.
Think about the RUST NOTATION SYSTEM.
The language that abstracts the implementation.
It is a syntax whose order of magnitude is not human. It is a syntax created by committee.
The programmer serves the Rust system. Rust is not a in the service of the programmer in the syntax.
its amazing how similar Rust is to the modern trans mentality.
is troony a political ideology these days?
where the frick have you been?
Must be nice. I'm rather envious T B H.
> Muh syntax
Rust isn't even the worst syntax I've ever seen, let alone bad. Its okay. That's it. It works. Its serviceable. Its not even exceptionally different from any other language. Its astounding how much IQfy hates a language they know nothing about.
The prose of The Rust Programming Language (2018) exposes the shortcomings of the syntax.
>we should do this
>but we can't, so we must do this
>this is incorrect
>so, instead, we do this
Say what you will about bytecode technology, I will concede and kneel, but for example, in Ruby, Yukihiro Matsumoto knows what he's doing, has an absolutely clear vision, and is thinking in human magnitude. He knows what he wants from syntax and paradigm and Ruby is the product of a single mind, with a clear and direct goal.
Rust Programming Language's prose, on the other hand, as a book, constantly references scenarios that clearly appeared midway through exploration and were obstacles the team only could solve on the fly and with tricks. Its fundamentals are not solid, smacking of patchwork solutions bracketed on top of each other like post-it notes.
Rustonomicon (2015-2016) is basically damage control from the Rust development team.
Do you have examples of when the book does this? I'm genuinely unsure what you're talking about. I can see how someone would mistakenly get this impression from the explanations about lifetimes but not when it comes to syntax.
I think the most direct example is how the language is sold from the marketing department as a totally secure language when, deep down, it is possible to do insecure and irresponsible things with it through the study of the Rustonomicon and even without the programmer's willingness to do on purpose.
It claims to be the technology that solves the security needs for the twenty-first century as the compiled language for systems that naturally displaces C and C++ by right of might, when at the end of the day it inherits the same problems of its ancestors in a different form.
Consider that a language that really was what it claims to be from an advertising point of view, would have things covered as a technical standard or specification as for example the Scheme families have, but the development history of Rust resembles from afar a big ball of spaghetti hurtling down the hill.
It must meet certain requirements that are clearly not even in the core design philosophy of the project. And worst of all, it lies about it.
>Do you have examples?
>I think the most direct example is <not an example>
you keep going back to shit like "marketing" (what marketing?), development history and design philosophy, because you're a fricking redditspacing pseud who can't actually program and provide concrete examples, so instead you larp on IQfy to feel smart
I'm going to read The Rust Programming Language again and promise you to build a code-based argument for you. Believe me, when I started the day I didn't expect to start talking about this language.
I don't hate Rust, I like Cargo, I get autism with some of its ideas, but I don't see a mature technology.
I just hope I can run into you in the future.
The official messaging doesn't promise total safety. I'm sure you can find Medium bloggers saying crazy things, but that's because they're Medium bloggers, not because it's Rust.
You can bypass Rust's safety mechanisms. You can also dereference raw pointers and call C code in Racket. Does that make Racket's memory safety a lie? I don't think so.
All safe languages are built on a foundation of unchecked code.
>would have things covered as a technical standard or specification as for example the Scheme families have
Can you give a specific example of something this would solve?
>It must meet certain requirements that are clearly not even in the core design philosophy of the project
Can you name a few?
>10mb
300kb
>can you give a specific example of something this would solve?
Order. Clarity. Maturity. A specification provides a universal reference point for building implementations that extend the scope of a programming language in an organized,
orchestrated and symmetrical manner. If Rust is to establish itself as the lingua franca of the future, a specification is the cornerstone for a correct development and evolution of the language, without surprises or confusion, but above all, security.
Cybersecurity is the application of policies that are executed through implemented procedures, but cybersecurity starts with the definition of organizational policies. Pen and paper.
If organizations need to write down on paper policies and procedures in order to establish Confidentiality, Integrity and Availability, all the more reason why a programming language needs a specification!
There is ongoing work done in the direction of a language spec: https://ferrous-systems.com/blog/ferrocene-language-specification/
Thanks for the information anon, this looke interesting.
this is quite possibly the dumbest, most non-answer post ive ever read on this hellscape site. stick to eating your own snot rather than giving any input on matters you don't have the mental ability to comprehend.
>all these words just to say "I dun liek the syntax"
Number 1 problem is that the borrow checker is too stupid. Not that it exists: that's great, it can catch a lot of bugs.
But it can't see past the function/method it's in.
If borrow checker is complaining about some call to a function and I can copy-paste that function in by hand (i.e. inline the source code) and the borrow checker is happy, it should accept the code.
It's just too limited in scope and it's super annoying. You end up either with macros instead of functions (because they basically "copy-paste" the code for you) or manually copy-pasted stuff going out of date all the time.
>the compiler should just infer lifetimes
Cool, have fun maintaining semver, all your dependencies will be on version 50 by the end of next year.
NPM style dependencies, that aren't validated by anyone. (like npm, this leads to huge dependency trees full of useless deps)
also compile/link-times are slow af. (only amplified by those huge dependency trees. and instead of choosing the obvious thing (letting the distro ship precompiled dependencies, like any other relevant lang, they try to push dumb chaching solutions)
Its tooling hasnt caught up, it has a 10mb hello world binary(not okay), its not even that much easier than c++
It might be better at web stuff but then you might as well something else since its performance is overkill
Its mainly just used for crypto and that makes the rust people seethe
>Argument is a hello world program
Shameful.
How can anyone tolerate rust on any of one's stuff?
The license
No POSIX API in standard library, systems language without syslang ability, even fricking Python has "os"
No recursive or self-referential generic types
Suffers from the same issues as C++, 3 types for strings etc
tbh I hate Go more for its moronic type system but Rust still sucks for me
>No POSIX API in standard library
really?
>No recursive or self-referential generic types
How often does this come up? I'm surprised I never noticed it.
>3 types for strings
What's the superior alternative? How do you deal with C FFI and invalid platform-dependent unicode otherwise?
>No POSIX API in standard library, systems language without syslang ability, even fricking Python has "os"
there are non-posix systems, what specifically are you missing that isn't covered by the rust cross-platform APIs for interacting with the OS and why would that have to be in the stdlib?
>No recursive or self-referential generic types
of course, they would create inifinite-size types
>Suffers from the same issues as C++, 3 types for strings etc
3 types of strings because there is no one "string" and different things expect their strings in different forms
like the OsString, which would be a string specific to a given platform/os (which rust supposedly doesn't interact with)
>3 types of strings
&str, String and what else?
>&str, String and what else?
C++ actually has a *single* string type, std::basic_string<...> and nothing else. null-terminated string arrays are from C.
>inb4 string_view
Grow up.
>inb4 millions of template specialisations
Also grow up.
string_view
basic_string is not a type it's a templated type, a collection of multiple types, you could say it's infinitely many types, but it would be constrained by char_traits in the std lib
or if you want to be very pedantic you can say C++ doesn't have a string type at all, as string literals produce char* and basic_string doesn't specify any encoding and makes no guarantees that it's contents would be a valid string
>string literals produce char*
There are different literals for std::string. There are also user-defined literals, so you can have an unbounded number of those too.
Do people use them much? I think basically all C++ code snippets I've seen use traditional literals, unless they need UTF-16.
Specifying a literal to be string instead of char* sometimes helps the compiler find the right overloads.
I haven't seen user-defined literals very much. The JSON lib I use has JSON literals though: "[1,2,3]"_json
Probably meant String/str, OsString/OsStr and CString/CStr
>there are non-posix systems
Windblows, and what else?
>recursice types
You can have recursive types like type-level lists, but it requires using two different generic types in the definition (so that size is well defined). See: https://beachape.com/blog/2017/03/12/gentle-intro-to-type-level-recursion-in-Rust-from-zero-to-frunk-hlist-sculpting/
What do you mean parametrize a type with itself? Types are things like structs or enums. Type parameters are traits and lifetimes. And you definitely can have a where Self: foo + bar + 'baz clause.
error[E0391]: cycle detected when expanding type alias `A`
--> src/lib.rs:1:14
|
1 | type A = Box<A>;
| ^
A is basically reasonable, but Rust doesn't like it.
struct S(Box<S>); is OK, but they said "recursive generic types", not "recursive types", so I assume they meant this.
No, it's not reasonable. It's a paradox. An unequality.
It's not at all paradoxical, it has a clear meaning (one that's similar to S).
It would make the compiler internals more complicated, I expect that's why it's not allowed. But it's reasonable.
Some Python typecheckers support recursive aliases, others don't.
A is potentially reasonable, but it would be uninhabited.
True, it would have to be type A = Option<Box<A>>; to be constructible without UB or even type List = Option<(i32, Box<List>)>; to be plausibly useful.
Yeah, I hadn't considered that there are potentially useful recursive aliases. The technical terminology is equirecursive vs. isorecursive types. Equirecursive types are used in structural type systems with subtyping, and isorecursive types are used in nominal type systems. Rust has the latter, hence it has no equirecursive types.
>equirecursive vs. isorecursive types
Neat! I just read a little about it and will dwell on it.
This made me realize that Rust would have to be able to normalize type A = Box<A> and type B = Box<Box<B>> into the same type, so a naive approach I had in mind earlier wouldn't fly.
>Order. Clarity. Maturity.
none of these is specific
>a universal reference point for building implementations that extend the scope of a programming language in an organized,
orchestrated and symmetrical manner
natural languages, in which specifications are written (even if very technical) are anything but organized or orchestrated
there already is a better reference point for implementations - tests
>need to write down on paper policies and procedures in order to establish Confidentiality, Integrity and Availability
no they don't, not for computer programs
Computer programs are the implementation of domain logics that are defined as phenomena that receive inputs and generate outputs. These phenomena must fulfill restrictive conditions.
By specifying the formal language used to implement these domain logics you are delivering to the organization something called consolidation.
>tests
No one is denying the possibility that a specification is born of empirical knowledge. It is entirely possible.
I would like to read a solid counter argument to the post instead of reading a colorless and listles comment.
People promised me it was better and less awkward than C++ it turned out to be pretty much the same,. No reason to migrate until they get a proper ide+Gui dev kit support honestly.
Rust is so hated you have to ask us why we hate it.
Rustbros, I got sick of how pozzed all the official rust communities were, so I have decided to set up a new forum.
It’s a comfy PHP forum like the good old days, not SPA soishit like the official forum.
Trannies are banned, off-topic political discussion is banned, and there is no language policing.
I will never run ads or ask for money, I am running this entirely out of my own pocket. I am disgusted at the direction that modern tech communities are going in and I think those of us with opposing views desperately need representation in communities on the wider internet, that’s why I’m running the forum.
Here’s the link, a few people from IQfy have already joined:
https://www.rustuf.net
>Trannies are banned
>RustConf right there in the subjects
Nice bait.
Trannies and Rust go hand in hand.
>borrow checker makes development very slow
And it's fricking pointless.
borrow checker makes development very slow, and no it doesn't get faster the more you become used to it like the trannies want everyone to believe
The borrow checker doesn't really enforce anything that you wouldn't have to also do in C++ to have safe code
If you find the borrow checker is "slowing you down" then you're trying to cut corners and write broken code
It looks like perl and c++ had a baby
I hate rust because
1. I invested 3 minutes of my precious lifetime reading about it
2. Turns out, there are no jobes
=> 3 minutes of my precious lifetime wasted
I will always remember this moment.
It was June 16, 2019, David Marcus testifies in front of the US Congress for the Libra/Calibra/Diem project, the blockchain created by Facebook/Meta that wants to position itself as the cryptographic capital system of the planet.
U.S. House of Representative member, Republican Denver Riggleman, asks David Marcus why the Rust programming language was chosen for the construction of the project.
This is the time to shine!
It didn't.
If you want to do anything worthwhile you have to
>unsafe
Which defeats the purpose of using it.
Go to any fork of something that they remade in rust to make it safe and grep the code for the amount of unsafe's used. Always there, every time, usually hundreds if not thousands of times.
Also, it's some kind of Black person version of pythons pip but rust gays are too moronic to write any code and rely on using hundreds of crates.
I recently found a cool project on github using rust but because it's such a nightmare to compile with all their bolocks I thought I'd write a github action to do it for me. Upon forking it, github (or technically dependabot) notified me 20 hours later that 15+ dependencies had medium to high security issues and CVE's filed against them. The main repo puts out releases knowing these exist.
So that's why I hate rust and mozilla trannies in general for attempting to force their mutilated wiener language down my throat.
>anything worthwhile
such as?
and no, reimplementing a container for the thousandth time is not worthwhile
>Go to any fork of something that they remade in rust to make it safe and grep the code for the amount of unsafe's used. Always there, every time, usually hundreds if not thousands of times.
Ok, picrel, one of the four is in a changelog
>Also, it's some kind of Black person version of pythons pip but rust gays are too moronic to write any code and rely on using hundreds of crates.
right, it's definitely them who are Black folk instead of people who actually understand what they're using
>it's such a nightmare to compile
you're just fricking lying, it's always just a cargo run, link it
>So that's why I hate rust and mozilla trannies in general for attempting to force their mutilated wiener language down my throat.
>So these imaginary issues I think I would have, and the trannies in my head, are the reason I spout my moronic opinion on IQfy, even if I could program, I wouldn't use it
I want to breed a Rust sissy
So im just do programming as a hobby and only really have experience in C++, but iv been looking at rust (about half way through that rust book on their site) and iv got a couple complaints already.
1. the compiler trying to enforce a naming convention is pure unmitigated homosexualry
2. The ownership thing feels less like a "feature" and more like a corporate wet dream to create an idiot proof language so they can replace everyone with cheap pajeets who will just be stopped by the compiler before they can do anything dangerous. Unsafe keyword and variables default being nonmutable also feel like corpo shit where they want to you to have to explicitly take ownership of deciding to doing something that potentially could cause issues down the line.
3. I feel like its usually sold as a "new and improved" c++ but so far it looks to actually be structured pretty differently. Its not just C++ with cleaner syntax and features. Nothing inherently wrong with it being different but I dont trust a community misrepresenting itself like that tbh
For positives.
Being able to return mutliple values in a function with tuples is cool though. As is enums being able to store values and not needing to split everything into header/source files. Cargo seems very nice too. Need to play more with the language to see how I feel about traits.
So far I guess its a wash which language I will like more? (The rust community needs to take the stick out of its ass though)
>1. the compiler trying to enforce a naming convention is pure unmitigated homosexualry
nah, forced style conventions are a good thing, if you don't like it, you can opt out no problem. rustfmt and naming conventions make codebases easier to jump into and understand what's happening. it's good for your own code and others'.
>2.
these are all good things i personally want for my own code and wish other languages made it as easy and idiot-proof. as you can probably see already, the borrow checker is still too hard of a concept for many programmers to grasp so if they can't follow something for "idiots", why would i trust them in a less "safe" language? also immutable by default is more academic than corporate.
>3.
not the community or language's fault really. because there's so little to compare languages by in describing them to others, people make crazy comparisons. i wouldn't describe it as c++ either but people who use the language and don't say it's like an improved c++. it's closest in some of the goals it tries to solve with c++ but i wouldn't say it's that similar. the entire community isn't a monolith and a lot of people who advertise it don't even use the language, just like with tons of other languages.
>the compiler trying to enforce a naming convention is pure unmitigated homosexualry
Agreed, even if I like the conventions (but not the rustfmt formatting). Luckily it's just warnings and you can disable them if you like.
>create an idiot proof language so they can replace everyone with cheap pajeets who will just be stopped by the compiler before they can do anything dangerous
That can't be true because Rust is harder to learn and get started with than C++. It also requires higher ability to reason and think systematically. If you want an army of cheap pajeets it's the wrong language.
>Unsafe keyword and variables default being nonmutable also feel like corpo shit where they want to you to have to explicitly take ownership of deciding to doing something that potentially could cause issues down the line
It's there to have an escape hatch for when the type system is insufficient to express something. In addition it explicitly marks regions of code where soundness guarantees could be violated which helps reasoning about the code. If someone fricks up code it doesn't matter if it's in an unsafe block or not.
>how I feel about traits
Traits are awesome! So much of the language is based on mechanisms expressed through (mostly) orthogonal traits that implementing a few for custom types often gives you a whole load of functionality for free. Definitely look into associated types and how to make use of them and how to express type constrains. If you like puzzles you will love this part of the language.
>So far I guess its a wash which language I will like more? (The rust community needs to take the stick out of its ass though)
I'm not trying to convince you or anything, but you might try thinking about the compiler as more of an assistant than a nagging language lawyer stopping you from doing as you like.
didn't read lol
fn main(){
let mut line = String::new();
println!("Enter your name :");
let b1 = std::io::stdin().read_line(&mut line).unwrap();
println!("Hello , {}", line);
println!("no of bytes read , {}", b1);
}
That looks ridiculous. In C++ its just cin and cout.
use std::io::{stdin, Result};
fn cin() -> Result<String, usize> {
let mut s = String::new();
let b = stdin().read_line(&mut s);
return b.map_or_else(move |e| (String::new(), b),
move |s| (s, b));
}
fn cout(str: &str) {
println!({}, str);
}
fn main() {
cout("Enter your name: ");
let (name, b) = cin().unwrap(); // Should handle this, tho
cout("Hello, {}", name);
cout("Bytes read: {}", b);
}
But can you use macros to implement the unnecessary "<<" syntax
You don't even need macros for that. You can just implement the Shl and Shr traits. You'll need to use newtypes because you can't implement external traits for external types directly, but it'll work.
https://doc.rust-lang.org/std/ops/trait.Shl.html
https://doc.rust-lang.org/std/ops/trait.Shr.html
I don't know Rust I just wanted to see someone create an abomination for my amusement.
you'd probably make a newtype and overload these. not sure if someone's done it.
https://doc.rust-lang.org/stable/std/ops/trait.Shl.html
https://doc.rust-lang.org/stable/std/ops/trait.Shr.html
Good job, now it's extra ridiculous.
Cuck license
We said non meme reasons
At the risk of asking something dumb. Can I not have all my source files in the same folder and link them as needed? From what im reading its starting to look like rust wants/needs some autistic folder organisation for linking files together?
You can do that, you don't need a folder structure. The module system isn't the same as how the files are represented on your system so it can be a little confusing.
With respect to how you want to structure your files, you have a decent amount of flexibility. It helps to understand how the module system works, however, so you don't get confused about how to import some other file in some other directory. You may even want to separate your project out into separate crates, each of which having its own Cargo.toml file and such.
You absolutely can have just a main.rs and other rs files alongside it.
No modular compilation. Refuse to integrate smoothly in my Makefile.
Rust is troony shit. Enough said. If you need any other reason to avoid it you're probably a troony.
I don't like the whole beginner friendly cult.
Or rather how it's misguided.
They compare themselves to dynamically typed or GCed languages. There's an inherent complexity with manually managed memory. While static typing will always feel like too complex for people who never programmed or only ever used dynamic typing.
I really don't understand why they're trying to appeal to Javascript devs so goddamn much.
>I really don't understand why they're trying to appeal to Javascript devs so goddamn much.
Not ironically?
Empirically it seems to work. I came from dynamically typed languages and did just fine, and I'm not the only one.
>There's an inherent complexity with manually managed memory. While static typing will always feel like too complex for people who never programmed or only ever used dynamic typing.
Where do you think C and C++ programmers come from? Do you think they were born knowing how to reason about memory?
Everybody has to start somewhere.
Yeah, exactly, C and C++ programmers were able to learn all of that without holding back the language or useful features roll out
Are you saying Rust is held back? In which way?
GATs is just one of the many examples
Do you think Python programmers are the reason GATs aren't stable yet?
And how does C do this better at all? C is neurotically afraid of adding new features.
>Do you think Python programmers are the reason GATs aren't stable yet?
not specifically, but their wish to cater to people who're unfamiliar with the most basic fundamentals and wanting the leap to be somehow effortless definitely is.
it's not just about stability of GATs. it's design of it, even the choice of GATs over alternatives.
>And how does C do this better at all?
C has completely different goals, it should be compared with C++ which has its own mountain of problems and failures.
>Do you think Python programmers are the reason GATs aren't stable yet?
GATs aren't stable yet because people started arguing that they're too complicated but not powerful enough.
It's not necessarily Python programmers but the guess isn't too far off.
>GATs
Whats this?
I tried compiling MMAccel from source to see if I could viably translate the thing
it did not want to compile and since I'm not a discord pleb I could not
therefore rust = bad
Nobody actually cares about the developers behind rust - unless they are wokes and it shows in their work, which afaik it doesnt. Rust just sucks to write, the compiler is slow you get a package manager inspired by npm with the language complexity of c++, mix in some more FunctionalBrogramming and you have an ecosystem that's very unappealing. Oh aync/await just seems inferior to CSP.
The do have one good thing. Temporal memory safety(ish?) without a gc. That one feature carries a lot, but not hard enough.
It's exciting to see whether Stroustrup shoehorns lifetime checks into C++ before Rust fixes its problems.
>Rust just sucks to write
Only if you are a brainlet.
>the compiler is slow
When you write in rust you very rarely compile your code. Most of the things are checked statically by language server and you only hit compile after you've done writing everything.
>you get a package manager
That's a good thing. It's waay more comfortable to use than downloading, compiling and installing dependencies manually.
>language complexity of c++,
Systems programming is complex. If you want simplicity, use scripting languages.
>mix in some more FunctionalBrogramming
Functional programming is great and it allows you to express a lot of invariant in the type system which let your write provably safe code.
>you have an ecosystem that's very unappealing
It's the most loved language according to polls.
>aync/await just seems inferior to CSP.
Who even uses CSP?
It's extremely convoluted and memory management in C isn't that hard.
>memory management in C isn't that hard
Then why do people keep fricking it up?
Most people are idiots.
Do you want the idiots who write the software you use daily to use C or C++ or Rust?
Idiots can't understand Rust, they need a language that lets them do moronic shit because they are moronic and only know the moronic way. Smart people don't need Rust because they aren't moronic.
smart people know they can make mistakes
>Smart people don't need Rust because they aren't moronic.
The whole reason why high level languages exist is because no one can be trusted 100% of the time. We make them to build abstractions to reduce surface of potential bugs and make it easier to comprehend what is going on.
>Smart people don't need Rust because they aren't moronic.
I actually don't use Rust because of its safety features, at least for my own sake. Its safety features are more interesting to me when I want to use other people's code. If they expose a safe API, regardless of whether the implementation is safe or unsafe, I know exactly what that code assumes from and guarantees for me. It's one thing to say that you can write correct code in an unsafe language like C or C++, but another thing entirely to say that you can use a library safely without having to pore over informal safety guidelines in its documentation, or worse, and frankly more commonly, look at its source code and figure it out for yourself because the documentation is just not informative enough.
I can't compile rust so I'll take C or C++
Ownership rules requires too big of an upfront api commitment. Lifetimes seem like they will work fine for your app until they don't. The Rust community seems to be slowly realizing this and thus defaulting to reference counting everything before optimizing, resulting in a dumb and ugly Swift. Graph data structures are an exercise in frustration. Async/await has color functioning problem and other ergonomic issues.
Rust doesn't attempt to make allocations explicit like Zig. If the use case affords hidden dynamic heap allocation theres a strong chance GC will be affordable as well.
Rust's anemic std lib makes it unsuitable for general purpose programming and increases the blast radius of supply chain attacks.
Rust pretends to support FP but only in a very shallow passing inline only anonymous functions sense. Closures are weird due to ownership. The lack of higher kinded polymorphism makes all sorts of fp type autism impossible. No persistent datastructures. Monad chads laugh at the `?` operator. Tail calls never ever. FP is now a requirement to scale across muh cores.
whats rust?
There is no way to develop Rust securely.
rustup is installed as curl | sh and it does not check GPG signatures on binaries it downloads (so compromised CDN -> instant code execution). https://github.com/rust-lang/rustup/issues/2028
cargo build-ing any reasonable-sized project will npm-style download thousand packages (remember leftpad? it is that bad) and execute their buildscripts.
nobody cares about dependency bloat, and people just bump up Cargo.lock versions as soon as new one comes out.