Why not Rust?

java is great tho

The mental gymnastics of rustaceans trying to prove that you don't need linked lists because their precious shit language can't support them without turning of the meme snake oil "security" features is priceless
And when you keep pushing them for a linked list they will finally admit to just use a ready one because implementing a linked list is somehow bad in their meme infested mind
Just avoid rust, it's a meme ugly language that makes the easy difficult and the difficult impossible

Immaturity is the main reason, it's not a killer for everyone, but a lot of people either really rely on the strong tooling offered by a lot of larger languages, or need support for more niche libraries, features or platforms that rust just doesn't have yet.

strong typing and lack of functional features can be a pain in the ass
Kotlin does it better, but it's not as fast

>Java
>Python
Both of them are very good though because you can feel the glorious C underneath them

>Kotlin
No

>I don't talk about the Jow Forums
This is how you know you are dealing with a SJW, they instantly want to make their filthy politics the opposite of something else. I'm not falling for your dialectic trick, politics is very much a factor in refusing to use Rust.

But it's the lesser reason compared to Rust's very poorly designed syntax and single idiom "hurrrr memory safety is the only problem in the world"

I find useful for the algebraic type system and traits, not just the memory model, although the memory model is very good.

Good post

Not yet stable enough to use for critical parts.

/thread

have fun reimplementing cs101 data structures and shitposting on Jow Forums all day instead of doing real work

as someone who's been writing c++ for decades already i don't see the reason to use it, sure they added a bunch of ML features and they run a static version of valgrind at compile time, and these are nice, but they don't really address any of the real issues with c++, which is that writing unsafe code is hard

Thanks to the module system and incremental compilation, that's not a problem any more.
>package management
>traits
>life-times
>perfect move semantics
>pattern matching
Few of the good things C++ is yet to offer. Even if you consider Rust as a C++ with package management, it's a quite good deal
Usage of linked list is vastly overrated in real world scenarios, hence if you do need it, you can use the generic linked list available in the standard.
>politics is very much a factor in refusing to use Rust.
If politics matter to you so much why do you use google/apple/GNU/Microsoft products/services? What's with your double standard?
>But it's the lesser reason compared to Rust's very poorly designed syntax
Syntax is very nice, except from macro rules.
Define stable. No language is backwards compatible unless it's dead.

So, no reason?

>never had a reason to implement a data structure
>t. java brainlet

one day you will grow out of OOP and mutable data

Unlike C, Rust actually has generics so you don't have to re-invent the wheel for every type you use. Although the best way of using a linked list is not using it.

immutability leads to extra allocation, which results in performance overhead

joke's on you because best practice with c++ now is to use const everywhere and to use private members very rarely

>needing to use const everywhere instead of having a language that's immutable by default

C++20 is chasing Rust but it will never be able to emulate Rust's package management ecosystem.

We all agree Rust syntax is horrible. Here's a list of the major problems and how to fix them, and then maybe people will actually use it someday.
1. No block expressions. No implicit returns. Use the fucking keyword.
2. Take the colon out of declaration syntax. remove the question mark operator. Give us a real ternary operator.
3. Take the "!" out of macros. They should look exactly like function calls.
4. Take the pipe bullshit out of closures. Use balanced delimiters.
5. Take out the "::" that sometimes appears when using templates. There is no reason for having this.
6. Fix all the keywords that were renamed for no reason: "match" = "switch," "let" = "auto," "()" = "void," and so on.
7. Replace the stupid "=>" operator with real case labels so IDEs can actually highlight them.
8. Make mutability the default. Use explicit const for immutable variables and references.
9. Put the type before the variable, not after.
10. Remove the pointless "fn" keyword. It's redundant.
11. Put template parameters before the associated declaration instead of mixing them in with a bunch of other stuff where it's impossible to read.
12. Change "self" back to "this" and make it implicit.
13. Struct fields should be defined with the same syntax as declaring variables.
14. Remove "impl Bar for Foo." You should be able to see all the interfaces a type inherits from at the declaration site.
15. Remove "impl Foo." Methods should be defined inside the struct body, or declared there and defined at the top level.
16. Make parentheses mandatory in if/while/for statements. Make braces optional.
17. Bring back the three-part for loop syntax. There are things that simply can't be expressed without it.
18. Make lifetimes completely invisible. They're implicit some of the time. Make them implicit all of the time, or just remove them. If the compiler can't make this work without a bunch of arcane symbols the programmer has to type, there is no point even having the feature.

