C++ V.S. Rust: The Final Battle

Rust is better, but is still in its meme phase.

C

>>58148720
Rust will get out of it's meme phase as soon as more developers start using it

>>58148726
go to your room, the adults are talking

Rust is objectively better, but C++11/14/17/20 is on the right way and it presents a more practical upgrade path from C or C++03. Coupled with a large pool of C++ specialists and huge amount of legacy code, I don't think Rust will be able to compete with C++ for real in the next decade.

>>58148730
My biggest problem is the lack and immaturity of libraries. I know Rust is really young, but I cannot recommend it to use in production for this reason.

>>58148708
C++ if you only consider the language.
Rust if you don't want to spend hours setting up your project before you've even written a single line of code whose purpose isn't evaluating the library you wanted to use.

Rust is the future, C++ is the past.

>I'm too dumb to learn to use any of these languages so I will start a flame thread to make the fanboys mad at each other, and to justificate my opinion on the usability of said languages
t. butthurt/brainlet OP

>>58148708

C++

Rust is a meme. If i want "security", then Ada is the right choice.

>>58150603
>either manual management or GC
>security
>performance
>right choice
You're the meme.

Rust is the better language, C++ is trying to play catch-up with it as far as memory safety is concerned, but it will never be able to.

how many Rust jobs are there? approximately 5?

>>58150983
better to write your backend processing maybe but anything user facing looks like a fucking nightmare in rust so far

looks ideal for writing libraries to do stuff though, leave ui to some other language and take advantage of rust where it'll help the most

learn Go (golang). surely won't work for making an OS or some critical low level stuff, but for eveything else, it works and it's just awesome.

>comparing godlevel Rust with shitty c++

Rust is still a meme

C++ is more widely used dogshit

stick to Java if you can

>>58151127
>java
toplmao!! why is /g/ full of plebs?

>>58151137
c++ is nothing but bloat, pain and suffering

I'd rather be a happy and productive plebfag

>>58151067
Not any more or less than C++ (actually less than C++ due to the functional, high-level features).

>>58151105
>all the flaws of C
>no feature from the past 40 years of language improvements
How about 'no'.

>>58151259
>>all the flaws of C
wat

>>no feature from the past 40 years of language improvements
yeah, the kind of "improvements" that make devs think themselves as 1337 h4x0rz while producing/duplicating shitty code

>>58151303
The joke is that linus doesn't know shit about C nor C++.
>m-muh os!11
It's like that guy who made libhungarian. Worst code I've seen in my life and it barely works but it works.

>>58151346
Gotards, everyone.

>>58151163
>impying I like c++

>>58151377
patches are welcome
also, you clearly don't know shit about Go

>>58148708
>>58151105
btw, you can start here:
https://tour.golang.org

>>58151491
>go
>any contribution whatsoever being welcome
Gotards everybody!

>>58151066
Yes, but it's the future.
5 jobs for humans and everything else for robots.

>>58148708

Depends on context.

If you're a guy looking for a job, C++, more companies use it atm.

If you're an old company with established practices, C++, because libraries.

If you're a new company, with time, money and developers, and you want to be able to do things that other companies can't yet, Rust.

If you're an open source developer with lots of time, Rust.

>>58151105
I can't see why would anyone have any interest in castrated C with GC. I spent some time reading about Go and it's like the authors stuck in 80s: weak type system, no generics, no pattern matching, interface{} all the way down, retarded error handling based on Bools and Strings, horrendous syntax and relatively poor performance for compiled language. The only reason it's still alive is because it has Google's prestige behind it. The only good thing about it is gorutines, and C++ and Rust are making steps in this directions.

I mean, for a long time they didn't even have bootstraping, having a lot of C code. Then suddenly they declared they rewrote it all to Go, yet when I check it, it turned out they wrote a tool which AUTO-CONVERTED all their C code to Go, and so they now have a ton of auto-generated Go code they need to support somehow. After that I became dead sure the developers not only are retrogrades stuck in 80s, but also brain dead.

>>58148778
Features isn't what c++ is missing.
There are 3 main problems which are never gonna get fixed.

1. Header files & long compile times
2. No reflection for automatic (de) serialisation.
3. Absolutely horrible trying to port/build to a different platforms

>>58151776
Google cared mostly about compile times

>>58151890
You forgot memory unsafety and exceptions.

>>58151776
This. And despite all that, gotards are somehow still a thing.

>>58151890
c++ is getting modules and reflection in c++20, hopefully. if it doesnt get pushed back to a later release again.

>>58151776
>I can't see why would anyone have any interest in castrated C with GC. I spent some time reading about Go and it's like the authors stuck in 80s: weak type system, no generics, no pattern matching, interface{} all the way down, retarded error handling based on Bools and Strings, horrendous syntax and relatively poor performance for compiled language. The only reason it's still alive is because it has Google's prestige behind it. The only good thing about it is gorutines, and C++ and Rust are making steps in this directions.
it's easy and simple, and supports lots of platforms, architectures, etc. sure, error management sucks and Go doesn't support generics... but, again, the Go devs have said so themselves:
patches are welcome

