RIIR

you have no clue, do you?

the community split to 16chan and endchan

Rust is basically just tracing over the work of others and claiming it as your own, I get it

No

they are asking the DEVELOPERS to rewrite it in rust

Rust is a decent language. It's the community that's shit.

Actually its an unfinished language and by definition that makes it "not decent". The community is just a reflection of the rest of it really.

No, because I don't hang around retards in san cucksisco.

>>>/tumblr/ pls

You'd have a point if the langage wasn't getting good, but right now it doesn't surprise me that it's popular.

Ultimately, arguing against popularity is fighting windmills, JS might be shit but having so many users makes the ecosystem worth a damn.

The main takeaway is that the current Rust community is full of SJWs, but that can only be fought by introducing more system programmer brethren to it, not less.

Fuck off faggot.

You're embarrassing yourself.
How new can you be?

No systems programmer is going to use a language that struggles on large codebases.

Well I am and I did not, but I also write a ton of sepples and that has compile times that are a pain due to the lack of modules.
Rust meanwhile has modules but the compiler is young.

Hopefully we'll get better incremental compilation and sepples will get modules in c++2x but dismissing the language on that basis seems a bit ad hoc don't you think?

hacks.mozilla.org/2016/07/shipping-rust-in-firefox/

That's pretty cool.

Can't wait for that O'Reilly book to be finished though, I want to have a good resource for advanced concepts. And the Rust Book is a bit too succinct to my taste.

I think it's perfectly fair to dismiss a language that does not currently work for the task. There are a lot of languages and technologies like that, and the promise of eventually being usable is almost never kept.

See, but though compile speed is important, we're at a point where I don't hold it anymore as something disqualifying to fitness for purpose.

rustc is definitely in a usable state right now, even for big projects and I'm afraid you're mischaracterising the compiler as slower than it is because you haven't tried the latest versions which brought huge improvements in that field.

Then again, it's a bit subjective what is and isn't in the realm of the usable, so depending on the use case, you might still want to go with good old C.

Ultimately, I care more about runtime performance and safety in my use cases.

This is the difference between SJWs and real programmers, you see.

A programmer rewrites code to make it better for everyone. He does not give a fuck about your politics, he makes his own path.

A SJW screams like a little bitch and tries to rewrite the English language by hijacking the definitions of words. They want to control the language you think in, how you think. A SJW does not write code.

Guess which one the OP is.

Well then you're wrong.
Go time a build of a servo with the latest and greatest and a recompile (as if doing development) and get back to us. And keep in mind that it's a tiny codebase by systems standards.

Obviously, not newer than you, cuck.

You sure showed him, user.

i see no reason to use rust, c++11 and 17 already offer basically everything you can hope for from rust.

biggest reason touted to use rust is "muh memory safety" but you already essentially have non-stop-the-world garbage collection in c++ if you use smart pointers at all.

compile times aren't hugely important to me. we're likely to see improvements in the future and compile time is critical for you then maybe you should learn how to write better code and better tests and adopt a more modular approach to programming and learn how to use available build tools.

my biggest complaint in c++ is shitty compiler messages in generic programming which stroustrup suggests should be solved in coming revisions.

rust is literally dead on arrival tbqh.

You misunderstand what memory safety means. And C++ does not "essentially" have it. It does not have it at all.
Naive and confident are a bad mix.

m8 i think rust fangays are insufferable but there's no way you can win this argument.

m80s if you can't into smart pointers i don't know what to tell you. probably 90%+ of problems using pointers come from mismanaging resources, not truly understanding when some resource is reclaimed, and simply forgetting to fucking delete.

i didn't say that it does, i'm saying that making effective use of smart pointers provides a weak form of garbage collection to eliminate entire class of errors that's always the most hyped reason to pick up rust.

Again, you have no fucking clue what "memory safety" means.
Smart pointers are nothing like garbage collection.
I am sad now that people like you exist.

clearly you don't code often because you either don't understand smart pointers or you don't understand how garbage collection works under the hood or both.

at this point you're just talking out your ass about something you don't understand. you don't need to argue just for the sake of trying to win an argument. socjus plus "intellectual artillery" types always out to win arguments are the reason people hate rust-fags.

you can have last word though if you want it buddy, i have things to do today.

read about smart pointers.
read about garbage collection.

use smart pointers in c++ it gives you a weak form of garbage collection and will reduce errors in your code in the long run. if you can't into that you have no business talking about c++ versus rust and no business being on Holla Forums

