rust vs. go Debate!

File: z35vm2ds-1409634662.jpg (534KB, 1356x668px) Image search: [Google]

534KB, 1356x668px

Debate!

>go
solution to a common problem
>rust
solution looking for problem

rust > go

>>62124202
Rust, obviously.

>>62124220
Apples.

Differe't languages for different purposes. Delete your thread

>>62124291
Explain

>>62124291
delet yourself

>>62124202
lol no generics

>>62124236
>solution to a common problem
And what problem is that?

Rust no libs
Go many libs
Go figure

>>62124342
>Rust no libs
https://crates.io/crates

>>62124321
Too much working code.

>>62124361
Barely any useful crates

>>62124316
>lol no generics
It doesnt have exceptions either, its a meme language, stop using meme languages and just use C++

Both are memes. Also yeah, different purposes. In my opinion i'd prefer Go.

>>62124395
Let rust = gay
>>62124369

>>62124202
Comparing Rust to Go is like comparing C++ to Python

rust could get interesting, go is not and will be dead after rob pike gets bored and googlers move to the next meme language

>>62124202
> Go
I'm waiting for dep
> Rust
I'm waiting for const generics and non-lexical borrowk

>>62124321
go is the solution for the problem of people being too dumb to use rust

>>62124687
kek

>>62124687
Nice false-flagging

>>62124704
you are fake news

>>62124265
>apples
Wrong

File: IMG_1289.png (69KB, 208x202px) Image search: [Google]

69KB, 208x202px

>>62124752
>eating fucking oranges
>literally such a pleb """fruit""" that they just named it after a color because it isn't worth its own name
end yourself

>>62124683
>non-lexical borrowk
It's called Rc and Mutex.

They're both garbage but Rust at least isn't fucking Go.

>>62124608
Except those are both at least decent.

>>62124220
> Apples
They're ok, I can't eat them though, my throat get's itchy.
> Oranges
It's not even edible! Whenever I try to take a bite I end up with with this nasty skin in my teeth and it squirts this sour stuff everywhere.

>>62124876
>C++
>Decent
>Python
>Decent
Fuck off, rajapajeet

>>62124946
C++ is fucking great, and Python at least works. Pajeets use Java/JS.

>>62124968
>C++ is fucking great
C++ is a hacked together language, a true abomination. It could be much better if it were to get rid of source-level compatibility with C but no
Enjoy 3 stdlibs, 2 arrays, 2 strings, and hundreds of corner cases but no modules

>>62124946
Both are great for their purpose and widely used in serious projects.
Not many others can say the same thing, except for C.

>>62125000
C++ was great because it introduced some low cost abstraction. Which is okay but nowadays C++ is literally two whole different language hosted by a same compiler.

>>62124997
>2 strings
And both of them are wrong.
>2017
>characters are one byte

>>62124202
go is for software engineers
rust is for script kiddies
that's all there is to it

>>62124202
Go is literally for Pajeets to stupid to use Java.
Rust is a nice safe but efficient alternative to C/C++.

>>62124236
More like
>Rust
Solution to a problem that nobody gives a fuck about fixing

>>62127558
Then why do they invent stuff like Address and Thread Sanitizers? People do care, they're just doing it wrong.

>>62127123
LOL

>>62126905
>insert highly region-specific meme here

>>62124220

Orange
>Pulpy
>Delicious
>Comes pre-sliced for easy snacking

Apple
>Are you even fucking trying?

>>62124395
Exceptions are shit, literally hidden execution paths.
Returning an error code is better. Returning a tagged union of the value and an error is ideal.

>>62126905
>O(n) indexing

>>62124202
Docker was written in Go. This one fact almost guarantees that Go will win in almost any "language war".

File: baitlegoquality.jpg (99KB, 726x592px) Image search: [Google]

99KB, 726x592px

>>62127558
Yea, no one really cares about race conditions or other safety issues when programming.

>>62124220
nigga why can't apples and orange be compared

>>62124763
>not knowing it's the other way round

>>62124202
>not making your own C parser and using the cool features that modern languages have

>>62131600
>gimmicky container manager
Rust heavy hitters:

redoxOS
dropbox's clustered petabyte filesytem
tor
firefox

>>62124236
/thread

>>62124202
The one in which you can write an OS
https://github.com/redox-os/redox

File: Screen Shot 2017-08-28 at 14.21.16.png (46KB, 566x203px) Image search: [Google]

46KB, 566x203px

>>62124321
training wheels language for retards who feel smart using a stupidly opinionated language

>in Google we hire the best of the best
>except they can't code

>>62124220
>Apple
Many flavours
Easy to eat
>Oranges
Not even the juice is healthy
Binary flavours: disgusting or OK
Not a grapefruit

The one that can implement circular linked lists in a reasonable number of lines.

>>62124202
Rust is pretty much a better OCaml, with a hardcore system focus.

Go is what Java should've been.

>>62137183
No, Go is just C with GC.

Kotlin is what Java should have been.

>>62137434
Kotlin is an ugly piece of shit that fixes nothing because it can't.

>>62137031
I mean, linked lists can have poor memory safety and rust is generic enough that it's like, might as well use some crate.

I can also bet that C++ implements them in fewer lines of code than Go...but does that make it better?

I don't think either reinventing wheels or purely concise syntax is a good measure of any language.

Gofag here
Both have their uses and pitfalls.
Rust is probably the better one. I wish it had something like goroutines and channels but it doesn't really matter.

>>62139299
Pre-1.0 rust had green threads. Also: https://github.com/dpc/mioco

>>62139299
Rust does have channels.
https://rustbyexample.com/std_misc/channels.html

which one do you think will be more prominent in malware?

>>62139467
That noise, though.

>>62139490
Go makes compiling for various target platforms really easy but static linking is pretty shitty if you want to distribute malware.