>I mean, for a long time they didn't even have bootstraping, having a lot of C code. Then suddenly they declared they rewrote it all to Go, yet when I check it, it turned out they wrote a tool which AUTO-CONVERTED all their C code to Go, and so they now have a ton of auto-generated Go code they need to support somehow. After that I became dead sure the developers not only are retrogrades stuck in 80s, but also brain dead.
being Go a small language, I don't even see the problem with this. also, as someone told me once, it's not exactly C what they autoconverted... but specific flavour of C they have used for decades.
and afaiu, they removed lots of the bad autogenerated code in Go 1.6.
the Go ecosystem moves fast as hell, but according to you, that's a bad thing, and the devs are "are retrogrades stuck in 80s, but also brain dead". meanwhile, Rust is still alpha, apparently for eternity.

btw, did you notice that Go takes lots of good features from many other langs? meanwhile, other lang devs are polishing their turds, simply making a mess of them

>>58151890
> 1. Header files & long compile times
Yeah, but I hope Modules will fix this.
> 2. No reflection for automatic (de) serialisation.
There are some proposals for compile-time reflections, but I personally don't think there is a huge need for this in compiled language. Serialization isn't such a big thing to include support for it in the language itself. Some actual macros system or C#-style attributes would be nice though, but it's unlikely we'll ever get them.
> 3. Absolutely horrible trying to port/build to a different platforms
I don't get it, the only language which have better crosplatform story is C.

>>58151935
Memory unsafety is a feature of systems programming languages. You NEED pointers. With gc it simply isn't a system programming language. Unless you want a draconian compiler checking like rust.

Exceptions suck and should be disabled in the compiler.

>>58151776
The C compiler used by Go wasn't all that great to start with. AFAIK it's a relic from Plan 9. Like you said, they auto converted the code from C to Go for whatever reason. It was most likely a prestige thing.
I never understood why they didn't utilize something like LLVM. They'll never catch up.

>>58151980
>No need for reflection
Is that why so many projects have some kind of shitty slow meta tool
>I don't get it
What I mean it's a horrible experience trying to build a project on different platforms. Everyone does kinda its own thing and there are dozens of different build systems.

Personally I switched to a unity build myself. This actually removed the need for header files ( only one for public api) and build systems and reduced the compile time.

File: stallman(20).jpg (4KB, 259x194px) Image search: [Google]

4KB, 259x194px

>>58151105
>systems programming language
>won't work for making an OS or some critical low level stuff

>>58151984
Just because you need memory unsafety for 0.00001% of programs in 0.1% of those program's codebases does not mean it should be the only way to deal with memory.

https://www.strawpoll.me/11949086

>>58151978
>it's easy and simple
This is might be the key here.
>the Go ecosystem moves fast as hell, but according to you, that's a bad thing
>specific flavour of C they have used for decades
So how "using a specific flavor of C" instead of standard C is a good thing to begin with? Read this - http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/ , their compiler infrastructure is a bunch of NIH shit they invented literally in 80s for failed Plan 9 meme OS and refuse to let go since then. Like, they have their own assembler with their own syntax, their own linker and codegen, all weird and incomparable with the rest of the world. Meanwhile things like LLVM exists for decade. I mean, yeah, they try to fix it but it's still idiosyncratic shit for no reason except for authors' severe NIH syndrom.
>Rust is still alpha, apparently for eternity.
Rust is stable since May 2015, they released 1.14 a couple days ago, stable Firefox uses Rust from some components.
>did you notice that Go takes lots of good features from many other langs? meanwhile, other lang devs are polishing their turds, simply making a mess of them
This is an interesting thing to say, considering Go still lacks algebraic types, real macro system, pattern matching and generics, while even C++17 have the last 3 in some form or another. Like, do you really have an idea how C++ or Rust changed in the last 5 years?

>>58152038
>I never understood why they didn't utilize something like LLVM. They'll never catch up.
speed, the devs said so: https://news.ycombinator.com/item?id=8817990
>Honestly, if we'd built on GCC or LLVM, we'd be moving so slowly I'd probably have left the project years ago.

>>58152079
>muh "systems programming language" meme

>>58152082
>does not mean it should be the only way to deal with memory.
thats what custom pointer classes are for.

>>58152128
>significant overhead
>plus even more overhead and non-determinism than gc because lmao refcounting ebin!

>>58152082
If you don't need pointers why the fuck are you going through the pain of using C++ in the first place. Use some GC language.

File: canvas.png (207KB, 1651x943px) Image search: [Google]

207KB, 1651x943px

>>58152151
>what is std::unique_ptr

>>58152151
you can use gc in c++ or any other memory management style you want if you really want to.

C++

Because freedom > safety
Freedom brings responsability = Better programmers
Safety brings confort = Pajeet programmers

Also, the necessary tooling already exists. Rewriting everything from scratch because it's hard to get "C++ done right" sounds like a bad excuse.

>>58152188
Because most languages don't have value types.

