Rust vs C

Rust vs C which is better why?

C
it's more portable, faster, has a better ecosystem and isn't governed by the non-programmers web hipsters at mozilla. A language that treats every programmer with kid gloves has no future.

There is no reason to use rust, prove me wrong.

Rust as a language is not as minimal as C. It does support a good deal of functional programming though. And I like the idea of not having to manage memory without the cost of GC.

I'd use Rust over C++ any day.

>He cut it off this Sunday

Rust

>not having to manage memory without the cost of GC.
You still have to manage memory user,

it's just that its ownership system will yell at you if don't.
It also makes other memory management schemes harder to implement, in C/C++ you can create all kinds of custom allocators for your own needs.

Simple RAII and "smart" pointers is good enough for me. That and good tools like Valgrind.

The only advantage Rust brings is pain free code sharing thanks to cargo.

Is better to be dead than being a code engineer.

Rusts first mistake for immutable by default.
It's second mistake was the borrow checker.

Everything else is perfect and I wish C++ had them as good as Rust.
I'll stick to C++17 due to the above 2 problems though.

C.
Rust is for sissies.

Lisp

C, because I'm a straight, white, male and Rust maintainers apparently hate me for that.

>valgrind

So you'd rather dynamically check for errors than statically? Also there's a high chance that you might still miss corner cases.

Immutable by default is better. Less mutable variables means lesser likelihood of errors.

Borrow check guarantees memory safety.

>cargo
>pain free
cargo is as bad as npm, you cannot debate reality.

immutability leads to excessive needless memory copying which is a waste of cpu cycles.
>missing corner cases
i mean sure you could miss corner cases if you are a shit programmer, the language cannot fix that problem. that is rust's fatal mistake, they think they can fix shit code by making their language restrictive to the point where it's nearly unusable for all possible use cases.

Javascript + Electron
/thread

Thing is, while cargo and npm are bad as package managers, their user interface is the best you can hope for as a dev.

Rust and C.

Rust is more of a competitor to something like C++. As C++, Rust gives you a lot of abstractions to help you design applications.

C is basically a thin layer over assembly code.

> their user interface is the best you can hope for as a dev
Thankfully most programmers would disagree as they have a higher standard than you.

Name a better language specific package manager except Hackage.

Spotted the Github intern.

Package managers are an anti pattern, if they worked we wouldn't be re-inventing them constantly.
vendoring > package management

True. Having to hunt down c libraries for hours to compile is SO MUCH BETTER.

see and realize that you are part of the peanut gallery.

C because I am too lazy to learn rust and enjoy writing exploitable code anyway

t. rusttodler

no, I meant it

No. Compilers can and do optimize most of the copying you talk about regarding to immutability. Rust's maps/folds while they look like they'd be copying shit around they compile to optimized as fuck loops or unrolled loops.

>>missing corner cases
>i mean sure you could miss corner cases if you are a shit programmer, the language cannot fix that problem. that is rust's fatal mistake, they think they can fix shit code by making their language restrictive to the point where it's nearly unusable for all possible use cases.

The language CAN fix the problems you catch with valgrind. Also missing those corner cases would mean you're a shit tester not a shit programmer. Leaving things that can be caught statically to be caught dynamically for tests is a waste of your precious time.

>So you'd rather dynamically check for errors than statically? Also there's a high chance that you might still miss corner cases.
Yes I would. because ownership works like literal ASS.

Enjoy your false feeling of security.

Please explain to me why vendoring is superior. If you cant I'll just assume you're talking shit.

why the fuck do people on here care so much about the pollicital beliefs of the developers of OS software.The same with firefox
Its not like there getting money from you

redpill me on the rust code of conduct
does it require you to hate / discriminate against white people?

For the same reason I wouldn't take software from a mentally ill bum. Their views just show that they lack the mindset for writing decent software, therein I don't trust them with my computer.

Rust is for Russian
C is for cunts

It's called tit for tat. The Rust community hates me? Fine. I'll hate them back.

>C
>it's more portable
myth
C's weak typing makes it easy to program to bare metal which is why its still the go-to embedded and systems language, but nothing about C is inherently easier to make compilers for platforms

>faster
myth
its harder to optimize C than it is higher abstracted languages, the reason the LLVM compiler is so efficient is that it uses VM technology

>has a better ecosystem
ha what a joke
C libraries are a complete minefield, anyone who trusts any C library is someone who has never programmed in C professionally

>tfw the maintainer of one of the libs i use is a retarded antifa
>tfw i don't give a flying fuck because he accepts my patches and fixes issues in a timely manner
People who try to inject politics and drama into software engineering are the fucking worst, it's because of these assholes that we can't just discuss the merits of shit like systemd without legions of retards trying to convince everyone of shit they don't have a clue about.

Who are you quoting?

C is for Chileans kek

fucking die with your shit threads, rust will always be a sjw meme

>rust will always be a sjw meme
UUUU

