The continuing story of why Rust is shit

...
19. No method overloading. No, type inference is not worth it.
20. Have to import implemented Traits separately to use this functionality on some Struct. This is, of course, absolute insanity.
...

Other urls found in this thread:

github.com/rust-lang/rust/blob/master/src/libstd/io/mod.rs
github.com/rust-lang/rust/blob/master/src/libstd/fs.rs
en.wiktionary.org/wiki/baby_duck_syndrome
twitter.com/SFWRedditGifs

Where can I see the whole thing?

I know this is bait I that I'm replying to someone who doesn't even care about the response, but here is it anyway.
>19. No method overloading. No, type inference is not worth it.
Method overloading is a non-feature, unless you are an IDE fag. There is no way to differentiate between A(x) and A(x,y) without documentation, or if you are an advocating insane naming schemes like AWithOptionalY(x), AWithOptionalY(x,y).
>20. Have to import implemented Traits separately to use this functionality on some Struct. This is, of course, absolute insanity.
That would break namespacing. Anyone can call his trait Cursor, Read, Write, whatever you fucking like be it an std trait or not you just have to import stuff accordingly.

Are you really too dumb to use overloading without an IDE holding your hand?

>That would break namespacing. Anyone can call his trait Cursor, Read, Write, whatever you fucking like be it an std trait or not you just have to import stuff accordingly.

How this works in real life is absurd and can make the most harcore OOP hater yearn for good old inheritance back.

Example, you want to read a File from the file system into a text string:

use std;

let mut file = std::fs::File::open(path).unwrap();
let mut contents = String::new();
file.read_to_string(&mut contents)?;

This will fail, because you have to actively look up potentially tens of different behaviors of a certain struct and import them all separately. Needless to say, how Java, C# or any modern OOP language handles this stuff is an order of magnitude more intuitive. I want to do something to a file, so I create a file object. The file object has a clearly defined set of behaviors which it supports.

> no method overloading with struct and interfaces only
go does this too and it's pretty nice
>have to import implemented trains separately to use functionality some some structs
mfw

Generic Rust-fanboy to warranted criticism that Rust lacks industry standard feature X

>X is a non-feature. X is bad. You dont want X.

Yes, Explain to me.
I mean I can use it on my own, if every line I write is done by me personally.
But as soon as I use a library or any other code that someone else wrote I have to open the documentation or use an IDE that can show me at least the variable names for the definition.

>The file object has a clearly defined set of behaviors which it supports.
And it doesn't support read_to_string. It's actually implemented in a completely different file as well.
(read_to_string: github.com/rust-lang/rust/blob/master/src/libstd/io/mod.rs )
(File: github.com/rust-lang/rust/blob/master/src/libstd/fs.rs )

it's not worth the effort to argue they'll learn after a few years of trying and failing to scale rust code bases beyond 10k loc

>This will fail, because you have to actively look up potentially tens of different behaviors of a certain struct and import them all separately.
Except there have been trait hints in the compiler for quite a while now.

>And it doesn't support read_to_string. It's actually implemented in a completely different file as well.
I understand why this isnt necessarily a change for the worse for someone who is used to program exclusively in C, but for anyone else this is shit. Functions are scattered and lost in random places in the API. This is the armageddon we deserve for all the gratuitous pooping on OOP.

add_int(x, y)
add_float(x, y)
add_double(x, y)
add_complex(x, y)
add_vector_2(x, y)
add_vector_3(x, y)
add_matrix_2_2(x, y)
add_matrix_4_4(x, y)

You're right, overloading is worthless.

That's what generics are for you dumbass.

Rust is dead. Actually, it has never been alive. The community does their best to give people the impression that their language is thriving while it is not.

It's not that bad because File is a low level API while Read is a kind of "middleman" trait, a lot of things in Rust are Read and a lot of functions take this Read variables.
Also there is the IO prelude (use std::io::prelude::*;) which imports File, Read, BufRead and Seek, while File is available from the std prelude which means you don't even need use std;.

And also operator overloading (which IS supported by Rust).

All you need is JS for the browser, C for low-level/high performance stuff, Java for everything else.

All these new languages do more harm than good.

You're confusing generics for overloading

use mycrate::cars;
use somecrate;

let audi = cars::Car::new();
audi.drive();


