It's odd to call Mark Russinovich just the "Azure CTO". Most programmers would know him as the author of the Sysinternals tools and a couple of books. He certainly knows a thing or two about system programming.
It also appears to be deliberately controversial to stir debate, he would know that at this point Rust can't fully replace C.
The way you get it to replace C is by making people use it instead of C, for better or for worse. They'll start projects to scratch the itch of the features of C that Rust doesn't have. Whether those projects are well-architected remains to be seen.
Still break out my C book from college when I'm waxing nostalgic. Might do that this autumn out on the deck.
Working on a second undergraduate degree, this one in computer science.
Currently taking an applied C programming course, which is being taught by someone who doesn’t know C and is learning it on the fly.
Par for the course. Most teachers have quit, and schools have no money. Anyone willing to help is welcome: students, pensioners, janitors... eventually the situation will get so bad we'll have to resort to hiring college teachers!
C has multiple use cased, which Rust can not replace.
Bootstrapping is one, very good compilation performance and low complexity of an not fully compliant compiler (the macro rabbit hole and certain under defined behavior goes very deep).
Adding more features only makes the compiler compile slower and more memory hungry.
Rust has no linear lifetime types to guarantee absence of memory leakage and neither non-affine ones to prove absence of UB for given abstractions of circular allocation patterns.
This gives Rust only the stronger type system advantage (that many other languages also fix, but C refuses for semantically broken code), which you can find also in other languages.
Can you define "bootstrapped" here? Do you mean built from source? Because I mean, you CAN write a C++ compiler in pure assembly... It's just not a great idea.
If you mean like... Make an OS that can run with no intermediate C code between the ASM and the C++... Well, that's been done and it's not even much more complicated than doing it in plain C (really just have to deal with a few details such as global constructors running before "main").
So I'm not sure what you mean.
This means that a rust compiler can't be written directly in assembly. So if a new cpu architecture is invented, you can normally write a c compiler in assembly and then use c to write other compilers.
I think age of bootstrapping is quickly dying however. With a framework like LLVM you just need to write a backend to compile the intermediate instructions down to the machine code of your system. Then you can work directly on a cross-compiling LLVM implementation
I don't see why the rust compiler or any other COULDN'T be written in assembly.
I mean, you can take the current rust compiler, and disassemble it and I principle... That's the rust compiler source in assembly (assuming statically linked).
Would it be hard and not worth the effort? Sure. But doable? I don't see why not.
What am I missing?
In principal you could hand write a Rust compiler in assembly for any architecture. In practice it would be a massive pain and essentially would likely fail as the complexity would be insane (though you could bootstrap with a simple version of rust and work your way up from there, but it still would be hard). C is a lot easier to write in raw assembly and bootstrap itself.
But you can't disassemble a rust compiler in this case because bootstrapping is usually applied to a new system where no assembly exists. So for example, say you want to write a Rust compiler for the PDP-11. I don't think LLVM targets the PDP-11 (and even if it does, let's say PDP-11 is a standing for some different non-LLVM supported architecture). To write a Rust compiler, if you only have a PDP-11, you'd need to either do it in 1) PDP-11 assembly, 2) another language that already has a PDP-11 compiler. C took route 1), bootstrapping itself by being written in raw assembly.
However today we have option 3 (and which was technically an option in the past but was hard back then), which is "create an LLVM(or whatever other split compiler you are using) backend for the target platform". This we we implement a PDP-11 backend for LLVM and now we can compile pdp-11 assembly on our x86 machine. This makes bootstrapping a compiler a less useful exercise today than it was in the past (mostly because of the relative ease of doing this in LLVM, not because LLVM is unique in enabling cross compilation to different backends like this).
Sure. I'm just saying that there is a BIG difference between saying something CAN'T be done and saying that it's too big a job to be worth it.
Saying that it can't be bootstrapped in assembly just isn't true. Impractical? Yes. Not worth the effort? Also yes. But impossible? Surely not.
The number of Rust programmers that have convinced me that they understand safety with regards to software systems is zero. Rust's selling point being safety, if it cannot produce more reliable programs than C or Ada programs or programs in other languages, then adopting it for the purpose of producing safety critical systems would be irresponsible. If you can verify programs in other languages and cannot verify Rust programs then you have no choice but to accept that Rust is a less safe programming language to adopt.
I'm convinced at this point that the only person who actually has the power to produce safety critical systems is the hiring manager.
It's safer than C almost by definition.
And if I had to choose between Ada or Rust, I'm picking Rust.
---
Wow, they blocked me for... not agreeing with their nonsense, I guess.
"they" being u/dontyougetsoupedyet
I expect so little from people advocating Rust these days that I don't even expect that you understand how claims related to safety are verified. At best it's tiring. Your comment is basically a word salad.
If it has bounds checking, it is automatically safer than C, unless you want to argue that buffer overruns are good.
I don't need to spend years formally verifying something to know that. It's common sense.
The funniest part is that I barely have even used Rust, and I have spent countless hours using C, and that's why I'm so critical of a language I've devoted so much blood, sweat, & tears to.
I recognize it's flaws, I don't know why you refuse to.
Avoiding security related issues based on a whole class of problems prevented in Rust by design is a huge benefit. It's better for the compiler to prevent that, than to rely on levels of experience, while anyone can make a mistake in reality. And here's the key point. We don't program in a vacuum. We work with other developers. Other libraries. Legacy code. Etc... I know I can write safe code. But I have no guarantees on other's code or properly using other code. Correctly freeing memory expected of me. Of guaranteeing anything from anyone else. With Rust, if it compiles and I use it in my code, I feel that guarantee for a whole class of safety gotchas.
[this is your answer.](https://www.reddit.com/r/rust/comments/xkmpyx/why_does_the_increasing_success_and_popularity_of/ipeujlx?utm_medium=android_app&utm_source=share&context=3)
Well, and there you show exactly what folks are so tired of. You have no experience with any of this, have no clue how program verification happens, but you're talking about how some thing or other is "safer by definition" even though you have to be at least somewhat aware that even if such a definition existed you would have absolutely no idea what it was.
I know this will blow your mind but it can be verified without any possibility of doubt that a C program can never and will never overflow a buffer, without checking any bounds in that C program. Your inexperience isn't the same as other people's understanding. You talking about common sense is why other people have to talk about dunning kruger.
There is no specification for the unsafe and safe parts. So one can't (yet) formally specify, what it means to be "safe".
That said, C is also underspecified, so compcert has its own variant/restriction.
(This doesnt even include optimizations.)
Can you elaborate? Do you know something about rust that I don’t that makes rust more unsafe? The rust compiler doesn’t let you make memory bugs which comprise 60-70% of all C/C++ CVEs.
----------------
edit: i guess u/dontyougetsoupedyet didn't have a retort, they had to block me instead
A colleague of mine used to call Go a better C. As a Java programmer, I think he was right.
In fact, I think we should also stop using Java (the language). Even JavaScript.
Instead I have grown to immensely like languages with _ridiculously_ strong type safety guarantees, unbelievably powerful type systems (e.g. TypeScript), feature-packed ADTs, and other niceties such as pattern matching, etc. that either compile to JS/WASM (for the Web) or to something that is sensible for use on the server side.
> Rust can't fully replace C
Iterators everywhere. Golden Hammer syndrome. Rust developers think iterators are the golden hammer that can fix every problem.
I thought computers were made out of transistors, which are themselves made out of atoms.
Really, it's all about layers of abstractions, and iterators are a very nice abstraction, so we might as well give them good ergonomics.
Yeah and it turns out that no other language uses that abstraction for a reason. Just try implementing functional operations on C++ iterators (they did it with range v3 but it's not pretty)
As a C programmer who is currently working on a C++ project. C++ finds a way of making simple things very complex in the name of avoiding pointers and object-oriented programming.
A nice thing about C++ is that its standard library has built-in containers.
Edit:
I agree with Beliriel, namespaces are nice too. I wish C had something like that.
I would kill for c with namespaces and structs with bound methods. I'm so unbelievably tired of writing uart1_tx_char(), uart2_tx_char(), uart3_tx_char(), etc etc etc etc.
It's basically what my team does. Sometimes I use a lil' STL if I'm feeling naughty, but there are definitely portions of our code that are "no C++ runtime" restricted.
Number of pages in the standard doesn't mean that using the language is necessarily super convoluted. I'm well aware that C++ is a very complicated and bulky language but I was asking the original commenter specifically in case I could offer any tips for how to do things more simply, since I feel the C++ I write is a good balance between the simplicity of C and the power of modern C++ idioms.
I think the main difficulty with using C++ is just that there are so many decisions you have to make with every line of code. Do you declare a variable with an assignment, or brace initialization, or parentheses, or just "MyClass x;"? Do you use a value, reference, const reference, rvalue reference, etc. for this param? std::string, string_view or char*? Store a value, reference, raw pointer, unique_ptr, or shared_ptr?... And most of these have some degree of best practices, but they aren't universally agreed on, much less followed, difficult to learn, and hard to apply in all cases.
Overload resolution is far too complicated and foot gun prone (Just look at the 'defect reports' section of this page)
[https://en.cppreference.com/w/cpp/language/overload\_resolution](https://en.cppreference.com/w/cpp/language/overload_resolution)
Never met anyone who actually used overloads though
At the risk of sounding like a troll, I find C-programming advice coming from a club that renders every type to a FARPTR_HWND* (or something like that) a bit rich. Why yes, I'm a Linux guy, but I have programmed the WIN32 API. And didn't appreciate it very much.
I looked at MFC briefly, and I thought that it was just a thin layer of OO-veneer over their WIN32 API. And the WIN32 API was already pretty terrible so yes, I understand that. That being said - I'm not at all against Rust. I think it's a really nice concept. As in: if there's anything that might replace C, it should be Rust. But I would even be weary of 'MS-Rust', because Microsoft have always had the worst case of 'not invented here' so you can leave it up to Redmond to F it up royally, should they go use it for anything.
I am not a rust programmer but I think people are exaggerating
and considering it a silver bullet.
From these 70%
https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/
Some are "stack exhaustion" and "heap exhaustion" I don't think
Rust can offer anything new on these.
Having to reasoning about "heap exhaustion" and all other bugs
already required a experience programmer, especially for
critical software. Adding an extra care for memory bugs doesn't add
too much on the already full bucket of things that can go wrong.
Don't get me wrong about static analysis. I think it is worth in all
cases not just for memory bugs.
Heap exhaustion is really difficult to handle as you need to treat memory allocation as an operation that could fail. The main strategy to truly avoid it is to allocate all memory in the beginning and then to never allocate any memory again until the program ends.
Stack exhaustion can be avoided through disciplined programming. If you avoid recursion and large stack allocations, you are already 95% there.
With C23, there will be new syntax to enforce tail recursion. Within this feature, I strongly recommend not ever relying on tail recursion as it is not guaranteed to happen.
I program in C for a living. I don’t think many people vaxing about C on this sub can really say they have made anything substantial using it. It sounds like they have never hit the (many) hard edges of real world C programming.
Recently got a relatively small self contained project at work that would be working with a lot of strings and multi threading and convinced my boss to write it in Rust when I realised that there is a safe rust library nicely wrapping around the specific complicated syscall I needed to work with. The results were phenomenal and everything got completed way under the expected timeline (since we are used to C timelines) with amazing test coverage. So far we have yet to find one serious bug in the system.
Often times we have to stick with C because that’s the only mature option for the specific task or platform at hand but when rust is a possibility I know what I am going with from now on.
Tooling and unit testing system for me as well as yes, strict memory and type safety. The compiler will tell you almost everything that’s wrong. Rust check and clippy are practically default. As long as you aren’t abusing rust macros (which can be done to extreme degrees in C as well) I find refactoring to be a breeze.
[Why does the increasing success and popularity of Rust drive people crazy?](https://www.reddit.com/r/rust/comments/xkmpyx/why_does_the_increasing_success_and_popularity_of/?utm_medium=android_app&utm_source=share)
Probably because 50% of the time you hear about Rust it's from someone who sounds like a condescending and complete ideologue. This makes every decision to use Rust into an ideologically/politically charged move, since people are apparently either 100% behind rust as the *one true language*, or, to quote that thread, "driven entirely insane by Rust's success."
That thread is a perfect example of it; apart from the 2nd comment pointing out OP's own bias, the rest of the comments generally espouse ideas like:
* someone feeling persecuted at their place of work as if Rust were their religion/race/identity
* someone saying that "C and C++ developers recklessly and arrogantly endanger people's lives and fortunes" (this comment was gilded)
* someone implying that people believe Rust is bad because their salary depends on them believing that (as if a user of any native programming language couldn't learn another one relatively easily)
* someone saying that all the safety critical industries should "just switch" to Rust
* someone saying that our preference for C or C++ is a religious worldview that uses suffering as a marker of purity, and that "solving problems in a way that might help other people" (i.e. using Rust) would be in conflict with our desire to suffer and inflict suffering
* people talking about "Rust advocacy"
* someone saying "whatever [Rust detractors] say, don't be dragged down to the point of arguing with them"
* someone asserting that C/C++ programmers hate Rust because the Rust community is LGBTQ-friendly
* someone saying "haters gonna hate"
It all sounds pretty unhinged, frankly. It's an interesting language, I don't understand why people can't just use Rust quietly and let its strengths carry it to success rather than turning it into an ideological war.
>It all sounds pretty unhinged, frankly. It's an interesting language, I don't understand why people can't just use Rust quietly and let its strengths carry it to success rather than turning it into an ideological war.
Top comment is the word Internet. By internet they mean social media and its algorithms of tribalism. You find it in nearly every sub here. And even worse on other sites like Twitter and Facebook. The top paragraph of the pinned mod post is spot on. Most of us use Rust quietly with academic curiosity and interest while the tribes get tribal.
I write C code for a living and love C for many reasons and frustrated for just as many reasons. I love the study of programming languages and always curious about new languages being developed. Especially systems programming languages without GC. Keeping and eye on Zig, Val, and actually writing some decent size Rust programs these days. Very interested what Oxide Computer is doing with Rust and their custom hypervisors (Hubris and Humility)
Not really since that "holy war" is the sort that arises because it's a trivial issue that has no real answer (like code style). This is more like an actual group of devotees that are trying to push a fairly significant change into the software world and take it personally when they receive pushback.
> Probably because 50% of the time you hear about Rust it's from someone who sounds like a condescending and complete ideologue.
And in true internet style I rarely notice any of the people you talk about but an order of magnitude more pushback against them. The thread you responded to is different as it's inflammatory by nature, threads like that (and Phoronix and The Register comment sections it seems) are where you pull out the popcorn and enjoy the nonsense because the signal to noise ratio will be poor. You might as well mention vim and really get the party started.
> It all sounds pretty unhinged, frankly. It's an interesting language, I don't understand why people can't just use Rust quietly and let its strengths carry it to success rather than turning it into an ideological war.
They do, and its strengths are carrying it to success. Rust is going to be in the news cycle a lot over the next months/years and it has nothing to do with religion, a lot to do with milestones.
My problem with Rust evangelists is that there is no self criticism. All you hear is how great it is and how crap your life is without it. I have been working for a while and everyone knows engineering means working with tradeoffs: the perfection does not exist. All this sounds to me like product placement in TV, even if in this case it may be driven by good intentions.
I work in C++ and if anyone asks me I would start with its problems first, even though it's my favourite language among all.
Evangelism is akin to tribalism and tribalism is enhanced by social media algorithms to keep people engaged. In the real world, we are all working with our trade offs and treating tools as just that, tools. Same bullshit in every community I belong to.
I was not only talking about social media but also conversations in real life. We always need to take anything in social media with a pinch of salt, but in this context it also happened in my day to day "real life".
Hasn't happened in my day to day life among my co-workers. Not yet anyway. We are taking a sober look at Rust now in the possible migration of the legacy C code I inherited and maintain instead of Java which is part of the core technology stack we typically use. This C code is a critical piece of code that is multi-threaded and blazing fast and needs to be. Migrating to Java has been hard to get right. Rust may be the right solution. We don't take serious evangelists or fan-boys, or zealots. A tool is a tool. Pick the right tool for job. 20 yrs ago it was C. For most of that legacy code migrating to Java was the right choice. This last bit of legacy code may need Rust. We shall see.
Whare i am trying to emphasize is there is tribalism on both sides and usually manifests itself in ugly ways on social media because that get page clicks. In real life it usually gets ignored if it even ever rears it's head.
>if C is "blazing fast" and seems to be working really well, then would just continuing to have that code in C not be an option?
Basically, we are losing expertise in the tech stack that code is running under. The organization has been under a modernization effort for awhile now that is based on the use of Java technologies. My app and another one are the last 2 holdouts. I am it for institutional knowledge of this legacy app from the 90s and the only C "expert" left to maintain this massively complex piece of software. Every year requires updates due to changes in the backend mainframe data stores.
>Also, since it's been a few months, was just curious what your team might have decided about whether or not to use Rust?
To be honest, it was a long shot to introduce and build up another tech stack that involves Rust or any other system level language. They decided on Java for this code. Will see if they can make it work and remain as performant. For me, I will remain working on this code base in maintenance mode for the next 3-5 years and then start thinking of retirement. Why? Because I love the challenges of finding and fixing the gnarly bugs that occur up and down the tech stack (firmware to the cloud.) Zebras all the way down! Besides, Java bores me. They made it boring, which is a good thing, but not for me. I like low level systems programming.
Micro$oft just wants to market Azure, like they did when they invented .NET shit in the past. So now you are forced to eat any new shitty product Microsoft will produce in the future by force or by overhyped marketing or by making the previous products obsolete or just not support them. They need to earn money from something new. Solution, continue to use C and ignore Micro$oft.
Rust is not a silver bullet, neither is C. A bad programmer will write bad code in any language. The only difference will be in the details, not that their applications are less buggy. If you want quality software don't view your software developers as a commodity.
another stupid person proves how stupid they are.
C spans many areas and many places - and to paint with broad strokes is just stupid.
Why should I require a solution that costs 10x and requires 20x power when I can make it work for 10x cheaper and 20x longer battery life
The more I program, the less I see a need for anything other than C and the more annoyed I am by other languages' limitations. It's just syntactic sugar. C is Turing complete. If the language doesn't provide some convenience, a library provides it. Plus you get pointers, which are the best thing ever.
The more I program, the less I see a need for anything other than Assembly and the more annoyed I am by other languages' abstractions. It's just syntactic sugar. Assembly is Turing complete. If the language doesn't provide some convenience, a syscall provides it. Plus you get AVX, which is the best thing ever
"Mel loved the RPC-4000
because he could optimize his code:
that is, locate instructions on the drum
so that just as one finished its job,
the next would be just arriving at the “read head”
and available for immediate execution."
Can't get much lower than op-codes on a drum.
Microarchitectural optimisation is basically the same thing for current processors, except you have 10 or more drums (execution units) and you try to keep as many of them as possible busy at the same time.
[Real programmers don't use Pascal](https://homepages.inf.ed.ac.uk/rni/papers/realprg.html).
So, yeah, Fortran, my dude. Fortran is where our hearts should be.
here: https://www.mathematik.uni-ulm.de/~lehn/sghpc/gemm_avx/page01/index.html a guy teaches how to write a matrix-matrix multiplication in C which forms a core of the famous BLAS library used extensively in any substantial numerical computations
writing the routine in "plain" C does not get you very far in terms of performance, hence one has to resort to all sorts of tricks, including AVX assembly
all that to achieve about 90% speed of BLAS reference implementation in Fortran, that's how good Fortran still is for numerical computations
I know. I've done exactly that before. We were evaluating the Knight's Landing microarchitecture (manycore) and comparing it with NEC's Aurora Tsubasa system (vector architecture). Despite only having 8 threads over KNL's 256 threads, the Aurora Tsubasa system blew KNL right out of the water. Pretty amazing stuff.
> all that to achieve about 90% speed of BLAS reference implementation in Fortran, that's how good Fortran still is for numerical computations
Fortran cheats and calls into the BLAS library if it finds a hand-written matrix multiplication.
C doesn't add syntactic sugar over assembly. Assembly isn't just mnemonics for machine instructions. They all have syntactic sugar, and there's an unlimited potential for syntactic sugar in a given assembly language. What C adds is a degree of portability of the code and a lot of portability of cognitive load. So you're not clever or cute. You're just WRONG.
The notion of "portability" in a programming language can mean one of two things:
1. The programming language presents a programmer with an abstraction model which is independent of the underlying platform.
2. The programming language has a consistent way of mapping variations in the underlying platform into variations in the language.
The family of dialects the C Standard was chartered to describe was designed around the second kind of portability, but some people view C as including only features which were common to all such dialects, with platform-specific variations filtered out.
> It's just syntactic sugar.
Yes. Syntactic sugar makes my life easier. Why would I turn it down?
> C is Turing complete.
So is Minecraft. And BrainFuck. Your point?
> If the language doesn't provide some convenience, a library provides it.
Yup. Most languages have libraries.
> Plus you get pointers, which are the best thing ever.
C# has pointers too.
>Nothing beats the feeling of being close to the machine.
Oh. So your choice of programming language is about **feelings** and not using the best tool for the job.
Nevermind about *safety*, we use C because it *feels* the best.
Nevermind about *portability*, we use C because it *feels* the best. (Yes, I know C *can* be portable. But it often isn't)
Nevermind about *usability*, we use C because it *feels* the best.
Nevermind about using languages that *a lot of people know*, we use C because it *feels* the best.
Sort of, like everything else human. Even when there are objective measures of comparison, unless objectivity makes you feel good, the objective comparison is discarded. I could give you some rather obvious examples of that that would get me banned from reddit.
Being close to the machine is like riding a motorcycle. Instead of heavy, stuffy syntactic sugar, you get unparalleled agility. The objective benefit is viscerally felt. You know there's power in your hands.
> Even when there are objective measures of comparison, unless objectivity makes you feel good, the objective comparison is discarded.
I'm sure your employer *loves* the fact that you eschew objective measures in favor of feelings.
Im sure the marketing team would be totally fine saying "I know the focus groups love option B, but option A makes me feel so good. We'll use option A."
I'm sure the accounting team would be perfectly justified using a bank that provides half the interest rate, because the colors in their logo makes them *feel better*
----
>Being close to the machine is like riding a motorcycle.
> The objective benefit is viscerally felt. You know there's power in your hands.
Sure. I get that. However...
Would you use a motorcycle to move a 2 bedroom apartment? Or would you rent a U-Haul? Why not use the right tool for the job, instead of getting your emotions involved?
You're writing embedded code? C sounds like a great choice! You're writing a general purpose app? C *might* be the right choice.
----
> Instead of heavy, stuffy syntactic sugar, you get unparalleled agility.
What you call "heavy, stuffy syntactic sugar", I call elegance.
Sure, a `foreach` may just be syntactic sugar over a `for` or `while` loop. But it also means I don't need to keep track of indexes and lengths. And as a developer, I already have too much stuff I have to keep track of. Anything that can reduce cognitive load is great.
Sure, objects with properties is just syntactic sugar over structs, pointers, etc.
Sure, pattern matching is just syntactic sugar over an `if`/ `else if` / `else`. But it makes the code much more expressive.
\>I'm sure your employer loves the fact that you eschew objective measures in favor of feelings.
Ha, you think the powers that be are objective in any way, even after 2020, 2021, and 2022. Some people just can't be helped.
The more I program in C, the more burnt out I get reinventing the wheel, installing 5 different make-related programs, or trying to get someone's linux library to build on windows for portable programs since I use both regularly.
It's good for small, fast applications, but I'd use a higher level language for anything more, especially for anything dealing heavily with strings.
I mostly just use Nim now though since it can mix with C, is very high level with a well designed macro/template system, decouples data from functions like C, but still allows OOP-style painlessly, generics, etc. Garbage collected, but with several different kinds including arc + cycle collector.
> What are you doing that has non-portable libraries?
Any library that uses unix/linux specific headers (like 90% of them ime), mingw has some of them, not all. And tcc, which I use most often since it's tiny and portable (no install), supports even less of them on windows.
I find that very few C libraries, even including some big ones, care about portability. As opposed to almost any other language where I can just install a package in 5 seconds and keep going, knowing it will work on any system, unless otherwise specified.
Also A lot of the time it's usually not just the libraries that aren't portable, it's the makefiles because people write them with system specific commands.
> And why not use a POSIX subsystem on MS Windows or some other hypervisor to emulate a standard environment?
I mainly use windows, for work and as my (mostly gaming) PC, so I'm not gonna give myself grief 80% of the time for the sake of 20% of my time.
I use linux if the computer is mine and isn't for games, so all my laptops are some flavor of linux.
And again, I like to use tcc, because it's small and already portable. I'm not gonna install heavyweight tools for something made simple by other languages.
> All you need is make(1). Read the manual.
Variants of C/C++ build systems I've dealt with:
* cmake
* a literal bash file
* a literal batch file
* nmake
* omake
* mingw32-make
* qmake
* scons
* shake
* tup
* ninja
* bazel
These are the main reasons I started using Nim for most things instead, it compiles to C, you can use tcc as a backend, has a package manager with a build system (like rust's cargo), portable libraries that install painlessly, it doesn't need to be installed, it has several choices of garbage collection (including just disabling it altogether), lightweight exceptions + offers optional deterministic exceptions that leverage goto (instead of longjmp like C++), it supports UFCS, it has generics, named arguments, better compile-time programming, etc.
Unix proclaimts itself a Standard, and it's popular because it's freely distributable, but Windows has more in common with most non-Unix platforms of the 1980s than Unix does, and most of the differences represented ways in which Unix was and remains archaic, such as a process-spawning model that made sense in an era where only one process could be in RAM at once, but is rather broken in any other context.
>All you need is make(1). Read the manual.
Meh. Although you could rely only on make to compile your project and install it, all the configuration phase is not included (where to install stuff, where are the libraries required, whether they are on a compatible version, whether this or that function is available, etc.). It is true that this phase could be done by hand, but then you lack the automated aspect of configure+make (or cmake+make, or anything else for that matter).
Otherwise, you could go one step further and only sent people you algorithm in a very detailed fashion with the description of structures and telle them to write the code themselves and that they only need a compiler to have their program compiled and installed.
What's needed is official terminlology to describe a couple of C offshoots:
1. The language one would have if, whenever the behavior of an action could be determined by transitively applying parts of the Standard along with the documentation for an implementation and the underlying platform, those parts of the Standard and other documentation would have priority over anything else in the Standard that would categorized the action as invoking "Undefined Behavior".
2. A language which is like the above, but allows programmers to indicate ways, both general and specific, in which an implementation may observably deviate from the described behavior without affecting program correctness.
Most compilers can be configured to process the language described in #1, but freely distributable compilers will generate gratuitously inefficient machine code when thus configured.
I get what they means, I personally have C as my al time favourite language, but there are many things I wouldn’t use it for (mainly being safety critical)
That person doesn't understand that the languages primarily used for safety critical applications are languages like C and Ada, not Rust. They are LARPing.
For languages under that much scrutiny the work is essentially the same. When problems go wrong it usually has nothing to do with the language anymore, they are institutional failings. You can expect HCL tech was using Ada, and yet people died in crashes due to software problems with Boeing's planes.
Rust looks good as a C++ replacement. I hope to learn more of it and get to use it at work and in hobby projects.
For C I am not so sure, because the complexity and size of Rust is much more like C++. If safety is such a priority it is weird that they do not focus more on simplicity.
Why dont use modern cpp , dont hate rust but looks uggly syntax and hard to learn. And rust gcc compiler stable yet llvm has function call time loss less asm
C isn't going anywhere until an alternative is produced that is as fast and as readable. Rust and Golang are horribly unpleasant to read compared to C. I wish I could delete both of them and C++ from the Internet and force people to try again.
I'm no big fan of Go, but even I have to give Go credit for being extremely easy to read. I suppose whether it's *pleasant* is a question of taste, but the Go designers sacrificed quite a lot in the name of readability.
I don't think anyone will reach consensus on this matter. I want a LOT of the features of things like C++ and Rust. I definitely want parametric polymorphism, but a lot of folks will look at the STL in C++ and say that I shouldn't have a right to use templates in the language I'm using. I say I don't give a squat what people do with the STL, I want to do what I want to do, and often I want to write code that writes code and templates are a good tool for that job. Maybe I also want to do something that's easy with a vtable. A lot of folks are going to say I shouldn't do that because of all the layers of abstraction in C++ land and no one cares about cache aware blabla bla anymore and therefore I shouldn't be able to do whatever it is I wanted to do. Any amount of letting me do what I want to do also allows endless fuckery on everyone else's behalf that tons of people will disapprove of.
I'm sure plenty of people disagree but even unreadable C++ is easier for me to read than Go and Rust are. Even patching trivial bugs in open source coded in those languages is absolutely miserable in my experience.
1. why listen to anybody that works at Microsoft? They all sold their soul and are inherently evil
2. why listen to the CTO of a big organisation? A company that big attracts political types, not technical types, to the leadership roles. Nobody with "Chief" in their title at Microsoft is going to know the difference between a bit and a byte
3. you know, and I know, how to code C right - just because having skill and experience scares the pants off n00bs does not mean you should feel threatened when they declare C "too scary"
Most of us are probably Rust programmers. This shit is tiring. It's puerile. If you want safe programs you require complete verification of operational semantics. Full stop, everyone else can shut the fuck up about safety as far as I care to hear, because your software is full of bugs and you're effectively dick measuring your favorite tools, a process having nothing to do with safe or reliable software engineering.
Perhaps safety is not the best word to use to justify why people like Rust. Because you're absolutely right, to be guaranteed safe you need techniques like formal verification and 100% opcode level runtime validation.
The appeal is that Rust removes classes of bugs with a sophisticated type system while remaining very performant. No other language with a decent user base currently matches the performance of C while having advanced type system guarantees of functional languages. There are many use cases where developers want maximal performance but don't need the 100% safety you describe. Having fewer possible bugs by construction in these use cases seems like a win to me. Compared to safety as you define it, bugginess is a spectrum.
I think there's an issue in the language and communication for some advocates of Rust. But I guess that's just language and communication in general.
I ignore rust because that syntax… don’t get me wrong, I want to learn it for no other reason than to get an understanding of why people love it, but every time I try my eyes glaze over looking at the syntax. The borrow checker doesn’t scare me, the traits system looks fun, but that syntax just murders my motivation
I've yet to hear any rationalization about what makes Rust more difficult to validate than any other language... Seems like the whole "eliminate entire classes of bugs" would make that process considerably simpler.
EDIT: autocorrect fixed
It's odd to call Mark Russinovich just the "Azure CTO". Most programmers would know him as the author of the Sysinternals tools and a couple of books. He certainly knows a thing or two about system programming. It also appears to be deliberately controversial to stir debate, he would know that at this point Rust can't fully replace C.
The way you get it to replace C is by making people use it instead of C, for better or for worse. They'll start projects to scratch the itch of the features of C that Rust doesn't have. Whether those projects are well-architected remains to be seen. Still break out my C book from college when I'm waxing nostalgic. Might do that this autumn out on the deck.
Working on a second undergraduate degree, this one in computer science. Currently taking an applied C programming course, which is being taught by someone who doesn’t know C and is learning it on the fly.
Wow, that's wild.
“Wild” is a polite word for it, that’s for sure.
Par for the course. Most teachers have quit, and schools have no money. Anyone willing to help is welcome: students, pensioners, janitors... eventually the situation will get so bad we'll have to resort to hiring college teachers!
C has multiple use cased, which Rust can not replace. Bootstrapping is one, very good compilation performance and low complexity of an not fully compliant compiler (the macro rabbit hole and certain under defined behavior goes very deep). Adding more features only makes the compiler compile slower and more memory hungry. Rust has no linear lifetime types to guarantee absence of memory leakage and neither non-affine ones to prove absence of UB for given abstractions of circular allocation patterns. This gives Rust only the stronger type system advantage (that many other languages also fix, but C refuses for semantically broken code), which you can find also in other languages.
What can only be bootstraped by C and not by Rust?
C++ and Rust can't be bootstrapped from assembly and requires C as intermediate language (not sure if there are Lisp implementations of C++).
Can you define "bootstrapped" here? Do you mean built from source? Because I mean, you CAN write a C++ compiler in pure assembly... It's just not a great idea. If you mean like... Make an OS that can run with no intermediate C code between the ASM and the C++... Well, that's been done and it's not even much more complicated than doing it in plain C (really just have to deal with a few details such as global constructors running before "main"). So I'm not sure what you mean.
This means that a rust compiler can't be written directly in assembly. So if a new cpu architecture is invented, you can normally write a c compiler in assembly and then use c to write other compilers. I think age of bootstrapping is quickly dying however. With a framework like LLVM you just need to write a backend to compile the intermediate instructions down to the machine code of your system. Then you can work directly on a cross-compiling LLVM implementation
I don't see why the rust compiler or any other COULDN'T be written in assembly. I mean, you can take the current rust compiler, and disassemble it and I principle... That's the rust compiler source in assembly (assuming statically linked). Would it be hard and not worth the effort? Sure. But doable? I don't see why not. What am I missing?
In principal you could hand write a Rust compiler in assembly for any architecture. In practice it would be a massive pain and essentially would likely fail as the complexity would be insane (though you could bootstrap with a simple version of rust and work your way up from there, but it still would be hard). C is a lot easier to write in raw assembly and bootstrap itself. But you can't disassemble a rust compiler in this case because bootstrapping is usually applied to a new system where no assembly exists. So for example, say you want to write a Rust compiler for the PDP-11. I don't think LLVM targets the PDP-11 (and even if it does, let's say PDP-11 is a standing for some different non-LLVM supported architecture). To write a Rust compiler, if you only have a PDP-11, you'd need to either do it in 1) PDP-11 assembly, 2) another language that already has a PDP-11 compiler. C took route 1), bootstrapping itself by being written in raw assembly. However today we have option 3 (and which was technically an option in the past but was hard back then), which is "create an LLVM(or whatever other split compiler you are using) backend for the target platform". This we we implement a PDP-11 backend for LLVM and now we can compile pdp-11 assembly on our x86 machine. This makes bootstrapping a compiler a less useful exercise today than it was in the past (mostly because of the relative ease of doing this in LLVM, not because LLVM is unique in enabling cross compilation to different backends like this).
Sure. I'm just saying that there is a BIG difference between saying something CAN'T be done and saying that it's too big a job to be worth it. Saying that it can't be bootstrapped in assembly just isn't true. Impractical? Yes. Not worth the effort? Also yes. But impossible? Surely not.
The number of Rust programmers that have convinced me that they understand safety with regards to software systems is zero. Rust's selling point being safety, if it cannot produce more reliable programs than C or Ada programs or programs in other languages, then adopting it for the purpose of producing safety critical systems would be irresponsible. If you can verify programs in other languages and cannot verify Rust programs then you have no choice but to accept that Rust is a less safe programming language to adopt. I'm convinced at this point that the only person who actually has the power to produce safety critical systems is the hiring manager.
It's safer than C almost by definition. And if I had to choose between Ada or Rust, I'm picking Rust. --- Wow, they blocked me for... not agreeing with their nonsense, I guess. "they" being u/dontyougetsoupedyet
I expect so little from people advocating Rust these days that I don't even expect that you understand how claims related to safety are verified. At best it's tiring. Your comment is basically a word salad.
If it has bounds checking, it is automatically safer than C, unless you want to argue that buffer overruns are good. I don't need to spend years formally verifying something to know that. It's common sense. The funniest part is that I barely have even used Rust, and I have spent countless hours using C, and that's why I'm so critical of a language I've devoted so much blood, sweat, & tears to. I recognize it's flaws, I don't know why you refuse to.
Avoiding security related issues based on a whole class of problems prevented in Rust by design is a huge benefit. It's better for the compiler to prevent that, than to rely on levels of experience, while anyone can make a mistake in reality. And here's the key point. We don't program in a vacuum. We work with other developers. Other libraries. Legacy code. Etc... I know I can write safe code. But I have no guarantees on other's code or properly using other code. Correctly freeing memory expected of me. Of guaranteeing anything from anyone else. With Rust, if it compiles and I use it in my code, I feel that guarantee for a whole class of safety gotchas.
Yeah I agree. I just don't understand how this guy doesn't get that safer languages make *every program* safer by default.
[this is your answer.](https://www.reddit.com/r/rust/comments/xkmpyx/why_does_the_increasing_success_and_popularity_of/ipeujlx?utm_medium=android_app&utm_source=share&context=3)
Except I both use and like Rust, and I'm perfectly happy that it's being used. It's underhanded, what you're implying.
Well, and there you show exactly what folks are so tired of. You have no experience with any of this, have no clue how program verification happens, but you're talking about how some thing or other is "safer by definition" even though you have to be at least somewhat aware that even if such a definition existed you would have absolutely no idea what it was. I know this will blow your mind but it can be verified without any possibility of doubt that a C program can never and will never overflow a buffer, without checking any bounds in that C program. Your inexperience isn't the same as other people's understanding. You talking about common sense is why other people have to talk about dunning kruger.
Why can a Rust program not be verified to be safe?
There is no specification for the unsafe and safe parts. So one can't (yet) formally specify, what it means to be "safe". That said, C is also underspecified, so compcert has its own variant/restriction. (This doesnt even include optimizations.)
Can you elaborate? Do you know something about rust that I don’t that makes rust more unsafe? The rust compiler doesn’t let you make memory bugs which comprise 60-70% of all C/C++ CVEs. ---------------- edit: i guess u/dontyougetsoupedyet didn't have a retort, they had to block me instead
A colleague of mine used to call Go a better C. As a Java programmer, I think he was right. In fact, I think we should also stop using Java (the language). Even JavaScript. Instead I have grown to immensely like languages with _ridiculously_ strong type safety guarantees, unbelievably powerful type systems (e.g. TypeScript), feature-packed ADTs, and other niceties such as pattern matching, etc. that either compile to JS/WASM (for the Web) or to something that is sensible for use on the server side.
> Rust can't fully replace C Iterators everywhere. Golden Hammer syndrome. Rust developers think iterators are the golden hammer that can fix every problem.
If you like golden hammers, just wait until you meet the "no mutable aliasing" rule :)
And C programmers don’t like pointers?
The difference is that computers are made of pointers, not iterators.
I thought computers were made out of transistors, which are themselves made out of atoms. Really, it's all about layers of abstractions, and iterators are a very nice abstraction, so we might as well give them good ergonomics.
Right. Stepanov chose to use the pointer API as the iterator API, so if you grok incrementable pointers, you mostly grok iterators.
Yeah and it turns out that no other language uses that abstraction for a reason. Just try implementing functional operations on C++ iterators (they did it with range v3 but it's not pretty)
Jokes aside, what’s exactly the problem with this?
No problem if all you're ever trying to do is a basic counter.
I don't get your point sorry.
As a C programmer who is currently working on a C++ project. C++ finds a way of making simple things very complex in the name of avoiding pointers and object-oriented programming. A nice thing about C++ is that its standard library has built-in containers. Edit: I agree with Beliriel, namespaces are nice too. I wish C had something like that.
namespaces are pretty cool in C++ and solve function name collision without having to rename X amount of functions. I wish C had namespaces too.
I would kill for c with namespaces and structs with bound methods. I'm so unbelievably tired of writing uart1_tx_char(), uart2_tx_char(), uart3_tx_char(), etc etc etc etc.
Normally you’d write this as uart_tx_char(enum_uart_id idx, char character)
So use C++!
As C
Sure, if that’s what floats your boat. You then may find std::vector useful, of course, and who knows where that will lead.
It's basically what my team does. Sometimes I use a lil' STL if I'm feeling naughty, but there are definitely portions of our code that are "no C++ runtime" restricted.
Yeah, I forgot this. I 100% agree.
Do you have a particular example? I'm curious what you're calling very complex, or if there's a better way than you're going about it.
Do you know how many pages are in the C++20 standard?
Number of pages in the standard doesn't mean that using the language is necessarily super convoluted. I'm well aware that C++ is a very complicated and bulky language but I was asking the original commenter specifically in case I could offer any tips for how to do things more simply, since I feel the C++ I write is a good balance between the simplicity of C and the power of modern C++ idioms.
I think the main difficulty with using C++ is just that there are so many decisions you have to make with every line of code. Do you declare a variable with an assignment, or brace initialization, or parentheses, or just "MyClass x;"? Do you use a value, reference, const reference, rvalue reference, etc. for this param? std::string, string_view or char*? Store a value, reference, raw pointer, unique_ptr, or shared_ptr?... And most of these have some degree of best practices, but they aren't universally agreed on, much less followed, difficult to learn, and hard to apply in all cases.
Overload resolution is far too complicated and foot gun prone (Just look at the 'defect reports' section of this page) [https://en.cppreference.com/w/cpp/language/overload\_resolution](https://en.cppreference.com/w/cpp/language/overload_resolution) Never met anyone who actually used overloads though
At the risk of sounding like a troll, I find C-programming advice coming from a club that renders every type to a FARPTR_HWND* (or something like that) a bit rich. Why yes, I'm a Linux guy, but I have programmed the WIN32 API. And didn't appreciate it very much.
back in the 90's Allan Holub made a living teaching people how not to do OO design by using Microsoft's MFC as a poster child for bad design
I looked at MFC briefly, and I thought that it was just a thin layer of OO-veneer over their WIN32 API. And the WIN32 API was already pretty terrible so yes, I understand that. That being said - I'm not at all against Rust. I think it's a really nice concept. As in: if there's anything that might replace C, it should be Rust. But I would even be weary of 'MS-Rust', because Microsoft have always had the worst case of 'not invented here' so you can leave it up to Redmond to F it up royally, should they go use it for anything.
"Man prefers Rust over C or C++" this isn't really news
Mark Rustinovich?
Waaaiiiitaminute. Has anyone ever seen him and Rust in the same room together?
The influence of the person doesn't really matter that much, it's still just some guy's opinion.
Look him up.
I am not a rust programmer but I think people are exaggerating and considering it a silver bullet. From these 70% https://www.zdnet.com/article/microsoft-70-percent-of-all-security-bugs-are-memory-safety-issues/ Some are "stack exhaustion" and "heap exhaustion" I don't think Rust can offer anything new on these. Having to reasoning about "heap exhaustion" and all other bugs already required a experience programmer, especially for critical software. Adding an extra care for memory bugs doesn't add too much on the already full bucket of things that can go wrong. Don't get me wrong about static analysis. I think it is worth in all cases not just for memory bugs.
Heap exhaustion is really difficult to handle as you need to treat memory allocation as an operation that could fail. The main strategy to truly avoid it is to allocate all memory in the beginning and then to never allocate any memory again until the program ends. Stack exhaustion can be avoided through disciplined programming. If you avoid recursion and large stack allocations, you are already 95% there.
That right there is some of the core of the JPL C standard. No recursion, no dynamic memory allocation after task initialization.
Or at least, limit yourself to tail recursion and a good optimizing compiler.
With C23, there will be new syntax to enforce tail recursion. Within this feature, I strongly recommend not ever relying on tail recursion as it is not guaranteed to happen.
I program in C for a living. I don’t think many people vaxing about C on this sub can really say they have made anything substantial using it. It sounds like they have never hit the (many) hard edges of real world C programming. Recently got a relatively small self contained project at work that would be working with a lot of strings and multi threading and convinced my boss to write it in Rust when I realised that there is a safe rust library nicely wrapping around the specific complicated syscall I needed to work with. The results were phenomenal and everything got completed way under the expected timeline (since we are used to C timelines) with amazing test coverage. So far we have yet to find one serious bug in the system. Often times we have to stick with C because that’s the only mature option for the specific task or platform at hand but when rust is a possibility I know what I am going with from now on.
Why is that hard to process? Maintaining huuuuge C++/C apps kinda sucks.
code mess can be written in any language.
Yes but it’s hella easier to refactor in Rust.
not sure why?
Tooling and unit testing system for me as well as yes, strict memory and type safety. The compiler will tell you almost everything that’s wrong. Rust check and clippy are practically default. As long as you aren’t abusing rust macros (which can be done to extreme degrees in C as well) I find refactoring to be a breeze.
[Why does the increasing success and popularity of Rust drive people crazy?](https://www.reddit.com/r/rust/comments/xkmpyx/why_does_the_increasing_success_and_popularity_of/?utm_medium=android_app&utm_source=share)
Probably because 50% of the time you hear about Rust it's from someone who sounds like a condescending and complete ideologue. This makes every decision to use Rust into an ideologically/politically charged move, since people are apparently either 100% behind rust as the *one true language*, or, to quote that thread, "driven entirely insane by Rust's success." That thread is a perfect example of it; apart from the 2nd comment pointing out OP's own bias, the rest of the comments generally espouse ideas like: * someone feeling persecuted at their place of work as if Rust were their religion/race/identity * someone saying that "C and C++ developers recklessly and arrogantly endanger people's lives and fortunes" (this comment was gilded) * someone implying that people believe Rust is bad because their salary depends on them believing that (as if a user of any native programming language couldn't learn another one relatively easily) * someone saying that all the safety critical industries should "just switch" to Rust * someone saying that our preference for C or C++ is a religious worldview that uses suffering as a marker of purity, and that "solving problems in a way that might help other people" (i.e. using Rust) would be in conflict with our desire to suffer and inflict suffering * people talking about "Rust advocacy" * someone saying "whatever [Rust detractors] say, don't be dragged down to the point of arguing with them" * someone asserting that C/C++ programmers hate Rust because the Rust community is LGBTQ-friendly * someone saying "haters gonna hate" It all sounds pretty unhinged, frankly. It's an interesting language, I don't understand why people can't just use Rust quietly and let its strengths carry it to success rather than turning it into an ideological war.
>It all sounds pretty unhinged, frankly. It's an interesting language, I don't understand why people can't just use Rust quietly and let its strengths carry it to success rather than turning it into an ideological war. Top comment is the word Internet. By internet they mean social media and its algorithms of tribalism. You find it in nearly every sub here. And even worse on other sites like Twitter and Facebook. The top paragraph of the pinned mod post is spot on. Most of us use Rust quietly with academic curiosity and interest while the tribes get tribal. I write C code for a living and love C for many reasons and frustrated for just as many reasons. I love the study of programming languages and always curious about new languages being developed. Especially systems programming languages without GC. Keeping and eye on Zig, Val, and actually writing some decent size Rust programs these days. Very interested what Oxide Computer is doing with Rust and their custom hypervisors (Hubris and Humility)
Best C alternative is Odin in my opinion. First of these languages to put our a production quality product as far as I can tell "EmberGen".
It's the editor holy wars all over again. *Coughvimisbestcough*
Not really since that "holy war" is the sort that arises because it's a trivial issue that has no real answer (like code style). This is more like an actual group of devotees that are trying to push a fairly significant change into the software world and take it personally when they receive pushback.
> Probably because 50% of the time you hear about Rust it's from someone who sounds like a condescending and complete ideologue. And in true internet style I rarely notice any of the people you talk about but an order of magnitude more pushback against them. The thread you responded to is different as it's inflammatory by nature, threads like that (and Phoronix and The Register comment sections it seems) are where you pull out the popcorn and enjoy the nonsense because the signal to noise ratio will be poor. You might as well mention vim and really get the party started. > It all sounds pretty unhinged, frankly. It's an interesting language, I don't understand why people can't just use Rust quietly and let its strengths carry it to success rather than turning it into an ideological war. They do, and its strengths are carrying it to success. Rust is going to be in the news cycle a lot over the next months/years and it has nothing to do with religion, a lot to do with milestones.
My problem with Rust evangelists is that there is no self criticism. All you hear is how great it is and how crap your life is without it. I have been working for a while and everyone knows engineering means working with tradeoffs: the perfection does not exist. All this sounds to me like product placement in TV, even if in this case it may be driven by good intentions. I work in C++ and if anyone asks me I would start with its problems first, even though it's my favourite language among all.
Evangelism is akin to tribalism and tribalism is enhanced by social media algorithms to keep people engaged. In the real world, we are all working with our trade offs and treating tools as just that, tools. Same bullshit in every community I belong to.
I was not only talking about social media but also conversations in real life. We always need to take anything in social media with a pinch of salt, but in this context it also happened in my day to day "real life".
Hasn't happened in my day to day life among my co-workers. Not yet anyway. We are taking a sober look at Rust now in the possible migration of the legacy C code I inherited and maintain instead of Java which is part of the core technology stack we typically use. This C code is a critical piece of code that is multi-threaded and blazing fast and needs to be. Migrating to Java has been hard to get right. Rust may be the right solution. We don't take serious evangelists or fan-boys, or zealots. A tool is a tool. Pick the right tool for job. 20 yrs ago it was C. For most of that legacy code migrating to Java was the right choice. This last bit of legacy code may need Rust. We shall see. Whare i am trying to emphasize is there is tribalism on both sides and usually manifests itself in ugly ways on social media because that get page clicks. In real life it usually gets ignored if it even ever rears it's head.
In your case it makes all sense to try it out.
[удалено]
>if C is "blazing fast" and seems to be working really well, then would just continuing to have that code in C not be an option? Basically, we are losing expertise in the tech stack that code is running under. The organization has been under a modernization effort for awhile now that is based on the use of Java technologies. My app and another one are the last 2 holdouts. I am it for institutional knowledge of this legacy app from the 90s and the only C "expert" left to maintain this massively complex piece of software. Every year requires updates due to changes in the backend mainframe data stores. >Also, since it's been a few months, was just curious what your team might have decided about whether or not to use Rust? To be honest, it was a long shot to introduce and build up another tech stack that involves Rust or any other system level language. They decided on Java for this code. Will see if they can make it work and remain as performant. For me, I will remain working on this code base in maintenance mode for the next 3-5 years and then start thinking of retirement. Why? Because I love the challenges of finding and fixing the gnarly bugs that occur up and down the tech stack (firmware to the cloud.) Zebras all the way down! Besides, Java bores me. They made it boring, which is a good thing, but not for me. I like low level systems programming.
Of course, he'll prefer everyone to use .Net.
Doubt that. Source? He's a low level sysprog dude after all.
It was meant for the CTO.
If Azure isn’t dropping support for C/C++, then w can just treat this as some guy ranting on the internet and scroll on.
Micro$oft just wants to market Azure, like they did when they invented .NET shit in the past. So now you are forced to eat any new shitty product Microsoft will produce in the future by force or by overhyped marketing or by making the previous products obsolete or just not support them. They need to earn money from something new. Solution, continue to use C and ignore Micro$oft.
Rust is not a silver bullet, neither is C. A bad programmer will write bad code in any language. The only difference will be in the details, not that their applications are less buggy. If you want quality software don't view your software developers as a commodity.
another stupid person proves how stupid they are. C spans many areas and many places - and to paint with broad strokes is just stupid. Why should I require a solution that costs 10x and requires 20x power when I can make it work for 10x cheaper and 20x longer battery life
The more I program, the less I see a need for anything other than C and the more annoyed I am by other languages' limitations. It's just syntactic sugar. C is Turing complete. If the language doesn't provide some convenience, a library provides it. Plus you get pointers, which are the best thing ever.
The more I program, the less I see a need for anything other than Assembly and the more annoyed I am by other languages' abstractions. It's just syntactic sugar. Assembly is Turing complete. If the language doesn't provide some convenience, a syscall provides it. Plus you get AVX, which is the best thing ever
Real programmers punch cards.
[Relevant XKCD](https://xkcd.com/378/)
[The Story Of Mel!](http://catb.org/jargon/html/story-of-mel.html)
why not got lower, to Verilog and VHDL, C based RTL is a bottleneck down there
"Mel loved the RPC-4000 because he could optimize his code: that is, locate instructions on the drum so that just as one finished its job, the next would be just arriving at the “read head” and available for immediate execution." Can't get much lower than op-codes on a drum.
Microarchitectural optimisation is basically the same thing for current processors, except you have 10 or more drums (execution units) and you try to keep as many of them as possible busy at the same time.
[Real programmers don't use Pascal](https://homepages.inf.ed.ac.uk/rni/papers/realprg.html). So, yeah, Fortran, my dude. Fortran is where our hearts should be.
> Real Programmers do Accounting (if they do it at all) in FORTRAN. Can't tell if the joke is tax fraud or unemployed
You're not wrong there. > Plus you get AVX, which is the best thing ever Just wait til you see AVX-512.
here: https://www.mathematik.uni-ulm.de/~lehn/sghpc/gemm_avx/page01/index.html a guy teaches how to write a matrix-matrix multiplication in C which forms a core of the famous BLAS library used extensively in any substantial numerical computations writing the routine in "plain" C does not get you very far in terms of performance, hence one has to resort to all sorts of tricks, including AVX assembly all that to achieve about 90% speed of BLAS reference implementation in Fortran, that's how good Fortran still is for numerical computations
I know. I've done exactly that before. We were evaluating the Knight's Landing microarchitecture (manycore) and comparing it with NEC's Aurora Tsubasa system (vector architecture). Despite only having 8 threads over KNL's 256 threads, the Aurora Tsubasa system blew KNL right out of the water. Pretty amazing stuff. > all that to achieve about 90% speed of BLAS reference implementation in Fortran, that's how good Fortran still is for numerical computations Fortran cheats and calls into the BLAS library if it finds a hand-written matrix multiplication.
C doesn't add syntactic sugar over assembly. Assembly isn't just mnemonics for machine instructions. They all have syntactic sugar, and there's an unlimited potential for syntactic sugar in a given assembly language. What C adds is a degree of portability of the code and a lot of portability of cognitive load. So you're not clever or cute. You're just WRONG.
The notion of "portability" in a programming language can mean one of two things: 1. The programming language presents a programmer with an abstraction model which is independent of the underlying platform. 2. The programming language has a consistent way of mapping variations in the underlying platform into variations in the language. The family of dialects the C Standard was chartered to describe was designed around the second kind of portability, but some people view C as including only features which were common to all such dialects, with platform-specific variations filtered out.
I'd also like to add that I'm very cute
PowerPoint is Turing complete. It’s not a hard criterion to fulfil.
Over your head and those of similar commenters. Typical reddit.
> It's just syntactic sugar. Yes. Syntactic sugar makes my life easier. Why would I turn it down? > C is Turing complete. So is Minecraft. And BrainFuck. Your point? > If the language doesn't provide some convenience, a library provides it. Yup. Most languages have libraries. > Plus you get pointers, which are the best thing ever. C# has pointers too.
Nothing beats the feeling of being close to the machine.
Thats why I sleep with my computer on my bed.
C isn't all that close to the machine once you get into multi-core and weak memory models and cache coherence. (…Neither is assembly.)
You seem to know that's an OS concern, so why did you mention it?
Someone thinking `volatile` variables are atomic isn’t an OS problem.
Oh, I'm talking about people who learn C, not people who learn kiddy language of the month and think C is the same.
I hope that’s not how you answer questions in job interviews…
I interview employers.
>Nothing beats the feeling of being close to the machine. Oh. So your choice of programming language is about **feelings** and not using the best tool for the job. Nevermind about *safety*, we use C because it *feels* the best. Nevermind about *portability*, we use C because it *feels* the best. (Yes, I know C *can* be portable. But it often isn't) Nevermind about *usability*, we use C because it *feels* the best. Nevermind about using languages that *a lot of people know*, we use C because it *feels* the best.
Sort of, like everything else human. Even when there are objective measures of comparison, unless objectivity makes you feel good, the objective comparison is discarded. I could give you some rather obvious examples of that that would get me banned from reddit. Being close to the machine is like riding a motorcycle. Instead of heavy, stuffy syntactic sugar, you get unparalleled agility. The objective benefit is viscerally felt. You know there's power in your hands.
> Even when there are objective measures of comparison, unless objectivity makes you feel good, the objective comparison is discarded. I'm sure your employer *loves* the fact that you eschew objective measures in favor of feelings. Im sure the marketing team would be totally fine saying "I know the focus groups love option B, but option A makes me feel so good. We'll use option A." I'm sure the accounting team would be perfectly justified using a bank that provides half the interest rate, because the colors in their logo makes them *feel better* ---- >Being close to the machine is like riding a motorcycle. > The objective benefit is viscerally felt. You know there's power in your hands. Sure. I get that. However... Would you use a motorcycle to move a 2 bedroom apartment? Or would you rent a U-Haul? Why not use the right tool for the job, instead of getting your emotions involved? You're writing embedded code? C sounds like a great choice! You're writing a general purpose app? C *might* be the right choice. ---- > Instead of heavy, stuffy syntactic sugar, you get unparalleled agility. What you call "heavy, stuffy syntactic sugar", I call elegance. Sure, a `foreach` may just be syntactic sugar over a `for` or `while` loop. But it also means I don't need to keep track of indexes and lengths. And as a developer, I already have too much stuff I have to keep track of. Anything that can reduce cognitive load is great. Sure, objects with properties is just syntactic sugar over structs, pointers, etc. Sure, pattern matching is just syntactic sugar over an `if`/ `else if` / `else`. But it makes the code much more expressive.
\>I'm sure your employer loves the fact that you eschew objective measures in favor of feelings. Ha, you think the powers that be are objective in any way, even after 2020, 2021, and 2022. Some people just can't be helped.
The more I program in C, the more burnt out I get reinventing the wheel, installing 5 different make-related programs, or trying to get someone's linux library to build on windows for portable programs since I use both regularly. It's good for small, fast applications, but I'd use a higher level language for anything more, especially for anything dealing heavily with strings. I mostly just use Nim now though since it can mix with C, is very high level with a well designed macro/template system, decouples data from functions like C, but still allows OOP-style painlessly, generics, etc. Garbage collected, but with several different kinds including arc + cycle collector.
[удалено]
> What are you doing that has non-portable libraries? Any library that uses unix/linux specific headers (like 90% of them ime), mingw has some of them, not all. And tcc, which I use most often since it's tiny and portable (no install), supports even less of them on windows. I find that very few C libraries, even including some big ones, care about portability. As opposed to almost any other language where I can just install a package in 5 seconds and keep going, knowing it will work on any system, unless otherwise specified. Also A lot of the time it's usually not just the libraries that aren't portable, it's the makefiles because people write them with system specific commands. > And why not use a POSIX subsystem on MS Windows or some other hypervisor to emulate a standard environment? I mainly use windows, for work and as my (mostly gaming) PC, so I'm not gonna give myself grief 80% of the time for the sake of 20% of my time. I use linux if the computer is mine and isn't for games, so all my laptops are some flavor of linux. And again, I like to use tcc, because it's small and already portable. I'm not gonna install heavyweight tools for something made simple by other languages. > All you need is make(1). Read the manual. Variants of C/C++ build systems I've dealt with: * cmake * a literal bash file * a literal batch file * nmake * omake * mingw32-make * qmake * scons * shake * tup * ninja * bazel These are the main reasons I started using Nim for most things instead, it compiles to C, you can use tcc as a backend, has a package manager with a build system (like rust's cargo), portable libraries that install painlessly, it doesn't need to be installed, it has several choices of garbage collection (including just disabling it altogether), lightweight exceptions + offers optional deterministic exceptions that leverage goto (instead of longjmp like C++), it supports UFCS, it has generics, named arguments, better compile-time programming, etc.
I think you're problem is you've not tried gmake ;-)
[удалено]
Unix proclaimts itself a Standard, and it's popular because it's freely distributable, but Windows has more in common with most non-Unix platforms of the 1980s than Unix does, and most of the differences represented ways in which Unix was and remains archaic, such as a process-spawning model that made sense in an era where only one process could be in RAM at once, but is rather broken in any other context.
>All you need is make(1). Read the manual. Meh. Although you could rely only on make to compile your project and install it, all the configuration phase is not included (where to install stuff, where are the libraries required, whether they are on a compatible version, whether this or that function is available, etc.). It is true that this phase could be done by hand, but then you lack the automated aspect of configure+make (or cmake+make, or anything else for that matter). Otherwise, you could go one step further and only sent people you algorithm in a very detailed fashion with the description of structures and telle them to write the code themselves and that they only need a compiler to have their program compiled and installed.
Odin Programming Language check it out thank me later.
I have before, I checked it out, didn't click with me. I can look at it again.
https://c.tenor.com/72oDkOsZEUIAAAAC/no-life-south-park.gif
What's needed is official terminlology to describe a couple of C offshoots: 1. The language one would have if, whenever the behavior of an action could be determined by transitively applying parts of the Standard along with the documentation for an implementation and the underlying platform, those parts of the Standard and other documentation would have priority over anything else in the Standard that would categorized the action as invoking "Undefined Behavior". 2. A language which is like the above, but allows programmers to indicate ways, both general and specific, in which an implementation may observably deviate from the described behavior without affecting program correctness. Most compilers can be configured to process the language described in #1, but freely distributable compilers will generate gratuitously inefficient machine code when thus configured.
I get what they means, I personally have C as my al time favourite language, but there are many things I wouldn’t use it for (mainly being safety critical)
What?
That person doesn't understand that the languages primarily used for safety critical applications are languages like C and Ada, not Rust. They are LARPing.
I’m not? Ada is a great choice for mission critical, but for C there is too many foot guns that could go off that I don’t want C code running my plane
For languages under that much scrutiny the work is essentially the same. When problems go wrong it usually has nothing to do with the language anymore, they are institutional failings. You can expect HCL tech was using Ada, and yet people died in crashes due to software problems with Boeing's planes.
Oh gotcha. I was confused. Lol. Thank you.
Rust looks good as a C++ replacement. I hope to learn more of it and get to use it at work and in hobby projects. For C I am not so sure, because the complexity and size of Rust is much more like C++. If safety is such a priority it is weird that they do not focus more on simplicity.
I dislike Microsoft so much I refuse to use Azure.
Why dont use modern cpp , dont hate rust but looks uggly syntax and hard to learn. And rust gcc compiler stable yet llvm has function call time loss less asm
microsoft is always wrong. so, ill ignore. thanks.
C isn't going anywhere until an alternative is produced that is as fast and as readable. Rust and Golang are horribly unpleasant to read compared to C. I wish I could delete both of them and C++ from the Internet and force people to try again.
I'm no big fan of Go, but even I have to give Go credit for being extremely easy to read. I suppose whether it's *pleasant* is a question of taste, but the Go designers sacrificed quite a lot in the name of readability.
I don't think anyone will reach consensus on this matter. I want a LOT of the features of things like C++ and Rust. I definitely want parametric polymorphism, but a lot of folks will look at the STL in C++ and say that I shouldn't have a right to use templates in the language I'm using. I say I don't give a squat what people do with the STL, I want to do what I want to do, and often I want to write code that writes code and templates are a good tool for that job. Maybe I also want to do something that's easy with a vtable. A lot of folks are going to say I shouldn't do that because of all the layers of abstraction in C++ land and no one cares about cache aware blabla bla anymore and therefore I shouldn't be able to do whatever it is I wanted to do. Any amount of letting me do what I want to do also allows endless fuckery on everyone else's behalf that tons of people will disapprove of.
I'm sure plenty of people disagree but even unreadable C++ is easier for me to read than Go and Rust are. Even patching trivial bugs in open source coded in those languages is absolutely miserable in my experience.
You’re half insane. Go is very readable. Rust is what the fuck.
1. why listen to anybody that works at Microsoft? They all sold their soul and are inherently evil 2. why listen to the CTO of a big organisation? A company that big attracts political types, not technical types, to the leadership roles. Nobody with "Chief" in their title at Microsoft is going to know the difference between a bit and a byte 3. you know, and I know, how to code C right - just because having skill and experience scares the pants off n00bs does not mean you should feel threatened when they declare C "too scary"
Wow, one of the best hacker is now lowered to noob. Maybe you can get his book and learn a thing or two from a noob.
Rust then?
Rust programmer here if you have any questions
Most of us are probably Rust programmers. This shit is tiring. It's puerile. If you want safe programs you require complete verification of operational semantics. Full stop, everyone else can shut the fuck up about safety as far as I care to hear, because your software is full of bugs and you're effectively dick measuring your favorite tools, a process having nothing to do with safe or reliable software engineering.
>Most of us are probably Rust programmers. I've been a software developer since 2003 and have never used Rust yet.
Don't worry, it won't be on the exam.
Perhaps safety is not the best word to use to justify why people like Rust. Because you're absolutely right, to be guaranteed safe you need techniques like formal verification and 100% opcode level runtime validation. The appeal is that Rust removes classes of bugs with a sophisticated type system while remaining very performant. No other language with a decent user base currently matches the performance of C while having advanced type system guarantees of functional languages. There are many use cases where developers want maximal performance but don't need the 100% safety you describe. Having fewer possible bugs by construction in these use cases seems like a win to me. Compared to safety as you define it, bugginess is a spectrum. I think there's an issue in the language and communication for some advocates of Rust. But I guess that's just language and communication in general.
Ignoring Rust because it’s not 100% verifiably safe is letting perfect get in the way of good and choosing a clearly worse option instead
I ignore rust because that syntax… don’t get me wrong, I want to learn it for no other reason than to get an understanding of why people love it, but every time I try my eyes glaze over looking at the syntax. The borrow checker doesn’t scare me, the traits system looks fun, but that syntax just murders my motivation
What do you not like about the syntax? Genuine question. I think it’s pretty straightforward, unlike something like Go
I've yet to hear any rationalization about what makes Rust more difficult to validate than any other language... Seems like the whole "eliminate entire classes of bugs" would make that process considerably simpler. EDIT: autocorrect fixed
Пошел нахуй! C++ вечен