I don't know what kind of advantages rust's safety would grant a malware distributor.

>>62124799
You're an absolute fucking idiot.

>>62124202
fuck google

>>62124202
Rust when you'd use C
C++ for highly-technical softwares (neural network, designing graphic cards, etc)
go for the rest

>>62139960
Why not Rust/C for highly-technical software?

C for OS and Drivers
C++ for performance intensive applications
Go for everything else.

>>62139532
Rust is also statically linked by default. Also, Rust isn't really that portable so to speak since it relies on a few assumptions about the hardware for safety and all that.

>>62141165
>a few assumptions about the hardware for safety and all that
Rust's safety is all done at compile time, it requires no hardware support.

>>62141196
No, but the compiler ensure there is no undefined behavior. For instance, Rust assumes twos complement for signed integers so an overflow will repeat back on itself, while in C and overflow is undefined behavior since there is no assumption about how signed integers are stored.

>>62124236
I'd say they both sought more problems than they solved. At least go is somewhat pleasant to work with though. Rust is just the people's comintern of overwrought ideological design techniques.

>>62140432
>Go for everything else.
>if err != nil { return err }
>if err != nil { return err }
>if err != nil { return err }
>if err != nil { return err }
>if err != nil { return err }
>if err != nil { return err }

>>62140432
>C++ for performance intensive applications
its the C++ (((((performance))))) meme
>oooh oooh, its faster bcuz Im mangaging the (((hardware memory))) myself

>>62141352
No, it's faster because it has decades worth of optimizations made for it.

>>62141352
you're retarded

>>62141317
Why is this so different from using try/catch?

File: 1503781265951.jpg (717KB, 642x1650px) Image search: [Google]

717KB, 642x1650px

>>62124202

>>62141384

if err != nil { return err }

>>62141384
Exception handling has no overhead if no exception is thrown and it doesn't require you to manually propagate it.

>>62135570
Source?

>>62141352

Brainlet

>>62141418
https://talks.golang.org/2012/splash.article
ctrl+f radical

>>62139491
Well, it's a low-level language after all.

>>62124220
>Orange
Juicy
Easy to peel
Event he peels are good for cooking
Strong pleasant smell
>Apple
Literally horse food

>>62141432
Thank you :)

>>62141414
So you people hate Go because its error model uses two more instructions than necessary in the even that no error occurs?

Would you feel better if you found out that the Go compiler locates all err != nil statements and transforms them into zero cost error handling?

>>62141471
no. not having wasteful error handling statements bloating the source is better

>>62141432
>>62141470
https://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/From-Parallel-to-Concurrent
The exact quote from >>62135570 is somewhere in this video.

>>62141471
>Would you feel better if you found out that the Go compiler locates all err != nil statements and transforms them into zero cost error handling
No because I'd still have to write all of them myself. I don't need to write a catch in every function leading up to where I actually want to handle the exception.

File: man-in-jacket-talking-on-phone.jpg (53KB, 534x800px) Image search: [Google]

53KB, 534x800px

>>62141352
>tfw you try to fit in with edgy contrarianism but out yourself as a flaming retard instead

>>62141483
Go's error handling doesn't take any more source code than a try/catch
And if it did take marginally more, that wouldn't be anywhere near sufficient to dismiss to the entire language.

>>62141517
You need an if err != nil in EVERY function. With exceptions you need a throw and a catch, only once, or only as many times as there are places where you're handling exceptions.

>that wouldn't be anywhere near sufficient to dismiss to the entire language
It's too simple and that makes it too verbose and hard to read. Even the simplest operations require you to write a for loop.
A reasonable language has "find_first_of(thing, iterable)" instead of "for i, x := range iterable { if x == thing { save the index and break } }"

File: epiphany.gif (670KB, 360x208px) Image search: [Google]

670KB, 360x208px

>>62133606
>>not knowing it's the other way round
>round
>like the orange itself

>>62137495
> Ugly as shit
Here's your (You), buddy.

> Fixes nothing because it can't
Oh right. Adding reified generics, a null aware type system, extension functions, sealed classes, data classes, et cetera, doesn't fix anything wrong with Java. My bad.

>>62141937
Kotlin is a meme language for pajeets that want a swift like language to do mobile apps. Scala is here to stay.

>>62141317
If you have to type that a lot, you're doing it wrong. Errors are values. Start programming.

>>62141937
>reified generics
which are crippled and restrictively contextual because the JVM doesn't really support reified generics
>a null-aware type system
Which falls apart every time Java tries to call kotlin. too little too late, but thanks for trying.
>extension functions
are shit
>sealed classes
final
>data classes
do nothing but remove boilerplate

>>62135570
ABSOLUTELY POLITICALLY CORRECT

>>62124220
> Apple
Mactoddlers BTFO

>>62135570
>>62141492
that quote was in that video at 20:40, but he clearly did not mean that Java, C, C++ and Python were brilliant languages, he was a saying that Googlers were not researchers that use the type of languages that researchers use but rather use dummy languages like Java, C, C++ and Python

Go is too simple. Add functional features and it would be okay.

>>62137495
Kotlin is a (way) better Java but it's still Java. That's fine for many.

>>62124321
Generics takes our jabs

>>62130931
Except they are more overhead.

>>62146278
In terms of the program? Not really, exceptions are famously slow.
In terms of the programmer? Hardly. The mental overhead of tracking the invisible exceptions is much worse. It's easier to program against an function whose signature clearly specifies exactly what it can return,

>>62147094
>exceptions are famously slow
Throwing an exception is slow but exceptions are very rare occurrences so it doesn't matter.
The other path is faster because you don't need to constantly check for errors.

>>62147160
>exceptions are very rare occurrences
Want to know how I know that you've never written anything that isn't a toy program?