you should be coding right now and so should i

have a nice day faggot

You have no idea what you are talking about when it comes to memory safety, and now you've shifted the goalpost.

I've written more C++ than you will in your lifetime. And are you really trying to say I don't know how garbage collection works under the hood because I didn't agree that a smart pointer works like garbage collection under the hood? Because if so that's just breathtakingly stupid.
I'm not arguing for rust you retard, you can't even understand the conversation let alone the technology. Get checked.

I think I finally understand the appeal of this language. It's simple; if you're a big company writing software in a powerful, mature and flexible language like C++, you need to hire smart and disciplined programmers. On the other hand, if you use a rigid, nagging and hand-holding language such as Rust, you can instead afford to hire a bunch of cheap Pajeets and dumb SJW hipsters and still get programs that don't leak memory and whatnot!
Simply genius. Mozilla, you are my greatest ally!

The appeal is that humans are humans and violations of memory safety have been the largest class of vulnerabilities in everybody's infrastructure.
Being smart and disciplined doesn't mean you're immune from violations of memory safety.

To learn why C++ programmers were hoping rust wouldn't be shit, try writing a non-trivial website in C++ and then advertise you did this to a forum full of programmers and use a stop-watch to time how long before your site becomes unusable because someone found a crash bug and 1 request per second it all it takes to keep you offline. Bonus points if you're hacked or all the data gets corrupted, too (use sqlite for maximum comedy since it mmaps the database).

What kills me, from several attempts at using it in beta up until the present, is cargo.
No, I don't want another fucking build system just because running `./configure && make && make install` gets your panties wadded up into the world's densest knot.
No, I don't want to download the same fucking library every time I want to use it in a project.
No, I do not want to download the same library over and over and over for each individual project.
Every other language has this figured out. Python has it figured out. C/C++ has had it figured out since UNIX immemorial. Even fucking Lisp has it figured out. I don't want to download the same lib more than once. You are not special just because you're an epic hipster meme language.
No, I don't want to use [my favorite flavor-of-the-month meme markup language] to configure every single one of my projects, including and especially hello world.

Rust is a little hard to read for me, but there are definitely worse languages out there. It's real problem right now is a lack of a Sepples FFI, which precludes it from using well-memed libraries like qt, but it's not the worst language in the world. If I could just use rustc with standard run-of-the-mill makefiles, I would consider using it. I don't even need any of the other very valid excuses to stay the fuck away from it, though, cargo is all the excuse to keep my distance that I need.

I can't find the source, but somewhere in the official docs, it was mentioned that cargo was made by ruby or javascript converts. Shocking.

u w0t m90

It is, by a sensible, but old-fashioned definition of high-level language.

Both Rust and Go are heavily infested with webdev-tier ideas. Like making the default, easiest way to deal with dependencies be to automatically grab the master branch of some remote repository with code the developer probably never saw or could be a different branch with the same tag served to a specific victim. Node started this security nightmare but I never thought it'd make it out of the javascript world.

Ah yes, the better solution is tarballs.

Dependencies from a distro are cryptographically signed, and larger projects sign their tarballs, too. Git securely hashes so it should be just as good... buuuuut hashes are scary so theae projects are set up to use tags instead, nullifying all security. Who knows what will end up in builds of these programs, or running on developer machines.

There's no way you're going to be able to rely on your distro for all build dependencies. Some of them, yes, but to say that "obviously they just need to rely on other package managers and their build systems lol for obscure projects relating to an unfinished programming language" you clearly show that you don't know what the fuck you are talking about.
As for security of git tags, a tag is just a pointer to a commit in that tree that already exists. It's up to developers to secure their git tags, they can sign tags if they wish, and you could then verify them. In practice, being another commit, there's really no issue if you don't see a problem with not signing every single commit in the first place.
I doubt you are the type of person to do so, so maybe you should stop calling the kettle black.

Just because it's pulled from a git repo pointing to a build of God-knows-what doesn't mean that I need to pull it for each and every individual project. It can live in a common directory designated to house libraries and shit for that language, just like every other sensible language has a common directory designated to house libraries and shit for that language.
But nah, fuck that, I need to grab shit each and every time I want it. I mean, what if I wanted a new or different version of shitlib for that project. It's not like I could grab the files and stick them in/compile them to another directory and point the linker there or something. That'd be ridiculous.