Here, the drive function is actually implemented in "somecrate" but there is LITERALLY NO WAY TO SEE THAT IN THE SYNTAX. There's no way of knowing without an IDE holding your hand, and of course IDE support for Rust is mediocre at best.

>::
The worst syntax in C++, now available in Rust!

>operator overloading
why would rust add the worst things from c++?

To be fair it's discouraged but it's a feature you sometimes really need.

iirc, that issue being brought up is the reason behind compiler trait hints.

So at least they aren't in wontfix mode, but the structural advantages of traits are too good to pass only because they make docs slightly harder to read.

It is one of the pain points right now, and you should probably go and complain to the language folks about it.

>we make everyone jump through hoops to pander to idiots creating new "Read" traits for standard library objects

Truly the AT&T syntax of programming languages

it's code smell, has nothing to do with an IDE or being too dumb to use it

in rust is after the ::
c++: class::method()
rust: class::::method()

so its even worse desu

Not at all, the :: operator is type annotation and is almost never used because it's always clearer to bind to a variable with an annotated type when it's ambiguous.

>Disliking the :: operator
Plebbest of plebs

But all three of those languages are shit enough that I would never touch them.

Nah, you only need C++. It can do browser stuff with webassembly/emscriptem, it is naturally high performance, and for general purpose desktop apps, QT > anything that Java offers.

wasm isn't ready. Some day.

I don't like Qt with C++, they basically reimplemented the standard library. PyQt is comfy though.
JavaFx is much better than Swing. I don't know if it can beat Qt in terms of features and usability.

Please use Rust.

Tbh I find QT core to be a lot more usable for day-to-day usage than the STL, because the STL is simply not intended for that purpose. It doesn't even have a string split function or any unicode string type because these are "not generic algorithms".

I miss C++11 features in the Qt core. For instance, there's no emplace_back in QList. String handling is indeed better in Qt. I guess we cannot have both.

You mean, the best thing.

Because it's a consequence of
>a) not locking features away from the users unless it's absolutely necessary
>b) no types are inherently special (there are exceptions, like marker traits (Sync, Send, etc.))
>c) multiple number types

I thought Rust might actually be cool until I looked at a program in it. Why defer from C-like syntax just for the sake of it?

Why woud Rust give a fuck about C, it's not even like C
/thread

>why would a language trying to replace C give a fuck about C

It's not as if it's an improvement in syntax. It's just renaming well established things to be special.

>renaming well established things
en.wiktionary.org/wiki/baby_duck_syndrome

Guess what, all the C developers they're trying to convert also have baby duck syndrome.

>Rust does not have the “C-style” for loop on purpose. Manually controlling each element of the loop is complicated and error prone, even for experienced C developers.

lel

Well too bad you have to look at something else in order to accommodate your baby duck syndrome. No one else has this problem

>No one else has this problem

What are you trying to say?

Kill yourself, you dumb fucking shit stain.

sad

C is comparable to one of those, maybe 2.

Rust is a direct competitor with C.

And not only do they want you to make new low-level systems in it, they want you to rewrite all of the old software and libraries that have been made in C over the past 30 years.

I switched to scala from C, and the amount of bugs I write has been reduced to a tiny fraction.
Have fun with your JS I guess...

>Rust is a direct competitor with C.
C++ actually
>they want you to rewrite all of the old software and libraries that have been made in C over the past 30 years.
That's good. We'd get rid of those god aweful bugs/exploits that have been residing for half a century. Example: LibreSSL

I loathe the :: clutter so much. It's a clear tell the language is hot garbage

In fact, I'm interested in rewriting most of the coreutils and common tools in Rust and rolling out my own FreeBSD based distro

>That's good. We'd get rid of those god aweful bugs/exploits that have been residing for half a century. Example: LibreSSL>>
Ok, let's stop all progress for another 30 years. Have you done any of this work yourself?

> let's stop all progress for another 30 years
I don't want you to. I am just looking back at our trail and fixing the mistakes on our misguided path to progress

C-style for loops were always a retarded design decision. They assume that an element can be referenced quickly with just an index, and that you know how many elements you have.

Your code may be so simple it only uses arrays, but modern systems programmers need to work with structures that are a bit more complex.

Rust fag myself, but I think for loop is very useful, I even use a macro to implement C's for in rust

I'm rewriting an interface to libdrm to be faster and less error prone.

it's the worst thing that ever happened to c++

Why would you trade `for i in 0..10` with `(int x = 0; i < 10; i++)`?

