I want to learn a language with a strong and static yet expressive type system, pattern matching, sane syntax...

Whoa whoa whoa. Rust does checking at runtime? Is there no optimization settings which turn that off? What kind of bullshit is that?

Attached: c788585.jpg (465x480, 27K)

>>array indices are bound checked at runtime unless unsafe
Taking a slice of known size would make the bound check should go away, wouldn't it? And you do needs a bound check if you don't know the size.

>>verbose (eg. Eq, PartialEq and Ord, try to use them without derive)
Derive works on trivial structs and if it's something more complicated it would be verbose in every language ever.

>>trivial data structures are now overly complicated
If they are really that trivial just do them in unsafe.

>>can't allocate directly on the heap yet (Boxed data is built on the stack)
That's unfortunate, but doesn't sound like something that can't be optimized out.

>>messy syntax
I give you that, it's like an unholy mix of C++, C and some functional insanity. It's never uglier than the ugliest possible C++ tho, but sadly it is messier on average.

>mistakes parallelism for concurrency

Attached: Csg1rzFXgAAWR9G.jpg (799x1200, 134K)

What operations does taking a slice compile down to in Rust?

Attached: 1523735213330.jpg (677x799, 144K)

>Taking a slice of known size would make the bound check should go away, wouldn't it? And you do needs a bound check if you don't know the size.
Slices and indices are different things for different purposes. And no, you don't always need bound checks. Try to implement "insert your favorite sitting algorithm here" with no unsafe and no bound checks. You can prove its correctness tho. Most of the times you don't have to prove anything to know you're not going over the bounds.

>Derive works on trivial structs and if it's something more complicated it would be verbose in every language ever.
No, not this much. In Rust it's extremely pedantic, and this is just an example.

>If they are really that trivial just do them in unsafe.
And it's still not so trivial at all.

>That's unfortunate, but doesn't sound like something that can't be optimized out.
It's something that is supposed to be fixed one day, in the future.

>It's never uglier than the ugliest possible C++ tho, but sadly it is messier on average.
From a modern programming language you expect "nice" and not "not as bad as one of the worst when it's used by insane people". I bet C++ didn't looked that bad back in the 80s and I wonder how bad Rust will look like 20-30 years from now.

>Is there no optimization settings which turn that off?
There is. It's called unsafe and I think you should also use something like array.uglyassname(idx) instead array[idx]. I'm not sure about this tho, it's been awhile since I tried Rust and now I'm phoneposting from my class. Google it by yourself.

Why don't you learn Go?
Rust sounds like a overenginneered bloat.
More complicated than C++, less expressive than C, less elegant than both and with an awful community.
Learn Go, if only for the fact that Rob Pike designed it.
Btw Go proverbs are nice.

Be careful as most of Rust's community is a bit... "Sect-like"

>verbose (eg. Eq, PartialEq and Ord, try to use them without derive)

struct A {
b: u32,
c: Vec,
ignored: i8,
}

impl PartialOrd for A {
fn partial_cmp(&self, other: &A) -> Option {
(&self.b, &self.c).partial_cmp(&(&other.b, &other.c))
}
}

Honestly, Rust is a bit too late. Most people that could program in Rust already program in sepples, and the reasons for changing are just not strong enough.

I don't know how people enjoy Go, it's just a terrible language.

Go is an alright language.
It's veru cool if you're a C programmer that wants to quickly whip-up few microservices or generally a distributed system.
It becomes pretty troublesome when you want to do something that's not in stdlib or doesn't play nice with it.

Rust is the way to go. I’m using it in my very complex app, i have 1k lines so far.

GO is a language by Google for Google, they designed it for their own needs.
People trying to use it for every task are merely trying to be like Google.

>the reasons for changing are just not strong enough.

Just like the type system in C++.

>needing a type system

Attached: brainlet.jpg (211x239, 5K)

>I did it reddit!
This is extremely useful, right?
My point was that if you want to implement one you probably need to implement them all.

