Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
Responding to a few points:
Rust has better syntax.
Just look at function pointers: int(*foo)(int)[4] (not even allowed) vs fn(u32) -> [u32; 4]
Also heard of the spiral rule?
Rust syntax is context free and more intuitive
Runtime of Rust is the same as C (and sometimes better). Compile time is slower but that's because of how the compiler is written
Standard library is a big plus.
Cargo is amazing and easier than writing makes file by hand when linking external libs.
Cargo doesn't force you to use github nor git. Crates are published to crates.io. git, svn and local deps are also supported -
Distributing to windows is literally just compiling the program with cargo. C is less portable due to poor stdlib and compiler extensions
Rust doesn't have a runtime (besides libc), it always runs on bare metal whether microcontroller or not
c99 arrays aren't a positive, they suck.
c99 "flexible arrays" are also supported in rust,
just put a unsized type as the last field of your struct
Rust's safety is a huge upside.
Unsafe let's you do all the low level shenanigans you want,
in a few documented places, instead of all over your entire codebase
C macros are less flexible, but yes Rust declarative macro syntax kinda sucks
Nothing is stopping you from exporting extern C functions in Rust, just like C
Drop doesn't introduce performance problems, and destructors are an absolute necessity for proper, modern software development
Rust doesn't do any automatic memory management besides calling drop impls -
@retoor War on so little subjects is for kids. We're just exposing opinions and again, I don't want someone to feel offended
-
@retoor I am not comparing to AI's but do a developer's real feeling
-
@12bitfloat Cmake, okay for that pointer syntax
-
Overall just use what you want to use, but don't be ignorant and put your head in the sand claiming that a language invented over 50 years ago is somehow better than one designed 15 years ago
You really think programming language research hasn't advanced AT ALL in the last 50 years in ways that allows us to design better languages than C? Come on man, use your brain
And that's not a dig against C. But nowadays we have planes and not horse carriages -
@12bitfloat WOHOOO THERE ARE FLEXIBLE ARRAYS for real i mean thats extra
-
@retoor crunchy
-
@AdamOnAir Not for local variables. And you probably shouldn't use them in C either because they will easily blow up your stack
-
@12bitfloat ehm. A language designed 50 years ago is better than Rust. Yes it is, and my arguments are above. C is in planes. C is in your phone, your computer you are using to post on devrant, why ? Because it's not heavy, fast, simple and effective. Ofcourse a bit less than AI, but effective. And C23 has : https://en.wikipedia.org/wiki/...#New_functions A whole set of functions that are incredible even if the best standard is C99.
-
@retoor Yeah, turns out we already have ;)
-
@retoor That's chad language
-
@AdamOnAir I rebuked most of them. Some are true but also kinda irrelavant or circumventable if you need (slower compile time, monomorphization bloat, alloca)
And it's fineee. Just use whatever language you want to use. It appears you aren't that far into your programming journey (written and having worked on huge codebases written in C and C++) to know the peril of manual memory management
Maybe some day after wasting 3 days chasing down a magical UB rabbit you'll appreciate memory safety more :D
Or maybe you'll just get really good at C, who knows -
@AdamOnAir Well, that's just objectively false, even for an apples to apples comparison
-
@12bitfloat yes that's why i use c
-
@12bitfloat Maybe I am, but in 14 years of industry programming experience, I can relate most parts
-
@retoor There's no war : wrong programming languae
-
@12bitfloat why is it so ? what does rust have that c doesnt except safety ofc
-
@AdamOnAir Module system, better type system, generics, methods, destructors, field/function/method visibility, a proper stdlib, async, algebraic data types, procedural macros for type reflection and codegen, pattern matching, sane and automated build system, more consistent and intuitive syntax, a vibrant ecosystem of libraries which "just work" in a portable manner, ...
Pretty much every aspect of Rust is an improvement over C. Literally the only thing I can think of where Rust sucks in comparison is using raw pointers. Rust doesn't have a -> operator so it can get pretty annoying
... that's pretty much it. Everything else is just better -
@12bitfloat Don't forget about the terrible syntax (in rust) ;P
GET ME ON THAT DARTBOARD YOU CAN'T MISS I'M TOO BIG ;P -
@BordedDev yes a compatriot
-
@BordedDev You forsaken heathens will never understand :P
-
@AdamOnAir No response... Almost like I'm right :P
-
@12bitfloat Rust syntax is not better than C. It's pretty much unreadable for anyone not already quite familiar with Rust itself. And it's also bloated. I am laughing at the people who tell that C++ has bloated syntax while also telling that Rust is better.
-
@iiii Rust syntax is context free and consistent, unlike C. Things that work the same look the same and things that work differently are clearly defined by a starting keyword. You don't like it because you don't know it, that's called familiarity bias
Function ptr syntax is objectively bad. const type syntax is objectively bad (spiral rule). Return type before function name is objectively bad.
Just to name three -
@retoor You care about the name of a function more than it's return type. In Rust you can immediately see it making it easier to read. In C or C++ your eyes first have to parse the return type to get to the name. That's harder to read
-
@12bitfloat it may be context free, sure that's a good part, but it's still obscure and bloated.
I don't like it because it's bloated. I don't like long bloated lines of C++ as well. -
@12bitfloat and I do agree that type declarations and function types in C are bad. Yes, they are hard to read indeed.
-
@retoor he can't be kidding, he's german
-
@12bitfloat and btw in C++ you can use syntaxu like
auto funcName(...) -> <return type>
which is more readable considering your comment.
However i would argue a ton that a return type should not be defined as a compound mess spanning 50+ characters, but instead should be aliased for readability. Like, I care fucking not whether some return type is a "map<shit, pair<shit, array<shit>>>" i care that it is a semantic "MapOfShit" and that mess should be aliased as such. -
@retoor almost every new language made in the past 10 years or so uses types after identifiers. Types before identifiers is archaic and inconsistent.
Why is it inconsistent?
Here is an example in C#.
C# has syntax for type inference and it collides with the syntax rule for types and mutability modifiers.
MyType hello = new MyType()
var hello = new MyType()
and var collides with const or readonly which forces you pick between explicit mutability or explicit type. You can‘t have implicit types with explicit mutability. -
@antigermgerm Korrekt
-
@iiii Cpps trailing return type syntax is a little better, except that you now have both (which adds more confusion) and it starts with auto
Is it a function, global variable or something else? You still have to parse further to know
In Rust everything starts with a proper keyword: struct, fn, static, const, type, trait... You immediately know what something is -
@12bitfloat yeah, i do not like the leading "auto" as well. A keyword would have been better, but that's the constraint of the language at this point. But it's not really that hard to see that it is indeed a function, because the first parameter has a type declaration.
-
@iiii Sure, it's not the hardest thing to read, but I'd say `fn foobar() -> u32` is better still
-
The selection of topics is weird too, in there you have some known weaknesses, but also a bunch of categorically false and outdated statements, and things literally no one takes seriously. It's like you searched a forum for statements that mention Rust and are rated negative by sentiment analysis and summarized them in a list.
-
@retoor They haven't been for at least 15 years... It would be funny if it wasn't so sad :(
-
@retoor that‘s ok. Readability is subjective.
-
@lorentz What happens is that people feel irrationally threatened by rust. No C/C++ guy goes into emotional rage mode over scala or python because those languages aren't competing with C. But Rust is, and it gets elevated into this holy grail, the solution to everything, so C people are scared of the ground shifting underneath them and them not being "needed" anymore
The reality of course is that Rust, while great, isn't a silver bullet, and there are still good usecases for C! And really, overcoming that fear is as simple as just learning Rust and seeing what it's about, because then you realize it's just another tool that has it's own advantages and disadvantages
But whatever humans are always like that :D
"Cars!? Are you insane!? We will have NONE of these dangerous metal contraptions in our town! Horse carriages only!" -
@12bitfloat i believe it's more of the opposite: the rust people are proclaiming that rust is the killer and the others just retaliate
-
@12bitfloat @Lensflare I cannot stand typing after function, mainly because you still have to use an unnecessary keyword in front of the function definition so it doesn't solve anything. Same with the modern use of the fucking ":" for type hinting it's not necessary in the slightest, and it's annoying to type
-
@iiii I don't know who's at fault but there's definitely some miscommunication happening
-
@BordedDev It does solve something: It allows the grammar to be context free which makes it easier for humans and computers to parse. And come on, fn space is really not a big bother to write, especially compared to all the other stuff
heap allocating in C is at least
`foobar_t* f = (foobar_t*)malloc(sizeof(foobar));`
while in Rust it's just
`let f = Box::new(Foobar::new())`
(and the c version doesn't even initialize the object)
The rust version is shorter, easier to read, more memory safe *and* does more -
@12bitfloat yes the "fn" annoys me because it could just as well be the type then.
No clue where you're pulling the context free from when it comes to the position of the type?
And the remark about the ":" I was referring to languages which make you do `var example: MyFuckingType = ...`. I don't hate that instantiation of rust but still just looks like a static/global function call (which I guess is technically correct)
I'm no C dev, but couldn't that be solved by just using a macro? (I like C++)
#define makeNew(typing) (typing*)malloc(sizeof(typing));
foobar_t* f = makeNew(foobar_t)
But even then, most C libraries I have used have an "out of line" constructor call, e.g. make_foobar(...) -
@BordedDev most if not all languages which have this syntax also have type inference, so the "type hints" can be omitted.
var myNumber = 5
instead of
var myNumber: Int = 5
Context free means that everything has its proper place and meaning.
First you have the thing that says what it is (function or variable), then the identifier (name) and then the type, which can be omitted if it can be inferred.
You don‘t need context to know if that thing before the identifier is a mutability modifier, visibility modifier, the type, a function marker or whatever. Easy to parse for humans and machines, consistent and (admittedly subjective) more readable. -
@Lensflare Sure in TypeScript/Python I accept it as it's more an evolution of the language without changing the underlying way the language is management. It was one thing I really hated about Kotlin because it was still required in things like function definitions (haven't touched it in a couple of years).
It could also be because of how I read/parse the code mentally, I generally don't read variable names and use the types/structure to find out how things work (of course, using the name to see how it glues but not for scanning the code) -
@12bitfloat C lacks a module system but allows flexible code organization via headers and build tools like Make and CMake.
Its minimal type system avoids complexity, unlike Rust’s advanced one. C supports generics with typedef and void*.
Function pointers and structs enable method-like behavior. Less elegant than Rust though.
Memory management is explicit, using free() and close(). Rust’s Drop automates cleanup but introduces unwanted control flow, especially in embedded systems.
C uses static for internal linkage and extern for global visibility.
C’s minimal standard library ensures efficiency and portability, ideal for embedded use, while Rust’s larger std adds bloat.
C handles concurrency with pthread, epoll, and select, where Rust’s async/await model adds borrow-checker constraints.
C’s enum and union are like Rust’s ADTs but without runtime overhead.
Macros in C require manual handling.
C’s switch, if, and else provide branching. -
@iiii The german spoke
-
@retoor ITS NOT A WAR peace and love
-
@lorentz yes, actually
-
@lorentz No I regularly uses everything I cited
-
@Lensflare No just read Python and Perl
-
@12bitfloat Like said @iii Rust IS the competitor, not C. And, it's not really a fear - because a better language would be greeted well - I just personally expose my honest reaction after using it ! There are pros, yes, but I feel strangled by the language purpose itself. Not managing my own memory or being told not to that specific way by the compiler makes me uncomfortable using Rust. And I worked once on a Rust-C-C++-Haskell(Yes haskell can be used in prod) as a C developer and saw the amount of `unsafe` above each functions, god ! (if anyone wondering haskell was used for calculating math above my understanding in a college research with local semiconductor company)
-
@12bitfloat In Rust you have complications with mem allocating, not in C. Trade ! And what is hard with that alloc ?
-
@AdamOnAir eh? am i a german now?
-
@retoor eh?
-
@iiii It's how the cookie crumbles, you'll be issued your lederhosen soon, you may start wearing socks and sandals at your earliest convenience
-
@BordedDev i am wearing sandals as loungewear at home. They were my office wear before we were exiled from the office at covid time
-
@retoor we're all german
-
@antigermgerm but you are the most German of us all, Kumpel :)
-
@retoor why would anyone drink a CUMpel beer?
-
@retoor i'm not a beer connoisseur to evaluate whether ukrainian beer is really good or bad. It's mostly fine and it's more a matter of taste: beer is an acquired taste itself.
though i do prefer taking some german or czech import usually, instead of the cheapest local ones
Related Rants
She runs C shells by the seashore.
@12bitfloat Serious debate on Rust vs C here are my arguments; C has :
1. Better Syntax
2. Betetr Performance (Compile and runtime)
3. Direct Hardware Access (No strict rules)
4. Lots of codebases use `unsafe` in rs
5. No Borrow Checker Frustrations
6. Established Ecosystem
7. More Control Over Memory
8. Easier to Port & Embed
9. No Heavy Standard Library
10. EASY Manual memory management (that's a pro)
11. Optimal inline assembly
12. Memory-mapped I/O (simpler pointer math)
13. No fat pointers ( slices)
14. Better control over ABI
15. Lighter executables
16. Simple linking (no cargo)
17. Cargo forces u to use GitHub
18. More compiler choices (GCC, Clang, TinyCC, MSVC, ICC, etc)
19. More debugging tools (GDB, Valgrind)
20. Cross-compilation is easier (and there's Zig support)
21. Easier to distribute AND RUN ON WINDOWS
22. Better for baremetal (Rust needs a custom runtime for truly bare-metal execution)
23. Compatible with legacy systems (Rust is too heavy to support some old architectures)
24. Better for microcontroller (no_std/std)
25. Supports every OS(sunOS, solaris, obscure BSDs)
26. No forced updates (cargo updates takes a year and installs I36579+E package)
27. Less strict versioning (new standard broke my old code)
28. Less restrictive aliasing
29. Flexible pointer types (ever heard of Box<T>)
30. No unwarranted type safety (Sometimes you just need a void*)
31. C99 flexible arrays
32. Anonymous structs/unions (less boilerplate than enums)
33. C macros are simpler (please help me rusts' require a mini language at this point)
34. No strict mutability rules
35. Better for hacking/debugging (poke around memory)
36. Better C++ interop (C++ sucks)
37. More lib-friendly (almosts every lib has C bindings)
38. Can use void pointers (void*)
39. Better for writing shared libraries (Rust’s dynamic linking is more complex)
40. No automatic drop semantics (Rust’s Drop trait can introduce performance issues)
41. No forced monomorphization that causes binary bloat
42. Better for real-time applications (No automatic memory management surprises)
MENTION : I'm not clashing or anything, not against the person I'd like to debate with, @12bitfloat, but against the argument (RUST>C)
It's not a war
rant
c
debate
rust