>>58152190
-deprecated
-as noted, still massive overhead
-not compatible with other pointer semantics
>unique

Is there a good library for web API on Rust?
What about db connections?
Maybe even ORM? Or at least some library that can generate query for you?

>>58152188
Or I could decide that maybe my IQ isn't in the single-digits and use rust instead, since it solves all related issues perfectly.

>>58152223
>Freedom brings responsability = Better programmers
>this is what pajeet believes
Don't you have another memory leak and 20 segfaults to fix pajeet? What are you doing not working?

>>58152124
>We refuse to look into any other toolchain than what Plan9 provides

Wait it can compile against arm-none-eabi?

>>58152236
Why do you even argue about things you don't know?
- Not only unique_ptr isn't deprecated, it's the recommended way to manage objects on the heap. You're confusing it with std::auto_ptr from C++98, which is deprecated.
- unique_ptr compiles to no-op, it literally does nothing, its purpose is to force ownership semantic during the compile time. You're confusing with std::shared_ptr which does refcounting on construction and destruction.
- what

>>58148708
C++ with good programming practices is objectively better than Rust.

>>58152252
>I want full control over my memory so i can reduce overhead and minimize memory latencies
>I don't want to deal with the inevitable consequences of that freedom

Can't have your cake and eat it to.

File: 2016-12-24-094906_1180x673_scrot.png (193KB, 1180x673px) Image search: [Google]

193KB, 1180x673px

>>58152190

>>58152244
Check crates.io for all your questions.
1- rustful/rustless, hyper, iron, aries, etc.
2- postgres, unqlite, ejdb, r2d2, mongo-rs, mysql, etc.
3- diesel, deuterium

>>58152244
>Is there a good library for web API on Rust?
https://rocket.rs/
http://hyper.rs/
http://ironframework.io/
>Maybe even ORM? Or at least some library that can generate query for you?
http://diesel.rs/

>>58152281
>literally posts a pic that literally describes the cost of unique_ptr
>"i-it totally c-compiles to nop nevermind what I just posted but don't forget what I just posted!"
My sides. Enjoy using your deprecated, slow pointer wrapper, retard.

>>58152252

> I can't handle sanitizers.

rofl

>>58152270
It can target anything LLVM targets, so yes.

>>58152294

This.

>>58152296
Turns out you can. It's called rust. Look it up.

File: platforms.png (389KB, 833x2481px) Image search: [Google]

389KB, 833x2481px

>>58152270
https://forge.rust-lang.org/platform-support.html

>>58152108
>http://dtrace.org/blogs/wesolows/2014/12/29/golang-is-trash/
>2014/12
whatever, m8. keep masturbating over your specialized knowledge of this or that language, while the Go devs produce shit that works™

I myself, like most devs, have no need for that.

>>58152244
>Is there a good library for web API on Rust?

http://rocket.rs

> Maybe even ORM? Or at least some library that can generate query for you?

http://diesel.rs

>>58152294
>no destructuring binds
>no proper functional tools
>mutability by default
>lmaoconst
>reversed ownership model
>heavyweight classes instead of 0-cost structs
>lmaoexceptions
>memory management is either costly or a guaranteed significant source of bugs ranging from heisenglitches to critical security vulnerability allowing full system access
>no proper modules
>no proper dependency management tools e.g. for reproducible building
Not even close.

>>58148708
Only neet would ask stupid question like this.

>>58152318
Can you read?
>Cost: same as new/delete or malloc/free
The smart pointer itself costs nothing, using unique_ptr is equivalent to using new/delete, which is more or less equivalent to using malloc/free.

>>58152390
Noob Question; what's the point of immutable variables?

>>58152411
for long nights of 'brain-off' programming

if the compiler shouts that you are changing an immutable variable, you should go into 'brain-on' mode

>>58152390
>heavyweight classes instead of 0-cost structs
the only difference is whether the default is public: or private:

>>58152411
threadsafe. simpler to understand and optimize.
creates a ton of garbage in functional languages because you cant mutate anything.

>>58152390
>no destructuring binds
They added it in C++17, at least for tuples.
>no proper functional tools
Like what? With lambdas and std::function you can do pretty much everything.
>mutability by default
Just write "const".
>lmaoconst
You forgot "volatile".
>reversed ownership model
Whatever.
>heavyweight classes instead of 0-cost structs
Classes and structs are literally the same and they are zero-cost except for vtable, and you don't have it unless you're dumb enough to use virtual methods.
>lmaoexceptions
It was a mistake, I agree.
>memory management is either costly or a guaranteed significant source of bugs ranging from heisenglitches to critical security vulnerability allowing full system access
Not if you know what you're doing.
>no proper modules
>no proper dependency management tools e.g. for reproducible building
Wait for C++20.

>>58152411
The compiler can optimize them, such as all immutable variables with the same value could actually be pointing to the same object.
The more important part, though, is that it acts as a simple protection against modifying part of the environment you do not want to modify inadvertently. For example, if you have the functions ret = do_first_step(x); and do_second_step(ret, x); it could be that do_second_step and do_first_step both modify x, yet both require the unmodified x as input. In C++, you don't even have a hint that this is happening. In rust, the compiler prevents you from calling do_first_step without making x a mutable reference, which in turn must mean that x itself is mutable.

