The R*st devs want to allow chaining control flow operators as if they were fields/methods, like this:

The R*st devs want to allow chaining control flow operators as if they were fields/methods, like this:
thing.field.method()
.if { a } else { b }
.match { Some(x) => x, None => other_value }
.iter()
.for x { /* do stuff */ }

Is this divine intellect?

The equivalent today would be:
let tmp1 = thing.field.method();
let tmp2 = if tmp1 { a } else { b };
let tmp3 = match tmp2 { Some(x) => x, None => other_value };
for x in tmp3.iter() { /* do stuff */ }

Attached: rustlogo.png (1024x1024, 46K)

Other urls found in this thread:

doc.rust-lang.org/std/iter/index.html
boats.gitlab.io/blog/post/await-decision/
internals.rust-lang.org/t/a-final-proposal-for-await-syntax/10021
hexdocs.pm/elixir/Task.html
docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/
gnu.org/software/guile/manual/html_node/Pattern-Matching.html
markopapic.com/csharp-under-the-hood-async-await/
en.cppreference.com/w/cpp/thread/async
twitter.com/SFWRedditGifs

Based rust devs

Rust has to be the least readable high level language that exists.

You've never read a Boost header, have you?

I don't see the issue.

seems okay i guess

We don't have this problem in Lisp.
Come and join us!

that's right, you don't have anything at all in lisp

Seems like a hacked together and inconsistent version of R's magrittr and Haskell's bind.
Just use a sane language like Julia if you want this feature and your code to run fast.

This is literally LinQ in C#

That's slightly misleading.
They have async/await implemented in the compiler, but not sure which syntax to use, so they started a discussion which became quite heated.
Right now it looks like they're going to use postfix dot-await notation, which makes it the first postfix dot-operator in the language, so they are considering making other operators postfix in the future for completeness sake mainly. Dot-operator is an unorthodox solution, but I much prefer
establish_connection().await?.write(&buffer).awai?t.close().await?;

to
(await (await (await establish_connection())?.write(&buffer))?.close())?

No, it's not, .await/.match/etc are operators, not methods. An equivalent to LINQ would be the Iterator trait: doc.rust-lang.org/std/iter/index.html .

Shell pipes
F#'s |> operator
Haskell's $, ., and >>= operators
Whatever they use in OcaML
And everything in APL & J
D and Nim's UFCS

It's nice to have

A Lisp master would laugh at this situation
Lisp the only language with sane syntax

Lisp has no syntax tho.

No, but it is niggerlicious.

Why if or for aren't regular functions in most programming languages is still beyond me. I blame C.

And this makes you upset

Attached: black-guy-tapping-head.jpg (2048x1131, 161K)

The plan for generic .keyword is the only thing that makes .await even slightly acceptable
Just like the plan for generic postfix macros is the only thing that makes .await!() even slightly acceptable, except that postfix macros had already been discussed as a potential good idea, whereas .keyword was made up on the spot to justify .await

No one gives a shit about Rust except Cfags on Jow Forums, so they have a convenient strawman.

How the fuck would you implement that and why would it matter?

How much more is this going to bloat the compile times?

That must be why most languages have played catch up over the years slowly implementing features of Lisp.

Rust devs has no idea of what they want to do.

Yes, such features of Lisp like static typing, ADT, generics, pattern matching, borrow checker, monads, sane syntax, async/await.

Of course they do. They want to do everything.

It's honestly amazing how Lisp is often conveniently ignored in language debates.
It's either close to teh hardwarez!!1 stuff like C, or some newer interpreted language which is often attacked for being slow, muh performance and muh whatever.
We already had many languages long before C was even created, Lisp including, many of which were better in mamy ways than C itself.

As long as it's zero-cost (at runtime, who cares about compile times)

>static typing
Has its place, sure.
>adt
>generics
>pattern matching
Useless with dynamic typing. They are all features to overcome the limits of static typing while preserving the benefit of static analysis.
>borrow checker
Useless with GC.
>monads
Useless when the language isn't forcing itself to be purely functional.
>sane syntax
Lisp has the sanest syntax out of every language that has ever existed.
>async/await
Not present at the language level, but there are libraries that implement them.

I used to think so as well, but it becomes very readable if you learn how implementations and closures work. everything is very linear and easy to follow.

