Slashdot Mirror
Rust 1.0 Released
TopSpin writes: Rust 1.0 has arrived, and release parties in Paris, LA and San Francisco are taking place today. From the Rust Programming Language blog: "The current Rust language is the result of a lot of iteration and experimentation. The process has worked out well for us: Rust today is both simpler and more powerful than we originally thought would be possible. But all that experimentation also made it difficult to maintain projects written in Rust, since the language and standard library were constantly changing. The 1.0 release marks the end of that churn. This release is the official beginning of our commitment to stability, and as such it offers a firm foundation for building applications and libraries. From this point forward, breaking changes are largely out of scope (some minor caveats apply, such as compiler bugs)." You can read about specific changes in the changelog.
Running out of words to call those next big things?
And the 3 users outside of Mozilla must be excited.
Apparently not that RUST.
So why should I use Rust instead of the languages I'm currently using (Ada and Racket)?
From the headline, I thought it was Rust the game.... Then I thought, typical of /. to be way behind on a story as Rust the game hit 1.0 a while ago. If you haven't played Rust (the game) it is way more fun then Rust the language.
Mozilla tries to reinvent a bicycle
Rust is old and creaky. Now introducing Shiny! It is the programming language that gets rid of all cruft of Rust and adds a layer of NICKEL (Non-Intrusive Code Keying for Easy Learning) to make your programs shine forever. It is a high level language that anyone can learn to code in, but brings almost assembly level of performance.
Get Started Coding Today!
https://www.youtube.com/watch?...
Microsoft, Apple, Google, Amazon what's the difference? All steal money from devs and control with walled gardens.
Ruby on Rusty Rails?
Imagine if MSFT had their Rally defects public...
Rust would have been useful 5 years ago. But now there is no reason to use it. Go, C++14, Ada 2012, OCaml, D, Scala, and even C# (now that core .NET code has been opened sourced and ported to non-Windows systems) offer everything Rust does, plus more. Somebody will probably claim that Rust "isn't competing with those languages", but in reality it is, and it's way behind them. Rust could have been a game changer, but like Perl 6 its developers just couldn't get a stable major release out on a reasonable schedule. Too many years went by and the alternatives became better options.
Job postings for Rust on Dice will require five years of experience for a programming language that came out six months ago.
They could have made the same simple concepts without going C++ style. This is obviously just aesthetics, but I don't think the language looks nice compared to lots of newer languages (Swift, Ruby, Kotlin, and even D).
The :: scope operator is ugly and redundant.
This match syntax is just ugly and hard to type:
match header[0] {
1 => Ok(Version::Version1),
2 => Ok(Version::Version2),
_ => Err(ParseError::InvalidVersion)
}
The following is ugly and is not obvious:
use std::sync::{Arc, Mutex};
use std::thread;
use std::sync::mpsc;
fn main() {
let data = Arc::new(Mutex::new(0u32));
let (tx, rx) = mpsc::channel();
for _ in 0..10 {
let (data, tx) = (data.clone(), tx.clone());
thread::spawn(move || {
let mut data = data.lock().unwrap();
*data += 1;
tx.send(());
});
}
for _ in 0..10 {
rx.recv();
}
}
A simple printf function has to be a macro, because the techniques it uses are unsafe which is a main feature of the language.
OK a lot of these gripes are trivial; I guess I'm getting at the fact that they went an academic route about how to deal with pointers and memory allocation safely, and then built everything around that. It was so academic and engineering-like and they didn't think or try very hard about the design and aesthetics.
Just because the U.S. is a republic does not mean it is not a democracy. Democracy/republic are not mutually exclusive.
What's the relevance of this exactly? I'm not sure how Microsoft having bugs in their software somehow cancels out the ton of bugs in the Rust compiler, it's standard library and the software project that is its biggest consumer. Does the Rust bugs somehow cease to exist because bugs exist in Microsoft software? Do their severity somehow change because Microsoft has bugs in its software? Come back when you have an actual argument not "BUT MICRO$OFT!!!"
Comment removed based on user account deletion
But when I see years of experience in a job posting it usually is like this:
X years of experience in backend/functional programming/frontend/relational databases like (java/ruby/C#)/(clojure,erlang,scala)/(javascript,html,css)/(oracle,sql server,mysql). Bonus points if you have experience with Y technology.
Which is sensible, even though rust might be only a couple of years old when you want a senior dev you want one that has been dealing with these kinds of problems for many years, even if most of those years were not in the right language. So expect a rust ad to say:
10 years with a low-level programming language (Rust/C/C++/Assembly), bonus points if experienced with Rust.
So, is that like a Python or D commitment to stability, or a C/C++ level commitment to stability? Exactly how committed are they to preserving to preserving backwards compatibility through hell and high water? Because that's why people trust C/C++ - they know that the language committees are not going to suddenly "fix" the language by making billions of lines of code obsolete, simply because it was written fifteen years ago before a bunch of new shiny features have been added.
I think widespread adoption is going to remain limited until it becomes clear how Mozilla plans to shepherd and develop this language as well. Will it become standardized? Will mature cross-platform tools become available? What will the performance penalties be to optimized C or C++ code?
I wish Rust all the best. It's going to be difficult to unseat C/C++ simply due to inertia, as well as convincing programmers of the merits of an entirely new language, but I like the idea of a memory-safe language that doesn't require a runtime or use managed memory.
Irony: Agile development has too much intertia to be abandoned now.
My post was flamebait? In what way exactly? Or did someone just get butthurt that I didn't go "Yeah, you're right. Hurr hurr micro$oft sucks!! Hurr hurr!"
They're already beginning to at least replace some components in Firefox with Rust ones, and they have another entire browser they're slowly writing in Rust (although some components are still in C++).
I think at this point, you either stick with what you know, go for the new language that you feel has the most momentum in your field/market, or pick the one that you feel will help you the most and try to see if it will. Waiting for adoption is just an excuse to not be an adopter yourself. If Rust interests you, be an adopter if you can. It's not like it has the support of a Google or Apple behind it, making it a big part of their ecosytems as quickly as possible. It needs interested parties to do their part, too.
When you have a release party and no reference implementation (i.e. hardware HAL to UI).... language isn't going to gain much attention in a few months.
How to tell if you're out hipster-ing your trendy, Brogrammer self:
Your next-big-thing programming language is having simultaneous release parties Paris, LA and San Francisco.
Hire a Linux system administrator, systems engineer,
Whenever Rust comes up for discussion at HN, and somebody points out a problem with Rust, or even just doesn't write something blindingly positive enough about Rust, that person is almost guaranteed to be mobbed by downvoters. The same appears to be happening here. Maybe this should not be surprising, though? Most people who like Rust are Millennials. Millennials are notoriously thin-skinned, can't stand legitimate criticism, and love to censor people. We're probably just seeing them act as the petty little tyrants that Millennials like them tend to be.
Imagine if you had an actual argument...
You can do whatever you want with pointers (although the things that are UB in C will tend to be UB in Rust also), you just need to do so in an unsafe{ .. } block. The improvement over C/C++ is that you won't trigger UB by accident while using the safe subset of the language, and the vast majority of the time you will be able to do what you want in that subset.
Waiting for adoption is just an excuse to not be an adopter yourself.
No, it's waiting for Mozilla to actually prove the language is viable.
Same here. And really, most pointer vulnerabilities go away when you code carefully, and finding the rest with things like Valgrind works well if you actually have thought about testing when you designed your code. And in really critical places, you can always do check-before-use and fail gracefully instead of insecure. Of course, all these things require that you know what you do. Things like Rust are an insult to those of us that do.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
The improvement over C/C++ is that you won't trigger UB by accident while using the safe subset of the language, and the vast majority of the time you will be able to do what you want in that subset.
I can do the same thing in C++ using a safe subset of it as well without needing to learn a new language and waste man years porting software. No one doing modern C++ should be dealing with raw pointers outside of exceptional cases.
Plus, they have yet to even prove the fact that Rust is good at what they claim it's made for. C and C++ didn't win over programmers through hype. They won over programmers by being proven through real-world applications. It's easy to talk up a language, it's much harder to back that talk up with real-world results.
It looks interesting, but they need to work on their documentation. I wasn't able to find anything about reading and writing random access files. It had many things that appear easy to do in Rust which are difficult in various different languages, but I couldn't find a way in which it was notably better overall in any area.
FWIW I was mainly comparing it against D and Python, with a few considerations of Ruby. I should have compared it against Ada, but it's been too long since I actually used it. I can't reasonably compare it against C++ as I haven't used it significantly since the STL was adopted. (At that point I was stuck using access basic, and relatively to that nearly *anything* looks good.) The only fortran I could compare it against is FORTRAN IV, and they are nearly disjoint in the tasks that they would be good at.
Mind you, this comparison is based purely on reading over the documentation, and shouldn't be taken too seriously. So often the contents of the package doesn't match what it says on the packaging. Given what it says on the packaging my favorite language would be Vala, but actually I never use it.
I think we've pushed this "anyone can grow up to be president" thing too far.
The more the compiler can protect me from past-me, the better. And certainly from my coworkers.
Look, I don't get how Rust deals with circular references at all (screw you, leak, I think). But the way to train better coders is to get them up on standards. Why you wouldn't want those standards enforced by the compiler I have no idea.
I read the Rust documentation (what 1/2 or 1/4 or something of it there was). Okay ideas, but not terribly interesting. But if I could snap my fingers and code that didn't meet the coding standard I used wouldn't compile. That would be amazing.
Your ad here. Ask me how!
The issue tracker in Rust is used not only for bugs in the compiler, but also for tracking the standard library, new features, enhancements, some infrastructure, documentation, lints, etc. Assuming that 1900 open issues means there are 1900 bugs is ridiculous. If you look at the labels used on the issues tracker, you'll find that the label I-crash has 19 open issues. Of course not all bugs will be labelled correctly, so no doubt there will be more defects, but hardly the number that the 'worried' anon suggests. Also note that the language has changed significantly over the years, until it reached the current design. To look at some of the older bugs and conclude that the current version of the language can't be very good is silly because the rust of two or three years ago might as well have been a completely different language. As for servo, looking again at the label I-crash, I see (at this time) 39 open issues, which sounds much more reasonable than 800.
while baby boomers created the cyber war domain and did one major FALSE FLAG WAR, just like hitler did.
does it hurt already or do you need more ?
rust and swift are attempts at closing down the horribly insecure and dangerous world of BELL LABS CYBER WAR DOMAIN.
You must be responding to the wrong person. My response was to the ridiculous "But Microsoft!!" post. The person who was pointing out all the issues was the GP of my post.
Why you wouldn't want those standards enforced by the compiler I have no idea.
This reeks of strawman. GP never said or implied any such thing.
a deterministic crash is infinitely better than the c++ STORAGE CANCER which enable chen, ivan and john to lurk in your kernel and suck off your latest blueprints along with key material.
memory safety is not about perfect code, it is about perfect, deterministic, debuggable crashes.
a stopped computer is much better than a pilfered one. kapiert ?
Do those smart pointers also solve iterator invalidation? :)
I ignored the AC because, well, AC. But you repeated the claim of 'a ton of bugs', so replying to you seemed worth it at the time.
Never claimed smart pointers solve all problems because that would be ridiculous. If you have cases that a smart pointer doesn't solve then clearly you would need to use the correct solution. But for the vast majority of cases that people use raw pointers for, they can be substituted with something safer and remove a whole host of potential bugs from their code.
Because there are a ton of bugs. Trying to claim there is only 19 bugs out of 100s of issues is complete silliness.
Oh and to add, it's quite interesting that you ignored the "ICE" label that reports over 200 issues reporting internal compiler errors.
It's also silly to be hell-bent on focusing on bug counts when ALL languages have hundreds of bugs if you include all of the criteria that the commenter just told you about: specific compilers, documentation, site infrastructure, etc. It's rich enough to try to make some sort of assessment of a language based on bug counts alone, especially one that has had such an open development that we got to see all of the massive changes made to it over time in public. I wonder how many bugs Swift and Go had on their path to 1.0 and beyond?
"Assemblers are an insult to those of us that know what we're doing."
"High level languages like Fortran and C are an insult to those of us that know what we're doing."
"High level scripting languages like Bash are an insult to those of us that know what we're doing."
"High level languages Java are an insult to those of us that know what we're doing."
Of course not all bugs will be labelled correctly,
Don't worry. Somebody is keeping track of that on 3 by 5 index cards in a shoe-box.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
There is no useful subset of C++ that is a) statically checkable and b) guarantees absence of dangling pointers and null dereferences.
Your point? That other people say things that _sound_ like what I said does not invalidate my point in the least.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Indeed. And I have the impression that Rust is not nearly that good, and hence an intense marketing campaign is done.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
It certainly is implied that he is against creating languages that enforce certain standards. Note, almost all standards include "Thou shall not"'s for some language features. You practically have to in C++. I mean, I don't know any (modern) standard that would let you pass and cast tons of void*'s around as the standard case.
Your ad here. Ask me how!