Arthur T Knackerbracket has processed the following story:
Mark Russinovich, the chief technology office (CTO) of Microsoft Azure, says developers should avoid using C or C++ programming languages in new projects and instead use Rust because of security and reliability concerns.
Rust, which hit version 1.0 in 2020 and was born at Mozilla, is now being used within the Android Open Source Project (AOSP), at Meta, at Amazon Web Services, at Microsoft for parts of Windows and Azure, in the Linux kernel, and in many other places.
Engineers value its "memory safety guarantees", which reduce the need to manually manage a program's memory and, in turn, cut the risk of memory-related security flaws burdening big projects written in "memory unsafe" C or C++, which includes Chrome, Android, the Linux kernel, and Windows.
Microsoft drove home this point in 2019 after revealing 70% of its patches in the past 12 years were fixes for memory safety bugs due largely to Windows being written mostly in C and C++. Google's Chrome team weighed in with its own findings in 2020, revealing that 70% of all serious security bugs in the Chrome codebase were memory management and safety bugs. It's written mostly in C++.
"Unless something odd happens, it [Rust] will make it into 6.1," wrote Torvalds, seemingly ending a long-running debate over Rust becoming a second language to C for the Linux kernel.
The Azure CTO's only qualifier about using Rust is that it was preferable over C and C+ for new projects that require a non-garbage-collected (GC) language. GC engines handle memory management. Google's Go is a garbage-collection language, while the Rust project promotes that Rust is not. AWS engineers like Rust over Go because of the efficiencies it offers without GC.
"Speaking of languages, it's time to halt starting any new projects in C/C++ and use Rust for those scenarios where a non-GC language is required. For the sake of security and reliability. the industry should declare those languages as deprecated," Russinovich wrote.
Rust is a promising replacement for C and C++, particularly for systems-level programming, infrastructure projects, embedded software development, and more – but not everywhere and not in all projects.
[...] Rust shouldn't be viewed as a silver bullet for all the bad habits developers practice when coding in C or C++.
Bob Rudis, a cybersecurity researcher for GreyNoise Intelligence, who was formerly with Rapid7, noted developers can carry across the same bad security habits to Rust.
"As others have said, you can write "safely" in C or C++, but it's much harder, no matter what dialect you use than it is in Rust. Mind you, you can still foul up security in Rust, but it does avoid a lot of old memory problems."
Related Stories
News and Advice on the World's Latest Innovations:
The Rust in Linux debate is over. The implementation has begun. In an email conversation, Linux's creator Linus Torvalds, told me, "Unless something odd happens, it [Rust] will make it into 6.1."
The Rust programming language entering the Linux kernel has been coming for some time. At the 2020 Linux Plumbers Conference, developers started considering using the Rust language for new Linux inline code. Google, which supports Rust for developing Android -- itself a Linux distro -- began pushing for Rust in the Linux kernel in April 2021.
As Wedson Almeida Filho of Google's Android Team said at the time, "We feel that Rust is now ready to join C as a practical language for implementing the kernel. It can help us reduce the number of potential bugs and security vulnerabilities in privileged code while playing nicely with the core kernel and preserving its performance characteristics."
It took a while to convince the top Linux kernel developers of this. There were concerns about non-standard Rust extensions being needed to get it to work in Linux. For instance, with the new Rust Linux NVMe driver, over 70 extensions needed to be made to Rust to get it working. But, Torvalds had told me in an earlier interview, "We've been using exceptions to standard C for decades."
This was still an issue at the invitation-only Linux Kernel Maintainers Summit. But, in the end, it was decided that Rust is well enough supported in the Clang -- the C language family compiler front end -- to move forward. Besides, as Torvalds had said earlier, "Clang does work, so merging Rust would probably help and not hurt the kernel."
[...] Now, Torvalds warns in this first release, Rust will "just have the core infrastructure (i.e. no serious use case yet)." But, still, this is a major first step for Rust and Linux.
A long-standing coding choice has seen an unexpected rise in popularity, according to one tracker of programming languages:
Software-testing firm Tiobe, which maintains a monthly tracker of the popularity of the vast array of programming languages available to software developers, has picked C++ as its programming language of 2022.
Despite it being placed third in Tiobe's January 2023 index, the popularity of C++ rose faster than all other languages last year, up by 4.26% compared with January 2022, the company said.
Runners-up this year were C, the second most popular language, which grew in popularity by 3.82%, and Python, the top language, which grew by 2.78%. Having fallen from third, Java is now in fourth place, growing 1.55%.
[...] [Tiobe CEO Paul] Jensen also notes that C++ rival Rust entered the top 20 again (being ranked at number 26 one year ago), but says that "this time it seems to be for real", suggesting it could now hold a stable position in the top 20.
Rust's profile shot up during the past year after it was officially adopted for the Linux kernel version 6.1, clearing its way for drivers to be written in Rust.
Previously:
Ironically: It's Time to Stop Using C and C++ for New Projects, Says Microsoft Azure CTO
(Score: 4, Offtopic) by bzipitidoo on Saturday September 24 2022, @12:39AM (37 children)
Deprecate C/C++?!?
So the thousands of libraries that are written in C or C++ will all be ported to Rust? Same with device drivers, Xwindows and Wayland, and all the killer apps? Rust will be the native language for making a system call? gcc and clang will be replaced with grust and rustlang?
Um, say, is Firefox ported to Rust yet?
(Score: 5, Funny) by Anonymous Coward on Saturday September 24 2022, @12:45AM (1 child)
All the legacy software will be left to rot, while everything else Rusts.
(Score: 5, Funny) by bzipitidoo on Saturday September 24 2022, @03:11AM
gcc will be replaced with grr.
(Score: 2) by RS3 on Saturday September 24 2022, @01:15AM (10 children)
How about https://c2rust.com [c2rust.com]
(Score: 4, Informative) by maxwell demon on Saturday September 24 2022, @05:31AM (9 children)
That tool turns simple, readable C code into unreadable mess.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2) by RS3 on Saturday September 24 2022, @07:03AM (5 children)
Hmm. I wonder what it does with messy unreadable input.
Can it be fixed? Or are there any better code translators out there?
(Score: 4, Insightful) by KritonK on Saturday September 24 2022, @08:18AM (1 child)
I don't know Rust, but the translated code seems to be written in some sort of C compatibility mode that should not be used when programming in Rust. I'm sure that proper Rust integers are not declared as "libc::c_int", Rust arrays are declared as such and not accessed à la C via pointers, and that "unsafe" keyword probably means that the translated Rust code is just as (un)safe as the original C code.
The compiled code is probably identical to the compiled C code, so that it can be directly callable from C. If so, this means that the translated code combines the disadvantages of Rust with the disadvantages of C! Still, in the far distant future, when C compilers are no longer available, the translator will be a way to maintain legacy C code.
(Score: 5, Insightful) by maxwell demon on Saturday September 24 2022, @01:13PM
Given that there are still COBOL compilers available today, I suspect by the time C compilers are no longer available, Rust will be utterly outdated as well.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 2, Insightful) by Anonymous Coward on Saturday September 24 2022, @01:19PM
That's where perl comes from...
(Score: 1, Touché) by Anonymous Coward on Sunday September 25 2022, @07:55PM (1 child)
I'll never understand why every language needs to fucking change the for-loop syntax. Just leave it. Do something actually useful.
(Score: 2) by DannyB on Monday September 26 2022, @03:29PM
Clojure does away with the for loop. You just use recursion instead. Yes, really.
The lower I set my standards the more accomplishments I have.
(Score: 3, Funny) by Thexalon on Saturday September 24 2022, @10:37AM
So perfect for the International Obfuscated Rust Code Contest? I mean, if that's going to be the language of the future, let's have fun with it!
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by turgid on Saturday September 24 2022, @05:48PM (1 child)
f2c turns an unreadable FORTRAN mess into an unreadable C nightmare. So there.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 1, Interesting) by Anonymous Coward on Sunday September 25 2022, @07:57PM
Then there's f2c2rust, put it through google translate, and back again. Compile, ship.
(Score: 5, Interesting) by JoeMerchant on Saturday September 24 2022, @01:18AM
Yeppers, they got what they think is an auto-Rust wrapper for C++ libraries, and they're willing to sell you a subscription to their wrapped libraries at a very reasonable price that they're sure you can afford.
Once in a rare while, I wonder if I should "grow beyond" this C++ thing I've been doing since 1996-ish. When M$ comes out and declares "C++ is dead, it's time to move on!" I know I'm doing the right thing by staying with it.
Also, took a brief detour through Micropython for the Raspberry Pi Pico recently - lots of fun, very easy to develop in, until... you want to use both cores? Um, yeah, there's this thing with the memory manager when you fire up the 2nd thread, and sometimes you can get past it with some manual garbage collection.... yeah, and sometimes you can't. The Thonny / Micropython development environment is very easy to use, when you're doing the things it does well. When you start coloring outside the lines? Nope, that's when you need the power of the C++ dev environment, which - after you get past the toolchain setup pains - is actually very much more powerful with a lot more libraries ready to do a lot more things than are presently possible in Python on the Pico. It will get there, someday, but by then what will C++ be doing that Micropython still hasn't quite caught up to yet?
🌻🌻 [google.com]
(Score: 3, Insightful) by epitaxial on Saturday September 24 2022, @03:07PM
All the low power devices that don't have resources to build rust will have to be cross compiled.
(Score: 5, Insightful) by bart9h on Saturday September 24 2022, @03:18PM (20 children)
"Stop using C and C++ FOR NEW PROJECTS" is very different from completely eradicating C and C++.
(Score: 2) by JoeMerchant on Saturday September 24 2022, @05:51PM (18 children)
I don't know about the rest of the world, but I am most often paid to do new things, things that haven't been digested into libraries for multiple higher level languages yet. I mean, sure I leverage lots and lots of existing stuff, but it seems that 5-10% of what I am doing just isn't available in library calls yet.
What this means is that when I use a higher level language like Python or whatever, I inevitably end up having to figure out how to write certain modules of my code in C++ or C, or suffer 100:1 slowdowns inherent in the so called superior language. Yes, it's higher level, but the only reason the whole thing isn't 100x slower than C is because it is calling C and C++ modules for everything that would slow it down.
When you are writing in Python, you are actually calling a collection of C and C++ submodules, I assume Rust is much the same.
🌻🌻 [google.com]
(Score: 3, Insightful) by sgleysti on Saturday September 24 2022, @08:52PM (14 children)
I'm pretty sure Rust compiles to machine language.
At my last job, I had to take some researcher's MATLAB code for processing a certain kind of data and make it run in robust and automated fashion within certain time constraints in GNU Octave. After reorganizing the code a bit and making it run in Octave, I spent some quality time with the profiler and ended up writing several large, slow functions in C++ against Octave's API. I should note that MATLAB has a just in time compiler, while Octave does not.
To this day, I think that interpreted languages are wasteful for anything that runs often. They're ok for prototyping, running quick calculations, and otherwise playing around. But if your code needs to run, why not compile to machine language?
(Score: 3, Insightful) by JoeMerchant on Saturday September 24 2022, @09:41PM (12 children)
Yes, makes sense that the Linux kernel would use a compiled language, so it _could_ handle that 5-10% of my code that needs to be custom, what remains to be seen is if Microsoft's auto translation of "all the things" really covers my library calls that constitute 90-95% of my stuff.
I led a team that did a Matlab to C++ translation, and after some profiler time we found an extra (unnecessary) level in a nested loop that resulted in about 100x speedup of the code... Language doesn't help much when your algorithms are intentionally wasting time...
🌻🌻 [google.com]
(Score: 2) by turgid on Sunday September 25 2022, @09:24AM (11 children)
Kernel code has to be compiled for performance and timing reasons, and also to have complete access to all the hardware. An interpreter implies all sorts of overhead. You could have an interpreter in the kernel, but underneath it there would have to be some basic functionality in machine code to make things like paging and virtual memory work, to implement the scheduling and device drivers and so on. Typically, in kernel code, there are all sorts of constraints that you don't have in user-land coding. For example, in the days of 32-bit CPUs (and many embedded systems use 32-bit ARMs these days) when memory pages were 4k bytes, you were very limited in the amount of stack each function or each thread could have. Basically, it had to fit in one 4k page. The Linux kernel build system checks your code for this and spits out an error if you exceed the bounds. You could write an interpreter for something that would fit in there. It would have to be something simple like FORTH or maybe a very tiny BASIC like the 8-bit micros from 40 years ago. The philosophy of the kernel is that it should be small and simple and provide the bare minimum. All the complicated stuff should be in user land, where processes are isolated from each other, memory is protected and virtual, things can be run without root privileges, stacks and heaps can be megabytes in size, the OS cleans up after your process when it terminates etc.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by JoeMerchant on Sunday September 25 2022, @12:35PM (10 children)
You are also describing my impression of Python in ML/AI applications: it has to have compiled modules (C, Fortran, whatever) underneath, or you will be waiting for years instead of days for your advanced models to train.
🌻🌻 [google.com]
(Score: 2) by turgid on Sunday September 25 2022, @12:46PM (9 children)
Correct. Interpreters add a significant overhead. Try writing one yourself to see how much. I once wrote a very simple interpreter, an "emulator" for an imaginary CPU whose instruction set I made up myself. I wrote it in C. It ran at about 8 MIPS on a 1.67GHz superscalar machine.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by JoeMerchant on Sunday September 25 2022, @03:13PM (8 children)
Oh, c'mon, I remember the Java sales pitches of the late '90s: it will compile to byte-code. We will have byte-code interpreters in silicon. Even today, aren't they pitching JIT byte code compilation and optimization as the most efficient possible solution (for a very particular problem space...)?
🌻🌻 [google.com]
(Score: 2) by turgid on Sunday September 25 2022, @04:26PM (7 children)
A bytecode interpreter in silicon is called a CPU :-) To be fair, there are apparently some corner cases that a JIT can do better than a standard compiler through feedback from the running program. Or at least, there were claims some years ago. I meant to write a re-compiler for my imaginary CPU to translate the machine code into C source, and then see how much faster it is. Hey. there's an idea for a little hobby project!
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by JoeMerchant on Sunday September 25 2022, @05:15PM (6 children)
>re-compiler for my imaginary CPU to translate the machine code into C source, and then see how much faster it is. Hey. there's an idea for a little hobby project!
A carefully selected University might just give you a PhD for that, unless something comes up that they need you to do instead to secure some grant....
🌻🌻 [google.com]
(Score: 2) by turgid on Sunday September 25 2022, @05:44PM (5 children)
Really? I can think of a completely trivial solution that ticks the box. It might not be optimal... But I think a certain Farbice Bellard of mega-super-intelligence and qemu fame might already have invented it and perfected it many years ago.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Funny) by JoeMerchant on Sunday September 25 2022, @06:21PM (4 children)
Could be, I disengaged from the theory long ago...
Now, when you say "imaginary CPU" that's where you become PhD eligible, since you can always imagine a CPU that hasn't existed before, and therefore your PhD will be original :-P
🌻🌻 [google.com]
(Score: 2) by turgid on Sunday September 25 2022, @06:41PM (3 children)
It was an ungodly mix of SPARC and ARM, FYI.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Interesting) by JoeMerchant on Tuesday September 27 2022, @01:58AM (2 children)
For my Masters' Thesis in 1989 I essentially built the processor from the PS3: Common Motorola CPU for a central controller with an array of 8 DSPs for the "heavy lifting."
🌻🌻 [google.com]
(Score: 2) by turgid on Tuesday September 27 2022, @11:49AM (1 child)
Cool!
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Funny) by JoeMerchant on Tuesday September 27 2022, @02:37PM
When they announced the architecture, some 15+ years later, I was like: "Well, it was obvious to me, what took everyone else so long?!!"
Side note: although I bought the parts and started breadboarding the actual thing, people from my advisor to other professors and other MS/PhD candidates kept saying "you know, you don't have to actually build one to get your degree...." I eventually listened to them after about a semester and a half.
🌻🌻 [google.com]
(Score: 0) by Anonymous Coward on Sunday September 25 2022, @08:06PM
A large part of the skill of leveraging high level languages such as MATLAB is to jack-knife your problem into things they are supremely fast at. In MATLAB, you're a fool if you're not using it as a wrapper to the hand-optimized assembly math libraries. It's a fantastic tool and I only resent that it costs so much, but it's a tool you have to learn. Think of it as a musical instrument like a piano and using it to record a track a single line at a time. Wrong. Play all the lines at the same time. Right.
(Score: 2) by bart9h on Saturday September 24 2022, @09:50PM (2 children)
No, Rust is not a higher level language. It's a system language, compiled directly to assembly. It's pretty much at the same level of C or C++.
(Score: 2) by JoeMerchant on Saturday September 24 2022, @11:48PM (1 child)
True enough, though all those machine translated C libraries may not work exactly the same when compiled as translated C to Rust...
🌻🌻 [google.com]
(Score: 2) by bart9h on Sunday September 25 2022, @05:24PM
Actually, Rust code can use C libraries with ease.
The libraries are not translated from C to Rust. Either you re-implement it in Rust, or, more commonly, you use the C library directly.
(Score: 2) by DannyB on Monday September 26 2022, @03:36PM
I am reminded of a conversation between Londo and Mr. Morden . . .
Londo: "why don't you eliminate the entire Narn homeworld while you're at it?"
Morden: "One thing at a time ambassador, one thing at a time"
The look on Londo's face shows that he suddenly realizes what he has gotten himself in to.
Maybe just wait for Rust++
The lower I set my standards the more accomplishments I have.
(Score: 3, Insightful) by turgid on Saturday September 24 2022, @05:34PM
No, in just the same way that all the C code wasn't "ported" to C++. I'll be learning Rust, though. If it's good enough for the old Ada folks, it's good enough for me.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Informative) by krishnoid on Saturday September 24 2022, @01:00AM
He was the one who embarrassed Microsoft [wired.com] over the "differences" between NT Workstation and Server. Still, he did also write the winternals (now sysinternals) [microsoft.com] Windows tools that make working on Windows more bearable.
(Score: 4, Insightful) by Kell on Saturday September 24 2022, @01:49AM (10 children)
The sad sorry truth is that C/C++ are good at what they do, they have ample mindshare and support, and people use them for those reasons. I work mostly in embedded systems and C is the lingua franca for our platforms. I don't care what advantages some other language provides if I can't compile it for my target platform and there's no library support.
Scientists ask questions. Engineers solve problems.
(Score: 4, Interesting) by HiThere on Saturday September 24 2022, @02:55AM (8 children)
And that's a crucial point. C is more portable than other languages. And that's necessary. Lots of other languages are bootstrapped out of C.
I just wish that C allowed references rather than pointers and using const rather than define, and a few other things that could be done without changing the language much.
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 3, Insightful) by acid andy on Saturday September 24 2022, @12:47PM (7 children)
It would be nice to have but then why not just write procedural C++ so you can use those features to your heart's content?
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 3, Insightful) by HiThere on Saturday September 24 2022, @01:13PM (6 children)
I do. But much of the rest of C++ is unneeded overhead, and a lot of people think I should be using them instead of "writing C code in C++".
Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
(Score: 2) by turgid on Saturday September 24 2022, @05:50PM
Nobody expects the C++ inquisition!
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Funny) by sgleysti on Saturday September 24 2022, @08:55PM (4 children)
Don't listen to the haters. At my last job, they used a C++ compiler to compile what was otherwise pure C code just to get the // style comments permitted in C++. I'm not joking.
(Score: 2) by acid andy on Sunday September 25 2022, @06:34PM (3 children)
On the one hand, life's far too short to be bothered about such things. On the other, it makes for a great anecdote on SN! =)
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by sgleysti on Sunday September 25 2022, @07:37PM (2 children)
Oh, I found it simply amusing and was not bothered by it. My main point is to encourage HiThere to keep doing what he's doing: use the minimal features from C++ that help him out and leave it at that.
(Score: 2) by acid andy on Sunday September 25 2022, @09:02PM
Got it, and agreed. This discussion has got me curious now to compare the output of the same source compiled as C versus C++ though. I'm not willing to just take the "haters" word for it that the C++ output will necessarily be more bloated or slower.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 2) by coolgopher on Wednesday September 28 2022, @12:18AM
A colleague of mine is fond of using C++ on embedded devices purely for the template support. When needing to support different configuration sets of values for various sample-related things, templating on integers means that we can trade some flash space for performance. And in (really) tight ISRs that makes the difference between possible and impossible. Sometimes an indirection to load a boundary value is too expensive, and C++ templates can be an efficient way of solving that problem.
(Score: 2) by DannyB on Monday September 26 2022, @03:44PM
For software that is not extremely large or complex and fits well inside a single human mind, C works well. Very well in fact.
Once complexity exceeds some threshold then you get memory management problems, buffer overflows, and other problems that C is extremely well known for, and for decades. It's not that the programming is, or the programmers are bad. It is that the language is not suited for the level of complexity. At some threshold of complexity, programmers should not be spending brain cycles on pointers, memory management, type errors, etc. Just as you prefer to use C over assembly language, and probably for similar reasons.
The lower I set my standards the more accomplishments I have.
(Score: 5, Insightful) by coolgopher on Saturday September 24 2022, @02:16AM (6 children)
...just because you can't write code that doesn't have memory issues doesn't mean that nobody can.
You don't give people chainsaws without teaching them how to use them properly, do you? Replacing chainsaws with butter knives is not the optimal solution.
(Score: 5, Interesting) by ElizabethGreene on Saturday September 24 2022, @02:38AM (5 children)
I don't think this is chainsaws to butter knives, instead it's more of a chainsaws vs. chainsaw with a hand brake. Also, it's not just memory management. It's incredibly easy to miss bounds checking and type checking, no matter how good you are. Those leads to buffer overflow vulnerabilities. Anyone can derp this.
(Score: 4, Insightful) by coolgopher on Saturday September 24 2022, @05:25AM
The compilers are getting rather good at telling you off about stuffed up bounds checks these days I have to say. And Valgrind is still a most useful tool in the arsenal on the memory front.
Over the years though I'd say my most important takeaway has been to spend more time on the design to keep the implementation as clean and simple as possible. To use the old adage - to write code that obviously has no defects, rather that code that has no obvious defects. And that applies regardless of language.
(Score: 4, Informative) by rpnx on Saturday September 24 2022, @04:09PM (3 children)
Disagree. Bounds checking is unneeded when your loop looks like:
for (auto & x: container)
Or
for (auto it = c.begin(); it != c.end(); it++)
{
...
}
And you can also just use std::vector::at if you're unsure about safety or compile the standard library with bounds checking even if you want.
C++ can be compiled in hardened mode with containers having bounds checking, that's up to the implementation.
But there is a huge difference between a skilled programmer and skilled C++ Programmer in terms of making mistakes in C++. C++ is not friendly to generalists.
A few universal trends among C++ haters:
This was a non-exaustive list of the trends of C++ haters. To summarize, all the people that hate C++ I have met do not understand it and are totally C++-incompetent. That doesn't mean they are incompetent as a programmer, but C++ is a complex language and you cannot expect to pick it up without a substantial learning investment. C++ doesn't excel at microbenchmarks, it tends to beat C on more complex algorithms because you can afford to express much more complex algorithm ideas in C++ than C in the same time span of writing code. But it does allow micro optimizations, however they rarely affect the performance significantly.
Truth is that C++ vectorization support can make massive gains for performance. C doesn't really have vectorization types, afaik it's all language extensions and inline assembly/compiler intrinsics, whereas C++ has it built in to the standard library. Sometimes -O2 will catch your intent and vectorize stuff anyway, sometimes it wont. C+assembly can compete with C++, but pure standard C with no non-standard extensions/assembly cannot beat C++ in most cases. At least that's what I observe for complex algorithms.
(Score: 3, Insightful) by coolgopher on Sunday September 25 2022, @03:18AM (2 children)
The one very legitimate argument C++ "haters" do have is that of language complexity. There is no denying that it is quite possibly the most complex/subtle programming language available. As someone who writes in C++ professionally on and off, even I have to admit to not having a solid grasp of things like the implications of move semantics or exactly when I can get ADL to work for me. That still doesn't stop it from being an incredibly powerful tool, and the best one for many tasks.
(Score: 2, Insightful) by loki on Monday September 26 2022, @12:52AM (1 child)
A huge problem with C++ is that it was bolted on top of C for compatibility, yet C++ tries to replicate and replace everything in C at the same time.
Thus, whereas C has char*, C++ has char* and std:string.
C has FILE*, but C++ has FILE* and istream, ostream, and fstream.
C has printf, but C++ has printf and .
C has *, but C++ has * and &.
C has [], but C++ has [] and std::vector.
C has struct, but C++ has struct and class.
C has malloc, but C++ has malloc and new.
C has free, but C++ has free and delete and delete[].
C has macros, C++ has macros and templates.
C++ tries to deprecate and replace all the features of C, yet fails in various ways to do so.
Design-wise, C++ is a mess.
(Score: 2) by acid andy on Monday September 26 2022, @03:07AM
I'll grant you that it's not as clean and pure as designing another language independently may be, but backwards-compatibility is rarely very pretty yet it remains an extremely useful thing to have.
I certainly wouldn't call it a huge problem. You just have to know which features are C and which are C++ and when best to use them, which isn't difficult to learn. I mean, hopefully you didn't spend too many minutes putting together that post, which is already much of the way there to providing a cheat sheet of what's what.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 5, Insightful) by Anonymous Coward on Saturday September 24 2022, @03:17AM (24 children)
No! It's time to stop thinking software is going to magically get easier with all the IDIOTS embracing all the these low-rent, toy languages, like Java, C#, and Python. All these languages do is make incompetent people think they can be programmers. Also, WHO do you think writes the code that sits UNDER these languages. Oh, that's right, it's the C and C++ programmers.
(Score: 1, Informative) by Anonymous Coward on Saturday September 24 2022, @03:33AM (17 children)
Soon to be Rust. All Rust, all the time. All hail Rust. That's what TFS is about, check it out sometime.
(Score: 4, Funny) by acid andy on Saturday September 24 2022, @12:50PM
Assemblers to ashes, Rust to dust.
If a cat has kittens, does a rat have rittens, a bat bittens and a mat mittens?
(Score: 4, Insightful) by turgid on Saturday September 24 2022, @04:10PM (15 children)
It doesn't seem that long ago that Microsoft was telling us that C++ was the only language we'd ever need and that we should be writing absolutely everything in C++. A cult grew up around it. Serious people would go out of their way to re-educate you into the ways of C++, despite its obvious shortcomings in many areas. I meet a lot of Ada programmers these days. They can't understand why C++ is so popular, but they can see the advantages of Rust. I have to admit, I thought Rust was a fad a few years ago because I didn't understand properly what it was about, and I saw some very poor examples on the web (stick to proper programming language books written by people who know what they're talking about). C++ started out as a hack on top of C. Then it diverged. Then were were told we needed to rewrite all our C in C++ to take advantage of all the C++ goodness, much of which was going to come along in the future. The syntax was absurdly complex. The compilers were slow. Templates were a mess. The object code was larger. The ABI was incompatible with everything else. There were abominations such as iostream. About ten years ago I made the conscious decision to have as little to do with C++ as possible. Sure, I'll do it in the course of my day job when I have to, but fortunately that's rare. I live in a world where C rules. I've done a fair bit of Java over the years. It's not perfect, but it's much nicer a language than C++. I've read about other languages too, that are far more advanced than C++ and I really can't understand why people have succumbed to the cult. You only need to look around at what else is out there. Your brain has better uses than fighting with C++ syntax and all the other idiosyncracies.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Saturday September 24 2022, @04:51PM (14 children)
A decade ago, I was a whippersnapper pursuing a master's degree, and I was asked to modify some program written in C++ so I only got into the language after the Standard Template Library was a thing. It is so helpful for someone just starting out who has not yet found / developed and learned some library with various basic data structures, sorting functions, and so forth to have a ready-made well-documented professional implementation of all these things included in the language itself.
I was later told that I basically wrote C++ like "C with STL containers", and you know what? I'm fine with that. I think the STL is great, and I'm very skeptical of the fine grained encapsulation that most people push with object oriented programming. I like functions. I'm not afraid of writing long functions; sometimes your program really does perform a long sequence of operations in order with maybe a few error checks. Maybe if I give that a name and call it a "pattern" it will be cool again.
(Score: 2) by turgid on Saturday September 24 2022, @05:21PM (13 children)
Long functions are bad because the can be refactored into lots of smaller functions. A function should do one thing and do one thing well. If all of the operations are factored out into their own functions, each can be comprehensively unit tested, put through proper use cases and demonstrated to work correctly. There are some good books on the subject including Clean Code by Robert C. Martin, Refactoring by Martin Fowler, Working Effectively With Legacy Code by Michael C. Feathers and Test-Driven Development by Kent Beck. If you are writing code without unit tests, you are writing "legacy code" by definition.
Design patterns are very interesting. They are an identified set of solutions to common problems plus a (human) language for talking about them. Why re-invent the wheel when there's a design pattern that solves your problem efficiently and correctly?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 3, Insightful) by sgleysti on Saturday September 24 2022, @05:33PM (12 children)
Yeah, I've heard it before. Lots of times. Some of the code I write automates testing with various programmable lab instruments, which often entails doing a long sequence of steps in order. Splitting that up into a ton of tiny functions would make it hard to read. There are helper functions for repeated operations, but not for the top level long list of things the code needs to do in order.
(Score: 2) by turgid on Saturday September 24 2022, @05:45PM (11 children)
What you want is a scripting language.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Saturday September 24 2022, @05:49PM (10 children)
I definitely do all of this in C++. Static typing, compiling to machine language, and strong support for multithreading are good things.
(Score: 2) by turgid on Saturday September 24 2022, @05:54PM (9 children)
It sounds like you've been a victim of the C++ Inquisition. "You should be writing all your code in C++." What other languages have you looked at? Why does the whole thing need to be compiled to machine language?
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Saturday September 24 2022, @07:20PM (5 children)
I've looked at FORTRAN because I like writing numerical software, but it seems to have poor integration with the OS and poor library support for some of the things that I do. I still might pick it up at some point in the future. I've used Python here and there, especially sympy for computing partial derivatives for optimization routines and matplotlib to make nice graphs, but I wouldn't use it for anything that needs multithreading, responsiveness, or speed due to the interpreter hit. I'm pretty good with MATLAB and GNU Octave, but again, I mostly use those for simple graphing of data, playing around with or prototyping numerical code, or some quick calculations.
C++ is amazing. It's fast, has lots of great features (you don't need to use them if you don't want), good OS integration, good library support (in my case Rohde & Schwarz's VISA library for talking to test instruments, C libraries for various data acquisition devices, and so on), lots of existing open source code (the Eigen Linear Algebra package is the one I use most, but there's so much), strong support for multithreading, and some great compilers. The STL comes baked in and is of very high quality. And you can use lots of C libraries and stuff.
Rust looks really promising due to the memory safety stuff. If C++ didn't already meet all of my needs and perhaps more, I might take the time to learn Rust.
Other people can write their software in whatever language suits their fancy. I'm not telling you or anyone else what to do. I am saying that I love C++ for the reasons above. Although, my favorite is still programming 8-bit PIC microcontrollers in assembly.
(Score: 2) by turgid on Sunday September 25 2022, @04:31PM (4 children)
FORTRAN is from another era, when programs were entered on punched cards and paper tape, and the terminal was a teletype with paper and an ink ribbon. Arrays in FORTRAN are in column major order. The syntax of the language is atrocious. It's totally ad-hoc and inconsistent. It does have some advantages over the C family of languages in terms of ability to optimise certain types of code because it doesn't have pointers and therefore pointer aliasing is not a thing. Back in the 50s, 60s, 70s and even the 80s a lot of numerical code was written in FORTRAN. In those days people didn't believe in unit tests. Combined with the horrendous nature of the language, human civillisation's numerical scientific code is enshrined in mysterious, unmaintainable gobbledygook and no one can rewrite it because they can't figure out what it does. The people who wrote it are long gone.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Sunday September 25 2022, @06:17PM (1 child)
FORTRAN is still actively maintained and still used to write numerical code.
(Score: 2) by turgid on Sunday September 25 2022, @06:44PM
Indeed it is.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 0) by Anonymous Coward on Sunday September 25 2022, @10:21PM (1 child)
I've typed many thousands of lines of FORTRAN and never used a punch card or teletype printer. I'm not sure what you find so horrendous about the language as I never found the syntax to be atrocious. It was wonderful to not have all these semicolons all over the place. Everyone it seems who started programming in the 90s or later have the oddest notions about FORTRAN, not just irrational, but almost defensive angry, even if they've never had to program in it at all. I've never understood it. I've had more than one Millennial insist that you have to use GOTOs in FORTRAN, which is why it is such a "horrible" language (even if one idiotically and blindly follows Dijkstra regarding the GOTO statement, for the record I've never needed to use one). I mean, how do you even have a conversation with someone with notions like that? That's "not even wrong."
And are you really blaming FORTRAN for peoole not writing unit tests?
(Score: 2) by hendrikboom on Monday September 26 2022, @12:51AM
When did Fortran acquire IF-THEN-ELSE and the like? Was it in the 80's? the 90'S?
(Score: 3, Insightful) by sgleysti on Saturday September 24 2022, @07:24PM (2 children)
Forgot to answer this one...
Have you ever written a routine that, even with the best available algorithms, maxes out a modern parallel processor for a non-trivial amount of time? Or that has throughput or latency requirements that require high performance code? Having done those things, I find interpreted languages so incredibly wasteful. Even when something would still work well enough in an interpreted language, I like the software that I use to be responsive. And if I'm writing it for myself, one great way to have a good chance at responsive software is to write it in some language that compiles to machine code.
(Score: 2) by turgid on Sunday September 25 2022, @09:08AM (1 child)
Yes, I know, I've seen project proposals where people were going to do something in Python and then spend $100k on the hardware just to get it to run fast enough without any understanding of how Python works underneath (most of the hardware being wasted). My question about scripting languages was for your use case where you are automating tests using lab equipment. Unless you have some fancy real time requirements, you could use a scripting language for that and make your development and test cycle much shorter. It would also make the test cases more easily maintainable by other people. There would be a smaller learning curve.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Sunday September 25 2022, @06:30PM
None of those things are my goals. To provide some context, I am personally writing code to automate tests for myself. The software is not the end goal; the test results are the end goal. I don't spend all my time learning or writing software—it is a means to an end. We have an automated test group at work, but they're to busy to help me with my stuff. They're more focused on system level testing of entire products and do their work in LabView, which by the looks of it would drive me crazy. The company doesn't have the budget to give me a LabView license anyway, and I don't have the time to train up on it.
I already happened to know C++, and it does work well for this purpose in the sense that I can get the tests up and running and working reliably in a reasonable amount of time. I can link to solid, professionally developed libraries for instrument control (Rohde & Schwarz VISA). I can link to libraries for other data acquisition equipment (usually supplied by the manufacturer). I understand the code and can fix it if something goes wrong. It's performant. One time, I had a bench DMM sampling at max rate in one thread while I was reading 20 event driven digital channels in another thread, eventually outputting everything to a VCD file. That was before the automated test people came around. I found so many bugs in the firmware written by our software team with that setup. Most of them having to do with misunderstanding or missing details in the supplied specifications, or coding themselves into such a corner with their pretty frameworks that implementing needed features required a ton of refactoring.
I don't know python well enough to write solid, functioning code on the first try reliably and would have to take the time to get there. Since C++ works very well for me, there's no incentive to learn something that runs slower and where I'd be relying on some library downloaded with pip that I wouldn't feel I could trust and wouldn't know the internals of.
And no, I do not write unit tests for this code.
(Score: 5, Insightful) by Thexalon on Saturday September 24 2022, @10:46AM
My general view on the matter: If you're writing low-level systems software in Python, you're doing it wrong. If you're writing your high-level applications in C, you're also doing it wrong. A good programmer picks the right tool for the job at hand, rather than trying to hammer a nail using a screwdriver.
And as someone who's done pretty well for myself in the industry: While I can wrangle structs, malloc/free, pointer math, and occasional asm{} blocks, I'd just as soon not when I don't need to because it's a bunch of work that won't benefit the users a lot of the time. Now, I've benefited from knowing about that stuff and what's going on under the hood when debugging particularly vexing high-level code bugs (e.g. in one instance we were having a problem caused by brokenness in that version of the PHP interpreter), but if you think I don't appreciate not having to think about string terminators very much, think again.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 0) by Anonymous Coward on Saturday September 24 2022, @12:48PM (2 children)
Yeah, and who writes the code that sits under those C and C++ compilers? Oh, that's right, it's the assembly language programmers. And who sits underneath those assembly language programmers? Oh, those who do opcodes in binary poked straight into the system. And who sits underneath those folks who never attach keyboards to their Altairs and Imsais? Oh, it's the electrical engineers who designed the CPUs with their ability to use opcodes.......
So, if you ain't an Electrical Engineer who can design a CPU from scratch you're an IDIOT, obviously.
(yes, you have a point... but you're looking at it only from your level of abstraction. Other needs, other languages/enviornments to cope.)
(Score: 3, Insightful) by maxwell demon on Saturday September 24 2022, @01:30PM
Actually not. The compilers are completely written in high-level languages, usually in C, C++ or the very same language they compile. And that has been the case for decades. Even the assemblers are typically written in high-level languages. Hand-writing assembly is extremely rare these days.
Has anybody actually done that in the last 20 years, except maybe for fun or for the learning experience?
Even those mostly do their designs in languages like VHDL these days. Using software that was most likely written in C or C++.
But you've got a point in that they do not design the hardware using C or C++.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 0) by Anonymous Coward on Saturday September 24 2022, @02:06PM
Swallow any flies recently?
https://www.youtube.com/watch?v=zQHmZMf6zwo [youtube.com]
(Score: 0) by Anonymous Coward on Sunday September 25 2022, @08:36PM
> that's right, it's the C and C++ programmers.
No. It's really talented people.
(Score: 2) by DannyB on Monday September 26 2022, @03:50PM
Yeah, MULTI BILLION dollar industries using toy languages.
Solving complex problems without worrying about pointers, buffer overflows, memory management, type mismatches and worse things.
Not that higher level problems cannot bring new higher level vulnerabilities. So don't get lazy if you use a higher level language.
It's like criticizing people for using an automatic transmission instead of the wonderful manual transmission (which is getting increasingly difficult to find). Or criticizing people as being idiots for using a backhoe to dig a ditch instead of using a shovel.
Use whatever tool you think is best. Your tool MUST be ideal for ALL possible uses. Everyone else is an idiot. Nobody could possibly be as well informed as you are.
The lower I set my standards the more accomplishments I have.
(Score: 4, Funny) by MIRV888 on Saturday September 24 2022, @05:00AM (5 children)
I don't know jack about programming, but if it's anything like hardware there are new iterations constantly. Wouldn't this necessitate eventually moving to a new coding language because of new features the advancing hardware provides?
I just know C / C++ are long in the tooth age wise. I don't know if this equates to being dated in capabilities.
Thanks
(Score: 5, Informative) by coolgopher on Saturday September 24 2022, @05:41AM
Generally speaking, no, you don't need a new language. Hardware advances/advantages are taken care of by the compilers. Modern compilers typically comprise a few distinct parts. You have a frontend which translates a particular programming language into what's known as an Abstract Syntax Tree. Various optimisers then reshape this for speed (or size, if that's the stated goal), possibly with some knowledge of the target architecture. The processed syntax tree is then handed to a hardware-architecture specific code generator backend, which may in turn further tweak the syntax tree to make the most of the available hardware. In this model, a new human/machine language needs only a new frontend implementation, after which point it can tap into the full optimisation/target support, while hardware advances often only need support added in the relevant backend. This is obviously a very generalised overview.
In short, only the compiler implementers end up having to worry about hardware advancements. Thankfully. Because modern hardware has gotten stupidly complex. And I have a huge amount of respect and appreciation for the people who spend their time working on the open source compiler toolchains.
All that said, there are indeed times when new languages are needed. For example, the massively parallel architecture of GPUs lead to the development of CUDA in order to better take advantage of that architecture, since it was such a radical departure from your typical CPU. And of course, development for quantum computers looks utterly different from classical computing (and there's a lot of maturing to be done in that area).
(Score: 4, Insightful) by maxwell demon on Saturday September 24 2022, @05:41AM (2 children)
There are new iterations of C and C++ constantly. Also, unlike hardware, languages usually get new capabilities through libraries. A new language means loss of all the libraries that haven't yet been ported. To mitigate that problem, many languages include ways to call C code.
The Tao of math: The numbers you can count are not the real numbers.
(Score: 3, Insightful) by sgleysti on Saturday September 24 2022, @04:45PM
And FORTRAN code.
(Score: 3, Informative) by turgid on Saturday September 24 2022, @05:44PM
There's another subtlety, though. On a Unix/Linux system, the Application Binary Interface, the way programs call each other, is defined by the output of the C compiler. Because Unix was written in C (the first portable OS written in a high-level language) the way C calls functions is the way you call the OS and hence other libraries on the system. Any language that can generate code that speaks this ABI is therefore compatible. By default, C++ does not. It has all sorts of hackery underneath. In general, interpreted languages do not either, for obvious reasons. Pascal and its family of languages do not by default (they put arguments on the stack in the opposite order).
On a Unix or Linux, the convention across the OS is for libraries to use the C ABI. That's what comes out of the compiler used to compile the system, after all. The problem comes when you have a load of libraries written in C++ (which is quite common). Because of C++'s weirdness, you won't be calling those libraries from any other program not written in C++ and not only that, having been compiled with the same compiler. That is, unless the programmers have provided an interface to the library using the C calling convention. That's a load more work in C++. It means wrapping each API call in an 'extern "C {}' declaration with a C function call...
C++ was supposed to take over the world. Fortunately it didn't.
I refuse to engage in a battle of wits with an unarmed opponent [wikipedia.org].
(Score: 2) by sgleysti on Saturday September 24 2022, @04:59PM
Perhaps the biggest new hardware features (for various definitions of new) are multiprocessing / parallelism and vector units. Some older languages don't handle parallelism well or need libraries or extensions to do so. Support for vector units in modern processors is usually handled by upgrades to the compilers. The compilers might add intrinsics to aid in vectorizing code, although I'm pretty sure a Linear Algebra package that I use has explicit assembly code for various processors and architectures to make sure that critical routines use the vector units.
Graphics processors are so different from CPUs that they require special languages and/or programming techniques.
And then FPGAs are usually "programmed" in a hardware description language because they're a more different type of hardware still.
(Score: 5, Insightful) by jb on Saturday September 24 2022, @06:50AM (1 child)
Speaking as a C (and occasional C++) programmer, that's wonderful news!
After all, we all know that almost everything that Microsoft has claimed since some point in the early to mid 1980s has turned out to be wrong, so this must be too, right? If Microsoft think C/C++ must die, then the probability that C/C++ will live forever is most likely quite close to 1.
(Score: 0) by Anonymous Coward on Sunday September 25 2022, @08:44PM
Yep, and in related news Microsoft CTO recommends redefining pi as ~3.
(Score: 4, Interesting) by digitalaudiorock on Saturday September 24 2022, @01:27PM (2 children)
I have to say, I am NOT as thrilled about rust as others here. As a Gentoo user, and having been forced to have it on my system for Thunderbird I fucking hate it. For one thing it's a fucking massive memory hog.
What gets really ugly is compiling new versions of rust. Luckily Gentoo offers a rust-bin package which makes that at least a little easier. The reason I say that is rust must be compiled with rustc itself, and they don't seem to give a shit about backwards compatibility, so unlike compiling gcc, you generally can't skip versions. There are some ugly details here [gentoo.org] in a post near the bottom by user Hu.
That has to make you think about how much thought has really gone into that thing as compared to things like gcc.
(Score: 2) by sgleysti on Saturday September 24 2022, @05:01PM
Rust is quite new relative to C. Hopefully the language eventually reaches a state of maturity where the shenanigans you describe are not required.
(Score: 0) by Anonymous Coward on Sunday September 25 2022, @08:46PM
> I am NOT as thrilled about rust as others here
Uh, not sure what forum you're reading but so far there are ZERO posts in favor or Rust.
(Score: 1, Offtopic) by looorg on Saturday September 24 2022, @01:35PM (1 child)
So when are they rewriting Windows and Office in Rust? Or have they already started? Or is this one of those things that everyone else should do but for them it's to big and expensive to do?
(Score: 2) by sgleysti on Sunday September 25 2022, @07:51PM
If Microsoft actually took the time to fix the bugs in Office, particularly in Word, even more particularly in Word + SharePoint, I would be so happy. They won't let me write documents in LaTeX at work... so I'm stuck with Word. On SharePoint. It's buggy, and I hate it.
(Score: 4, Interesting) by Rich on Saturday September 24 2022, @02:03PM
Has anyone here done anything significant in Rust? I haven't, so I wonder how their "borrowing" ownership model works out in reality.
Does it allow to keep data structures and algorithm flow as we know it, or are there constraints felt in what can be done? How's life with the lifetime annotations? Are they required on a regular basis, and do they take up significant mindwork? Or does all that stuff go out of the way if programs are written in what safe practice would suggest, anyway? Is the "trait" system suitable to replace inheritance?
What about the missing exceptions at higher levels of logic in practice? I fear if you consider "out-of-memory/disk" a possibility in a highly dynamic desktop app, they are pretty much needed, if you don't want to write the majority of code to handle errors.
(Score: 5, Touché) by stretch611 on Saturday September 24 2022, @02:26PM (1 child)
Well if Microsoft is truly committed to Rust, when will they announce the deprecation of C# ?
Now with 5 covid vaccine shots/boosters altering my DNA :P
(Score: 1, Touché) by Anonymous Coward on Sunday September 25 2022, @08:48PM
No, they are readying to announce their new feature rich language Rust#.
(Score: 3, Insightful) by VLM on Saturday September 24 2022, @03:20PM (2 children)
The problem is the concept of turing complete languages. There's nothing you can write in lang A that can't eventually be translated into lang B, in the sense they're all in the same complexity class.
The way it has rolled out for decades is the bad coders write bad code on old languages because thats all they had. "Hey look, the bad coders all use gwbasic / perl / C, so if we use the new shiny Python / C++ / whatever then we won't have bad programmers, so we'll have good code". Then the bad coders arrive, code quality in that language goes to shit, rinse and repeat with yet another new language, apparently Rust.
This is a good site:
https://www.rust-lang.org/learn [rust-lang.org]
But bad programmers will never learn from it anyway, and will just F up the code some other way. At least you know what to expect with C and C++, LOL.
You know for a fact that bad programmers will start to use Rust and they'll implement some kind of dynamic storage system for strings that uses an array of 8-bit bytes, and WTF why not implement null terminated strings in those data-buffer arrays, and a crap tier homemade function to allocate ranges of that array for certain tasks, and WTF if you're going to implement null terminated strings in your array of bulk data why not implement a function probably named strcpy that copies strings until it sees the null termination, like what could possibly go wrong, obviously Rust will save us all in this situation. Why would a programmer implement a dynamic memory heap of his own instead of using "Safe" library? Well, thats so complicated and if they were good programmers they wouldn't be the problem anyway blah blah blah.
The other problem is best explained as the Scala experience where Scala never prevented bad coders from making type mistakes, it just made everyone define all the types as Any because the lower skill programmers prevent the use of types. (It has been something like 7, 8 years since I last used Scala but IIRC "any" type short circuited all the Scala type safety stuff and you can't fire everyone who can only use type Any in scala code for all type annotations and "ship it yesterday" mentality will always apply so if it compiles and runs with everything set to type Any then thats whats gonna ship)
(Score: 2) by sgleysti on Saturday September 24 2022, @04:42PM (1 child)
I really, really hope this is not correct:
There's no language fix for bad coders, as you get across. I do think languages with new features can make it a lot more practical for reasonably competent coders to maintain or increase productive output while introducing fewer bugs into the code. Rust seems to have some legitimate technological innovations along these lines in the area of memory safety. Personally, at my last job, I wrote C++ code basically like "C with STL containers", and I avoided using C pointers. Valgrind always came back saying "no memory leaks possible". I probably would have fucked up something if I wrote programs with identical functionality in C. I probably would have learned more about coding also.
All of that said, my favorite programming language is Assembly for 8-bit PIC microcontrollers (and related Holtek microcontrollers). But I mostly use that for hobby projects and little fixture circuits to help run tests of electronics hardware at work.
(Score: 2) by RamiK on Saturday September 24 2022, @07:12PM
That's not quite true. Purely functional programming language make it really hard to write shit code. Not impossible. But hard enough to deter bad coders. Also, a language like Dala [arxiv.org] that goes at glitches through capabilities pretty much prevents sloppy coding due to forcing the developer to think through what they're doing.
Anyhow, the point is, if you take away the imperative conveniences out, bad coders will actively avoid using your language.
p.s. There's also something to be said about data flow languages here but it's not as easy to argue.
compiling...