>>62124202
They belong in the trash.

>>62147396
>using exceptions for flow control in a tight loop
Want to know who I know that you're retarded?

>>62134446
These aren't heavy hitters, nobody uses them

>>62140401
Rust is slow, stupid

>>62147415
I'm not as retarded as Guido at least.

>>62147470
Rust and C++ are comparable

>>62147534
Rust is about 50% the speed of C++ which is about 50% the speed of C

>>62147545
C++ is only slower than C if you suck at writing C++ or you're not aiming for optimal efficiency.

Also https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=gpp

>>62147525
I don't know why you'd drag an interpreted language into this but even there an exception is only thrown when you exhaust an iterator.
There's no point discussing speed when even just entering a try block has an opcode.

>>62147450
I nearly took this bait.

>>62147450
this. mozilla btfo

>>62147598
It's getting off track. The main points I have left to say are this.
>Correctness is better than efficiency. It's harder to write correct code with exceptions.
>Exceptions are only faster if you never have to handle them.

>>62124202
rust programmers are toxic

you can't reason with these people

rust programmers see anything even resembling a negative comment about a rust app as a slight and downvote the shit out of everything

they want to push all their concepts on everything. how do you know rust is doomed to fail? It's inherently faulty to toss out whole industry proven languages like C++ to pick up *anything* new

has anything other than servo been written in rust? nope.

on the other hand, golang has static site generators, docker, and other daemon type apps. it's been around as long as golang.

so? Where are all the rust apps.

guess what: We don't need a new language that forces you to do all this stuff with safety. for us who actually ship shit, we already have wrappers that handle memory management. we basically have *no* need for rust! Lol.

On the other hand, golang just gives you basics, and everytime go wins, all these Haskell, Scala, and Rust crybabies recoil. let's face it, the golang community runs laps around all three languages sheerly because it sticks to basics and simplicity without be prima donnas about language superiority, when we only want fucking tooling.

for christ sakes. grow up and act like adults

>>62147700
>le downvotes
>reddit spacing

Pls go.

>>62147700
>it's been around as long as golang
>go 1.0 released 5 years ago
>rust 1.0 released 2 years ago
Are you even trying?

>>62147699
>Correctness is better than efficiency
Any professional programmer would sacrifice 1% correctness for a 10% speedup.

>>62147699
>Correctness is better than efficiency. It's harder to write correct code with exceptions
Checked exceptions are a thing.
>Exceptions are only faster if you never have to handle them.
If you're continuously reading data from a device, your constant error checks will become measurably slower and will take way more time than a single exception that is thrown when you accidentally unplug the cable.

File: rustvscpp.png (70KB, 619x1183px) Image search: [Google]

70KB, 619x1183px

>c++ users on suicide watch

Go is designed to be a server-side language designed for simplicity. Rust is a language designed to be memory safe without the GC. Rust is highly opinionated concerning best practice.

Go helps you write more kinds of programs. Rust forces you to write fewer kinds of programs.

>>62124291
This. Go for network services, Rust for systems programming.

>>62147812
Checked exceptions are being disregarded by modern languages because modern developers are script kiddies or indians who don't care about code quality.
Checked exceptions are great, but you still have the problem of hidden execution paths.

>>62147813
H−HAYAI
how it's even possible?

>>62147879
You have a warped definition of "systems" if you think Rust can fill those shoes. We still need C. We always will.

>>62147907
"systems" programming without MMIO because muh safety

>>62147931
>what is unsafe { }

>>62147950
an admission

>>62124202
Rust disgusts everyone outside of the dragon dildo crowd, how is this even a question.

>>62124202
Why would you compare Go with Rust? They are not even in the same League
Here is the tier division:
Top tier:
ASM
C
C++
Rust

Okay tier:
D
Go
Java
C#

Slow as fuck/skid tier:
Python
JS
Ruby
Lua

Autism tier:
C
C++
Rust
Hasklel
F#
Scala
OCaml
Erlang
FORTRAN
Clojure
Coq
Agda
etc

Emerging tier:
Elixir
Nim
Crystal

>>62147733
>>62147774

This is it.

See how butthurt these rust people get?

Look. Do what you want. But take this as a word of warning. If you want to waste your life away with these chumps who will never create anything useful other than vanity and type safe fakeness, go ahead.

If you want to get real work done, go see what people do.

Also, "rust 1.0" doesn't matter. The time is a strawman. Rust didn't become 1.0 until later, blah blah blah. Quite bickering rust guy, and actually write something or do something with your life .

See, Rust people talk talk talk. But Python/ruby/node/etc. at least produce stuff. Hell even PHP people are more useful than Rust lovers, who just talk talk talk.

A lot of crusty rusty old repos . They're small fries and not to be taken seriously. They'll do everything but actually write a useful piece of software.

>>62148781
>Get BTFO by clear logic
>"S-See how butthurt these rust people get?"
>proceeds to write a second essay
You are an embarrassment. I don't even use Rust.

>>62148811
I don't care. My points on rust people being a waste of space? Still valid.

World doesn't revolve around you.

You see this as a sword fight of words where it's you vs. someone. I'm relaying facts from the ground.

It's time to march skyward. For the starbound.

>>62148834
>My points on rust people being a waste of space?
IDK about them but you definitely do. Missing reddit with that spacing, aren't you?

>>62147821
Rust is designed for idiots who don't understand computers.It isn't readable, sane, or logical.

Example:

> elite autist using /C++/
>int* function(int number) {
> int * raw_pointer = new int[32];
> // OH NO BUFFER OVERFLOW
> for(int i = 0; i < number; i++)
> raw_pointer++;
> // OH NO WRONG DELETE
> delete raw_pointer;
> // OH NO USE AFTER DELETE
> return raw_pointer;
>}