Then there's concurrency. If two things are trying to read to an object, you can do that in parallel. When one thing tries to write to it, all reads must first be complete, then no other write must happen, then the scheduled write can happen, and finally the reads, or further writes, can resume. It's impossible to tell what needs to be locked in this manner without knowing if something needs to be mutable. On the other hand, if you know what is mutable and what isn't, it's not an issue.

>>58152472
>Not if you know what you're doing.

Nobody knows what they're doing then since basically all C and C++ code is riddled with vulnerabilities. The only reason you think yours isn't is because it's so small and irrelevant that nobody smarter than you has bothered to look at it.

>>58152431
No it's not. In rust, the only overhead for structs is the variant identifier. In C++, every time you create or destroy a class, you have a runtime cost. On top of that if you use inheritance in any way, size cost is not trivial at all.

>>58152313
Nice, tanks!

>>58151105
Fuck off Rob

>>58152318
unique_ptr simply calls new in the constructor and delete in the destructor. That's all. There is no overhead.

Rust shills are shilling for emptiness.

No one uses Rust (yet)

>>58152508
Inheritance in C++ is a meme anyway. Only use it for java style interfaces at best.

>>58152545
The overhead is small != there is no overhead.

> C++ V.S. Rust

fuck both

It is hard to program for linux since the api is meant for C

>>58152568
because of the model used in c++, only a retard wouldn't use it. the trait-based approached is infinitely superior for sure.

>>58152576
I don't agree with this statement. Rust makes it truly painless to work with C while retaining as many of its advantages as possible (and libcore and the like of runtime are goat, much better than anything C++ has to offer for working with C).

>>58152508

struct {...}; == class {public:...};
class {...}; == struct {private:...};

it only has runtime cost if constructors/destructor has runtime cost.

and obviously inheritance is going to increases the size unless it has no data.

>>58152508
> No it's not. In rust, the only overhead for structs is the variant identifier.
Did they get rid of the drop bit or whatever they called it? They had to put a byte in every type to see if Drop::drop was called on it already or not, because the compiler was too dump to determine it at the compile time.
> In C++, every time you create or destroy a class, you have a runtime cost.
You have no idea what you're talking about. Creating a class instance on heap in C++ is basically a single operator new() (which is malloc) + constructors chain. Creating a boxed value in Rust is exactly the same, ::new() being a constructor. Yes, virtual methods add vtable to the picture, but so do Trait Objects in Rust.

>>58152610
t. inbred

>>58152615
I laughed, but only a bit.

>>58152633
Come on mate this is shit-tier trolling. Ever heard of inline?

unique_ptr literally does what you would do in C, it just removes some of the potential for mistakes.

>>58152472
>Like what? With lambdas and std::function you can do pretty much everything.
Most of the whining about 'muh functional' that I've heard seems to revolve around not having reflection/type info that can be hacked into a json serialiser

std::function and all the tricky shit like bind and remove_reference make it so much easier to do a lot of common shit like gui or any other event-based stuff

>>58152573
Only if you don't handle exceptions correctly when doing new and delete manually.

>>58152573
if you want no overhead then use the stack.

File: 1482590910375.jpg (94KB, 499x542px) Image search: [Google]

94KB, 499x542px

>rustfags think they can ever challenge the collective autism devoted to c++

>>58152776
it's a useless language for most c++ users until there's good libraries for shit like gui or the 30-year dumpster fire that is the windows api

if people keep at it for 5-10 years, maybe it'll get there

>>58153517
There are already bindings for qt though.

>>58153517
Both of these already exist.

>>58153517
so... conrod?

File: image005.gif (137KB, 652x434px) Image search: [Google]

137KB, 652x434px

>>58153517
>programming is about gui toolkits and windows api
What is this, 90s?

>>58153580
I think I counted about 3 or 4 windows api wrapper attempts but they all sucked and were nowhere near complete or very useful

I also remember seeing some "rust on windows!" code that was basically endless unsafe blocks, defeating the purpose of Rust entirely

>>58153606
people still get paid to do those things

>>58153641
Where's the unsafe?
https://github.com/gabdube/native-windows-gui/blob/master/examples/simple_form.rs

>>58148708
With C++11 and 14 and with the upcoming updates C++ turned modern and relevant to be used in new projects. And with the new philosophy with quick standard iterations while still keeping backwards compatibility C++ effectively kills languages like Rust. Golang have it's niche due to google backing but it has serious problems with the standard lib to ever compete in traditional C++ segments.

If Rust is so good, why is it not the most popular systems language?

>>58153711
kek'd

>>58153721
If linux is so good, why is it not the most popular operating system?
Protip: justin bieber is the best musician this world has ever produced.

>>58153668
Yeah, it's marginal task now, you would use web for everything. Then again, if you need to write a traditional GUI you'd better off with technologies with traditional OOP and GC like C#/Java, because they're were designed with this things in mind. Rust is more about server-side, HPC and maybe embedded.

