But why do you think China will be the same after that? Today's China is nothing like Mao's China or the Imperial China from before that. It continues to change. Tomorrow's well-educated Chinese will ask for even more changes in their society.
US today is not like the US from 100 years ago. And tomorrow's China will not be today's China.
I am not worried about the Chinese. They are a practical people and mean well. I am only impressed about all the fresh-off-the-boat Chinese in US. They have all been humble, polite, gifted and hard-working.
Every dominant culture in history made its own mistakes imprinting itself on the world. The Chinese may too. But that's OK.
I am all in support of taking care of the homeless. However, San Francisco seems to get the least bang for the buck. They need a completely different strategy. Pity that with all the smart people in the area, they cannot come up with any effective solutions. I saw a documentary recently. Drug addicts, excrement on the street. Felt like third world than one of the richest areas in the world. I hope the documentary was not exaggerating. I haven't been there in a decade and that was for a conference. I just remember aggressive pan handling. The documentary said some conferences pulled out as well. They didn't feel safe, they said.
For decades, we talked about Knuth's literate programming. Jupyter is finally an open source tool that made it usable for everyone. There is no better way to explain the use of a library than making a Jupyter notebook available.
Most of my Python use lately is for one-off analytics with heavy libraries. Jupyter suits this workflow very well. IPython already has decent hooks for IDEs (PyCharm, Spyder), but I hope this gets even better.
Diet surveys are notoriously poor in reliability. They are lazy and just done because they cost little. They generate bad science. Self-reporting over long periods does not work, the surveys are not rigorously validated or are not broadly usable. The questions are often vague and people interpret them differently.
This does not apply just to this study but correlational studies in nutritional research as a whole. Nutritional research often and notoriously produces poorly replicable results that keep flipping back and forth and the enthusiastic coverage of these flips in popular media erodes public trust in the scientific method. Until full expert consensus is formed, these lazy studies should not be reported outside scholarly journals.
In that case, there is no such thing as true intelligence either. Your so called intelligence is nothing but a property of a very large graph network.
Your brain is a humongous network. Upto 500 trillion synapses. These so called deep learning networks that are all the rage today are still tiny in comparison, but do quite well for the size. Lets reserve judgment until we built as complex networks first. And we haven't even begun to give them other higher level properties of a biological network like the brain.
> predictions about things it has never experienced
The current ones already do that to a degree.
> based on first principles.
Those can be programmed. Yours were too - by evolution via natural selection.
> We may never be able to do that.
Unless we destroy the planet first, AI creation is inevitable. Just a question of when.
Yeah seriously. They have turned off features that were useful saying that an addon would address those better, and yet have added features that clearly belong in addons. Pocket was much better as an addon. I used to use it a lot, but stopped after it became a core feature. Browsers should not add third-party online services into their core functionality.
That said, I still stick with Firefox. Their general policy and values, however chaotic, inconsistent and confusing, are more aligned with open software than the rest.
Again, you did not read the article. https://ruudvanasseldonk.com/2... Rust compiler did not include bounds checking overhead (not function call overhead. Just as with C, you can also inline functions in Rust) in the machine code either.
There is no overhead. This is why Rust is different from all the other C/C++ alternatives that preceded it. This is what is meant by "zero cost abstractions". By using modern abstractions over the old, naive and primitive ones that directly translate in C, Rust has more information to do better compile time checks. But it keeps the runtime code exactly as lean as C compilers generate.
Quote: "All overhead is gone completely. What happened here? First of all, no loop is used to compute the inner product. The input slices have a fixed size of 12 elements, and despite the use of iterators, the compiler was able to unroll everything here. The element-wise computations are efficient too. There are 12 movslqs which load a value from the buffer and simultaneously widen it. There are 12 multiplications and 12 additions, 11 for the inner product, and one to add the delta after arithmetic shifting (sar) the sum right. Note that the coefficients are not even loaded inside the loop, they are kept in registers at all times. After the sample has been computed, it is stored simply with a mov. All bounds checks have been elided. The final three instructions handle control flow of the loop. Not a single instruction is redundant here, and I could not have written this better myself."
If C can be seen as a high-level assembler, so can Rust.
C is primitive, naive translation to machine code since its 70s bare bones constructs don't have enough information for the compiler to better understand your code. Modern languages like Rust benefit from decades of Computer Science research in compiler technology. Its newer constructs give more information to the compiler to perform static checks but strips these from runtime. To make C safer, you need additional frameworks that supply that metadata. But most don't use those or even know about them. And they are very tedious to use because they are bolt-ons.
Till now, modern languages generated good code, but they didn't stop there. They took it further and made the code even more concise and safer by including a few inexpensive runtime checks and not inexpensive garbage collection. But this meant that they were not strict C alternatives even if they were generally better general purpose languages.
Rust avoids all those enhancements in the core that cost anything and only keeps things that don't prevent it from generating C like machine code, while providing better safety and productivity at compile time. It is not as safe or concise and elegant as Haskell or OCaml code. But it eliminates the excuse that only C allows you to squeeze out every ounce of performance. Earlier, only C++ kept the strict principle of zero-overhead abstractions. But it has become so unwieldy that no one really understands all of C++. Rust is a cleaner re-imagining of C++ using modern design from ground up. There is nothing in Rust that prevents you from generating machine code as lean and light as C does.
You can however choose to forgo that and use higher abstractions. With Rust, you can write very high-level code like Scala or extremely low-level code for a micro-controller. The overhead is what you decide it should be.
This isn't about the baby. This is about the dads who keep walking off the cliff, all the same.
Quote: "Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
This is saying that there have been enough deaths that the canyon needs some guard rails - for child and adult alike. This is saying that simply warning people and posting signs has proven inadequate over 4 decades. Time for new measures.
Sigh. It isn't just junior programmers who keep shooting themselves in the foot, it is also the senior ones. It is their exploit-ridden code that makes the news, not a young man's college project.
My argument is: Your hammer is useful, but we found out that a lot of people are getting hurt using it, even experienced users. We know what we need to do to make it so that it does not hurt people. With some changes, it will be just as efficient, but safer. No, we don't need to dumb it down. This modern material is better and costs the same as your current one. Also weird: somehow, the users seem to think they can solve every problem with it. They even keep banging on screws. They think screwdrivers are for sissies. Anyway, there is this other hammer in the market with a rubberized grip.
Your response is: Nah! This is a classic design. It must always be like this, frozen in time, more or less. Users should just man up and blame themselves. Yeah we know; we made our hammer super slippery that it keep flying out of hands at the slightest distraction. But we won't provide a better grip. It is your job to find the right gloves if you need. Post alert signs. Wear helmets if you must, but that is your problem and choice. Join a special hammering class so that you can learn all complicated rules to measure humidity, sweat factor, swing speed, striking angle - things that increase the incidence of hammer incidents and oh mental exercises so that you stay alert and always on your toes. Hammering is for Jedis. We can't just put a grip and have it be safe for average Joes. We have a reputation to protect.
Again, what is this abstracting away? It outputs the exact same machine code as C compilers do. It is more mathematical. It is safer. It is more concise and readable. It is more explicit. It is better typed. Exactly, what is the complaint?
> people tried to abstract things away and then complain when their abstractions just won't work anymore.
Not sure what you have in mind. We are not talking about something like Haskell here, where abstract stuff is a goal onto itself, not the machine.
Cost free abstractions are good. There is no excuse in not having more of them available to reduce avoidable errors.
C control structures are abstractions. Why do you declare that we must stop adding further cost free abstractions to the toolbox? Is C some holy standard that must never be improved further? Is the risk of falling off arrays and strings so much more edgy, even when we now can avoid that at no cost? That way, we can call ourselves real men or women? This is like laughing at seat belts and air bags in the face of accident statistics.
No, accepting bitter empirical evidence for safety and employing safeguards is the mature, professional thing to do.
Math is abstract and eternal. C is a historical technology artifact from when programming language theory was in its infancy.
> if it's not broken don't try to fix it
When C enables more errors than every major non-scripting language (other than the assembler), it is broken. The response? Oh, it is just that you are not l33t enough child. Now run along.
The C community did not bother fixing it and instead rested on its laurels.
The language and compiler technology are two different things. The language has nothing to do with the machine. The language is a cognitive tool. It targets humans. The compiler targets the machine. You can absolutely have languages that prevent human lapses and errors while generating the same efficient machine code.
> These undefined behaviors are what C experts try to avoid.
Don't try to avoid them at personal level. Fix them, at the tool level. Else, people will choose better tools.
> Not learning why C works the way it is, makes a person a noob, not an expert.
C is just a tool. If it is not improving itself to handle the more complex problems the world provides, it will get discarded and people will look for other alternatives. It is a free world.
If C or C++ programmers want their investments to stay relevant, they have to innovate. But they have stagnated and others are picking the ball. The C/C++ communities are so lethargic that asking for even simple conveniences that do not impose any additional costs is too much. I think C and C++ will be generational things. Younger programmers will just move on to more modern, better designed tools. They won't put up with archaic ways of doing things.
I'll ignore the rest of the post because it is just frustration without arguments.
You sound like an old timer wistfully looking at some glorious past where you had a nice station.
The entire point of system design is to create tools that prevent errors. It should not take talent to do anything. We should take art and reduce it to a science.
If we know that people keep making certain errors, the solution is not to find the elite of the elite who have fewer cognitive lapses. It is to understand why the errors occur in the first place and eliminate them at the machine level, where we can reliably control things. This is system engineering.
Please don't be a craftsman. Be an engineer. Think like one.
"Civilization advances by extending the number of important operations which we can perform without thinking of them." - Alfred North
Make things easier so that we can advance to the next level of problems, rather than getting stuck in the old ones.
It generates the same machine code as C, except with safer and more concise constructs.
I would say that you are arguing that we learnt no better way to do things in the last 4-5 decades in programming language research in terms of generating safe and efficient machine code. That is just absurd. C is a dinosaur that exists mainly for legacy and compatibility reasons.
This is about being a luddite, hanging on to 45 year old way of doing things. This is not a religion. Let there be more Rust alternatives with other paradigms, not just the borrow checker. But it is time to wake up and catch up with modernity.
Again, read the Rust book, examine the machine code it generates and decide for yourself. If you really are smarter than an average programmer, you should pick up Rust in no time and take it for a spin on a small project. This is not mind-bending Haskell. It is easier than OCaml. All your machine awareness from C still carries over. You are just less likely to shoot your foot. Oh and C programmers do keep shooting their foot (which is the point of the article). They are like diabetics who don't often realize that they have and keep telling they feel perfectly fine.
Writing non-buggy code in Haskell is very different from writing non-buggy code in Assembler. Completely different strategies and paradigms.
Programming languages do significantly promote or reduce errors. You haven't even bothered to read the article (nor the Rust book). Yet you think you have an opinion.
Even experienced C programmers make errors that users of other languages simply don't make. You can have a lifetime of C experience. You will still make errors in C because it is an unsafe language by design. You can't eliminate all bugs, but you can eliminate entire classes of bugs by a more thoughtful language designs. We have learnt a lot in the decades since C about programming language design. You just haven't caught up.
If you think you are writing bug free code in C, it is only because either you are writing fairly simple code or your code has not been audited by a security expert.
You don't sound like you used any modern languages with sound type systems, let alone Rust.
Quotes from the article: "Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
"C language itself has fundamental, unfixed bugs that await the unwary"
"C comes with some worrisome baggage, undefined behaviors, and other weaknesses that lead to security flaws and vulnerable infrastructure."
These aren't my opinions. These are consensus positions of C experts. They still use C because they have to. Most don't.
> The only reason to use rust to write system code today is if it's ABI compatible with C.
Again, you don't understand Rust. Most C++ code today is better written in Rust.
> No argument for rust holds good unless rust can literally replace C
That's probably because you have not written any Rust code. You will like it, if you have some functional programming background. Else, it may take longer to understand what it brings to the table.
Rust does not have to replace C. C can stay C. But outside a very small selection of software that is best written in C, C is overused. Rust is a replacement for C in those areas.
> Nobody needs to learn rust
People just need to write non-buggy code and C is not helping. Rust is not the ultimate language. I can imagine better. And either Rust will further evolve or we will get other alternatives. But C is a dinosaur that only people who have invested decades of their lives and can't see beyond can love.
My main argument is not promoting Rust. It is about NOT using C, when it can be avoided. Too many people use C who should not be, for things that don't need C. I personally favor Nim, a somewhat obscure language and transpile it to C, over Rust. It better suits my needs. But I appreciate the amount of thought that has gone into Rust.
There will be a lot more expressive, high-performance languages coming out, thanks to LLVM making it easy to create them. These will replace both C and C++ in a number of areas.
> That was until someone pointed out that C++ was a fancy preprocessor
So what? C++ is a new language, even when it was written on top of C.
I like Nim and transpile it to C. I don't like to write raw C - too error prone, not enough productivity features. But Nim on top of C is fine. Likewise, there are plenty of languages (Elm) written on top of Node.js that are nothing like Javascript.
Ultimately, everything is machine code. That does not mean the programming experience is the same - not even close.
Where did you get that idea? Of course there will always be logic errors. Our tools can't read our minds. But at least let the compiler catch everything that can be caught. Rust isn't Haskell. As an impure language, it cannot reason as much. But it is heck of a lot better than the bare minimum C does, all while not imposing any costly abstractions.
I find the GPs reasoning here and elsewhere, that we should not have nice things because non-masochists are not L33t enough ("The advantage of C is that the incompetent coders fail early and obviously" - He seems to think of C users as sort of an upper caste of programming who should protect their position by keeping this hard), is silly. We should bring as much machine assistance as we can into our work.
> Rust does not turn a bad coder into a good coder.
The point of Rust is to allow good coders actually write better (not perfect) code. With C, good coders still manage to write bad code while thinking they are golden. That is the entire point of the article, which you seem to have glossed over.
Don't worry. No business coder is going to pick up Rust and start writing bad kernels and drivers. That won't happen.
Well, Julia is expected to be the next step forward for linear algebra projects that demand performance. We'll see how it will play out. Yes, Fortran code is everywhere.
Sigh. Yeah, these are "beliefs" most of the programming world shares: aka consensus.
Let me paste some quotes for you from the linked article:
"The C language is very powerful, widely used—particularly in the Linux kernel—and very dangerous. One of the Linux engineers outlines how developers can cope with the programming language's security weaknesses."
"C code runs quickly, but it has no safety belt. Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
"the C language itself has fundamental, unfixed bugs that await the unwary. "
"With its operational baggage and weak standard libraries, C contains a great deal of undefined behavior. "
"C comes with some worrisome baggage, undefined behaviors, and other weaknesses that lead to security flaws and vulnerable infrastructure."
Not talking about the use of C in kernels, drivers etc. C is good for that. However, C is widely used beyond that since C skills are widely available, even if it is not ideal for many projects.
I recall reading similar old research that a programmer can reliably maintain just around 10K LOC, regardless of the language. I am not sure how that number is effected by tool factors. I haven't looked up newer research either. This is the case for productivity.
Wonder what the results were for safety. I would expect Ada or Eiffel, which had more safety features to be less bug prone than say, C++98. But this is to be determined empirically since the results can be counter-intuitive.
Haskell should not have much in runtime errors once it compiles. OCaml and Rust should be a little less reliable since they are not pure. I wonder how Mozilla fared on bug counts with Quantum, relative to their earlier C++ implementation.
Slashdot Mirror
You may be right about the exponential tech-up.
But why do you think China will be the same after that? Today's China is nothing like Mao's China or the Imperial China from before that. It continues to change. Tomorrow's well-educated Chinese will ask for even more changes in their society.
US today is not like the US from 100 years ago. And tomorrow's China will not be today's China.
I am not worried about the Chinese. They are a practical people and mean well. I am only impressed about all the fresh-off-the-boat Chinese in US. They have all been humble, polite, gifted and hard-working.
Every dominant culture in history made its own mistakes imprinting itself on the world. The Chinese may too. But that's OK.
I am all in support of taking care of the homeless.
However, San Francisco seems to get the least bang for the buck.
They need a completely different strategy. Pity that with all the smart people in the area, they cannot come up with any effective solutions.
I saw a documentary recently. Drug addicts, excrement on the street. Felt like third world than one of the richest areas in the world. I hope the documentary was not exaggerating. I haven't been there in a decade and that was for a conference. I just remember aggressive pan handling. The documentary said some conferences pulled out as well. They didn't feel safe, they said.
For decades, we talked about Knuth's literate programming. Jupyter is finally an open source tool that made it usable for everyone.
There is no better way to explain the use of a library than making a Jupyter notebook available.
Most of my Python use lately is for one-off analytics with heavy libraries. Jupyter suits this workflow very well.
IPython already has decent hooks for IDEs (PyCharm, Spyder), but I hope this gets even better.
Diet surveys are notoriously poor in reliability.
They are lazy and just done because they cost little. They generate bad science.
Self-reporting over long periods does not work, the surveys are not rigorously validated or are not broadly usable. The questions are often vague and people interpret them differently.
This does not apply just to this study but correlational studies in nutritional research as a whole.
Nutritional research often and notoriously produces poorly replicable results that keep flipping back and forth and the enthusiastic coverage of these flips in popular media erodes public trust in the scientific method.
Until full expert consensus is formed, these lazy studies should not be reported outside scholarly journals.
In that case, there is no such thing as true intelligence either. Your so called intelligence is nothing but a property of a very large graph network.
Your brain is a humongous network. Upto 500 trillion synapses.
These so called deep learning networks that are all the rage today are still tiny in comparison, but do quite well for the size. Lets reserve judgment until we built as complex networks first.
And we haven't even begun to give them other higher level properties of a biological network like the brain.
> predictions about things it has never experienced
The current ones already do that to a degree.
> based on first principles.
Those can be programmed. Yours were too - by evolution via natural selection.
> We may never be able to do that.
Unless we destroy the planet first, AI creation is inevitable. Just a question of when.
Yeah seriously. They have turned off features that were useful saying that an addon would address those better, and yet have added features that clearly belong in addons. Pocket was much better as an addon. I used to use it a lot, but stopped after it became a core feature. Browsers should not add third-party online services into their core functionality.
That said, I still stick with Firefox. Their general policy and values, however chaotic, inconsistent and confusing, are more aligned with open software than the rest.
Again, you did not read the article.
https://ruudvanasseldonk.com/2...
Rust compiler did not include bounds checking overhead (not function call overhead. Just as with C, you can also inline functions in Rust) in the machine code either.
There is no overhead. This is why Rust is different from all the other C/C++ alternatives that preceded it. This is what is meant by "zero cost abstractions".
By using modern abstractions over the old, naive and primitive ones that directly translate in C, Rust has more information to do better compile time checks. But it keeps the runtime code exactly as lean as C compilers generate.
Quote:
"All overhead is gone completely. What happened here? First of all, no loop is used to compute the inner product. The input slices have a fixed size of 12 elements, and despite the use of iterators, the compiler was able to unroll everything here. The element-wise computations are efficient too. There are 12 movslqs which load a value from the buffer and simultaneously widen it. There are 12 multiplications and 12 additions, 11 for the inner product, and one to add the delta after arithmetic shifting (sar) the sum right. Note that the coefficients are not even loaded inside the loop, they are kept in registers at all times. After the sample has been computed, it is stored simply with a mov. All bounds checks have been elided. The final three instructions handle control flow of the loop. Not a single instruction is redundant here, and I could not have written this better myself."
If C can be seen as a high-level assembler, so can Rust.
C is primitive, naive translation to machine code since its 70s bare bones constructs don't have enough information for the compiler to better understand your code. Modern languages like Rust benefit from decades of Computer Science research in compiler technology. Its newer constructs give more information to the compiler to perform static checks but strips these from runtime. To make C safer, you need additional frameworks that supply that metadata. But most don't use those or even know about them. And they are very tedious to use because they are bolt-ons.
Till now, modern languages generated good code, but they didn't stop there. They took it further and made the code even more concise and safer by including a few inexpensive runtime checks and not inexpensive garbage collection. But this meant that they were not strict C alternatives even if they were generally better general purpose languages.
Rust avoids all those enhancements in the core that cost anything and only keeps things that don't prevent it from generating C like machine code, while providing better safety and productivity at compile time. It is not as safe or concise and elegant as Haskell or OCaml code. But it eliminates the excuse that only C allows you to squeeze out every ounce of performance. Earlier, only C++ kept the strict principle of zero-overhead abstractions. But it has become so unwieldy that no one really understands all of C++. Rust is a cleaner re-imagining of C++ using modern design from ground up. There is nothing in Rust that prevents you from generating machine code as lean and light as C does.
You can however choose to forgo that and use higher abstractions. With Rust, you can write very high-level code like Scala or extremely low-level code for a micro-controller. The overhead is what you decide it should be.
http://pramode.in/2018/02/20/p...
This isn't about the baby.
This is about the dads who keep walking off the cliff, all the same.
Quote: "Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
This is saying that there have been enough deaths that the canyon needs some guard rails - for child and adult alike.
This is saying that simply warning people and posting signs has proven inadequate over 4 decades. Time for new measures.
Sigh. It isn't just junior programmers who keep shooting themselves in the foot, it is also the senior ones. It is their exploit-ridden code that makes the news, not a young man's college project.
My argument is: Your hammer is useful, but we found out that a lot of people are getting hurt using it, even experienced users. We know what we need to do to make it so that it does not hurt people. With some changes, it will be just as efficient, but safer. No, we don't need to dumb it down. This modern material is better and costs the same as your current one. Also weird: somehow, the users seem to think they can solve every problem with it. They even keep banging on screws. They think screwdrivers are for sissies. Anyway, there is this other hammer in the market with a rubberized grip.
Your response is: Nah! This is a classic design. It must always be like this, frozen in time, more or less. Users should just man up and blame themselves. Yeah we know; we made our hammer super slippery that it keep flying out of hands at the slightest distraction. But we won't provide a better grip. It is your job to find the right gloves if you need. Post alert signs. Wear helmets if you must, but that is your problem and choice. Join a special hammering class so that you can learn all complicated rules to measure humidity, sweat factor, swing speed, striking angle - things that increase the incidence of hammer incidents and oh mental exercises so that you stay alert and always on your toes. Hammering is for Jedis. We can't just put a grip and have it be safe for average Joes. We have a reputation to protect.
https://ruudvanasseldonk.com/2...
Again, what is this abstracting away? It outputs the exact same machine code as C compilers do. It is more mathematical. It is safer. It is more concise and readable. It is more explicit. It is better typed. Exactly, what is the complaint?
> people tried to abstract things away and then complain when their abstractions just won't work anymore.
Not sure what you have in mind. We are not talking about something like Haskell here, where abstract stuff is a goal onto itself, not the machine.
Cost free abstractions are good. There is no excuse in not having more of them available to reduce avoidable errors.
C control structures are abstractions. Why do you declare that we must stop adding further cost free abstractions to the toolbox? Is C some holy standard that must never be improved further? Is the risk of falling off arrays and strings so much more edgy, even when we now can avoid that at no cost? That way, we can call ourselves real men or women? This is like laughing at seat belts and air bags in the face of accident statistics.
No, accepting bitter empirical evidence for safety and employing safeguards is the mature, professional thing to do.
And C is a very lousy language to express math.
Math is abstract and eternal.
C is a historical technology artifact from when programming language theory was in its infancy.
> if it's not broken don't try to fix it
When C enables more errors than every major non-scripting language (other than the assembler), it is broken.
The response? Oh, it is just that you are not l33t enough child. Now run along.
The C community did not bother fixing it and instead rested on its laurels.
Once again, you refused to read the article.
The language and compiler technology are two different things.
The language has nothing to do with the machine. The language is a cognitive tool. It targets humans.
The compiler targets the machine.
You can absolutely have languages that prevent human lapses and errors while generating the same efficient machine code.
> These undefined behaviors are what C experts try to avoid.
Don't try to avoid them at personal level. Fix them, at the tool level. Else, people will choose better tools.
> Not learning why C works the way it is, makes a person a noob, not an expert.
C is just a tool. If it is not improving itself to handle the more complex problems the world provides, it will get discarded and people will look for other alternatives. It is a free world.
If C or C++ programmers want their investments to stay relevant, they have to innovate. But they have stagnated and others are picking the ball. The C/C++ communities are so lethargic that asking for even simple conveniences that do not impose any additional costs is too much. I think C and C++ will be generational things. Younger programmers will just move on to more modern, better designed tools. They won't put up with archaic ways of doing things.
I'll ignore the rest of the post because it is just frustration without arguments.
You sound like an old timer wistfully looking at some glorious past where you had a nice station.
The entire point of system design is to create tools that prevent errors. It should not take talent to do anything. We should take art and reduce it to a science.
If we know that people keep making certain errors, the solution is not to find the elite of the elite who have fewer cognitive lapses. It is to understand why the errors occur in the first place and eliminate them at the machine level, where we can reliably control things. This is system engineering.
Please don't be a craftsman. Be an engineer. Think like one.
"Civilization advances by extending the number of important operations which we can perform without thinking of them." - Alfred North
Make things easier so that we can advance to the next level of problems, rather than getting stuck in the old ones.
> Now if you're telling me rust does exactly that, it is just another dialect of C.
That is not at all what I am telling you.
https://ruudvanasseldonk.com/2...
It generates the same machine code as C, except with safer and more concise constructs.
I would say that you are arguing that we learnt no better way to do things in the last 4-5 decades in programming language research in terms of generating safe and efficient machine code. That is just absurd. C is a dinosaur that exists mainly for legacy and compatibility reasons.
This is about being a luddite, hanging on to 45 year old way of doing things. This is not a religion. Let there be more Rust alternatives with other paradigms, not just the borrow checker. But it is time to wake up and catch up with modernity.
Again, read the Rust book, examine the machine code it generates and decide for yourself. If you really are smarter than an average programmer, you should pick up Rust in no time and take it for a spin on a small project. This is not mind-bending Haskell. It is easier than OCaml. All your machine awareness from C still carries over. You are just less likely to shoot your foot. Oh and C programmers do keep shooting their foot (which is the point of the article). They are like diabetics who don't often realize that they have and keep telling they feel perfectly fine.
Writing non-buggy code in Haskell is very different from writing non-buggy code in Assembler. Completely different strategies and paradigms.
Programming languages do significantly promote or reduce errors. You haven't even bothered to read the article (nor the Rust book). Yet you think you have an opinion.
Even experienced C programmers make errors that users of other languages simply don't make. You can have a lifetime of C experience. You will still make errors in C because it is an unsafe language by design. You can't eliminate all bugs, but you can eliminate entire classes of bugs by a more thoughtful language designs. We have learnt a lot in the decades since C about programming language design. You just haven't caught up.
If you think you are writing bug free code in C, it is only because either you are writing fairly simple code or your code has not been audited by a security expert.
You don't sound like you used any modern languages with sound type systems, let alone Rust.
Quotes from the article:
"Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
"C language itself has fundamental, unfixed bugs that await the unwary"
"C comes with some worrisome baggage, undefined behaviors, and other weaknesses that lead to security flaws and vulnerable infrastructure."
These aren't my opinions. These are consensus positions of C experts. They still use C because they have to. Most don't.
> The only reason to use rust to write system code today is if it's ABI compatible with C.
Again, you don't understand Rust. Most C++ code today is better written in Rust.
> No argument for rust holds good unless rust can literally replace C
That's probably because you have not written any Rust code. You will like it, if you have some functional programming background. Else, it may take longer to understand what it brings to the table.
Rust does not have to replace C. C can stay C. But outside a very small selection of software that is best written in C, C is overused. Rust is a replacement for C in those areas.
> Nobody needs to learn rust
People just need to write non-buggy code and C is not helping. Rust is not the ultimate language. I can imagine better. And either Rust will further evolve or we will get other alternatives. But C is a dinosaur that only people who have invested decades of their lives and can't see beyond can love.
My main argument is not promoting Rust. It is about NOT using C, when it can be avoided. Too many people use C who should not be, for things that don't need C. I personally favor Nim, a somewhat obscure language and transpile it to C, over Rust. It better suits my needs. But I appreciate the amount of thought that has gone into Rust.
There will be a lot more expressive, high-performance languages coming out, thanks to LLVM making it easy to create them. These will replace both C and C++ in a number of areas.
> Every rocket scientist/insert one of your choice knows that C makes it possible to exactly build what they want as precisely as possible.
Scientists avoid C every chance they get. Too much plumbing. They prefer Fortran, Julia, Python, MATLAB etc.
> than rely on some elegant high level construction that will clearly just not work on every piece of hardware.
Rust just leaves that to LLVM.
> The first rust implementation was not written in rust, but in C++ https://github.com/rust-lang/r...
Actually, it was first written in OCaml. This was before it hit GitHub.
> You need to learn a lot of things before you come here and start trashing other people about your made up knowledge on what C is and isn't.
And you need to read the online Rust book before you understand what Rust is. Right now you don't.
> That was until someone pointed out that C++ was a fancy preprocessor
So what? C++ is a new language, even when it was written on top of C.
I like Nim and transpile it to C. I don't like to write raw C - too error prone, not enough productivity features. But Nim on top of C is fine.
Likewise, there are plenty of languages (Elm) written on top of Node.js that are nothing like Javascript.
Ultimately, everything is machine code. That does not mean the programming experience is the same - not even close.
You haven't made a point.
> Your assumption that all bugs are so obvious
Where did you get that idea? Of course there will always be logic errors. Our tools can't read our minds. But at least let the compiler catch everything that can be caught. Rust isn't Haskell. As an impure language, it cannot reason as much. But it is heck of a lot better than the bare minimum C does, all while not imposing any costly abstractions.
I find the GPs reasoning here and elsewhere, that we should not have nice things because non-masochists are not L33t enough ("The advantage of C is that the incompetent coders fail early and obviously" - He seems to think of C users as sort of an upper caste of programming who should protect their position by keeping this hard), is silly. We should bring as much machine assistance as we can into our work.
> Rust does not turn a bad coder into a good coder.
The point of Rust is to allow good coders actually write better (not perfect) code. With C, good coders still manage to write bad code while thinking they are golden. That is the entire point of the article, which you seem to have glossed over.
Don't worry. No business coder is going to pick up Rust and start writing bad kernels and drivers. That won't happen.
I suggest you actually read the Rust book.
https://doc.rust-lang.org/stab...
It is a good read even if you don't plan to ever use it.
For someone who has clearly not given Rust a proper look, you have way too strong opinions.
Well, Julia is expected to be the next step forward for linear algebra projects that demand performance. We'll see how it will play out.
Yes, Fortran code is everywhere.
Sigh. Yeah, these are "beliefs" most of the programming world shares: aka consensus.
Let me paste some quotes for you from the linked article:
"The C language is very powerful, widely used—particularly in the Linux kernel—and very dangerous. One of the Linux engineers outlines how developers can cope with the programming language's security weaknesses."
"C code runs quickly, but it has no safety belt. Even if you're a C expert, as are most of the Linux kernel developers, you can still make killer blunders."
"the C language itself has fundamental, unfixed bugs that await the unwary. "
"With its operational baggage and weak standard libraries, C contains a great deal of undefined behavior. "
"C comes with some worrisome baggage, undefined behaviors, and other weaknesses that lead to security flaws and vulnerable infrastructure."
Not talking about the use of C in kernels, drivers etc. C is good for that.
However, C is widely used beyond that since C skills are widely available, even if it is not ideal for many projects.
I recall reading similar old research that a programmer can reliably maintain just around 10K LOC, regardless of the language.
I am not sure how that number is effected by tool factors. I haven't looked up newer research either.
This is the case for productivity.
Wonder what the results were for safety.
I would expect Ada or Eiffel, which had more safety features to be less bug prone than say, C++98. But this is to be determined empirically since the results can be counter-intuitive.
Haskell should not have much in runtime errors once it compiles. OCaml and Rust should be a little less reliable since they are not pure. I wonder how Mozilla fared on bug counts with Quantum, relative to their earlier C++ implementation.