Give me 1 reason to use rust instead of go, other than writing

Using rust helps promote Mozilla so they can get funding and donations for their Social Justice activism.

>>58465322
Using go helps promote pajeets so they can get funding and donations for pro H1B activism

Stick with perfection that is ANSI C

>>58465053
Performance and or security.

I'd rather use rust than go for crypto.

give me one good reason to use rust OR go

>>58465363
That's such a funny way to spell Nim, anon!

>>58465831
As long as they have a compiler that compiles to C instead of targeting LLVM IR directly and therefore leaks C semantics, no respect.

>>58465886
>LLVM IR directly
>I know nothing about compilation: The Post
Look up C--, ya doofus.

>>58465940
It's a garbage idea. You faggot don't know anything about compilation.

>>58465954
Is that why CLANG is the best C compiler around?

>>58465954
To add: Like all ideas by S P J

>>58465963
No, that's because it's a C compiler. Those are fucked anyway.

>>58465822
Performance nd or security

I'd rather use rust than c for crypto

Virtue signalling.

>>58465563
But go has crypto functionality in its standard library, unlike rust. What crypto are you talking about?

Languages other than assembly, C, C++, Java, Fortran and Python are unnecessary and will never be popular.
There's simply no need for more programming languages.
Same with operating systems, there will be Windows, GNU/Linux and Android.

File: women in tech laughing.png (1MB, 960x792px) Image search: [Google]

1MB, 960x792px

>Go
>no generics

>>58470355
Generics were a mistake. Generating multiple versions of the same code is the job of the preprocessor.

>>58472441
So... generics?

>>58465053
>tfw to intell

>>58472441
>generics are a mistake
>the solution is generics where you have to write everything yourself each time and potentially fuck something up

What's the best reason to pick any language?

File: TJMVnJ4.png (291KB, 935x712px) Image search: [Google]

291KB, 935x712px

>>58465053
>.unwrap().unwrap().unwrap()
>if err != nil { return nil, err }

Pick your poison.

>>58474139
The project you're going to be working on is written in it. That's about it.

Faggots who swear by a programming language are just that: faggots. Any actual programmer can master a new language in two days and will do so in order to work on whatever project gets assigned to him.

>>58474346
What's the best reason to choose a project?

>>58465053
Give me one reason to use Go.
What is the obsession with either of these languages?
>muh safety
>muh "easy" concurrency

Concurrency isn't easy. There are inherent safety issues with it that developers need to understand before trying to multithread anything. Building little ways to run a function on a separate thread into the language does fuck all in a more complex situation. How the threading is done needs to be built around the structure of the program. This can't be done with goroutines.

Everybody needs to shut the hell up about either of these languages making concurrency easy. Concurrency gets less hard when you understand the structure of your program. No language construct can do it for you.

All you need is a solid, simple threading library.

>>58474279
>.unwrap()
You usually shouldn't unwrap(), except if you're 100% sure no error is possible. "Correct" error handling would look like this:

if let Ok(file) = File::open("lol.txt") {
    if let Ok(x) = file.read(&mut buf) {
        if let Ok(y) = do_stuff() {
             // You get the point
        }
    }
}

Which is pretty retarded.

Or you could do this:

let file_result = File::open(...);
if file_result.is_err() { return file_result }
let file = file_result.unwrap();

let read_result = file.read(&mut buf);
if read_result.is_err() { return read_result }
...

And now you have Go-tier error handling (also retarded).

But the rust devs aren't stupid and you have the try macro to do all this early returning for you:

let file = try!(File::open(...));
try!(file.read(&mut buf));
try!(...);

Still too cumbersome? Try the '?' operator:

let file = File::open(...)?;
file.read(&mut buf)?;

You can even chain expressions this way:

File::open(...)?.read(&mut buf)?;

>>58475580
I like also the ability to "continue" through "option"-like types, such as

let x = File::open(...).and_then(|x| x.read(&mut buf)).and_then(|x| ...);

Didn't know about the ? operator though, that's really cool. Is it in nightly?

>>58475580

> Having dozens of ways to express the same thing with a disgusting syntax

Oh, it's the new C++ as well.

File: 1484110778069.jpg (133KB, 700x869px) Image search: [Google]

133KB, 700x869px

>>58477755
I guess it is after all.

>>58477295
>Is it in nightly?
Yes I think it just came out a couple of weeks ago. The problem is that this feature introduces a new trait, "Carrier" and I fear that Rust is going in the same direction a Scala (a language I once loved): type signatures so complex you just want to commit sudoku.

>>58465053
Check the ntp fuckups with leap second. Go isn't ready and never will be. Rust development is fast.

>>58480216

it's already there because of the lifetime stuff on top of generics.
rust needed to be golang with lifetimes.
generics add a shitload of complexity onto any language but then worrying about lifetimes too is just too much

>>58480708
t. inbred