source, I thought they wanted to avoid this, that's why they have .map() and .filter_map() instead.

It's waaay better than C++

boats.gitlab.io/blog/post/await-decision/
internals.rust-lang.org/t/a-final-proposal-for-await-syntax/10021

Out of this debate have been calls for UFCS and more.

>dynamic typing
>GC.
nice bloat.

disgusting

After nearly 10 years of hobby Haskell and professional C++ and more, I've come to the conclusion that proper dynamic typing is the only typing that makes sense

>monads
>useless when the language isn't forcing itself to be purely functional
Rust isn't purely functional by any means, and it still has monads because they're fucking useful for error handling.

If they get rid of the dots and brackets and allow you to redefine and implement any keyword you want I might be interested.

Reading this thread keeps remind me how well designed elixir is.

They don't even need extra syntaxes just for async/await, or chaining control flows (pipe operator was there from start).

how does it handle async/await then?

standard function call? its a FP language after all
hexdocs.pm/elixir/Task.html

Problem is Rust developers probably have the most exposure to async through Javascript, the worst possible implementation ever conceived.

That's not the async/await Rust is getting tho, it's getting C#-style async: docs.microsoft.com/en-us/dotnet/csharp/programming-guide/concepts/async/ . I.e. an async function compiled to a state machine witch each await representing a state it can be in awaiting to be resumed. It can't be implemented as library.
That's wrong, the async is motivated by Tokio/Futures and inspired by C#, the difference being Rust has no GC, which makes it tricky to implement. The breakthrough was pinning.

JS is also getting F#'s pipe operator and async piping is also in consideration

Promises/A+ is probably the best possible implementation tho

That's implementation, we're talking about syntax-o retard-o

Whoa, wait a minute, you're mostly correct, but pattern matching has absolutely nothing to do with overcoming the limits of static typing.
Of course, you can easily implement pattern matching in any lisp.
gnu.org/software/guile/manual/html_node/Pattern-Matching.html

>I.e. an async function compiled to a state machine witch each await representing a state it can be in awaiting to be resumed. It can't be implemented as library.
what the fuck are you talking about, user?

this, the Task library of Elixir is just "conveniences for spawning and awaiting tasks.", aka they are just glue code for the "spawn" syntax that was built in since version 0.1.

markopapic.com/csharp-under-the-hood-async-await/
The semantics are completely different, what's the point of comparing syntax?

I meant, why do you think async/await works differently in other languages?

meant to quote

Because it does?
On one hand, you have `async` function/method, like en.cppreference.com/w/cpp/thread/async , which takes a closure and runs it on the global thread pool, returning a promise you can blockingly wait for. The goal here is to run some computation in parallel with the main thread.
On another hand, you have C#/Rust `async` you put at function definition instructing the compiler to produce not a simple function, but a state machine, states in which are defined by the `await` operator in the function. The goal here is to simplify working with async IO. I believe it was first implemented in F#.

The ternary operator in conditional statements... why?
it is just syntactic sugar, isn't it?

Given that every programming error can essentially be reduced to a type error, static typing proves you wrong.

>Whoever does not understand Lisp is doomed to reinvent it
Other languages still catching up.

Based rust devs

Kek fucking rekt

Based and redpilled

No, for await is the only implementation

It's funny how lispfags repeat the same memes for 50 years while the rest of the world moved on.

>The equivalent today would be:
Wat. I don't know Rust, but it seems you could just as well remove the temporaries from your example:
for x in (match (if g.field.method() { a } else { b }) { Some(x) => x, None => other_value }.iter())

Not very funny when you consider that it's because every other language is still catching up to 50-year-old Lisp.

->

This is terrible.

r u hi

->

Guise we have an infinite loop, halp.

That's a recursion, the only thing lispers know.

This is possible if control flow operators are nothing more than functions. Unfortunately, Rust is fucking retarded and too steeped in its C-isms to allow that.

Clojure:
>static typing
core.typed
>ADT
If you really need anything which can't be modeled with lists, vectors, maps, sets, records and arbitrary dispatch multimethods you can always extend it in Java and implement the interfaces you need.
>generics,
multimethod
>pattern matching
core.match
>borrow checker
All data types are persistent, immutable, structure sharing
There is also syntax for data you'll want to share between states, like stoms, transactions, etc.
>monads,
clojure.algo.monads, but what's the use case for them in Clojure? what problem are they solving?
>sane syntax,
Clojure fixed everything wrong with any lisp's syntax
>async/await
core.async