> too hard need some /Rust/
>fn function() {
> let arr = [1, 2, 3, 4, 5, 6, 7];
> let arr_iter = array.into_iter();
> array_iter.filter(|&&x| x == 2);
>}
> so readable
> so safe
> im glad i dont need to (((manage my memory)))
rust autists explained

>>62149048
RUSTFAGS BTFO! HOW WILL THEY EVER RECOVER?

>>62145656
>he clearly did not mean that Java, C, C++ and Python were brilliant languages
Of course he didn't mean that.
The quoted text doesn't imply it at all.
Why would you feel the need to clarify that?

>>62149048
Your C++ function has undefined behaviour and your Rust function is a no-op.
I don't think anyone would even consider your opinion.

>>62149298
Undefined behavior is not actually a problem, no responsible programmer would use it

>>62149371
Well that anon just did while trying to explain why C++ is better.

>>62149389
That anon is a falseflagging Rust shill of course he doesn't know C++

>>62149401
Sorry but he's not even a Rust shill, the code he wrote is shit as well.

>>62135570
>if a language is easy, then it's bad
Why do people make this assertion?

>>62141317
>I hate Go because it forces me to handle errors
This is my least favorite argument, do you people seriously just ignore errors in other languages and hope for the best? The only difference in Go is that errors have their own type in the standard and that functions can have multiple returns, in something like C you'd do this anyway but in a roundabout fashion, by passing in a pointer that gets filled with some data like an errno that you check right after calling and before using the returned value. In other languages you'd be checking exceptions which seem way worse to me since they're half baked, it standardizes errors and removes the need for adding error specific parameters to your function but it's not enforced in any way, you don't have to have exception handling, at that point what's the point if people are just not going to check for them, or worse, just check for ANY exception and fail outright. Error paths should be in your mind, most people seem to just think about what will happen during perfect execution where nothing goes wrong and don't care about handling problems gracefully, to me this is a sign of a bad programmer, regardless of the language, handle your damn errors. I'm glad Go is forcing people to handle them, like it or not.

>>62124220
Fuck citrus fruits.

>>62150222
The issue is not that it forces you to handle errors, the issue is how much boilerplate you need to write to handle errors.
Rust has a Result type that can contain both a value and an error code.
But instead of doing if err == nil { return err } every time you want to use the return value of a function you just append ? to the result.
If the result has no error code then the value is unwrapped and you can use it normally, if there is an error then that error is returned early.
If you want to handle errors instead of propagating them then you can use pattern matching, no unwieldy ifs required.

>>62148781
Go

back

to

plebbit

>>62124202
Racket

>>62150513
>if err == nil
And this is why too much boilerplate is bad. People make mistakes, this should be !=
If you forget a ? in Rust then that's a type error.

>>62150035
Simple ≠ easy

Case in point slices.
Their justification for slices is to "prevent errors when handling arrays" but this
a) adds too much boilerplate
b) any decent programmer knows how to handle those errors, because if your learnt C/C++/Java, you already seen this happening a lot so you just avoid the pitfall.
c) "Preventing" errors with slices is retarded when the whole language forces to use try/catch everywhere anyway. Would make more sense for the compiler to force to add a try/catch block for arrays (more boilerplate?) than force me to use slices.

Forced handholding is worst handholding.

>>62150695
>decent programmer
This is where everything you've said falls apart and why google made this shit language.

>>62150732
Did you actually read the post? Or did you just rush to write whatever you wanted out your ass

                                                                                                                                I'm trashing Go

>>62150760
>I'm trashing Go
So am I. Google is hiring programmers who aren't decent so they need a language with forced handholding.

>>62124202

Rust, a language which holds the promise of near c speed while still offering safety, does this at the expense of the developer by burdening him with the cognitive overhead of the solution it offers (borrow checker).

Go, a language that is deliberately simplistic and thus has very little in the way of the developer 'expressing' himself, which leads to code bases that looks very much alike since there are idiomatic solutions to practically any given problem.

I don't think they overlap very much, Rust is primarily a C, C++ competitor, Go is a Java, C#, Python competitor.

>>62151116
Finally some sanity in this thread. (I wouldn't use either, but that only because bootstrapping the Go or Rust runtime library is a bitch on anything that isn't the [latest version of your target platform]

>>62151116
>Go is a Java, C#, Python competitor
Except Java and C# don't force you to use training wheels have training (C# even allows for unsafe code) and Python doesn't have the boilerplate Go requires (granting Go is faster than Python since it's compiled)

File: 1473544868444.jpg (80KB, 838x855px) Image search: [Google]

80KB, 838x855px

lol no generics

>>62151447
this one >>62148600

File: Screen Shot 2017-08-29 at 14.01.12.png (131KB, 633x666px) Image search: [Google]

131KB, 633x666px

>>62148600
>>62151479
Toddler language is for toddlers

>>62151654
>consider copy and paste

>>62151438

>Except Java and C# don't force you to use training wheels have training (C# even allows for unsafe code)

Go allows for unsafe code as well, what are you babbling about ?

>>62151447

When Go 2.0 comes around (likely the release after 1.10) you will need some fresh memes since generics will make an appearance.

>>62152496

>>62141697
>>62150513

>>62152469
The fucking training wheels where you need to keep surrounding shit with try/catch so the compiler let's you continue.

>>62152577

>The fucking training wheels where you need to keep surrounding shit with try/catch so the compiler let's you continue.

There's no try/catch in Go, wtf are you smoking ?

>>62152469
>Go allows for unsafe code as well
>golanglet trying to defend a shit language
C#'s unsafe is a special keyword that lets you work with pointers just like in C.

>>62150695
>Case in point slices.
>Their justification for slices is to "prevent errors when handling arrays" but this
>a) adds too much boilerplate
>b) any decent programmer knows how to handle those errors, because if your learnt C/C++/Java, you already seen this happening a lot so you just avoid the pitfall.
>c) "Preventing" errors with slices is retarded when the whole language forces to use try/catch everywhere anyway. Would make more sense for the compiler to force to add a try/catch block for arrays (more boilerplate?) than force me to use slices.
This is C/C++ mentality right here, having arrays that dont know their size that allow buffer overflows and hackers to walk off arrays is the cause most all crashes and insecurities. Their 'logic', uh, dont worry, if it crashes, we'll catch it with exceptions.