Attached: 1497089841342.jpg (563x712, 148K)

>immutability leads to extra allocation
not with linear types you fucking pleb

fucking incredible bait, user

>language isn't appropriate for cs101
>implying it's appropriate for anything else
lmao
rust confirmed for monkey glue placebo shit

it was terrible when you posted it for the first time and it's still terrible, C++ has the worst syntax ever and there is no reason to copy it

i really hope you are trolling

immutable by default leads to unnecessary copying and is arguably just as bad as mutable by default

your distro is supposed to handle package management, this current practice of every language having its own special snowflake package managing is garbage

I enjoy writing a bit of hobby stuff in the language. I find the workflow with Cargo much more enjoyable than I do when writing C++.

It does take me like 10 times longer to write anything in the language though but that is mostly due to me not having much experience and doing most things in the wrong way.

I don't like the 1001 ways errors are handled, I would like to option to explicitly return from a function (with the return keyword) and

peak Jow Forums
lol
>your distro is supposed to handle package management,
see picture

Attached: DeepinScreenshot_select-area_20180530032837.png (2602x1510, 327K)

>3. Take the "!" out of macros. They should look exactly like function calls.

wew lad

Attached: 1490566067996.png (325x300, 89K)

>I would like to option to explicitly return from a function
>I enjoy the functional parts of the language
bipolar?

mut is three characters long whereas const is five characters long, meaning it's much more acceptable to have a bunch of them bogging up the code

seriously, though, also how exactly does immutable by default lead to unnecessary copying? if you forgot to make a variable mut when you mutate it you'll run into a compiler error and need to clone the variable or set it to mut, and at that time you'd obviously choose the latter if it's actually a variable you mean to be mutable. by contrast, making variables mutable by default means when you forget to make a variable const your imagined API will be fucked when you mess up and you'll need to explicitly test to fix it

Yeah I'm still a bit confused..

I know why having the return keyword is a bad idea and is really annoying when doing functional programming but I also find the implicit return without the semicolon just strange.

I would rather have something like an arrow function in JavaScript. Oh well..

Rust is shit.

Tiny Rick!

go make your own thread fampai

github.com/FeministSoftwareFoundation/C-plus-Equality

Problems with Rust
1. Incredibly inconvenient.
Rust's lifetime oriented programming together with it's strict borrow checking restrictions is very counter productive. A complex Rust program will make a complex C++ program look like child's play.
2. Macro syntax is bizzare. I don't understand why they chose such stupid syntax for macro_rules
3. Module system seems like a clusterfuck. Although it grows on you.
4. No inheritance. Rust has traits which are very useless as of now (there are RFCs for extended enums/virtual structs/fields in traits). Currently you cannot make default implementation of trait methods because accessing fields of types are not permitted.
5. Shared Mutable Reference is nearly impossible! Unless you use unsafe{} or Arc/Box pointers. Probably for a good reason,
6. Does not work like C. Non idiomatic Rust code creates shitty ASM, whereas "functional" Rust, surprisingly, will create better codes (in my experience).
7. FFI needs unsafe{}. For obvious reasons but still a caveat,
8. Absolutely 0 implicit conversions. Leads to more verbosity.

>No inheritance
>t.pajeet

>FFI needs unsafe{}
All performant code needs unsafe, safe code will always be slower

>Define stable
C-ansi stable.
feature-complete with no more todo-list.

>name your language after something that literally falls apart and wonder why people are not interested

Rust doesn't have type classes / HKT either. Inheritance isn't a bad thing.
C is not even backwards compatible

>when you take a prank so far that nobody knows anymore if you are kidding or not

>feature-complete with no more todo-list.
That doesn't describe any language, including C.
Hence what you are looking for is available in almost all languages with extern "C"

Package management isn't even built into Rust and it shouldn't be built into C++ either
There is a blessed/official package manager but it isn't part of the language