You're going to love the real world where you're often forced to for support and security reasons. Ever try development on RHEL? (b-but you don't know what you're talking about, please say it isn't so! pls no RHEL!)
But snark aside, when getting dependencies yourself, the onus has been on you to verify your sources. If you haven't been it just means you personally are a shitter and does not affect me unless you're the loser responsible for builds. But these tools take over that role yet don't care much about verification and are often hard to stop in the middle to let you verify them by hand (nodejs is especially bad about this). I doubt anyone does it. It's 1995 all over again and it's just a matter of time before another tcp-wrappers scandal.
You're adorable, but kill yourself.
So if you tell git to retrieve "v1.0.0" from a remote repository, possibly not over https, possibly on a mirror, etc. and someone creates a v1.0.0 tag that points to evil, does git notice? Was it the developer's fault even though their tag was properly signed? Or was it the fault of a shitty build system that encourages tags instead of hashes?

Aw yeah, mockbuild is really secure. It definitely tells you where shit came from xdd. Relying on upstream for security is a middle manager's solution, not a real solution.
That's just plain wrong:
github.com/rust-lang/crates.io/issues/75
Tell me more about how an alpha for a package management system for an unfinished programming language is not exactly up to everyone's standard, autist.
"I'm not going to verify that my dependencies file is sane and am going to run it anyways lol!"
I don't even use rust but it took me three seconds to find "rev" and it looks like the cargo guide, or whatever that shit generates, does commits by default.

So you're basically arguing about nothing.

i.e. doc.crates.io/guide.html

ok

If you agree that it sucks, could you be less obviously triggered when someone says it sucks?

There's another prong on that attack though. Even after the language and its package management system improves, it's still +1 package management systems in the world. I hate administering this shit.

1. Customer wants WordButt with Butt-SEO

2. Customer asks me to set up a CentOS server with Butt-Lang, which WordButt is written in

3. I don't want to spend an entire day figuring out how all of these NIH layers and dimensions of butts intersect with each other

4. I eventually find ButtBrew, a Butt-Lang version manager, and use it to install Butt-Lang and WordButt

5. I do this as a normal user because ButtBrew devs have never heard of "multi-user operating systems". If you install it as root, it gets the permissions wrong.

6. Next week the customer wants a system install of WordButt

You'll find it's rarely used as they made it easier to do things insecurely by leaving it off. Like I said, it encourages tags over hashes. It shouldn't have supported tags at all. Go ahead though, try to defend it supporting tags.

how about you fuckos try researching next time before launching into your rant
is where you can find the sources for dependencies, shared across all (locally) built cargo projects. also, what is DLL hell for 500, alex

and if you insist, you can use makefiles with rust. just call `rustc`. and no, i do not want to go back to ./configure && make. for the vast majority of projects that setup is both overly tedious/error prone

a tag is just a particular way to point to a commit hash, dumbfuck. it can be signed, just like anything else.
at this point it's clear you know nothing about git or rust, just shitposting

Is this really that hard for you to understand? If the only thing you've told your build system is that you want to check out "faggots" at some location, how does it know how to tell that one signed faggots tag was the one you wanted and not some other signed faggots tag by someone else? It's like using SSL/TLS without certificate validation, it's entirely useless security. You are clearly mentally defective and I sincerely hope you are never allowed to work on anything important.

"how do u kno u checked out the right linux kernel xddd? they might mitm kernel.org u never know xdd"
you know that most package maintainers rely on tarballs generated by github and gpg sign that, right? there's no real "verification" by your definition that what you're getting is really upstream.
again, crates will solve this, much like pypi solves this for python, in addition to being resistant to break just like pypi thanks to PEP480 or whatever, but using TUF.
github.com/rust-lang/crates.io/issues/75

I don't even use rust, and yet you keep strawmanning when you're getting fucking told itt. it's pretty hilarious to see how angry you faggots get when called out for being incompetent.

The reason why we started tarball signing was because of a hacked ftp server serving a trojaned tcp-wrappers. The idea was that it's stupid to trust several third parties when you don't have to. This idea was picked up by package managers and we've been a lot safer ever since.
Here we are today though with a new generation of programmers in a situation where you don't need to trust several third parties (if using the revision hash) but you're angrily insisting we trust a web host, OpenSSL, every certificate registrar, and then we still need the hash anyway to prevent the author changing the tag in the future due to mistake, malice (see: nodejs), or hack.
So why the fuck support tags at all? They're no better than a comment at best when they're ignored due to the presence of a revision hash and at worst when they're trusted they're not trustworthy. They're an anti-feature.
Anyway, I doubt you'll ever underatand but maybe this post will help someone else.

I sense that you're an autist who rails against systemd, so I'll answer it thusly:
Why not support tags? It's all about choice?
See, tags are the OpenRC of revision information.
If you don't like it, you are a SJW.

Seriously though, you're sperging out over nothing right now. You've been corrected several times now, and you're still pompous as fuck. You were wrong about not being able to use makefiles. You were wrong about only supporting git tags, and you certainly moved the goalpost about that, and moved it to "encourage" which the intro docs certainly does not encourage.

I doubt you'll ever stop railing against percieved meme languages and make shit up about them, but maybe this post will help someone else understand your autism.

saying that language is good because it has garbage collector is like saying your bicycle is awesome because you can attach training wheels

The only places in which the official documentation mentions any registry, it seems to imply that it's more a manifest and less a dependency source. Unless you're seeing something I'm not, in which case, please, share with the class.
doc.crates.io/config.html
doc.crates.io/guide.html
Looks like it's more ports tree than /usr/include.

Last I checked, cargo handled dependencies by having everything in the project folder and resolving shit at compile time. So unless something drastically changed, you can, but that would defeat the purpose. Cargo is a tightly-knit clusterfuck for a reason, I just hate the reason.

world's densest knot
Yeah, you're right, we should have another fucking build system on top of the unknown many we already have. Because nothing strikes the fancy of your potential users quite like having to install a bunch of bullshit just to build your software just because autotools touched your no-no spot and hurt your feelings.
And if I were a betting man, I'd wager that you'd even try to justify having to install Code::Blocks just to compile software, because Code::Blocks is a huge piece of shit which takes the prerogative of also being a build system that forces you to use it to build software made in it because the developers of Code::Blocks and any users dumb enough to use it that way decided that cmake being a lovecraftian horror wasn't enough pain and suffering, and that we needed another opium-fueled shitshow lopped on top of it. And that you'd justify all of this with a straight face just to avoid using autotools.

if you're going to use make either ditch cargo all together and control the whole process via make or delegate part of the make commands to `cargo build` and soforth.

we do, and we will. build systems suck. the less time i spend configuring how to build my code is more time writing the actual code. until we get build systems right (and we never will), expect new ones to come out and expect some of them to catch on. cargo has streamlined the build/testing/benchmarking process to such a degree i hate the thought of returning to even CMake land, much less makefiles land. pain is not cargo. pain is your unconquerable yearning for "the good ole days"

Autotools has tons of problems, m8. One being that's it's sometimes slower than the actual compilation (us Gentooans can tell). The other is that's it's horrible to read.

Saying that manual garbage collection is good is like saying your dog is awesome because you have to pick up its shit

I'm gonna require sauce on that chinese cartoon

It's manual memory management, Pajeet. "Garbage collection" is an entirely different concept that involves not releasing individual objects at all. It's why you can't do RAII in Java.

That'd be libtool (it can easily take 80% of the compile time), and there's a shim version for when building on simple systems to avoid that but it's a hack. It'd be nice if someone reworked libtool but instead we get a million horrible build systems that fail to fully replace autotools.

I believe you. But you have to understand, given the choice between a build system with problems that everyone already has, and meme-of-the-week build system with problems that everyone would have to procure first, I'd prefer everyone stick with the former rather than the latter. Much to my ire, that xkcd comic is as applicable as ever. As a gentoo user, I'm sure you sympathize when I say that the more shitty new build systems that are introduced, and the more "that one program I use" that inevitably pick them up, forcing you to get and use them, the worse off we all are.
Read also

It is, m8. Just because you're spoiled by python and other bullshit, doesn't mean that C isn't a high-level language.

That's Space Dandy, m8.

Sure, but it's still gotta go. I think cmake is the currently less worst contender; still has problems, though.

I'm a street shitter, so this topic is way over my head, but why do we even need anything beyond make? I get resolving dependencies of source files on header files, that's shit, but it can be solved by both gcc and clang.

As for configuration (./configure), wouldn't it be enough to pass definitions to the preprocessor? I.e. if you want to set the directory for settings files instead of of having autotools poke around the user's system, have a #define instead that's set to some dumb default, like the current working directory. Then when building pass your directory to the compiler as a definition instead using the -D flag.

This way you can produce an isolated build for testing that only uses its working directory, or your can produce a production-ready build that will work properly on the end user's system. Package maintainers can set their package managers to automatically supply the appropriate definitions to the compiler. Different package managers will use different settings, so you can't rely on an external tool to probe the environment accurately.

As for make install, that one would be handled by the package manager as well. Again, different package managers want to put files in different places, so let the package manager make the decision.

Of course this requires that the developer of the program maintains a well-documented interface of preprocessor symbols for the user. Again, I haven't worked on a 1 million SLOC sized project, so maybe there is something I'm missing here. Please educate me.

It doesn't have to go, just rewrite libtool. I don't want to use your shitty build systems that make cross compiles a nightmare, can't easily work with mixed language builds, and require special attention to work in a full system build.

Build a Hello World _library_ in C that works between Windows (32/64), Linux, Mac, and Android, cross-compiles between any combination of them with no special effort required by the user, uses the proper naming and install paths per platform, leaves information as to how to link with the library, handles skipping certain tests on cross builds, and packages itself. And I'm being kind here and not adding the requirement of detecting a platform dependency.
At the end of that journey you'll understand why we have autotools and why greybeard-tier programmers get pissed off when faggots use horrible build systems that don't handle some combination of the above because they were scared by the complexity of autotools or set off to "fix" a problem before understanding what the problem was.

I remember once trying to install a newer version of Krita than what was provided in some distribution I was using, and doing so required installing a bunch of bullshit. Part of this bullshit that I remember distinctly was KDE-specific cmake components. Krita would not compile unless you had a bunch of fucking depends, not for the program itself to run, but for the fucking build system to compile it in the first place.
Oh, and let's not forget, compiling C with cmake has a prerequisite of having Sepples shit first, because cmake. And compiling anything requires having a certain directory structure, usually placing the ownness on the person compiling software to create directories that cmake has to have existing in order to function, because cmake.
Fuck that shit, cmake can blow me. I'll take autotools and eat shit with a smile on my face any day of the week over trying to wrestle cmake into functioning for once in its life.

confcache doesn't go anywhere near libtool though.

I've not tried it, but dolt and newer libtool replacements work well. I've not tried jlibtool yet.

My point being autotools is so slow on its own that someone went out of their way to write a whole cache system to circumvents it.

My point is you could fix the performance rather than shitting out an entirely new build system that fails to cover the same problem space as autotools thus creating yet-another-shit-build-system that does not.obsolete autotools.
The issue here is that the caliber of programmer that used to work on autotools no longer exists as they're old and retired and today's programmers are retarded. So telling them to improve autotools is like asking a car mechanic to work on a space ship. It's an impenetrable problem for them so they try to make something new and surprise surprise it's shit compared to the greybeard project because they didn't even understand the problems autotools was solving before setting out to replace it.

I'd love to, unfortunately I'm no demigod.

>>>/g/
sage for gay and embarrasing thread

Saying sage for gay and embarrasing thread when it actually has some good tech discussion is like actually being a faggot from halfchan that would rather talk about chinkpads and systemdicks.

why not tell the dog to go shit in the designated shitting street instead

lol that page reads like it's one of those ponzi get-rich-quick-type scheme website

Except that's retarded.

Underage pls

Saged, reported, hidden, called the cops, initiated tactical nuclear strike.

But seriously now, your bait is shit.

Rust becomes like JS and PHP, it is a retard magnet we need so real programming language advances can happen elsewhere.
It is not like an army of shit programmers will manage anything significant to general computing, so I wouldn't worry.

Yeah, I am sure retards will love manual memory collection, immutable values and a myriad of compiler checks to make sure you are far from fucking the program's shit up. Just like my JavaScript!

Jesus fuck, have you ever programmed anything that's not a Hello World?

...

Rust is a joke, why even discuss it? The language is so retarded it can't even deal with internationalization because some moron thought it would be a good idea to COMPILE format strings. So for languages where you need to re-arrange the order of variable replacements or request a different numeric formatting at run time you're screwed. How anyone in 2 CYE could make such boneheaded design decisions is beyond me, especially the multikultis at mozilla, and rust is full of similar bad ideas. The standard lib will need scrapped and redesigned just like cargo. I doubt anything will be salvageable.

It's not bait. You're clinically retarded if you think a programming language has anything to do with "social justice.". Like how can you even justify that retarded mental leap? Computer instructions -> faggot pride

Just fuck off before anyone else catches your case of stupid

So you agree with that the OP is all shit and no substance. Code talks, Holla Forums walks.

OK...
#include int hw_print_hello_world(FILE *restrict out) { if (!out) { return -1; } return fprintf(out, "Hello world.\n");}

It uses the standard library, the person who set up the environment is responsible for providing it.

Just type make

Responsibility of the package manager

Write a manpage

Responsibility of the package manager

But I see where you are coming from. Compiling the source file into an object file is one thing, that's universal. But making a library out of it is different, on the Unices it's one with ar, but on Windows it might be something different. Writing a manpage for Unix might be useless on Windows. But how does autotools manage all that mess? Does it mean someone has to go in an explicitly support the fickle details of every OS? That sounds like hell.

Dodging the hard parts were not why I told you to attempt this. There are pretty dramatic differences and limitations on libraries between the two that require different compile/link options, tools, and code changes. Those are what build systems like autotools are designed to help with. Do you even know how a .lib works in the Microsoft world and how to generate one? If you're making a makefile by hand to do these things, you're gonna have to learn. And this is why we use autotools.
Back to webdev, son.

Man, I agree with you, your reading comprehension is quite lackluster.

Sure. Emscripten is the future of cross-platform C after all.

I use autotools to detect a working emscripten.
Also it isn't the future, it's a transition tech to leverage the install base of browsers. Normalfags don't use the mobile web due to battery drain.

California must be destroyed.

excellent blog post

The San Andreas will do that eventually.

I don't know a lot about Rust, but the community alone makes me avoid it like the plague. These people didn't just slap a CoC on the software to shut up the SJWs, they have an entire team devoted to detriggering. I don't want the quality of the ONLY compiler for the language I use to depend on such people.

Thing is, Rust is a pretty decent language and by ignoring it you're basically letting the community stay like that.

It's much more sensible to write a ton of triggering projects in rust and watch the retards complain, because after all, what can they do to stop you from compiling your shit?

Hell it's way more lulzy at least.

Didn't one of the main Rust developers get tired of the direction the project was going and started writing his own Rust standard lib for Linux not based in libc? How did that go?

There was some free (but very active) contributer being pissed by Mozilla tight grip on the language.

The alternative stdlib you're talking about is github.com/lrs-lang/lib github.com/lrs-lang/lib/pull/33 (lel), not sure if thats the same guy.

Yeah that's the guy. And he's removing gendered pronouns? No use to me then.

Hey, that's mahkoh, he's a ruskie that used to work on rstox.

I wondered what he was up to these days.

The following is a random keyword the nsa monitors via pastebin.com/raw/UWffBQbn: m118

Thing is, that isn't true. See

That's a retard who doesn't know what he's talking about.
Internationalization isn't even in the stdlib, localization was removed from the macro equivalent of printf.
Relevant external libraries are in the process of being written, though.
The reason no one replied to the fucking retard is that it's best not to feed retarded sacks of shit who don't know what they're talking about.

Calling him a retard doesn't actually address his criticisms.

The claims are wrong because neither internationalization nor localization is in the stdlib, it wasn't a goal for 1.0 and it hasn't been a big thing that many have focused on.
The harping on format strings being compiled, when localization in the format! macro was removed, isn't the only way to solve the problem.

my.mixtape.moe/oroysb.webm
TL; DW: Javascript monopoly is inescapable, Angular is incurable, and SJWlang is the tumor that is agressively trying to replace C/C++ in the same way as Javascript.

Nice video, but the idea that Rust is trying seriously for popularity , how does that make sense with CoC(k)s and commie philosophers in documentation and such? Most languages I don't use because I prefer other tools. Rust I don't use because fuck their community. And all this guy sees is that it's nice?

Holla Forums rewrite in Rust when?

notes.willcrichton.net/rust-the-new-llvm/

I doubt it

That much was evident. I doubt you can even code.

You mean like this?
internals.rust-lang.org/t/diversity-on-the-governance-teams/2048

It's just basic moz dickery, not using good tools because the makers have some retarded politics that don't affect you directly is stupid. I'd rather still use Rust and tell them to go WONTFIX themselves when they ask for CoCs and quotas on my projects.

Ultimately good tech is what matters, the rest is just noise and wankery to employ people with useless "skills".

...

Call me when C++ finally has modules.

It's funny that the anti-Rust's shills main argument is slow compile times on large projects when its main competitor (C++) is even worst.

At least C++ has separate compilation. Rust is at what version now? And this feature is nowhere in sight.

youre retarded. i compile often because it takes long. while it compiles i can look at cat images on the internet and when the boss is asking why im not working i can tell him "its compiling"

you mean namespaces?

Maybe he meat this:
youtube.com/watch?v=4Xo9iH5VLQ0

You blind or something?

Did you even pay attention to c++17?