>>62147812
>Checked exceptions are a thing.
Checked exceptions are a failed experiment. Checked exceptions means being forced to handle exceptions by the compiler which can turn certain code into an unreadable mess of try/catch/finish blocks

>>62153278
If you don't want to handle a checked exception in a particular method, then just write throws on the signature and forget about it.

All that checked exceptions do is force you to write in the signature what the interface to your method really is. That's a good thing.

>>62124202
Mozilla vs Google.

File: skub.gif (7KB, 181x251px) Image search: [Google]

7KB, 181x251px

>>62124220

>>62124220
Apples are better, healthier & tastier.

>>62153278
>>62153198

func TestHandler(t *testing.T) {
    gofile := "/tmp/testprog.go"
    if err := ioutil.WriteFile(gofile, testprog, 0666); err != nil {
        t.Fatalf("can't create go file")
    }

    outfile := "/tmp/testprog.out"
    arg := time.Now().UTC().String()
    err := exec.Command("go", "run", gofile, outfile, arg).Run()
    if err == nil {
        t.Fatalf("completed normally, should have failed")
    }

    data, err := ioutil.ReadFile(outfile)
    if err != nil {
        t.Fatalf("can't read output file %s", outfile)
    }

    if string(data) != arg {
        t.Fatalf("bad data")
    }
}

>

if err != nill

>

if err == nill

>is not try/catch guys!!!
Just like people saying

try/catch

wasn't the new goto

>>62153198
>implying C# solution isn't more elegant
We already have mutable Array<T> objects. Oh wait, that needs generics.

>>62153474
>is not try/catch guys!!!
It isn't try/catch, it's poor man's Maybe/Optional<T>.

>>62153474
>>implying C# solution isn't more elegant
>We already have mutable Array<T> objects. >Oh wait, that needs generics.

>oh, b-but, we got vectors in the C++ template library
>Oh wait, that needs generics....duh

>>62147907
>We always will.
Only for as long as there is Unix, and even then you could use a different language with a C-compatible ABI.

>>62153491
>runs a functions that might fail
>expect an error
>no error? go on
>error handle error
>not try/catch
I guess there's no point arguing that.

>>62153537
What Go does is closer to optionals than exceptions because it doesn't involve non-local returns. Read https://github.com/nlkl/Optional if you aren't familiar with optionals.

>>62153537
>one is a bunch of if statements and explicit returns
>the other has no ifs and tears down the stack until it finds a proper handler
Totally the same thing.

>>62153564
>>62153577
Seems like something that can be handled with proper initialization of return values. But I guess that's the (oh my gosh) C/C++ mentality.

>>62153636
no. C++ literally shits on Rust and Go simultaneously. write me a compile time HTML parser in Go/Rust. Write me a compile time assembly interpreter in Go/Rust you cant,,
C++ CAN!
https://github.com/stryku/ctai
https://github.com/rep-movsd/see-phit

>>62153636
>something that can be handled with proper initialization of return values
No, Optional<T> is there to handle errors that cannot be represented in the type T. E.g., if you're decoding a UTF-8 byte sequence to a string, the proper result type is Optional<string> to handle the case when your input is invalid. You could return a special value like an empty string or "!!!ERROR!!!" or something to represent an error, but then what do you do if your byte sequence decodes to literally that special string? Optional<T> lets you avoid those hacks.

>>62153537
write this in Go

void function()
{
 try{
function();
throw 42;
}
catch(...)
{
throw 42;
}
}

int main()
{
while(true) function();
return 0;
}

>>62153733

int main(int argc, char **argv)
{
    const int x = 3;
    *((int*)&x) = 4;
    printf("x = %d\n", x);
    return 0;
}

Write this in Go.

> you can't

>>62153789
What language is this?

>>62153789
What does this have to do with my post?

>>62153671
>write me a compile time HTML parser in Go/Rust
You can probably do it in Rust with const functions. D is better than either C++ or Rust at this, though.
https://tour.dlang.org/tour/en/gems/compile-time-function-evaluation-ctfe

>>62153795
C.
>>62153798
It's proof you can't write it in Go. I don't care about UTF-whatever no one uses that junk.

>>62153825
It's an ill-formed C program, it has UB.

>>62153812
REEEEEEEEEEEEEEEEEEEEEEEEEEEEEE

>>62153825
>It's proof you can't write it in Go. I don't care about UTF-whatever no one uses that junk.
It has nothing to do with my post.

>>62153842
It does. You talked about Optional<T>. I made a rebuttal with a C program, which isn't optional. You Can't write It In Go.

>>62153736
Well, my idiotic gopher, that function will stack overflow before reaching throw because the recursion doesn't let it hit throw.

>>62153886
yes. correct. can you write it in Go?

>>62153896
What? You want me to translate your idiotic mistakes to Go. No thanks. Write them yourself of you can do as in here >>62151654
>Consider copy and paste

>>62153872
https://www.qedcat.com/moviemath/holy_grail.html
I literally said nothing about the relationship between C and Go. I only explained why Go's errors are not exceptions, but (a worse version of) optionals.

>>62153916
Ill try

fn test() {
  test()
}

fn main()
{
  test()
}

literally never written Go in my life is it correct