>C is not even backwards compatible
Not a problem if you use a standardized version like the linux kernel
kernel.org/doc/
c11 add nothing of value for the average c dev so c89 or 99 are a rock solid base for anything supposed to run for decades.
C-ANSI
ANSI
words have meaning, don't cherry pick whatever you want.

>Replace the stupid "=>" operator with real case labels so IDEs
Took me up to here to realize this is bait.

Rust is comfy as fuck once you internalize how the borrow checker works.

>Not a problem if you use a standardized version like the linux kernel
Linux kernel uses ANSI C. Both C11 and C99 are not backwards compatible with C89
>C-ANSI
>ANSI
It's called extern "C"
Pretty much bottom of the barrel, lowest common denominator of all language that can FFI to C,

this is by design and is unlikely to change, trying to enforce a naming scheme across package managers will only cause more problems, if you want reproducible builds then stick to one system, if you have problems with how different distros are packaging your dependencies then build them yourself

fyi it gets even worse if you try to support various different windows and macos versions too

linear types are great until your memory layout includes more than one mutable vector, and then they are useless

>typing two extra characters kills my productivity
here you go: "#define C const"

>how exactly does immutable by default lead to unnecessary copying
accidentally modifying const stack values isn't a real issue, the whole reason why move semantics exist is for return values, but the novice programmer who is writing rust or c++ will get errors with move/borrow semantics and in frustration just force a copy instead which will eat up memory

You cannot embed a package manager into a language but you can most definitely standardize a package/build management tool before it's too late

That's my point. Rust won't be a thing unless thay can guarantee things won't break every 6 months or whatever like you can do with C and its revisions.

>before it's too late
Too late for what? What the hell do you think is going to happen? C++ gets "replaced?" That will never happen, C and C++ will both live forever
Whereas Rust will be dead by the end of the year
Remember D?

Interesting, can you show me a case where things "broke" post 1.0?
Also, I already told you C is not a backwards compatible language, so you cannot compile certain C89 code in standard C99. Hence C89 is pretty much available with extern C.

>Too late for what?
Trying to make a package manager "standard" and not failing miserably. Are you too retarded to stay with a topic?

what C89 can you not compile in C99?

From the top of my head
1. K&R function syntax
2. the implicit int return type is allowed in C89 but not C99
3. gets()

there are probably other breaking changes but gets() isn't one of them because it hadn't been removed yet

>A complex Rust program will make a complex C++ program look like child's play.
Debugging a complex C++ will make a complex Rust program look like child's play.

>Macro syntax is bizzare.
Big step up from C in readability and reasonability. But agree it's not great.

>Module system seems like a clusterfuck.
You don't have to redundantly name a file, then specify a namespace to match (and edit if you choose to move the file). Less of a clusterfuck than most.

>Rust has traits which are very useless
No idea how you reach this conclusion, unless you somehow need instance fields for every C#/Java interface you define. In which case you probably have massive issues with redundant object state.

The ability to blanket-implement traits based on other traits - and implement for types you don't own - plus partial default implementations, make traits 10x better than anything in 90s-style OOP shit.

Also, you can implement as many traits with partial defaults as you like. There's no multiple inheritance for abstract classes.

>Accessing fields of types are not permitted.
Accessing runtime fields from a trait is useful in about 1% of cases. And even in those cases, you can specify that a struct should implement a function which exposes the field you need, so it's not a blocker.

You can 100% access a struct's fields in a type-specific implementation.

>Shared Mutable Reference is nearly impossible!
If you know something is safe that the compiler cannot prove, you use `unsafe{}`. This is a feature. Why do you think it's a problem?

>FFI needs unsafe{}. For obvious reasons but still a caveat,
This is a problem how? rustc should be able to predict what another language is doing?

>Absolutely 0 implicit conversions. Leads to more verbosity.
Any expression that looks cluttered by extra "as _" prefixes is one whose auto-casting behaviour is equally difficult to reason about. And in many situations, type inference means you can just `y = x.into()`.

>Also, you can implement as many traits with partial defaults as you like. There's no multiple inheritance for abstract classes.
Java since version 8 has default method implementations for interfaces.

1/10 I replied

Leave it to brainlets to not see the long-term advantages of a language with a high degree of reliability compared to one that could break at any level easily because of minor mistakes even smart people sometimes make.