+pattern matching
+map, fold, zip, take etc in the std lib
+llvm backend, performance is tightly comparable to C++, imagine a languagage almost as fast as C and not the piece of shit called C++
+Modules
+automated dependency management with a package manager
+tons of higher order functions
- No hkt ootb, not unlike c
-TCO not guaranteed, not unlike c
-Steep learning curve unlike c

I dont have any use for C since I only do desktop applications. I am used to functional programming. So Rust is the fastest and most suitable choice for me.

Cniles can keep writing header files

>I only do desktop applications
CLI applications I suppose.

What made you think so?

>Steep learning curve unlike c
Only if you don't care about writing code that actually works.
People who think C is easy to learn are the idiots Linus is talking about in his C++ rants.

C was my first language, I learned it at the age of 16

>C is hard
kek you will never make it, brainlet

You guys probably don't *know* C. You probably don't even know the specifics of array decay or half of the common undefined behaviours.

You only think you do because you can write stuff that kinda works in it.

Go write something useful in kernel land that doesn't crash and then tell me what you thought you knew.

>Go write something useful in kernel land
I don't contribute to Linux, NT, Darwin, Free/Open/Net/Dragonfly or any BSDs. As I said before, I don't write kernels. Do you?

>Rust vs C which is better why?

Depends, if you are making a library where performance/size is paramount and want it to easily integrate with any other language out there, C is still the lingua franca.

If you want to have close to the speed of C, but with language enforced safety at the cost of a substantial cognitive burden when developing, and a syntax that looks like the developers thought 'hey, people think C++ looks really ugly, let's make something that looks much worse!', then Rust is your choice.

Rust has better operator precedence for bit twiddling. Its operator precedence is
as :
* / %
+ -
>
&
^
|
== != < > =
&&
||
.. ...

Well, it's fast in a sense that it has nice LLVM backend. It's not inherently faster than C.

I'm writing a driver right now actually.

If you were only talking about userland C I agree with your assessment. However I'm pretty sure my job is also in Rust's target demographic.

In Sup Forums, we are all aspiring kernel writers user

C in userland don't generally make sense. Why not take the advantage of the state of the art PLT and set the trend of automated(!) memory management without GC?

Surely it's better than C#. And I think Rust to be the future replacement of C++. This is because although C++ is a mature language it has many flaws in design.

That's the implementation. Rust has the potential to be faster than C as a language because the compiler has more information to optimize.

It probably won't be for quite a while though.

And I believe Rust already has multiple OSes (kernels) written in it. That's not going to be a valid argument in "Sup Forums", judging by the fact that most of the Sup Forums users are school kids.

It actually does have a better type system.

Yeah I know, I've sent PRs to Redox and their shit is pretty interesting.
It's still a toy in terms of what actually counts sadly.

I wish Sup Forums wasn't the kiddie pool it is now, but be the change you want to see in the world right?

Redox has a few nice ideas going for it. As far as I know the guy responsible for kernel also works at system76.

Thing is, HURD has gained a lot of negative mindset on Microkernels. I wonder why they haven't finished it yet. But the Redox kernel is pretty impressive.

Bet then again, I don't do kernels.

>But the Redox kernel is pretty impressive.

In what aspect ? It's slow as fuck, and it will remain slow as fuck due to their micro kernel implementation.

I can agree that it's impressive that they've gotten so far in a relatively short period of time, but unless you are willing to sacrifice 20% of your machines performance compared to monolithic kernel operating systems, then it's of no use.

>Micro kernels are slow
That's not a Rust problem is it?

Microkernels aren't inherently slower than monolithic ones in any significant manner.
We ain't in the 80s anymore.

Yeah pointer aliasing is a real bitch and Rust certainly gets around that.

> nothing about C is inherently easier to make compilers for platforms
It's smaller. I suppose you haven't even attempted to write a compiler.

>>faster
>myth
Absolutely false. It's easier to optimize low-level languages. That's why all compiler vendors like RISC architectures.

>> has a better ecosystem
> ha what a joke
Everything is written in C. Rust was written in C. All scripting languages are written in C. All libraries are written in C, all other languages just provide wrappers to C libs. You are a joke.

>Rust was written in C.

>The level of ignorance

Have you notices "was" there? The first compiler had to be written in a language different from Rust. I can't even imagine how stupid you have to be to not understand it. This is the same way C was written in PDP-11 asm first

Fucking skids think they know something

>The first compiler had to be written in a language different from Rust.
It was OCaml. Maybe do some research before turning your brain off and shitposting like a 14 year old as you are

Whatever. Rust doesn't fit UNIX philosophy in any way. It tries to do two jobs when it should be doing one.

If you want make your code bullet-proof just use Isabelle/Coq.

This is an interesting question. Fundamentally I think not even Unix tools are Unix. For example Unix cat, wc, head, tail etc do not adhere to the Unix philosophy. Why is that?

with vendoring your dependencies never break because of other people.
with vendoring you ensure that you will always have the source code with the right version
with vendoring you bypass vendor/platform specific packaging bullshit
os x application bundles and linux appimage are the only ones that got it right because they vendor everything, everyone else failed on an incredible level.