>>58153730
Nice argument

C++. Built-in WinAPI, better support from Microsoft, more diverse range of compilers (mingw, gcc, etc), better OOP experience.

File: 46bc7db51d8243b948ef3d431e0c2275.jpg (235KB, 625x833px) Image search: [Google]

235KB, 625x833px

>>58154001
> Built-in WinAPI
> better support from Microsoft
> better OOP experience.
What is this, 1995? No one gives a shit about WinAPI, no one cares about what MS supports and no one thinks traditional OOP was a good idea.

>>58152038
because llvm is written entirely in c++, therefore requires the developers of a programming language meant to get away from the fucking complexity races to write in the language that solely created those complexity races.
llvm sucks, and rust is stuck with it, so any of the new developments rust has will be riding on the back of the thing they are being compared to.
i don't know specifically what compiler go's is based on, but 8cc rocks if that's what it is, and it makes perfect sense to base your simple programming language on a simple compiler. evidently, that was the correct decision, seing how rust is still useless and go's 1.0 release was considered stable, and go has a frontend for gcc.
>>58151259
>all the flaws from c
they switched to a pascal-like type postfix (a very significant change, apparently only people who remember problems from 40 years ago can solve) to make things like first class functions simpler, they removed pointer arithmetic (which apparently also makes it 'castrated' to you autists, even though that makes it possible to satisfy restricted pointer optimizations at compile-time, something that fortran had and c still doesn't even after c99) to prevent memory leaks and simplify garbage collection, they added garbage collection to remove _any_ requirement for freeing (which is also evidently the correct choice, considering fucking java was adopted like crazy with one even though it had a bloated to hell oop model and it had to do so when we had a fraction of the memory we have now), also note that go's garbage collector is extremely simple and now has less than 100ns of s-t-w time overhead whereas rust's idea originally required that every instruction had a hard time limit and is more complex than what it's replacing.

go's developers specifically stated they were open to generics, but that they really weren't a big issue (they're not) because interfaces work fine unless you're not actually doing anything with your functions.

>>58154368
further, go's "flaws" are also its greatest strengths, not every programmer thinks that structs are the devil and classes are the greatest abstraction ever developed, and if you were really worried about abstractions you'd be very pleased to know that go has very nice anonymous and first class functions that rival lua's (a scripting language) in simplicity, and that go's type casting is explicit to a fault.

go is an excellent programming language that keeps concepts that are used poorly by dumb people out, and while that means they must sacrifice "muh ENTERPRISE GRADE abstractions" and other things that do make some things simpler, (ternary operators, honestly something i wish go had, but i understand why it doesn't) it is for a very just cause that only a drone who has never written anything more complex than a prime sieve in c++ would be unable to see.

>>58154510
I like go, I also like rust very much. Even though a lot of people compare them together as enemies I see them very much for different purposes. Go is for projects where scalability is the priority, while Rust is where safety and speed are a priority. The Rust team of course is also aiming for the 'productivity' angle which the cargo packager shows quite well.

It seems more that Go was engineered with the mind of teams working productively by forcing them to write in a readable and opinionated language.

Rust was designed by Mozilla due to the inability to keep up with Google/Microsoft while maintaining a project with a large codebase that had to be secure and fast, yet still be able to keep up with code reviews for each contribution, which became unfeasable based on the current C++ codebase.

>>58154368
>llvm sucks
I stopped reading there. The LLVM infrastructure is legendary. Clang is a top notch product, even though GCC generates faster binaries. 8cc can only dream having all those optimizations. There's no way for the Go compiler team to implement all those optimizations and stay up to date in a reasonable amount of time. A good example is SSE. Proper compilers like Clang and GCC have them for a long time, and Go only has it since 1.7(?) only for x86.
Yeah, it's a complex beast, but that doesn't mean it's bad. Some things just have to be complex. I really cannot imagine someone calling LLVM bad.

>>58154368
>because llvm is written entirely in c++
It doesn't matter what language llvm is written in, it has bindings to many languages, pure C including. That matters is the functionality it provides to compile-writers, and it's enormous.
>llvm sucks
Now that's a strange thing to say about the best compiler infrastructure out there, considering both Google and Apple actively use llvm-based products like clang and swift in the production, and dozens of the new programming languages became possible because of llvm.
>i don't know specifically what compiler go's is based on
It's based on some weird Plan 9 stuff from 80s no one ever used for real.
> 8cc rocks
What do you mean? Does it support hundreds of optimizations, dozens of architectures, OSes and binary formats, modern CPUs and cutting edge stuff like LTO?
>rust is still useless
Can you stop repeating this meme please? It's definitely not useless, considering Mozilla and Dropbox among dozens others use in in production: https://www.rust-lang.org/en-US/friends.html
>[go developers basically reinvented java from the early 90s by combining GC with slightly modified C-like syntax]
Good for them. No, why is it so innovative again?
>[generics] weren't a big issue (they're not) because interfaces work fine unless you're not actually doing anything with your functions.
Do you realize the difference between compile-time monomorphisation with garanteed function inlining and virtual methods? Do you realize the importance of strong static typing for performance and safety? Ignoring generics is like ignoring the last 20 years in the PL development. Then again, I'm not sure the Go authors know about it, they're too busy reinventing the wheel.

>>58155177
>they're too busy reinventing the wheel
I get the feeling Go developers think there are two programming languages in existence: C and Go. If you compare Go to C, you'll see some improvements.
I'm >>58155145 BTW.

>>58155177
>it doesn't matter what language llvm is written in
it very much does when it's written in the language you are trying to replace, and you can't replace it. maybe the irony is lost on you.
>>58155145
notice how you both provided zero reasons for /why/ clang is good, the closest you came was sse which you acknowledge go does fucking have.
also, sse is an x86 (and the like) extension, i don't know of any other architechture that supports it.
and as for performance, you acknowledged that gcc makes faster binaries, and go has a mediocre frontend for it, if you want to completely give up on simplicity and go back to the 80s, which you apparently hate for some reason.
>tons of optimizations
8cc rocks because it's simple and ellegant, it might not have a billion insane optimizations that close performance gaps of nanoseconds, but go performs better than java in almost every benchmark, and a lot of people use java. (note that i am comparing java's _usage_ and not the language itself)
>supporting tons of oses, binary formats, and modern cpus
actually laughed, if you think this is an issue i understand why you think llvm is so good.
>mozilla and dropbox
while i'm very fucking impressed that mozilla is using their own language, how ever much, dropbox is honestly the only other big name company using it, compared to go which is backed by fucking google, one of the biggest tech companies in the entire world.
>go developers reinvented java
i don't know where you got this, my comparison was made of java's success and adoption, nothing to do with the language itself.
if go was a 'reinvented java', i imagine it would at the minimum have some similairity in abstractions.
also, nobody claimed go to be innovative, not everything has to reinvent the wheel to be good.
>guaranteed function inlining
ask me how i know you don't actually write in c++
>inherited methods
something that is a requirement of oop, not an advantage.

-already went over generics and am out of chars.

>>58155853
All Go shills I've talked to are really defensive. It reminds me of the fox and the grape pic.
>optimizations
Clang does wonders optimizing your code. Write a toy program that finds mersenne primes. Now make a debug and a release build. You'll notice that the release build is much faster. That's because of the optimizations. And those are not nanoseconds we're talking about.
>java
You're posting in a C++ and Rust thread. Don't pull the Java card here.
>go is backed by google
How can that be a good thing? What good has it produced?

>>58156151
>clang optimizes
wow i am fucking amazed, you sure got me, it's not like go has fucking optimization.
>write a prime sieve
lmao this has to be a joke
>you're posting in a c++ versus rust thread
while i'm amazed that this is the CURRENT THREAD, as i stated previously, i made a comparison of adoption and somebody implied that i was comparing java and go, which i was not.
>what good has come of a company using and supporting the development of a programming language
honestly, i could explain this, but i never said it, someone else brought up that muh big companies are using rust, and google is bigger. that's all i said.

please read posts before replying to them.

>>58155853
>it's written in the language you are trying to replace, and you can't replace it
I don't get it, Go programmers don't use soft written in C++ like browsers and editors because they try to replace the language it's written in? And what about all that C your OS is written in?
>the closest you came was sse which you acknowledge go does fucking have
Of course it does, SSE came out in the 90s. But does its codegen support AVX, AVX2, AVX512, SENPAI and all the nice stuff before the CPUs even available? Does it support Neon on ARM? And the main question is, does it support cutting-edge stuff like auto-vectorisation? Because clang and every language using llvm surely do - https://godbolt.org/g/lHxE3R .
>8cc rocks because it's simple and ellegant
You know what else is simple and elegant? The original C compiler from the 70s. At some point focus on "simplicity" leads to asceticism and narrow-mindedness what hurts developers, and "elegancy" becomes a buzzword to cover up the inability to innovate.
> it might not have a billion insane optimizations that close performance gaps of nanoseconds
It surely doesn't and it wont, because the authors too narrow-minded and focused on NIH to use the state of the art solution.
> but go performs better than java in almost every benchmark, and a lot of people use java. (note that i am comparing java's _usage_ and not the language itself)
Why would you ever compare a language compiled to native code with java?
> if you think this is an issue i understand why you think llvm is so good
How the support for hardware and software platforms isn't an issue for a compiler backend?
> go which is backed by fucking google, one of the biggest tech companies in the entire world
Yet the same company uses C++ for their HPC serverside, Python for web and ML, Java for their mobile os, and is one of the main contributors to LLVM and clang. And other major companies use other languages, Java, C and C++ being the most popular. What is your point?

>>58156559
you can't replace c, and nobody is claiming to.

'auto vectorization' is best achieved with restricted pointers, which go has.
also, someone else brought up sse, not me.

i'm sorry that you want to reinvent the wheel

if you need speed, you should be writing in c, llvm and c++ will never compete, no matter how much complexity you throw at it.

>why would you compare go and java
i fucking didn't.

support for obscure architechtures is not an issue for a systems language, nor is it an issue for any well-made, simple compiler.

someone brought up _RUST_ being used by big companies, and i made my argument based on that, nothing to do with llvm.
stop moving the goalposts.

>>58148743
Go back shitting in your designated street Abdul.

>>58155853
>my comparison was made of java's success and adoption, nothing to do with the language itself
Your description of the good things Go have applies entirely to Java and the better half of the languages created since 1995. "Simplified C/C++ syntax", "GC", "no pointer arithmetic". I actually don't understand why don't you mention the only really interesting thing Go have, namely goroutines.
>nobody claimed go to be innovative
So what's the point then? Is it just because Google wanted a language of its own, free of Oracle patents?
>ask me how i know you don't actually write in c++
How do you know I don't actually write in C++? Because I actually do it professionally for many years now, and I've spent some time with objdump -d and __attribute__((always_inline)) to understand how inlining works and what impact it has on the performance.
>something that is a requirement of oop, not an advantage.
You do realize what since Go lacks generics every call of interface method is actually a virtual call in OOP term, i.e. uninlinable indirect call via vtable?

>>58148708
C++. Sorry, Rust just isn't production or industry ready yet, and for an "industrial language" that's a big deal. Rust is a fun hobby language though. If it ever builds up critical momentum it might be good, but right now it's dealing with the same chicken-or-the-egg problem that plagues every language that claims to be replacing another, no libraries. No libraries means it doesn't get used, and less users means not enough libraries being written. It's easier to just use C++ and make a few library calls than it is to use Rust and make all those libraries you rely on yourself.

>>58148730
Why would more developers start using it when no developers are using it?

>>58152615
>Did they get rid of the drop bit or whatever they called it?
Drop flags. Yes, they got rid of that.

>>58156665
>'auto vectorization' is best achieved with restricted pointers, which go has.
Auto-vectorization and restricted pointers are orthogonal, see https://godbolt.org/g/lHxE3R again. And you can't achieve auto-vectorization at all if your outdated backend doesn't support it.
>if you need speed, you should be writing in c, llvm and c++ will never compete, no matter how much complexity you throw at it.
I don't get it, how can llvm the backend compete with C the language? In any way, current llvm is on par with current gcc, loosing on some tests, winning in some - http://www.phoronix.com/scan.php?page=article&item=gcc-clang-kblclear&num=1 , and both GCC and LLVM are written in C++.
> i fucking didn't.
You actually did compare go to java to demonstrate how "fast" it is, >>58155853 .
> support for obscure architechtures is not an issue for a systems language, nor is it an issue for any well-made, simple compiler.
What? It's not an issue for a scripting language, it's definitely an issue for a system language. It's not an issue if you use llvm and get it almost for free, it's certainly and issue if you have to reinvent the wheel and implement codegen from scratch for every architecture. Like, how long will it take for go compiler to support WebAssembly? Rust and other llvm languages already do.
>someone brought up _RUST_ being used by big companies, and i made my argument based on that
So how Rust being used by Mozilla, Dropbox and dozens other is different from Go being used by Google, Docker and dozens others?

>>58156726
yes, but you criticised my comparison, not my point.

it's a systems language that is simple and makes multithreading simple, and i agree, the most 'innovative' (whatever that means, most compiler optimizations that make significant differences in performance were described before the 90s, and most modern language features have been done before a hundred times) feature go has is goroutines.

because if you knew anything about c++ you'd know that guaranteed inlining is NOT a feature of any of the things you listed, and regardless, it wasn't relevant of the topic of generics, you just wanted to flaunt oop because somehow generics is related to it in some twisted way.
also, i'm not impressed that you can use objdump, nice try. go back to your blatant oop namedropping.

not all implementations of generics are inline-able, you have to make a choice between compile times and inlines, and in reality any significant functions (ones that can take heavy advantage of inlining) aren't going to easily be made generic, and in go you can optimize things that matter like that. you really wouldn't gain anything major with plain generics like in c++, and, once again, the go developers fucking *plan* to add them, they're just not high on the priority list because they're really only useful for things that either aren't realistic or are solvable with interfaces.

>>58157101
>because if you knew anything about c++ you'd know that guaranteed inlining is NOT a feature of any of the things you listed
Gee, tell me more. Of course it's not guaranteed, this is why you use objdump -d to actually see if the code you care about was inlined and what you can do about it, and "inline" with "__attribute__((always_inline))" usually works.
> and regardless, it wasn't relevant of the topic of generics, you just wanted to flaunt oop because somehow generics is related to it in some twisted way.
This is pretty much relevant to generics. With real parametric polymorphism compiler can monomorphize polymorphic code producing optimized version for each type, including inlining. If you have a generic list in a language with real generics and you call a method on the elements of that list in a loop, there is a significant chance compiler will inline the method, maybe even unroll the loop a little. If you have no generics and use home kind of runtime polymorphism like Go's interfaces, you're stuck with indirect calls to that method via vtable with significant hit to the performance. And it has nothing to do with OOP - neither Rust nor Haskell have OOP yet both benefit from such optimization. At the same time Java generics are really just type erasure, so this kind of optimization isn't possible in Java.
> they're really only useful for things that either aren't realistic or are solvable with interfaces
So why every other compiled language created in the past 10 years has them? How come standard libraries of languages like C++, C#, Java, Scala, Rust, D and Swift use generics everywhere? Do Go's authors know something the rest of the industry doesn't? Or is it just because Go's authors are out of touch and Go's compiler is an obsolete trash?

>>58148730
Now we have one more different, incompatible standard.

>>58148708

C++, the other one is a meme.

>>58148708
Rust, the other one is retarded

File: ogycbfsNUo1uaaoreo1_1280.png (298KB, 1280x427px) Image search: [Google]

298KB, 1280x427px

>>58157813
>>58157899

Neither, both sucks.

The real alternative is D

What's the best place to learn Rust from? I tried their Rust Book twice and it was ok, but everything seemed overly complicated, I feel like I learned how to do specific examples instead of generally learning the language.

You can try https://doc.rust-lang.org/reference.html for a dry but comprehensive reference, or you can take a look on http://rustbyexample.com/, but as you can guess, it's even more about concrete examples.

>>58157934
D is pretty good, avoids a lot of mistakes c++ has,

but because no language can be perfect,
they added a bunch of stupid shit to it.

>>58153606
>tfw browsing msdn while writing win32 code just for the nostalgia

>>58158019
Do not learn Rust. It is dead.

>>58151163
>>58151127
>C++is nothing but bloat use java

You hear it here first

File: lceOAtI_0.jpg (84KB, 600x787px) Image search: [Google]

84KB, 600x787px

>>58148708
This.

>>58148730
Stop writing code that nobody else can read you fucking mong.

>>58158326
>Stop writing code that nobody else can read you fucking mong.
He's not talking about perl.

>>58158346
It might as well be perl, nobody gives a fuck about rust the same way nobody gives a fuck about perl. Use a real programming language.

>>58151935
>what are smart pointers

>>58158360
So innovations are impossible, because there is no reason ever to start using something new, since nobody else uses this new thing, because it's new.

File: 001.jpg (42KB, 562x437px) Image search: [Google]

42KB, 562x437px

>>58158428
>rust
>innovation
More like degeneration.

>>58157934
>The real alternative is D
>JSON library cant make "list": [ [int, string] ]
yeah, no

>>58158360
rust syntax looks about as readable as perl

>>58159591
Perl is literally the easiest language I've ever used. Just because you don't understand it doesn't make it unreadable, look at lisp or assembly without knowing it and you'll think the same thing

File: perl_small.png (76KB, 680x482px) Image search: [Google]

76KB, 680x482px

>>58159658
The easiest one to write maybe, not the easiest one to read.

is it true rust is an sjw language

>>58159764
yes, but if you ignore them, they'll go away, just like every other issue in your life

>>58159764
>>58159772
All of the documentation examples have subtle undercurrents of Marxist propaganda.

>>58148708
What about D?

>>58159819
I know, and that's why if you ever publish your code, you publish it on a website that doesn't pander to degenerates, like gitgud, or host your own.

>>58159829
It has no killer feature like Rust's borrow checker or Go's goroutines, and there isn't any reason to use it rather than C++14 or Java/C#. It has schizophrenic relationship with GC (the language is GC one and can't work without GC yet for some reason standard library is trying to use it as little as possible), and had multiply personal disorders in the past(two incompatible language versions, two incompatible standard libraries). It tried to create a niche somewhere in between C++03 and Java, but failed. Overall it had it chance back in the early 2000s but now it's irrelevant and is dying slowly. The only good thing about it is Andrey, it's really a shame he haven't embraced Rust instead.

C++ is perfectly fine, Rust just caters to babbies who are afraid of doing things with memory.
Even that is suspect because I haven't needed to touch raw pointers for ages; I wrap them up in unique_ptr or shared_ptr as soon as I can.

>>58159920
pls stop, you're gonna make me drop my rust project and port it to c++

>>58158019
second

how do i implement a Hawkes Process in rust

>>58159591
chinese looks just as unreadable until you learn chinese

>>58159871
You don't understand the problem here, anon. Reading any of the documentation exposes you to corruption by actual witches who sacrifice children to Satan for their liberal powers.

>>58160026
This is where your 4chan prowess should kick in, filter out all the shit and only read the actual important stuff.

>>58151890

>1. Header files & long compile times
Modules will be a thing sooner or later. Until then, compile times won't be the worst price to pay.

>2. No reflection for automatic (de) serialisation.
How important is this really?

>3. Absolutely horrible trying to port/build to a different platforms
And how does Rust solve this? It's a systems language just the same, so problems of endianness, alignment, library compatibility with operating systems, etc... are going to be fucked in the same way.

>>58148726
Hi gramps