back to your containment board dumb nigger

Attached: 1534240739362.jpg (1023x818, 147K)

java doesn't have adt either lmao

Is structured programming a meme now like object orientation?

Attached: 52822078-52B8-438A-A29F-B4A39254C19D.gif (243x283, 5K)

But all these things were copied into Clojure from other, non-lisp langauges, that's the point. It's Lisp catching up to the modern languages, not the other way around.

I don't use Java so I honestly wouldn't know. Could you describe your use case for ADTs in Rust?
Lisps are more about describing behavior and not data structure, but they're equivalent
Copied? Are you moving the goalpost?
It's true that Clojure shamelessly borrows from everything, including erlang and databases. It makes it powerful, but stuff like the actor model and ACID are fucking old and have been around since the 60-70s. Everything was already done by the old languages, but every 10 years some memed up idiot rediscovers the wheel. I think Haskell may be the only language which innovated something in the past 40 years.
Clojure is still very nice, you should try it.

Looks a lot like stream in Java 8

So, let me get this right, instead of writing 4 readable lines of code they want you to write 5 unreadable lines of code? Fucking hell.

We're going back to goto now?

>I think Haskell may be the only language which innovated something in the past 40 years.
This, but unironically. People like to forget that entire operating systems, much larger and more complex than Unix were being made long before C was ever invented.
And no, they weren't all in assembly, despite what Unix weenies believe.
After Haskell (which itself builds over ML) I don't think there has been any real innovation in programming languages.

Affine types, which after several attempts culminated in Rust's borrow checker, is a significant innovation, at least in system programming.

>implying trannies can read

Lisps are pretty neat too. Although they're old and haven't innovated as much, at least not in positive ways.

>Affine types
I'm not sure I understand what they are, can you explain them to me and what problem Rust solves using them?

Memory- and thread-safety without GC. With Rust you have C-tier performance with static guarantees against memory errors and races, the bane of C and C++, the source of all the vulnerabilities. It was made possible by the advancements in type theory in the 2000s. Rust isn't the first language to implement them, but it's the first to make them practical.

Affine types (and variants like linear types) encode variable lifetimes within the type system. They can therefore statically determine when variables go out of scope, allowing them to be deallocated deterministically rather than using a garbage collector.
In truth, Rust's type system doesn't have much in common with affine types. It's pretty much just C++'s RAII types except with fewer quirks and the addition of borrowing semantics.

Is Rust worth getting into, Jow Forums?

no. if you want to be productive use C++. If you want to be a nerd you learn Haskell.

>for x in tmp3.iter()
If Rust is a low-level language, why does it abstract away a for loop into an iterable? What if you want a variable interation?

Iterators are compiled into tight loops, just like C++ iterators, they're completely zero-cost.
> What if you want a variable interation?
for i in [1..10] { ...}

you can use an enumerate method for that. that isn't the real problem.

the real problem is you need at least 3 different kinds of iterator.

Yes

There is a reason why C fags can't stop talking about it even if they outnumber rustfags 10000 to 1

They sense a threat

If you're into system programming, then yes.
If you don't really care about performance and/or safety, then you can skip it.

>>static typing
>Has its place, sure.

Indeed. And the first version of ML was implemented in Lisp, I believe.

And the first version of Lisp was implemented in Asm, what's your point?

No, I mean variable increments inside of the loop. E.g. in C you would increment byte-by-bye until you found an aligned pointer, then increment by sizeof(ptr) since memory is now aligned (maybe not the best example since that would best be done in two loops for performance reasons).

You're just supposed to just a while loop.
That said, Rust has a real hateboner for mutating anything so good luck with that.

Keep on believing that. Enjoy a language developed by Discord users.

Attached: Hipp_on_Rust.png (581x660, 64K)

Rust has an infinite loop you can use for a non-linear looping
let mut x = 0usize;
loop {
if x > y { break; }
if x > z { x + = 1; } else { x += 10; };
...
}

Based and redpilled

C has a leg up on just about every language through its stable ABI
C++ can do so as well by only exposing C interfaces
This is part of the reason that just about every language has pretty easy C compatibility
I've heard chatter that the Rustaceans have that on their roadmap though

Rust can do that since forever.