>>62153934

void function()
{
  throw std::runtime_error("This is an error");
}

There is a proper exception for you. It's not an optional.

>>62153973
Yes, and? Expections aren't optionals.

>>everyone who is arguing with >>62153934
You're retarded, you don't understand what Optional/Maybe/Result and you're just spouting nonsense.

>>62153952
pretty close, just use func instead of fn

package main;

func test(){
    test();
}

func main(){
    test();
}

>>62147700
Dropbox wrote their distributed petabyte filesystem in rust.

>>62153991
Correct. How about

template <typename F, typename... Args>
auto ptr(Args&&... args)
{
   return std::make_shared<F>(args...);
}

int main()
{
  auto variable = ptr<std::vector>(10);
  return 0;
}

how about this?

>>62153789
>Write this in Go.
>> you can't
nor would I want to

>>62154039
>nor would I want to
>because no training wheels
:^)

>>62149048
Nice Rust code, troll.

let arr = [1, 2, 3, 4, 5, 6, 7];
let result = arr.iter().filter(|i| i == 2);
[\code]

>>62154033
I am still not sure what you point is. You're not putting it in words, so in case you're just trying to waste my time I'll stop replying.

>>62154102

template <typename F, typename... Args>
auto ptr(Args&&... args)
{
   return std::make_shared<F>(args...);
}

int main()
{
  auto variable = ptr<std::vector>(10);
  return 0;
}

write this in rust
> you can't

>>62154110
the point is can you write that in Go? you keep going on about how optionals are better than exceptions they C++ trumps all.

>>62154116
>originally asked to be written in Go, now in Rust
>the old switcheroo
golang users have a lot to be ashamed.

>>62154057
>>because no training wheels
>oh look, I can cast something like a string into a memory address of an array that holds pointers to ints
sorry, Im not impressed

all this pointer bullshit might have legitimate uses in systems programming, but anyone who thinks this does anything useful in user space is just fooling themselves

>>62154133
All right, since you did put it in words I'll reply once more.
>you keep going on about how optionals are better than exceptions
I said nothing of the sort in my posts (>>62153491, >>62153564, >>62153733, >>62153798, >>62153842, >>62153934, >>62153991).

>>62154166
>pointer bullshit
I guess you're (((first))) for not working with large datasets and mutating the data as needed.

>>62150330
fuck you

>>62154172
dude it's fine. i'm just messing with you. some anon told me Rust is a functional language. I had to let out a few trolls for that.

>>62153671
Rust has procedural macros and compiler plugins which you can both use to do either of that.

>>62154225
>I was just pretending to be retarded

>>62153789
Literal retard.

>>62154211
somebody should really take time to learn exactly what large data sets are. because if you think dynamically allocating large data sets on the heap and using a pointer to walk that data is efficient, then maybe its time to pull your head out of K&R

>>62153733
You don't seem to understand exceptions. With your example if the stream is invalid, then raise an exception and handle it or just flag it and check the flag down below. Returning empty strings or something like "!!!ERROR!!!" is lazy coding and an ugly hack.

>>62150583
Racket is cool.

>>62154312
how else do you do it?

>>62154312
>what are *pointers* to file
>what are *pointers* to arrays/structs
If you believe that the only way to code in C is to load everything on the heap then I can see why you need Go.

File: the go book and it's users.png (774KB, 1000x706px) Image search: [Google]

774KB, 1000x706px

Even the go book it's patronizing

so in total I think the results are about 1/3 Go, 1/3 rust, 1/3 they're both shit

>>62154583
this

>>62148680
Fixed

Top tier:
ASM
C
C++
Rust

Okay tier:
D
C#

Slow as fuck/skid tier:
Go
Java
Python
JS
Ruby
Lua

Autism tier:
C
C++
Rust
Hasklel
F#
Scala
OCaml
Erlang
FORTRAN
Clojure
Coq
Agda
etc

Emerging tier:
Elixir
Nim
Crystal

>>62156535
Top tier:
ASM
C
C++
Rust

Okay tier:
D

Slow as fuck/skid tier:

Autism tier:
Hasklel
F#
Scala
OCaml
Erlang
FORTRAN
Clojure
Coq
Agda
Go
Java
Python
JS
Ruby
Lua
etc

Emerging tier:
Elixir
Nim
Crystal

>>62156599
>Emerging tier:
>Elixir
>Nim
>Crystal
I wouldn't say elixir is emerging. Compared to the two others it might as well be Java.

>>62156599
>>62156535

Here:

People actually ship stuff tier:

- Java
- C, C++
- PHP
- Python
- Ruby
- Node

Theoretical tier:

- Haskell
- Rust

>>62156535
>Slow as fuck/skid tier:
>Go
>Java
The "Java is slow" meme is a good way to detect kiddos who don't actually program.

File: IMG_1460.png (1MB, 1920x1080px) Image search: [Google]

1MB, 1920x1080px

>>62156667
>Theoretical tier:
>- Rust
>implying there isn't an OS already written on Rust
>Comes with screenfetch for your ricer threads.
Try again

>>62156867
Sure thing pajeet.

https://benchmarksgame.alioth.debian.org/u64q/java.html
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=java&lang2=csharpcore

>>62156874
yeah,

how many fulltime users?

it's like Haiku/ReactOS, 0 people use it for day to day

come on man, try harder.

>>62156667
Let me fix that.

People actually ship stuff tier:
C
C++
Rust
D
C#
Go
Java
Python
JS
Ruby
Lua
Haskel
F#
Scala
OCaml
Erlang
FORTRAN
Clojure
Coq
Agda
Elixir
Nim
Crystal

Really, people ship in just about every damn language, though in something like Coq, Agda and R what they ship is more likely to be reports/research articles than production code.

>>62156874
also, one more thing

