Tor Project Hopes to Replace 'Complex', 'Fragile' C Code With Rust (yahoo.com) 107
CoinDesk reports that "A project is in the works to make the Tor Client more adaptable and easier for third parties to use, with some help from Zcash Open Major Grants (ZOMG)."
ZOMG announced on Tuesday that it is awarding the privacy-focused Tor Project a $670,000 grant to continue to develop Arti, a Rust coding language implementation of the Tor Client... Arti should make it simpler for third parties to embed and customize the Tor Client than the current implementation in the C coding language... "Arti is a project to make an improved version of Tor that will be more reliable, more secure, and easier for other software to use," said Nick Mathewson, chief network architect and co-founder of the Tor Project. "We hope that within the next several years, Arti will become the preferred implementation of the Tor protocols...."
"Onion routing has just had its 25th anniversary in May, and although Tor is a great set of privacy tools, the C program 'tor' itself (note the lowercase t) is beginning to show its age," Mathewson said. "We've found over the recent years that the complexity of the existing C code, and the fragility of the C language, make it unnecessarily difficult to improve the code while maintaining our security and privacy guarantees....
"Roughly half of Tor's security issues since 2016 would have been impossible in Rust, and many of the other issues would have been much less likely, based on our informal audit," he said...
The funding will go toward developer salaries as they develop Arti. Mathewson said the goal with this round of funding is to advance Arti to the point where it is ready for general use, testing and embedding.
"Onion routing has just had its 25th anniversary in May, and although Tor is a great set of privacy tools, the C program 'tor' itself (note the lowercase t) is beginning to show its age," Mathewson said. "We've found over the recent years that the complexity of the existing C code, and the fragility of the C language, make it unnecessarily difficult to improve the code while maintaining our security and privacy guarantees....
"Roughly half of Tor's security issues since 2016 would have been impossible in Rust, and many of the other issues would have been much less likely, based on our informal audit," he said...
The funding will go toward developer salaries as they develop Arti. Mathewson said the goal with this round of funding is to advance Arti to the point where it is ready for general use, testing and embedding.
poor craftsman (Score:5, Insightful)
Re: poor craftsman (Score:2, Flamebait)
Re: (Score:2)
Re: (Score:2)
Not really. Wayland is essentially using the same design as used in X for local graphics, but removed of a lot of old stuff. That this make everything better or faster is largely propaganda. Simplifying stuff would be fine and welcome if not for the fact that this breaks decades of compatibility, introduced a lot of new problems which were already solved a long time ago in X, and does not have one of the most useful features of X: network transparency. Improving X, e.g. having disconnect and reconnect, or
Re: (Score:2)
Yup, I have seen so many total rewrites that result in a square wheel: Wayland, Gnome...
Which is maybe why, instead of doing a total rewrite and starting their own operating system, these people are starting with Linux and just attempting to improve it. Is that perhaps possible?
Re: poor craftsman (Score:4, Interesting)
And if your Python programs are written for 3.x, they'll have to be rewritten to run on Python 4.x. And 4.x won't run on some legacy version of Debian still kicking around in your network, so you'll need to upgrade the whole OS.
While my C programs from 1989 still compile and run fine.
Re: poor craftsman (Score:5, Insightful)
While my C programs from 1989 still compile and run fine.
Unless it was something really simple, it probably won't. Chances are pretty high that a library you're using has changed. Even if it does, there's a decent chance that you shouldn't be running it. For example, if it uses gets().
32-bit Pro*C (Score:3)
Re: (Score:2)
But you still had to make changes to it
Re: (Score:2)
Yes, I'm sure source code that is actively used will need to be working on if there are changes to business logic or fix bugs. But it can still be essentially the same core program, changing software versions isn't a compelling reason to rewrite all our software.
Re: poor craftsman (Score:2)
Oh wait...
Re: (Score:2)
Au contraire mon frère, it was a parser for an infix calculator. And my friend had his database (b+tree) building and running mostly by fixing obsolete Makefiles, no C changes. Also, I'd like to add that I have picked up lots of old Usenet shars and compiled them on Linux, even recently. Some work some do not. Things that stick to ANSI or POSIX tend to do better.
Even if it does, there's a decent chance that you shouldn't be running it.
Nonsense.
For example, if it uses gets().
It depends on use case if gets() security is a priority or not. But how many seconds does it take to fix such a valid but deficient p
Re: (Score:2)
But how many seconds does it take to fix such a valid but deficient program?
How many seconds does it take to port python code from one version to another? The point is that either way, you probably aren't going to just leave it as is. Maybe you will if it's a super simple program with only a minimal set of requirements. The same can be said for python.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
If anyone is still bitching about 2 to 3, then they're the poor craftsman.
Maybe you've never met real craftspeople (or artists). Bitching about minutia is a cultural touchstone for them.
Re: poor craftsman (Score:1)
Re: (Score:3)
Yep yep. Remember Netscape throwing out Netscape to produce Mozilla/Firefox which resulted in losing two years of competitive pressure on MSIE, practically cedeing it to MSIE until Chrome came along.
The general rule for programming is. If it can't be done with C alone, then it's not portable, performative at all.
C++, Rust, Pyhton etc have their places, but more frequently than not, people switch to less performative programming languages to save on compiler time, at the cost of the program running at 100's
Re: (Score:2)
Re:poor craftsman (Score:5, Insightful)
And yet we stupidly endeavor to build better tools.
Re: (Score:2)
Re: (Score:2)
Rust isn't better for anything, it's a childish scripting language with functions for everything and the kitchen sink, and it performs worse than Visual Basic. Name something for which it is needed other than lining the pockets of IT companies. Nothing worthwhile is written first in Rust and it's just another buzzword used to sell services and server rental, not a practical choice for development. It's worse than PHP, even.
Re: (Score:3, Insightful)
Maybe it's not a popular opinion, but it should be said: He's a poor craftsman who blames his tools.
Came here to say pretty much this. I'm a hardware guy and haven't done much programming but I've done enough to question that "fragile C" assertion. I can see the code being fragile if it was sloppily written, but that's not the fault of the language itself. There's been plenty of solid, reliable, long-lived C code written over the decades, yet all of a sudden C is fragile? I don't buy it.
Re: (Score:2, Insightful)
The older the code is doesn't necessarily make it safer. There have been security vulnerabilities found in the Linux kernel that were over 15 years old at the time of discovery. You'd figure one of these superhuman C programmers that never make mistakes would have spotted them much earlier, but here we are. However, if it were written in a more modern language that wouldn't even compile if these mistakes were present, these vulnerabilities would never have existed.
Re: poor craftsman (Score:4, Interesting)
Modern language? Ada has been around almost as long as C, and is considered by many to be quite safe.
Re: (Score:2)
Ada has been around almost as long as C, and is considered by many to be quite safe.
My understanding is that Ada isn't well suited for kernel development. I don't know the exact reasons as I don't know the language, nor do I know kernel development that well, so you might take the word of an actual Linux kernel developer instead:
https://www.youtube.com/watch?... [youtube.com]
Re: poor craftsman (Score:1)
Re: (Score:2)
The main reason they give is they say that in Ada, deallocation of dynamic memory requires manually tracking lifetimes, which opens you up to use after free errors. So not really memory safe after all.
Re:poor craftsman (Score:5, Insightful)
And then there are routinely really bad security vulnerabilities discovered in other languages than C. The problem is not the language.
Re: (Score:3)
What seems ridiculous to me is that we are still having sql injection exploits written. That problem was solved 20 years ago.
Re:poor craftsman (Score:4, Insightful)
What seems ridiculous to me is that we are still having sql injection exploits written. That problem was solved 20 years ago.
Indeed. The problem that was not solved so far is how to make sure people writing code have a clue as to what they are doing. Most do not.
Re: (Score:2)
Yeah, that's basically the great big gaping hole in the arguments regarding moving anything to Rust (or to any other language, for that matter). In the end, it's the programmers' expertise in writing the language that matters most.
What new holes are going to be introduced by programmers rewriting all their code in a language with which they are less familiar?
Re: (Score:1)
What seems ridiculous to me is that we are still having sql injection exploits written. That problem was solved 20 years ago.
6ofone. The problem is the fact that the program is doing EXACTLY what the writer intended it to do....?
Re:poor craftsman (Score:5, Insightful)
The older the code is doesn't necessarily make it safer.
The same can be said for the newer code -- perhaps even more so as it's less proven.
There have been security vulnerabilities found in the Linux kernel that were over 15 years old at the time of discovery. You'd figure one of these superhuman C programmers that never make mistakes would have spotted them much earlier, but here we are.
Were these programmers tasked with proactively reviewing millions of lines of code? As things evolved? No. The issues were found and corrected when they were found / exploited. No one can test/debug every scenario up front.
However, if it were written in a more modern language that wouldn't even compile if these mistakes were present, these vulnerabilities would never have existed.
You're assuming all these issues were "mistakes" that the compiler could/would find. Often they're programming decisions that are perfectly valid code, or the issues arise because something changed up/down stream.
It's true and you're correct that *some* things could be solved / prevented by simply using a more stringent language (like Rust vs. C) but that won't necessarily solve everything, or even guarantee solving the major things. It will, however, generate completely new code that will have to be re-proven all over again, probably with new bugs and issues. It's a cost/time/quality trade-off. Some things may be worth completely redoing in a different and/or new(er) language, some redoing in the same language and some simply updated in place. Unfortunately, the best path to take for some (many?) can't be determined up front.
Re: (Score:1)
I was assured that enough eyes make all bugs shallow, and that literally tens of millions of linux users are competent C programmers.
Re:poor craftsman (Score:4, Insightful)
Same here. C is not "fragile" in any way. The mess some people write in C is, but these people will create a fragile mess in any other language, because they do not have what it takes.
Re: (Score:1)
Same here. C is not "fragile" in any way. The mess some people write in C is, but these people will create a fragile mess in any other language, because they do not have what it takes.
More modern languages like C++ can automatically detect situations like out of bounds array indexes, write an error log, and abort.
That's the sort of thing I want in critical software, not just to continue as if everything was OK.
Re: (Score:3, Informative)
You do not understand the problem.
Re: (Score:3)
For example, it is true to say that the C language, as a language, can produce perfectly robust, secure and performant code.
But at the same time, it’s probably also true to say that there are other languages out there which, thanks to language design features, make it harder for a less skilled developer to make a mista
Re: (Score:3)
Same here. C is not "fragile" in any way. The mess some people write in C is, but these people will create a fragile mess in any other language, because they do not have what it takes.
More modern languages like C++ can automatically detect situations like out of bounds array indexes, write an error log, and abort.
That's the sort of thing I want in critical software, not just to continue as if everything was OK.
Yeah, the natural path here is to take your currently-working C code, plop it into C++, and then iteratively start replacing the "critical" bits with managed memory / containers. IMHO, Rust is no better in terms of security or speed than modern, idiomatic C++. And C++ has the maj
Re: (Score:1)
Actually, you seem to have no clue what C++ can and cannot do. An array index out of bounds is not something the language can detect in C or C++, because that situation is dependent on the intent of the coder and neither the compiler not the run-time system cannot know what that is. Also, since when do C++ code come with a standard, always present way to log errors to a file? It does not.
You may be talking about some specific library here, but safe containers can be done and are available in C as well.
Serio
Re: (Score:2)
Hmm. Maybe you messed up the quoting in your reply?
Re: (Score:2)
Actually, you seem to have no clue what C++ can and cannot do. An array index out of bounds is not something the language can detect in C or C++
Seriously, stop trying to push your agenda with lies.
C++ can throw an exception on this code:
std::vectora(10);
a[11] = 0;
Re: (Score:2)
Yeah, the natural path here is to take your currently-working C code, plop it into C++, and then iteratively start replacing the "critical" bits with managed memory / containers.
This.
Re: poor craftsman (Score:1)
Re: (Score:1)
Actually, you seem to have no clue what C++ can and cannot do. An array index out of bounds is not something the language can detect in C or C++, because that situation is dependent on the intent of the coder and neither the compiler not the run-time system cannot know what that is. Also, since when do C++ code come with a standard, always present way to log errors to a file? It does not.
You may be talking about some specific library here, but safe containers can be done and are available in C as well.
Serio
Re: (Score:3)
An array index out of bounds is not something the language can detect in C or C++,
Partly correct, but missing the point. If you're actually writing C++, instead of just throwing your C code into a class, you won't be using an "array". The standard library comes with good number of excellent data structures, and you'll be using one of those instead. If you do actually need an array, you'll use a vector. A vector will throw if you access if out of bounds using ".at". You will also design your program so you're not using integer indexes into containers unless you absolutely have to.
but safe containers can be done and are available in C as well.
If you d
Re: (Score:2)
You can have your compiler check your bounds in C and generate a trap for out-of-bounds accesses.
void foo(int N) // traps with right compiler flag. /app/example.c:5:4: runtime error: index 10 out of bounds for type 'int [*]'
{
int a[N];
a[N] = 1;
}
https://godbolt.org/z/rnvojMx6... [godbolt.org]
Re: (Score:2)
Only for very limited scenarios.
Re: (Score:2)
I am not sure what you mean. Basic arrays can be bounds checked as I just showed you. Advanced data structures in a library are accessed using wrapper functions and can also be bound checked. So what is missing according to your opinion?
Re: (Score:2)
Vectors are significantly slower, not guaranteed to be contiguous memory and are not thread safe.
a) Wrong.
b) Wrong.
c) push_back() isn't thread safe, but neither is realloc() in C.
Iterating std::vector and random access to the data via [] is just as thread safe as in C.
Re: (Score:2)
More modern languages like C++ can automatically detect situations like out of bounds array indexes, write an error log, and abort.
I'd rather have the compiler / development toolchain detect that an out-of-bounds was possible (while giving you ways to do the job where it ISN'T possible) and abort the build, rather than have it go to the field and some day die with a kernel panic or other error message.
Gosh, isn't that the sort of thing Rust is all about?
Re: (Score:3)
The issue is that some core C functions, which aren't deprecated, tends to be dangerous by default.
scanf("%s") - is how most people were taught to use the function. No width specifier, and that allows an instant buffer overflow. Programmers could write their own parsing function, but tha
Re: (Score:2)
I always think this saying is misunderstood. A good craftsman doesn't blame his tools because he ensures he has the right tools and that they are properly maintained. It doesn't mean that good craftsman don't care about their tools.
Re: (Score:2)
He's a poor craftsman who blames his tools.
Ok, maybe, but there's also no denying that some tools are just inadequate for heavier jobs.
It's like saying a craftsman is poor because the hand-drill he was using didn't do a great job at making holes, when power drills exist...
Re: (Score:1)
C is suitable for a lot of things, as many large and successful projects show, including the largest software project ever, namely the Linux kernel. Blaming C is just another dishonest attempt by the Rust fanatics to push their fetish.
Re: (Score:3, Insightful)
C is suitable for a lot of things, as many large and successful projects show, including the largest software project ever, namely the Linux kernel.
Sure, it could also have been written in assembly language, or even hexadecimal.
That doesn't mean it couldn't have been written better and with far less effort using a more suitable language.
Re: (Score:2)
Large parts of it are written in assembly, too, due to architecture-specific code. Rust isn't going to do anything for you there, either. At this point, Rust is more like a solution looking for a problem. It's not substantially different from those idiots who wanted to write device drivers in Perl via CORBA 20+ years ago, who also made a lot of the same arguments as the current rust fanatics. I have no doubt rust can be great for certain things, but to suggest that the kernel is fragile and isn't using the
Large does not mean Safe (Score:1)
C is suitable for a lot of things, as many large and successful projects show
Curious which of those used by millions of people have in fact avoided security bugs?
I would argue there is a separate definition of safe and successful, just because millions use soemthing does not mean it's safe.
But as more and more things exist entirely on a virtual base, the safety is a thing that starts to be a lot more vital than simply the metric that a lot of people use soemthing and it doesn't crash often.
The time for play
Re: (Score:2)
Yes, it is too early to claim that Rust and co. are much safer because there is not too much evidence at this point. I heard the same arguments regarding memory safety from Java proponents in the past, and then there were still millions of security problems in Java code.
Still, I think Rust uses some really good ideas and I believe it will have a positive impact. I wish it the best of luck!
And some of the good ideas should just also be added to C in my opinion.
Software needs to survive multiple craftsmen (Score:2)
Maybe it's not a popular opinion, but it should be said: He's a poor craftsman who blames his tools.
Sure, a great craftsman can do good work with nearly any tool. However, when you do this for a living, projects get handed off between teams. Original authors get promoted or seek new opportunities. Contributors add things from all over the globe. People you will never meet extend your current product or take it over. Maybe a large company buys you out and expands your team with their employees.
When your team is tiny and there's no money on the line, do whatever you like. When you make money and ne
Re:poor craftsman (Score:5, Insightful)
Maybe it's not a popular opinion, but it should be said: He's a poor craftsman who blames his tools.
Think more along the lines of putting a hand guard on a circular saw. Sure, it's easy to avoid cutting your fingers off without one, but mistakes happen. The hand guard makes them a lot less likely.
Re: (Score:2)
Blaming the tools is the hallmark of the lazy and incompetent.
Yes, but a good craftsmen van do far more work in a day if he uses better tools, and>/i> get better results.
Mod Parent Up (Score:1)
Did anybody else read the headline as "Tor Project Hopes to Replace 'Complex', 'Fragile' C Code With Complex, Fragile Rust Code"?
Re: (Score:2)
There are oodles of poor craftsmen around in software, the morons that desperately cling to the hope that Rust will finally make their code not suck are just one faction.
Re:poor craftsman (Score:4, Insightful)
That's because a good craftsman chooses his tools carefully and makes sure that they are right for the job.
Re: (Score:3, Insightful)
Contrary to this idea, I hope nobody expects a craftsman is able to do his best work with shitty tools and materials. If it were so, then why doesn't everybody just use the shittiest and cheapest?
Re: (Score:2)
Re:poor craftsman (Score:5, Interesting)
C is supremely tedious without necessarily providing benefit for it, and a lot of inconsistent approaches to development. Frequently needing to pass the length along with any data. Having to check every index before trying to use it. Is this function going to take a pre-allocated struct, or does it allocate new data. As the calling function, do I have to free memory allocated by the called function, or am I forbidden from freeing it because it's part of some static memory that the called function is reusing?
This all produces maintenance problems. Recently I uncovered a vulnerability in a C application owing to assumptions about index validation. At one point the author wrote function a, but it was only called by b. Because of that, he only bothered to check the index in b, because a was an internal function. Later, another developer wrote function c and needed a again. In this case c didn't need to process the parameter, so he just passed it through to a without checking, because there was no document saying that a required it to be checked for it to be safe. It was a detail that didn't seem significant at the time.
Another time I found a memory leak in a python application. It was due to C code returning some data to python, and the newly allocated memory was returned to python as a memoryview. So the C function couldn't free the memory since it was destined for python calling code and neither would python free the data. The developer *thought* that python would free memory if 'given' to python by the function call, but actually python won't do that, so the developer would have had to have provided a 'cleanup' function. But even if they did that, good luck getting a python developer to bother to explicitly call a cleanup function reliably, even if available, because that's not a tedium that is common to inflict on python developers.
There are a lot of details that have to be meticulously tended to, and a need for overwhelming clarity in communication about ambiguous issues that if not agreed upon can overflow, corrupt stack, or leak memory. With no good upside to these freedoms. Compared to a C-ish language, but with index bounds baked in as mandatory and memory allocation and freeing handled in the logical fashion, you get the upsides of C like strategy but without the messiness.
Re: (Score:2)
C is supremely tedious without necessarily providing benefit for it.
Very well put. It sure builds fast though.
Re: (Score:2)
That mindset has long been removed from the places where safety actually matters.
Eg, when an aircraft crashes, we don't just go and blame the pilot. Sometimes airplanes do weird, confusing things that pilots have trouble dealing with in a critical moment. Which is why we research what happened, and try to come up with solutions other than "the pilot should have done the right thing". Even in the cases where it's clear a pilot was just screwing around and did something they shouldn't have we often come up wi
Re: poor craftsman (Score:1)
Re: (Score:2)
Maybe it's not a popular opinion, but it should be said: He's a poor craftsman who blames his tools.
Every craftsman starts out as a poor craftsman. Some get better with experience.
But to do that they need a workbench and set of tools that lets them work, make mistakes, and learn from the mistakes. (It is said in some branches of engineering that "Expertise is directly proportional to value of equipment destroyed (during learning).")
There are tradeoffs here. The upside to padded rooms is that they don't l
Addressing complexity, fragility (Score:5, Insightful)
We've found over the recent years that the complexity of the existing C code, and the fragility of the C language, make it unnecessarily difficult to improve the code while maintaining our security and privacy guarantees....
It's one thing to try and address code that is "fragile" because of the latitude C allows programmers -- which is more a fault of the programmer than language -- in another language that may be more stringent (like Rust), but another thing entirely to rewrite code in another language simply because it's "complex". (a) There's no guarantee the fresh code will be any less complex and (b) this new code has to be re-proven -- especially if redone in a different language, that may have different idiosyncrasies. The latter also applies to rewritten "fragile" code, but with the consideration that it may be less so because of the constraints of the new language. Finally noting that all this could simply be addressed in the current C implementation -- but I guess that doesn't sound as sexy on a grant proposal...
Re: (Score:2)
Indeed. They will just swap one set of well-known and well-understood problems for a new set which is far less understood. I fail to see how that is a good thing.
Re: (Score:2)
Indeed. They will just swap one set of well-known and well-understood problems for a new set which is far less understood. I fail to see how that is a good thing.
It's a good thing if you're working on "Arti":
ZOMG announced on Tuesday that it is awarding the privacy-focused Tor Project a $670,000 grant to continue to develop Arti, a Rust coding language implementation of the Tor Client...
Re: (Score:2)
It depends on the codebase and I don't know the Tor codebase to specifically say whether it's along the lines of how you are thinking, but there is an alternative.
Long lived codebases can grow in very awkward ways, particularly with many hands. Chunks of functions that are awkwardly organized, unnecessarily convoluted compared to if the big picture was known from the beginning of coding. A rewrite is sometimes more straightforward than reworking a complex codebase.
The latitude that C offers inflicts a need
Tor has been made irrelevant (Score:3, Interesting)
If you run Tor securely to browse the web, you need the Tor browser. The Tor browser is essentially a declawed Firefox with all the possible features that can be used to deanonymize you disabled removed - chief of which is Javascript of course.
When you use the Tor browser in truly secure mode, the web is as good as unusable. If you don't use the Tor browser, then all you have is a false sense of security, as the NSA, Google and various other Big Data sumbitches have no trouble linking your traffic to your real persona. And that's exactly how they like it.
If you are a spy or a dissident and you do use Tor securely to connect to Tor-friendly services setup specifically for that purpose (be it http or some other protocol), then yes, it's a useful tool. If you're an ordinary internet dweller seeking to escape the constant corporate and state surveillance, look elsewhere.
Re: (Score:3)
Fragile means poorly designed and maintained code (Score:5, Insightful)
In my experience, "Fragile" means that doing updates that should be minor turns out to be a nightmare because of how easily simple changes breaks the whole application.
It also means that the code wasn't all that well written to begin with and changes have been made haphazardly with no regard to the new code following the same approach as previous code and are not documented.
Saying that the current code is "Fragile" means that the skills and processes aren't in place to develop robust code that is easily maintained.
As for "Complex", all code is complex, but that can be mitigated by a good initial design with documentation and proper maintenance procedures that update the documentation.
Re: (Score:2)
Usually if there is fragile code, the best approach is to refactor it rather than rewriting it. When you refactor it, you learn how to make it better. When you rewrite it, you make the same mistakes you made the first time.
Re: (Score:2)
I would tend to agree with you but in this case (like seemingly everything involving Rust) there is the desire to rewrite applications to something shiny and new.
I expect that a few years down the line they'll be saying that their Rust code is needlessly complex as well as fragile and the only solution to the problem is to write it in the latest flavour of the week.
Re: (Score:2)
"There is no silver bullet."
Complex and fragile (Score:1)
Can mean one of two things given working code:
A. The guy who wrote it doesn't work here anymore and no one here bothered to learn it.
B. He still works here but he is either incapable of clear communication so it's a wonder his code runs correctly or he's perfectly capable of speaking and writing clearly but he has an audience of size one.
In either case, the language isn't the cause, catalyst, or driver of the problem; all three can be found between someone's ears.
C "Fragile"? (Score:2)
Funny thing, some of the tools they used to develop Rust were written in C. Some of the things they used didn't state what they were made with, and I don't feel like digging into it that far, especially for a PLBKAC issue...
wrong tools (Score:5, Funny)
Re: (Score:2)
I've always used a grinder followed by a stiff metal brush on rust before applying the healing balm of primer.
This is what I'm looking forward to (Score:5, Insightful)
So I figure that in about 5 years, some Millennial is going to decide that Rust "sucks" because they didn't invent it, so they are going to invent a brand new language that "fixes all of the many problems with Rust while retaining the advantages", throw in some nebulous "security is better" phrases to boot, and then the "Rust is awesome" people are going to tell you with a straight face that they never really trusted Rust, but this new language is the real deal, let me tell you. Personally, I've never learned Rust and have no desire to use it, so I can't personally comment on whether it's any good or not, but after seeing all the unnecessary changes in IT in recent years, I can promise you that Rust will come under criticism soon enough. Remember that both Ruby and Python both had their days in the sun when they were supposedly "so much better than everything that came before" and neither of them could stop someone from coming up with Rust, etc.
Re: (Score:3)
Re: (Score:1)
Re: (Score:2)
I've used that argument before :)
One question (Score:2)
How do you get stability out of a language named after rotting metal? If a bridge rusts, it falls down. It doesn't get more stable.
Re:One question (Score:5, Funny)
It's a recursive acronym. RUST Until Something Trendier.
Re:One question (Score:4, Funny)
If a bridge rusts, it falls down. It doesn't get more stable.
Technically, a bridge that has fallen down _is_ more stable than before. :)
C is extremely tedious (Score:1)