Try this without making it ugly
for (i in array)
if (the next item to i) == the nth item + something

do you read C++ in fucking braille?

zip with index then map :^)

:^)

for &item in array.iter().skip(1) {
if item == (the nth item + something)
}

Emacs can do documentation lookup while typing out the function name. Stop using a piece of shit editor and crying IDE wolf.

You're gonna try being faster than C? Lol good luck.

Not that guy, but it already happened successfully and may be highly related to the high number of linked lists, ad hoc arrays and other pleb tier/evading tier shit you find in the average C project.

Rewriter here. That's part of it.

libdrm writes to stdout on errors even if you don't want it to. It also dynamically allocates data that can easily just be placed on the stack. You can't change the allocation function either.

And finally, since almost everything is referenced by an integer, the compiler will let you mix up resources and cause errors.

Anyone wants to join me?

>It's another brainlet is to dumb too Rust and nitpicks at irrelevant issues

spotted the Koder

and ?

look, this board is clearly for people that mentioned, so asking here is contraproductive at best

DELET THIS!!!!!!!!

I don't know if Rust sucks or not. Seems to me like it is C++ but not quite. Well, people are free to do shit in their free time. At least D is being developed by wellknown compiler fags, whatever

But, why is Rust Defence Force a thing? Why does it attract unholy amount of literal fanboys? "Hm but actuauallly, what if we rewrite it in Rust" It's just a language, who the fuck cares.

Does Mozilla unironically spend money to shill it or what is happening here

>why is Rust Defence Force a thing?
why is C Defence Force a thing?
why is hasklel Defence Force a thing?
why is Java Defence Force a thing?
why is C# Defence Force a thing?

>I don't know if Rust sucks or not. Seems to me like it is C++ but not quite. Well, people are free to do shit in their free time. At least D is being developed by wellknown compiler fags, whatever
>But, why is Rust Defence Force a thing? Why does it attract unholy amount of literal fanboys? "Hm but actuauallly, what if we rewrite it in Rust" It's just a language, who the fuck cares.
>Does Mozilla unironically spend money to shill it or what is happening here
Who knows. They are screwy.

However, historically speaking, the well known compiler fag that writes D did everything wrong you can do wrong when pulling through. Like calling the language finished, then restarting the whole thing. Or working on the compiler at his workplace. Remembering that you actually want to develop a system programming language after a decade of designing a standard library that uses a garbage collector. Really pant on head retarded stuff.
Now the Rust team on the other hand did almost everything right or at least they didn't do such pants on head retarded things. So it's not hard to get euphoric for Rust and not for D and that surely includes common SJW shitposters.

also, see

they're nowhere as bad

that's wrong, though

You don't know the half of it

I hear so many more people saying that than saying everything should be written in Rust. Maybe try being part of communities that aren't complete morons.

>abstractions on abstractions on abstractions
>crates promoting dependency hell
Rust is like javascript, if javascript compile to native.

I know youre just baiting but please explain how

is irrelevant or a nitpick. Rust has serious issues it needs to fix if it wants to be a real programming language some day.

>No method overloading
Doesn't belong in a systems language. You might as well write separate functions int_dosomething() and double_dosomething() since that's what the name mangler is going to do anyway. The idea of a function that acts differently depends on the "type" of argument passes to it doesn't make sense in systems programming since 99% of the time there is no type system at the binary level anyway. Either leave the type system a compile-time construct as it should be, and use different functions to handle different types of data, or implement a run-time type system using tagged unions or a separate argument to control polymorphic behavior.

You at least need C++ or similar for high-level applications that require performance. Java lets you write complicated programs quickly, but you'll pay for it at runtime if you're doing any kind of heavy math. C is great for those sorts of computationally intensive tasks, but the constructs are so low-level and limited that it's difficult to write large-scale programs without introducing errors. Something like C++ provides the advantages of both, and the disadvantages of neither (unless you opt in to the disadvantages by using bad coding practices).

Generics are a special case of overloading. Unless you mean traditional C-style "generics".

Compiling to JS kills your performance though. On top of the VM/interpreter overhead, C/C++ code compiled to JS is poorly optimized, largely because C/C++ are designed to target low-level instruction sets, while JS is a high level instruction set. So it's not practical to convert C++ into efficient, idiomatic JS.

>Rust isn't even on the chart
SAD!

Emacs is basically an IDE.