nice uptime

lol

come on dude, no one's writing anything serious in rust other than gimmicks.

>>62156924
>he thinks I'm talking about the OS
>not the fact that Rust has so many users that they could band together to write an OS to begin with
You're missing the point.

>>62156924
I think Haiku devs actually use Haiku. It's pretty usable on old ThinkPads, at least.

>>62156960
Do yourself a favour and read the thread. You're just embarrassing yourself >>62134446

Go and Rust are totally used in different areas, Go is used for web and other high level requirements while Rust is more useful for systems programming and maybe building new Os and embedded systems in the future

>>62156951
Like, no one uses rust.

Or D

How are you even fathoming stating that Rust even places? It's a hobby language that lives on reddit and HN.

It's filled with butthurt weenies. and despite the PR, there's nothing to show for it.

No offense, but the attention isn't proportional to the industrial merit. It's just a bunch of prima donnas squalking hard about safety.

you guys can't even think of a AAA game engine, a real OS that's used at scale, a library other than servo.

there's nothing you got going on

yet you get all egotistical and cry about stuff. just grow up and actually learn achivement

you're not going to be on reddit forever, you gotta focus and actually do something real, or you'll never amount to anything

>>62156874
But can you use it to talk to God?

>>62156914
The HotSpot vs. .NET Core link says HotSpot is as fast or faster in most cases. You should really compare HotSpot to C++, not .NET Core, and that is practically the definition of "fast". I say this with no love for Java, no love at all.

>>62156535
>Slow as fuck/skid tier:
>Go
Go compiles to machine code, you fucking retard.

>>62150513
I'll look into it but I guarantee you that this 1 potential advantage does not outweigh the things that put me off of Rust, especially if the advantage is just around reducing how much you type since the rest of Rust is extremely verbose.

>>62157062
Indeed HolyC is the best. Everything else is CIA cancer.

>>62157049
They're trying their hardest to have some kind of viral explosion in popularity, and it's just not going to happen.

>>62157156
Alright, so?

>>62157077
If you go that way, then we should add Mono into the mix, which is already faster than .NET Core. And while we're at it, we add Jython (with HotSpot) and PyPy for Python and see what happens.

File: 1500672075143.png (455KB, 810x688px) Image search: [Google]

455KB, 810x688px

>>62124202

Go programming is my day job. It's a great language. Debugging is a cake walk. Automating typical office stuff is a cake walk. Building a functioning API that is virtually error-free is a cake walk.

Go is a language for grown ups who want to get shit done and not get bothered by higher ups about the 50k edge case bugs you'll get when using JS / Ruby / PHP. It's got most of the ease of use of a scripting language but with enough stopping power to build 3D games, emulators, networks, and global scale web apps.

Uber an IPFS use Go as their backend.

Cons:
Error checking. Error checking everywhere.
Working with dynamic JSON is a bitch.
I really enjoy functional programming and Go is basically the opposite of that. On the plus side, you don't need to be an expert in category theory to read my code.

>>62157049
>It's a hobby language that lives on reddit and HN.
No, I think a realistic view of Rust is that it is a language built for a specific purpose: to improve Firefox's performance. Mozilla built it for their needs much like Ericsson built Erlang for theirs in the 80s. Every other use of it is a nice bonus, PR material for Mozilla, and another boost to Steve Klabnik ego, but that's it.
>No offense, but the attention isn't proportional to the industrial merit.
Personally, I would not say anything about Rust's broader merit. I think its ideas about safety are valuable, but it isn't very ergonomic to use compared to C# 7, OCaml, or even reference counted language like Swift. I think if Rust's GC-less safety ever becomes available with good ergonomics, it will take another language or two first. But! Mozilla ships Rust code in Firefox, thus Rust's purpose is fulfilled.

>>62157163
>rust is extremely verbose
The only circumstance in which Rust is more verbose than Go is when you're delegating traits to members of a struct.
Go implicitly does that for you when you embed structs. There's an RFC currently open that would add a shortcut for explicitly delegating traits though.

Every other aspect is far less verbose because Rust actually learned from mistakes made in previous languages. You have flow control options beyond for, if and return.
Go just butchered C and added a GC and concurrency.

>>62157211
>>62157049
see >>62134446
You guys are just sad, probably Go users too. You're just trashing Rust because nothing go has proven to be a training wheels language for brainletes and are adding nothing to the discussion.

>>62157228
JRuby is fast than MRI Ruby, but Jython is slow as fuck. It is consistently slower than Python 2.7. Only ZipPy is fast on the JVM, but it ain't ready.

>>62157257
>Debugging is a cake walk.
What do you use to debug Go, gdb?

>>62157289
Your language will never amount to anything other than a hobbyist lang, and the sooner you accept that truth, the happier everyone will be

>>62148600
>>62151447
>>62151654
>>62154583
this

>>62157257
I guess they also measure your performance by your LOC output too.

>>62157312
>waah, the shipost
:^)

>>62157257

This. Go gets it right on what's most important for getting shit done. Great tooling and keeping the retards from fucking things up with their unmaintanable patchwerk of code. I'm glad you can reverse a list in 9 different ways with your language but I need to get shit done.

>>62154116
>using variadic functions
Go die in fire

>>62157357
>what's most important for getting shit done
Except for generics.

>>62124687
>>62135570
>Taking that quote out of context over and over and over
Go fills the niche of academia not producing people capable of writing production-grade code. Why the fuck do you think it so closely mimics standard pseudo-code syntax?

It also makes concurrency a breeze, which most other languages struggle with.

File: 1407630627378.png (14KB, 464x212px) Image search: [Google]

14KB, 464x212px

>>62157352
>i sent him the meme emoticon, i sure showed him

