The Rust Programming Language Finds a New Home in a Nonprofit Foundation (techcrunch.com) 62
Rust -- the programming language, not the survival game -- now has a new home: the Rust Foundation. From a report: AWS, Huawei, Google, Microsoft and Mozilla banded together to launch this new foundation today and put a two-year commitment to a million-dollar budget behind it. This budget will allow the project to "develop services, programs, and events that will support the Rust project maintainers in building the best possible Rust." Rust started as a side project inside of Mozilla to develop an alternative to C/C++. Designed by Mozilla Research's Graydon Hore, with contributions from the likes of JavaScript creator Brendan Eich, Rust became the core language for some of the fundamental features of the Firefox browser and its Gecko engine, as well as Mozilla's Servo engine. Today, Rust is the most-loved language among developers. But with Mozilla's layoffs in recent months, many on the Rust team lost jobs and the future of the language became unclear without a main sponsor, though the project itself has thousands of contributors and a lot of corporate users, so the language itself wasn't going anywhere.
That list is scary (Score:4, Interesting)
Sounds like we're going to continue to see select platform support with the financial backers listed. Too bad.
From a security perspective, rust is a good idea but it can't replace C if it can't run where C can.
Re: (Score:2)
What are you missing?
Re: (Score:2, Insightful)
He's not missing anything. C can run where rust can't. What part of that truth are you having a malfunction with?
Re:That list is scary (Score:5, Interesting)
But they are not really languages that are in direct competition.
Using Rust for say 85% of the projects over C may be a good idea, because you can still make good performance programs, that are more secure and for less effort.
However for the 15% of the programs where you need deep level control on what your computer is doing, C is a good choice. If you need precise control, then you need assembly, but then your program is very platform and OS specific.
For much of my stuff I actually don't even bother going down to the speed of using rust, and I do most of my work with slower interpreted languages such as Python. Because what I write often doesn't need to be blazing fast, just normal fast, and I can use Pythons robust higher level language to focus more on the algorithm vs the mechanics. Because I can often get my code programmed and running and completed in a much shorter time than me developing something that will save me 5 seconds off a run, that I normally run once a day.
Besides for me most programming isn't big apps, but what I call disposable programs. Meant to run and hang around for a few years, until work changes the IT Architecture again, where I would then need different sets of programs to fill in the gaps.
However if you need to make high performance stuff, that may be facing the general public, Rust may be a good choice, or go with C if speed or access to more computing is needed.
Re: (Score:1)
sure that's fine, if Rust runs there. However, the list of platforms where Rust won't run is at least 10 times as long as the list of where it will run even if we include the tier 3 and so it shall ever be. You won't be doing Rust on Z/OS or Z/VM on a mainframe or NonStop, nor on a very long list of controllers...
Re: (Score:3)
Doesn't the language just need to be ported to GCC and then all those problems are solved?
Re: (Score:2)
As has been mention in another thread, there isn't a formal spec for rust. That makes writing and maintaining a third party implementation difficult.
But yes, rust becomes significantly more portable if someone makes a gcc front end for it. But for that to happen, rust needs a "spec" beyond the implementation.
Re: (Score:2)
One thing I've found with using rust over dynamic languages, even for small admin-scripty-like things, is that when my code is written in rust, if it compiles then it works exactly the way I intended it to. Yes, it takes longer to write something in rust than say powershell, but it takes a hell of a lot less time to debug.
That, and for some reason, writing stuff in rust feels somehow satisfying, almost like playing and winning a video game type satisfying. I started learning the language back in September a
Re: (Score:2)
One thing I've found with using rust over dynamic languages, even for small admin-scripty-like things, is that when my code is written in rust, if it compiles then it works exactly the way I intended it to. Yes, it takes longer to write something in rust than say powershell, but it takes a hell of a lot less time to debug.
That's interesting.
I've always felt the same way about Ada.
Re: (Score:2)
Even within programs, there are parts that are performance-critical and parts that aren't. In many cases, you might be able to get away with writing the majority of your program in Rust and a few hot code paths in C or unsafe Rust. Or even Python with C modules.
Re: (Score:2)
True, you can write mixed languages apps. However for the life cycle of the App, you are opening the door for a lot of headaches.
Oh look that Rust code is calling a C module, the Rust Guru at the office, may have to switch to thinking in C, or reach out to the C Guru. Often when you need to swap languages, the secondary language, basically becomes a black box code, that you are afraid to alter, because it is more difficult to figure out its full impact.
I am sure people will say documentation, should cover
Re: (Score:2)
True, you can write mixed languages apps. However for the life cycle of the App, you are opening the door for a lot of headaches.
Also: Beware the perils of premature optimization. Are you sure going through the trouble of rewriting that chunk in C was the best way to increase the app's performance over a significant amount of time?
Comment removed (Score:5, Interesting)
Re: (Score:2)
and its PDP-11 view of how memory management works.
What memory management system is better? (Don't tell me automatic garbage collection, because that doesn't work everywhere C is needed).
Re: (Score:2)
Re: (Score:1)
Or maybe almost half a century of staying power just shows that most languages can't be a "high level low level" language, and C has won. I don't see any serious contenders at all for alternatives. Certainly not Rust.
And you don't even bring up writing OS and drivers, rust is missing a load there.
Anyone who brings up the toy Redox gets a punch in the snoot, thing can't even handle disk filesystem.
Re: (Score:1)
On the other hand, Rust integration into the kernel build system was proposed last year and contrary to the expectations, Linus not only didn't shoot it down but weighted in with some opinions of how it should be implemented: https://lkml.org/lkml/2020/7/1... [lkml.org].
Re: (Score:1)
Yes that's nice and all but meanwhile we have zero real operating system kernel code, Linux or otherwise, written in Rust. The kernel and system language wars are over, C won.
Re: (Score:3)
That's true for last century's OSs. A new OS would benefit from being built on something like Rust over something like C.
Re: (Score:2)
You're right. Nobody ever wrote an OS kernel in Rust.
Oh, wait...
https://www.redox-os.org/ [redox-os.org]
Re: (Score:2)
Re:That list is scary (Score:4, Insightful)
I think a better characterization of C than unsafe is similar to aircraft - C isn't unsafe, it's unforgiving.
After working with C for 30 years, the biggest "problem" with C is that it requires diligence. Most of the new languages out there exemplify the tradeoffs between freedom and responsibility: with C, you have the freedom to do anything, therefore you must act responsibly. I have never found a "critical" C bug that isn't a result of poor planning or process.
That said, this doesn't mean that there aren't places where trading off some freedom in exchange for letting a compiler or some other library be responsible for something isn't a sound engineering tradeoff.
My suspicion, though, is that we will never eliminate nefarious computer bugs: as soon as people get complacent about writing software, bugs emerge. I can't even fathom the new class of bugs that will arise to replace "trivial to implement" bugs like buffer overflows, simply because people think "oh I don't have to worry about X any more."
After all, a buffer overflow bug is almost never an implementation error but is a design error where such a condition was never considered in the first place. I'm strict though - I consider it a design error to have an implementation for which there are no requirements or design, or if an implementation is not checked against a design. Don't add functionality that isn't specified!
Re: (Score:2)
I can't even fathom the new class of bugs that will arise to replace "trivial to implement" bugs like buffer overflows, simply because people think "oh I don't have to worry about X any more."
XSS and sadly, sql injection (I say "sadly" because it's also trivial to avoid).
Re: (Score:2)
Indeed. Well said.
Re: (Score:2)
Re: (Score:2)
Sorry, you must not be a pilot: an aircraft absolutely can crash if you "steer in the wrong direction for a little bit". If you are low and slow during a landing, and you pull back on the stick for 1 second too long and stall, good luck.
The example of hiding mistakes is also a perfect example of being a design problem - the design didn't include requirements for "what to do with more than 4 characters." You can hand-wave that "the protocol says that it should only be 4 characters" - but that is an incompl
Re: (Score:2)
This is spot on.
The last time I used C was when I was writing kernel modules. I wouldn't use C for something that doesn't require it, because the amount of due dilligence it needs is astronomical - BUT if you have your guidelines and rules together, there's no reason why you couldn't write secure, good code in C.
It just doesn't hold your hand, and a mistake can screw you over royally.
Re: (Score:2)
After working with C for 30 years, the biggest "problem" with C is that it requires diligence. Most of the new languages out there exemplify the tradeoffs between freedom and responsibility: with C, you have the freedom to do anything, therefore you must act responsibly. I have never found a "critical" C bug that isn't a result of poor planning or process.
Rust gives you the same freedom, you just have to turn the safety off. But only do so in the right circumstances, and use due diligence. C was made before the concept of a safety switch was created, so the safety is always off.
After all, a buffer overflow bug is almost never an implementation error but is a design error where such a condition was never considered in the first place.
Even if you have a good implementation plan, the larger your code base grows, the higher the probability you'll run into bugs. Nobody anywhere ever can guarantee that their code will be free of bugs; they WILL make mistakes. Anybody who says they can write bug free code every time sho
Re: (Score:2)
A high-priority rule of safety critical code is: don't trust your compiler.
Either you can write bug-free code and therefore write a bug free compiler, or you can't write bug free code and therefore you cannot trust a compiler to "guarantee" you can't hit a class of bug.
Re: (Score:1)
no good reason why we need to write stuff like 'cat', 'echo', 'groff', et al, in C
Except they were already written and perfected, decades ago. Solved problems that C solved. Most OS are solved problems that C solved.
Rust is too late to the party for things where it could be used. Browsers, GUI, systems programming above kernel level. A LOT of competing languages in that space with massive IDE and library advantage.
Re: (Score:2)
Re: (Score:1)
No, my "complaint" is that Rust isn't a viable replacement for most thing with established infrastructure, and it will be a decade before Rust gets what it needs, if it turns out to not be yet another passing fad.
Sure, Rust can eliminate a class of bugs, that's great. Has potential, that's all. Missing a long list of stuff though.
You then do the silly Rust fan boi thing of point out this C program or that has bugs, as if Rusty folk won't write Rust code with bugs and have a whole long list of new types o
Re: (Score:2)
You're bashing on C while saying that Rust should be C++.. Not only has what you want been done for decades now, it was done in a way that is 99% compatible with C. Rust is cute, but there is no niche for it and the fact that Linus Torvalds has a stick in his ass about what he thought of the C++99 standard doesn't change that fact.
hello world is 200k (Score:3)
compile with release mode and then strip the binary.
c++ apps have drifted away from filespace-saving usage of dynamic libraries a long time ago, which is why we have things like flatpack, appimage, macos "apps" which are all the dependencies shoved in a subfolder, and finally the trend towards people saying "here, download my docker image - it would take you like forever to install all the same versions of the same dependencies"
static linking is there because it prevents an enormous amount of problems with
Re: (Score:2)
Re: (Score:2)
As a basic example, with the default configuration, a simple hello world application compiles down to a 10Mb executable on Ubuntu right now. With an option or two in the Cargo.toml I can halve that, but... and before the Go enthusiasts chip in, Go isn't much better, with 2M for a similar executable. Now, to put this into context, the 'cat' binary takes up a mere 43K.
Actually, your 43KiB for the cat binary is very misleading; that figure excludes a ton of stuff. It's really much, much larger than that:
https://users.rust-lang.org/t/... [rust-lang.org]
Rust by default builds a binary that is entirely self-contained. C doesn't really have a default, however in most cases it counts on the OS to provide much of its runtime and standard library, as shown in that link. If you want to build a minimal rust binary, try something like this:
https://docs.rust-embedded.org... [rust-embedded.org]
I'm able to build a 1536
RUST is not a good name. (Score:1)
We need people in technology to be more socially competent. That is not a good name.
Re: RUST is not a good name. (Score:2)
Let me tell you story:
bear with you
bear just ate you.
story over.
Re: (Score:2)
Bears.
Beets.
Bears eat beets.
Bears. Beets. Battlestar Galactica.
Re: (Score:2)
Yep, better name them Befunge, Brainfuck, INTERCAL, JSFuck, LOLCODE or Malbolge.
Re: RUST is not a good name. (Score:2)
If you think iron oxide is useless, you clearly have never had fun with thermite! :D
Also, if you had looked up from your literal bean counting for once, you'd have realized the name is symbolic for big iron machines, like ships, heavy industries, and a certain style of post-apocalyptic scifi.
And if you don't think that is cool, you're not cool.
Re: (Score:2)
Worse than Devuan?
Re: (Score:2)
Perhaps to the uninitiated it's a bad name, but does anyone who's a software developer really stop to think about associations between a programming language name and it's usage in the common language? Do you start thinking about coffee whenever someone mentions a Java program or snakes when someone talks about a Python script?
The name is the least of Rust's concerns as a programming language
Re: (Score:3)
... or snakes when someone talks about a Python script?
No, I tend to think of silly walks, or cheese shops without a scrap of cheese.
Re: (Score:3)
Re: (Score:2)
In the case of git, I certainly do. Whoever decided it should be the de facto version control system for the computer industry is a total git. Also, it rhymes nicely with "shit". "git is shit", see. Git has totally destroyed all innovation in software version control systems, which would be fine if it wasn't terrible.
Also, "Gimp". Whoever thought of that na
Re: (Score:2)
I guess I won't tell you about the MOLD and MILDEW projects.
For a language that is supposed to replace C/C++.. (Score:3)
... they took very a long time to integrate inline assembly properly. Not until last year in fact. Maybe Rust will replace C++, maybe it wont. But this hardly demonstrates a commitment to the to-the-metal coding that C is used for. If I want a C++ alternative for app dev, Java has been around for 25 years. Why would I use rust?
Re: (Score:2)
Performance. Despite decades of trying, languages like C# or Java (even with JIT compiling) still can't match the performance of C++ or Rust. They can get fairly close, but I'd guess there are too many abstractions that aren't friendly for modern-day CPU caches.
Most applications, of course, don't have such stringent performance requirements (the popularity of Electron apps clearly demonstrates this). In that case, Java or C# are likely superior choices, especially for back-end work. No one with a brain
Re: (Score:2)
Compared to Java, Rust has significantly smaller binaries, faster startup, 3-4x lower memory use and about 2x the speed - these may or may not matter to you.
GraalVM takes care of some of those to some extent though.
Re: (Score:2)
As somebody who actively uses both Java and Rust, I have to say, Java pisses me off, and Rust doesn't. Forget speed, forget memory, forget binary size, and forget the fact that you have to make sure somebody has a compatible version of the various JREs out there in order to actually run your code; the reason Java pisses me off is because it lets other programmers get away with the most god awful annoying shit, and then pass it to you to debug it when their god awful annoying shit doesn't run right.
By god aw
"Today, Rust is the most-loved language ..." (Score:1)
Re: (Score:1, Troll)
Rust the language most developers want other developers to use. They want nothing of it themselves.
Still not specificaiton (Score:5, Insightful)
There is still not formal specification given for Rust which means Rust is exactly what they claim it is. This make a third-party compiler impossible as they may break it at any moment.
Re:Still not specificaiton (Score:4, Insightful)
There is still not formal specification given for Rust which means Rust is exactly what they claim it is. This make a third-party compiler impossible as they may break it at any moment.
I don't see this as a big problem, at least not in the short-to-medium term. I'd rather the language has some wiggle room to throw out or fix misfeatures if necessary, then to immediately force it into a backwards-compatibility straightjacket for the next 50 years, and require the next N generations of programmers to learn what parts of the language are broken and should be avoided. That way lies C++. :/
At some point they will need to formally specify everything, of course. But there's no huge hurry; even a third-party compiler is perfectly doable, as long as its implementers are okay with being required to update it if/when necessary... which is something e.g. C++ compiler writers have to do periodically as well, formal language specifications notwithstanding. In the meantime, they can see what works in practice and what doesn't, and proceed accordingly.
Rust the programming language, (Score:2)
not the oxide of iron.