>implying you can't just copy-paste the implementation and replace PartialOrd with Ord or PartialEq.

Rust will make you literally want to quit programming

ticki.github.io/blog/why_im_leaving_open_source/

"Safe" rust leaks memory
You can't implement a doubly linked list in Rust
IDE selection is shit
Oh, and the Rust community is full of racists and sexists. The popular kind that hate white males.

How does rust do concurrency better?

And since you may copy paste most of the stuff it's not verbose anymore? Isn't that the very definition of verbose?

>I want to learn a language with a strong and static yet expressive type system, pattern matching, sane syntax, sensible concurrency, and good performance that doesn't entirely rely on the compiler to determine what values are better mutated than copied. Why shouldn't I learn Rust?

Because Swift is going to implement a good subset of what you like about Rust, including memory ownership, but the syntax of Swift is better and there is a large eco-system being built around it that is not Apple dependent.

>Oh, and the Rust community is full of racists and sexists. The popular kind that hate white males

Nothing wrong with being racist or sexist, the problem is that they don't want us to fight back.

>Rust will make you literally want to quit programming

There a lot of languages that can make you do that frankly. Rust is one of these Velvet Underground languages that people won't enjoy as much themselves but will be influenced by.

I noted above to a different commenter that Swift is planning to add memory management. I think that is a very positive development.

Why can't you say the same about Rust? Are Google's needs != most programers? I'll give you its opinionated but I think thats more on Rob Pike and Dennis Ritchie more than google lol.

Fuck Ken Thompson*

>there is a large eco-system being built around it that is not Apple dependent.
Fucking where? I want to believe you but I'm gonna have to see some proof first.

Attached: 1518984114081.jpg (1920x1080, 709K)

>>Automatic refcounting.

No thanks. Either give me static memory management, or use a real GC. ARC just combines the disadvantages of both.

Do you enjoy COCS in your mouth?

literally has official Apple support on Ubuntu and builds fine on pretty much every other distro, IBM is pushing it hard too

ticki.github.io/blog/the-lazy-argument-of-human-nature/

It's supposed to be used with iterators which just make it sure you have only one bound check at the start.
for example, you can do something like select from x1 to x2, skipping by 2, i.e. if x1 = 10, x2 = 75, you would have iterator that yields 10, 12, 14, ... 74 elements.
But they do not suite cases when you have to do random access by indexing. like in one iteration it would be a[100], then a[30], then a[112], etc. Such cases can't be handled by iterators.
> I think you should also use something like array.uglyassname(idx) instead array[idx]
uglyassname could be get and get_mut I think. And no, they don't safe from bound checks at all.
Bound checks are actually enforced on llvm level tho. There is no need to avoid them in regular programming, only if you write core algorithms. That's unsafe is for.

> Are Google's needs != most programers?
Google's needs = management needs.

Which is typical for any development or technological community. Especially FOSS ones.
Most people on this board just shitpost, but what they say is what lots people of appropriate groups really think.

>uglyassname could be get and get_mut I think. And no, they don't safe from bound checks at all.
Than it's not what I'm talking about. I think it's unsafe_ref and unsafe_set, or something similar.

>Bound checks are actually enforced on llvm level tho. There is no need to avoid them in regular programming, only if you write core algorithms. That's unsafe is for.
In a system programming language you want to implement them. If Rust was aimed as a python replacement than I'd agree with you. I know you need unsafe, I said it.

The only place you should worry about bounds checks being too expensive is in a loop, and you don't need to worry about it there, because the optimizer will remove redundant bounds checks, because you're already comparing the index to the length in the loop condition. And that's assuming you even have explicit indexing operations, which is pretty rare.

Bullshit. If they are useless, let's say because you made a study of your algorithm, you should remove them. If you don't worry about bound checks you shouldn't worry about a garbage collector either.

>And that's assuming you even have explicit indexing operations, which is pretty rare.
This statement makes no sense.