>>62157257
>Working with dynamic JSON is a bitch.
Agreed, and dynamic YAML even more so.
>On the plus side, you don't need to be an expert in category theory to read my code.
To be fair, that is also the case with most Haskell code.

>>62157357
>Go gets it right on what's most important for getting shit done.
You can get shit done in any language if you're competent

>Great tooling and keeping the retards from fucking things up with their unmaintanable patchwerk of code
This seems to be the only thing Go is good at. No wonder why their userbase thinks everyone but them is a retard.

I think this thread is definitive proof that Go and Rust fanboys are the worst. Avoid both languages to avoid interacting with them.

>>62157212
>Alright, so?
try compiling the C or C++ programs in the benchmarks game with -m generic -mtune=generic in an amd64 system, and run the benchmarks again... you'll notice that the difference isn't much at all.
this happens because the C/C++ compilers take advantage of ISA extensions (AVX, etc), while Go doesn't, simply because it compiles binaries for the most generic arch (in this case, amd64)

>>62157407
>Go fills the niche of academia not producing people capable of writing production-grade code.
So do Java, C#, Python, Ruby and JS.

>>62157357
Hi, Deutsche anon.

>>62157407
>Go fills the niche of academia not producing people capable of writing production-grade code.
odd... I thought academia loved mentally masturbatory stuff that barely, if ever, helps anyone. things like FP langs...

>>62157448
>Go doesn't, simply because it compiles binaries for the most generic arch (in this case, amd64)
So the compiler is written by brainlets too?

>>62157584
>Go linker, written in Go, produces code that is as fast as C/C++, without taking advantage of specific ISA extensions
>brainlets
you must be a genius. show us your work, an0n...

File: Screen Shot 2017-08-29 at 20.59.56.png (194KB, 1394x1298px) Image search: [Google]

194KB, 1394x1298px

>>62157730
>Twice to thrice slower
>As fast as C
Brainlets indeed.

>>62157467
They don't at all.

>>62157506
That's because you're probably 17 and have been nowhere near a higher institution. All upper level concepts aren't taught in a specific language, they're taught using pseudocode.

File: 2017-08-29 20_11_54-Go vs C gcc (64-bit Ubuntu quad core) _ Computer Language Benchmarks Game.png (18KB, 505x464px) Image search: [Google]

18KB, 505x464px

>>62157790
Hey look I can cherry pick too!

>>62157790
are you retarded, or just pretending? >>62157448
go try benchmarking some sha256 hashing, let us know how it goes

>>62157933
>That's because you're probably 17 and have been nowhere near a higher institution. All upper level concepts aren't taught in a specific language, they're taught using pseudocode.
that's how I know you never got past 1st year of CS, if that.

>>62157957
>that's how I know you never got past 1st year of CS, if that.
at a really shitty university... assuming you went to uni, and not some technical school

we got a retard posing as an enlightened developer

File: Screen Shot 2017-08-29 at 21.13.28.png (132KB, 1478x872px) Image search: [Google]

132KB, 1478x872px

>>62157946
>>62157957
Too bad that even during your "cherry picking" is still slower than C
https://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc

>>62157957
>that's how I know you never got past 1st year of CS
Ask how I know you went to community college

>>62157992
Nobody said it was fastER than C, dipshit, just "comparably as fast"

>>62157946
glad to see I/O is the same speed across languages. thanks anon

File: Shadowmagexd+rolled+a+random+image+posted+in+comment+94+at+_d15406c934125b95d6c525a260483082.gif (224KB, 267x199px) Image search: [Google]

224KB, 267x199px

>>62158008
>moving the goal post
You brainlets said it was AS FAST here
>>62157730
>as fast as C/C++

which it isn't, and I never assumed it was faster (because it's not) but whatever let's you sleep at night fuckwad. Don't forget to take your helmet before you

go to_bed

>>62157999
>community college
not a thing in my country.

btw, protip: real unis don't teach using pseudocode... that's for dumb people like you. in fact, apparently you just outed yourself, again.

>>62158071
again, retard posing as enlightened...

>>62158097
>again, retard posing as enlightened...
>waaah, waaah, waah, mommy he's hitting hard
Keep posting, maybe you'll stumble upon an actual argument we can talk about.

>>62158120
exactly, I'm waiting for real arguments, not just
>hurr durr Go is slow!!1
>C/C++ are much faster than Go!!1

>>62158120
>>waaah, waaah
are you quoting yourself?

>>62158153
Well, you could read the thread, but I guess that's too much effort for you.

Scala?

Thread is sinking, so long suckers

>>62124220
apples taste like shit. oranges are good

>>62159328
Swift

t. IBM

>>62157284
Okay but what if I've changed my mind about Mozilla and no longer like them? You can argue that this doesn't afect Rust itself but I'm legitimately worried that they might be bad for the future of the project for several reasons, some of which is their history of poorly maintaining projects and questionable judgment. Google seems to have an alright track record with tools and only have this problem with products/services, the people in charge of Go and its direction seem very sensible.

I want to point out that I'm not arguing for arguments sake, I do like Rust conceptually but there are things about it that make me reluctant to invest the time needed to learn and utilize it, my greatest fear is it being a waste of time.

>>62150695
>>62150732
Can you give an example of what you mean by boilerplate?

I also don't think it's a fair point to make necessarily since Go has a focus on saftey; why I think it is unfair is because with any language that focuses on safety you will have features that are unnecessary if you instead just put the onus on the programmer, like you did with your stipulation.
>any decent programmer knows how to handle those errors

For example, languages that don't let the programmer use pointers directly to avoid any problems associated with them, you could say "just use C and don't make mistakes", it's not necessarily wrong but it doesn't seem like a valid argument against the language, more of an argument against safe focused languages, even then though it seems like a correct but impractical solution, humans will always make mistakes.

>>62153414
>skubfags