Rust is a good langu-

>rust is a good langu-

Attached: Screenshot 2018-10-29 at 22.57.48.png (878x636, 84K)

Other urls found in this thread:

youtube.com/watch?v=bwQl73KgS1g
doc.rust-lang.org/std/option/enum.Option.html
twitter.com/AnonBabble

what's wrong with it? monads too hard for you?

fuck I hate rust and modern c++

learn D

pattern matching on an Option can be shortened to an if let statement.

What a nightmare to read, I'll stick to Go

Javascript for everything!

youtube.com/watch?v=bwQl73KgS1g

the enums are aids. as well as not being able to do;
if (item) == true
you have to do custom checks like with "match" or if i != 0 for integers for example

admittedly using cargo is better than the absolute clusterfuck of c++ using cmake.

age.
It really is, though.

go's syntax is even worse lmao

why not
println!(3*8) ?

its just to showcase how retarded it is. so if you have a value in an enum and want to multiply it by another value you have to write all this boilerplate code that is retarded in the first place.

you cant just do
fn multiply(a, b) -> u32 {return a* b}

Should I stick with C?

That’s because enums are not limited to containing integer values. Every enum you write is a new type. Rust’s enums are actually just simple to use tagged unions that can be used somewhat like enums are in other languages. Even basic support for algebraic data types is a good thing. Although I guess it would be convenient sometimes to have enums that are just skins on integers sometimes, I don’t think that’s a very useful feature in general.

>if (item) == true
You sound like some JS webtrash developer.

hello pajeet. shouldn't you be busy writing if statements for every possible calculation for ms calculator?

lmao are you serious? JS or not its literally like this in every language but rust.

uint32_t num = 4;
if (num) {
//do stuff
}

They never do that and it'd be if(item===true) or just if(item).

You're definitely a brainlet.

There’s not even a guarentee that two enum (union) variants will be of the same type. That’s why you can’t just operate on the enum directly.

C
C++
Erlang
JS

You'll never need more than this.

Doing that with with an enum wouldn't be type safe.

based

This

>Erlang
whats erlang for?

common lisp

If you understood the purpose of enums in rust you wouldn’t be using them as shitty integer wrappers.

i'm not all that familiar with rust, but i'm pretty sure it would be a single statement to turn num2 into zero if its a None. The compiler is helping you to be a better programmer by guiding you away from undefined results.

>he thinks i'm op
can one effectively program without deductive skills?

Why would you think you can directly operate on an enum type without refining it to a specific variant first? What would it do in the case of a variant that doesn't contain a u32.

> you cant just do

You could with a generic constraint that a and b implement Mul.

>implying old C++ isn't ungodly shit
CS 101 dropout detected.

=> is finger acrobatics and should be banned

Can't you just use num2.unwrap_or(0)?

op gave a useless toy example, so i have a useless response.

fair enough.
play stupid games, win stupid prizes i guess.

>cont'
so from a quick look at doc.rust-lang.org/std/option/enum.Option.html

num2.unwrap_or(0)*s

Upvoted, although I still don't get the Erlang meme.

bro wtf delete this and get out my thread

You're a brainlet if you think that is bad syntax. It's pretty clear if you read the rust tutorial.

Rust is awesome once you get over the initial "wtf am i reading" phase

that syntax

Attached: syntax.gif (280x258, 1.03M)

what you really should be doing is using the map function for option and returning a none if the input is none.

The problem with Rust is the Syntax. But I don't find it worse than C++ really.

its enums are fucking brilliant. The ability to easily pack variants in a type-safe way without obscene amounts of boilerplate is nonexistent in most other imperative languages. I would kill to have Rust enums in C, which is the lang I use at work.

i hate langs that make hard things harder its just retarded

The example he gave is pretty convoluted for a multiplication. Too bad it's also a straw man, as other people have shown itt. Learning about Result, Option and Iter and their methods is easy and makes for easy and concise code. And not everything has to be an option, wtf.

What is the point of passing in a Option?

also
>let mut res

What's wrong with this code ?
i'm no rustacean but it's clear enough to understand.

>installing a language
hello plebs

You only need the compiler (rustc) to use it, but installing the package manager is way comfier.

Consider me baited. What's wrong with modern C++?

Attached: 1429059356058.jpg (837x892, 98K)

C and Python. Call C shared objects in Python as needed. There, wa la.

font?

it's gay

this

low iq

Replace C with Python and you'd be correct.

Rust is gud

Attached: received_300561367442457.jpg (430x379, 11K)

Not a Rust programmer, but I don't see anything wrong with the language there. It looks like a shit developer overcomplicating things for no reason. Why would you take an option for a multiply method? Why do you want to pass missing values and get 0 back? Jesus

I really don't get why people love non-explicit return statements.

If you have a function that returns something, it should always have return stuck in front of it so you know no matter what what is returning. Just needlessly annoying.

>wa la
Let me guess, you thought voila was pronounced voy-lah, right?

Attached: 1453766063521.png (265x318, 147K)

My company's linter complains if I don't implicitly return objects in JS. Annoys me so fucking much

This fucking annoys me. I have no idea why people like it.

No, I thought it's vi-o-la.

owned

Attached: lol.jpg (700x466, 52K)

That's baby shit, OP.
Wait until you see some REAL idiomatic Rust code:
use std::ops::Mul;

enum Calculator where T: std::fmt::Display + Clone {
N1(T),
Result(T),
}

impl Calculator where T: std::fmt::Display + Clone {
fn log_result(&self) {
match self {
Calculator::Result(i) => println!("{}", i),
_ => (),
}
}

fn multiply(&self, num2: Option) -> ::Output
where U: Mul, ::Output: From {
num2.map_or(0i8.into(), |i| if let Calculator::N1(s) = self { i * s.clone() } else { 0i8.into() })
}
}

fn main() {
let m = Calculator::N1(3);
let res = Calculator::Result(m.multiply(Some(8)));
res.log_result();
}

looks pretty, I like the colors

Actually, I just thought of a way to make it slightly "better".
use std::ops::Mul;

enum Calculator where T: std::fmt::Display + Clone {
N1(T),
Result(T),
}

impl Calculator where T: std::fmt::Display + Clone {
fn log_result(&self) {
match self {
Calculator::Result(i) => println!("{}", i),
_ => (),
}
}

fn multiply(&self, num2: Option) -> ::Output
where U: Mul, ::Output: Default {
num2.map_or(Default::default(), |i| if let Calculator::N1(s) = self { i * s.clone() } else { Default::default() })
}
}

fn main() {
let m = Calculator::N1(3);
let res = Calculator::Result(m.multiply(Some(8)));
res.log_result();
}

This actually looks okay, user.

Attached: 1540838067596.png (3840x2160, 2.48M)

When you have an enum type where all the variants take the exact same set of arguments you should realize that your design is bad.

Also there's absolutely no good reason for num2 in multiply to be an Option. If you don't have a number you shouldn't be calling multiply. The possibility of not having a number should be dealt with elsewhere (like when taking input).

I was just following the design of OP's image as closely as I can. I'm fully aware that it's retarded.