That's why I'm currently learning the ELF format. I will write at least 10 UNIX utilities in hexadecimal for x64. I will make them less than 500 bytes. cat will only read from stdin and write to stdout, NOTHING else. You will be able to concatenate using the >> operator, which I've recently learned about. After those 10 or more utilities written in basically raw machine code I will be ready to take on a compiler, which will be a shell script managing many programs, like preprocessor, tokenizer, parser, parser-optimizer, intermediate-representation, intermediate-repr optimizer and finally object code generator, which I will then use with the linker I will have by then.

I will post GitHub repo this month, we will make Linux UNIXy again.

I dream that one day we will make an uncompressed functional repo of 2MB or something like that.

C is not hard, the "hard part" in C only comes when you want to support every system imaginable in which the problem is memorizing every target's constraints and quarks.

Not him but package management allows you to share common packages and thus leads to more minimal system. Also it unifies installed packages and thus you can have your whole system updated all at once, right?

I will also drop X11 in favor of Wayland. I hope it will be ready by then.

Coreutils aren't the only non unix things user, although it's a fun beginner level project where you can learn stuff

minimalism is an archlinux/suckless tier meme by turboautists for turboautists.

Because they have to force their political beliefs and associated insanity onto everything they touch

They're more cancerous than the fucking GPL

No actually. Vendoring leads to slow systems as well.

spoken just like a mactoddler

GPL has its uses

>Microkernels aren't inherently slower than monolithic ones in any significant manner. We ain't in the 80s anymore.

Please inform me of what magic has occured which makes the micro kernel design less costsome ?

Have context switching costs disappeared ? NO

Have message passing costs disappeared ? NO

Have syncronization costs between kernelservers, serversservers disappeared ? NO

Micro kernels are inherently slower because they can NEVER be as fast as a monolithic kernel where everything resides in the same address space, which means that when the kernel needs to get or pass info to any of it's subsystems, it can do so with NO overhead penalty.

The biggest advocate of micro kernels have been working on his Minix project for over 30 years and it's at version 3.0 and it's still insanely slow, and as such not used for anything outside of academia, this despite him having recieved over $3 million in grants to make it commercially viable.

There is no magic, micro kernels will never be near as fast as monolithic.

Windows, Linux, Apple (Mach in OSX is NOT a micro kernel), BSD's, they all use monolithic kernels.

Yup, I'm a total beginner and I this will make a good starting project to make me a better programmer.

>unsubstantiated bullshit
please do continue
i hate os x with a fucking nuclear passion but they did a lot of stuff right.

>minimalism is an gentoo/suckless tier meme by turboautists for turboautists.

FTFY

Suckless is not meant to be taken seriously, it's sarcasm. And Arch is not minimal. However vendoring has serious concerns as other user explained
Due to vendoring you have to use more software and allocate more memory in RAM. Imagine 5 isolated versions of libcurl running on your system

yes, the purpose of the GPL is to force counter productive political ideologies onto the software ecosystem in the name of GNU/FREEDOM!!1

Think of GPL as a fully publically auditable proprietary license

GPL doesn't suddenly turn you into/convert you from a republican or a democrat. Stop spewing nonsense like an underage moron

> i have no idea what I am talking about hurrrr
every time you load a program it also loads their shared libraries into ram for each program, so basically you're 100% wrong and talking out of your ass,.
minimalism turboautists are the intellectual peanut gallery, never take their advice they have no idea what they are talking about.

>every time you load a program it also loads their shared libraries into ram for each program
Not always, idiot. Do more research

>Please inform me of what magic has occured which makes the micro kernel design less costsome ?
Hybrid kernels. And the ton of publications on the subject in the last decade.
I'm not saying Monolithic kernels won't always be faster, I'm just saying the difference isn't what it used to be in theory.

The real question is about the tradeoff between speed and security these days. But yeah I would kill for a microkernel architecture that implements all the theoretical optimisations that are possible. And Minix doesn't do that yet (nor will it probably ever do).

correct it's a way to force software communism onto the world.
hybrid kernels are a marketing term made to please mactodlers.

>it also loads their shared libraries
True vendoring will prevent you from using shared libraries or keeping it to a minimum. Are you 12?

Also, before anyone asks, the original ML and OCAML compilers were bootstrapped from Lisp family languages, so they don't have any direct C heritage from that point of view afaik.

What does it have to do anything with communism? And why are you posting like an underage toddler?

t. turboautist

>hybrid kernels are a marketing term made to please mactodlers
Yeah and NT doesn't exist.
Stop trolling anytime.

xDxdxdddd look mom I won an argument!!! yeah i called 'em autist :ddddd

Stop replying to him, he's not old enough to be on this site

>rust thread successfully derailed
my work here is done
yw

All I see is some valid arguments on why one should use rust and some kids bitching about creators being faggots or something, Average thread on 4chen I suppose