>Java since version 8 has default method implementations for interfaces.
It's kind of funny how this is like multiple inheritance and Java designers beg you not to abuse it

>writing unsafe code is hard
And you can avoid this in Rust in 95% of cases, since most the fundamental data structures and operations which require unsafe behaviour are already defined in std.

>5. Shared Mutable Reference is nearly impossible!
that's what RefCell container is for
>"functional" Rust, surprisingly, will create better codes (in my experience).
I've always been wondering if this is true, e.g. using iterators over just iterating over array, chaining functions with the monadic error handling, pattern matching and all that abstraction... if that's actually optimized well. Turned out I don't understand assembly so I kept wondering.

And still they have no runtime fields, so they're still equal to, or more limited than, traits in every way.

That's stupid. If you're using a systems programming language then you need bespoke data structures that are optimized for your use case.

You are correct on all other accounts, I just wanted to amend that one point.

That's how it works in Lisp you coon.

Then you define the ones you need, and constrain the are where any dodgy behaviour might occur.

Although for embedded/OS purposes, Rust still has a long way to go (e.g.lack of ability to define direct memory placement, custom allocators).

>hey guys if you don't want to write low level code then just write java lol!!!
every big c++ project i've ever been on implements its own data structures for performance reasons, if rust is bad at this then it isn't a suitable alternative to c+

>most the fundamental data structures and operations which require unsafe behaviour are already defined in std
I just threw up a little
If this is the "power of rust" I may as well use python

>tripfag
Politics is a valid reason not to use something

Even if you don't use std and make 100% your own structures, you can limit where to look when problems occur.

and you can do the same in c++ by finding anywhere where there are raw pointers

>I would like to option to explicitly return from a function
You can, and sometimes it's the idiomatic thing to do.

>If I say "meme" enough people will believe me

In a nutshell: Modern concepts at C++ speed. Too many to list.

Also, the most effective package management in any language.

>It's time to stop believing the rustfags, the burden of proof on why you should use rust is on them and their silence is deafening
This, still not one valid reason ever given.

>Modern concepts
"Modern" isn't a good thing. Programming was a solved problem 30 years ago, modern practices have only made it worse.

>most effective package management
>try to use a popular library in rust (or any other meme language)
>it requires me to have the c++ library & headers installed which i have to fall back to my distro for anyway
every time

>modern concepts
functional programming and ADTs were invented decades ago

So package management doesn't count unless it also packages other languages?

>functional programming and ADTs were invented decades ago
And they're traditionally slow, use gc, and are unsuitable for non-PC environments. Rust provides one of the most complete implementation stories available, suitable for more environment than anything except for C/C++ (due only to compilation targets).

Being this naive disqualifies your opinion. Modern != NodeJS/web framework bloat.

Is there an ide and good debugger for rust or no? Java is hard to beat in that respect

>And they're traditionally slow, use gc, and are unsuitable for non-PC environments. Rust provides one of the most complete implementation stories available, suitable for more environment than anything except for C/C++ (due only to compilation targets).
That's the biggest fud and lie I ever heard on Jow Forums
Just when you think rustaceans can't get worse and more desperate they prove you wrong

>your distro is supposed to handle package management
yeah fancy that, needing root just to install a library and also it being a year or more out of date because it missed the cutoff point for being included as a stable package
>current practice
cpan has been around since the 90s
and not that it matters but cargo isn't just a package manager, it's also the whole build system

>Remember D?
d had licensing concerns throughout its early and mid history and while the concerns weren't legitimate they were something that almost every potential d developer asked about and were certainly scared away by, the community was also split between two incompatible general libraries and if that wasn't enough d introduced new backwards compatibility breaking language features not long after its 1.0 release, if you want a case study on how to create a language that would be dead on arrival you'd basically redo d's early history

imagine being a programmer that doesnt even understand memory to allocate it correctly lmao

ok

Attached: b.png (891x457, 84K)

why do rustlets always post this graph? are they unable to read box plots?
Let me translate this into english for you chump - the majority of Rust programs are slower than 75% of C++ programs.

And you seem to not realize it's on a log scale and that 75% is still below 2

This is in reply to the comment that traditional functional languages are in any way fast. C and C++ are still fastest.

then why are so many programs written in C so slow?