If passwords expire in just 30 days people will either stop picking good passwords or start writing them down (they'll probably do both). A password should be usable for several months at least.
> It's a chicken and egg situation. Do they advertise to women less because fewer women click ads for high paying jobs, or do fewer women click ads for high paying jobs because they advertise them to women less?
Let's assume google is not completely retarded, surely they measure the effectiveness of an add by looking at how often it was clicked compared to how often the add was shown (click-through rate). Or do you really believe they only count the absolute numbers?
* Note: if you set DNT=1, it is possible that you may not be receiving Suggested Tiles. You can very simply enable them on the new tab page with the cogwheel. We made the decision to opt users out of all sponsored Tiles experiences if they have DNT=1 quite early on, as we believe that most DNT early adopters are seeking to opt out of all advertising experiences. However, it’s important to understand that no tracking is involved in delivering Tiles.
let badref: &u32 = unsafe { std::mem::transmute(0 as *const u32)};
But doing this trick is UB in both C++ and Rust, so it's not really fair to hold it against either language. Having said that, one advantage of Rust would be that it is impossible to create such a bad reference without using an unsafe block, while in C++ it seems much easier to do so by mistake.
But C++ does not allow references to references, arrays of references, and pointers to references. Rust has all these things, while still being able to ensure that the references are valid.
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.
Re:Make better language, not better coders.
on
Rust 1.0 Released
·
· Score: 1
Do those smart pointers also solve iterator invalidation?:)
Re:I'm worried by what I see.
on
Rust 1.0 Released
·
· Score: 4, Insightful
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.
Re:Commitment to stability
on
Rust 1.0 Released
·
· Score: 4, Informative
> What will the performance penalties be to optimized C or C++ code?
Some of the guarantees that the Rust type-system provides could theoretically allow better optimization than C/C++. For instance, when you have an immutable reference (&something)to a object of a type that does not have internal mutability (that means the vast majority), that object is guaranteed to be immutable for as long as your reference is alive (note that this guarantee is stronger than that offered by a const *). And when you have a mutable reference (&mut something) your pointer is guaranteed not to alias, so once again your object is immutable except for the changes that you choose to make. You could say that all &mut T references are T *restrict. In addition, references in Rust are guaranteed to be non-null. All this extra information offers opportunities for optimization. Note that (AFAIK) not all this information is being communicated to the LLVM back-end at this time.
In short, I do not expect performance penalties.
Re:Make better language, not better coders.
on
Rust 1.0 Released
·
· Score: 3, Insightful
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.
High speed internet is a relatively new thing. I think it's safe to say that there was barely any online movie piracy twenty or thirty years ago. Were movie tickets $3 back then (or really $1.95 / $1.38, when we adjust for inflation)?
It's not really a useful general purpose computer that you can carry around unless the keyboard, mouse, required usb-hub, cables, and screen also fit in your pocket. Whenever you get to a location where all that stuff is present, then there is probably already a computer present (otherwise why would all that stuff be lying around?). Now compare with a good usb memory stick: you don't have to connect all those cables, and it has much more storage for the same price.
No, because it would take some time for the far galaxy to interact with the mid-way galaxy, and it would take some time for the mid-way galaxy to interact with our galaxy, and if we add those times we find that while we were waiting the mid-way galaxy has also moved out of our range.
The Rust language is intended to reach version 1.0 soon (either before the end of the year or early 2015), which comes with the promise of being backwards compatible. However the Rust standard library is still undergoing stabilization and parts of it may still change for a while. Right now a lot of work is being done in that area, to stabilize the most important bits.
Mozilla is also working on Servo, a research-project to develop a browser engine in Rust. The goal is to experiment with more parallelization in the browser, and Rust is supposed to help by making it easier to write correct multithreaded code. To do this Rust has a strong focus on ownership of data.
Rust can run without a runtime and the standard library is split up into several parts (which is not invisible to users of the standard library) that can be used separately when you choose to compile without the standard library. The advantage is that when you target, say, a platform that does not support dynamic memory allocation, you can still use the parts of the standard library that do not require allocation (liballoc). Or you can go without libc bindings. So it is relatively easy to run Rust on bare metal. You could write an operating system in Rust if you wanted to (and I think some people are trying to do just that, but I haven't heard from them for a while).
C is great for low level stuff since it is capable of generating machine code that has zero dependencies. K&R even explicitly mentions "non hosted mode" with no libc and implementation defined entrypoint semantics. In fact, it is the only language in mainstream use today that has this feature (aside from assembly.)
I very much doubt that is true. For instance, I think Rust can also make that claim.
Well someone has to make sure that the ads are actually unintrusive. Should the people from ABP do that for free, or should we take the advertisers word for it?
Your statement is shit. "Some guy I knew a long time ago once used threads for some unspecified purpose and when he got to thousands of threads it become very slow". Well that is just great. What was he trying to do? How was he trying to do it? You act like your anecdote proves something but without this information it contributes nothing to what could have been an interesting discussion.
Since the discussion was originally about COBOL, are you suggesting that language is more suited to massive multithreading than Java? If so, why? And if you truly need thousands of threads, perhaps you need Erlang?
Irrelevant, an actual testdrive is also not going to cover all possible scenarios, and appears to be sufficient at this time. Remember, perfect is the enemey of good.
Someone who deliberately cuts off their own legs with a chainsaw don't get sympathy. So why should addicts?
I imagine someone who would do that on purpose must be suffering from some serious mental problem, or must have been blackmailed or under some kind of duress. Certainly they do deserve sympathy and help.
Slashdot Mirror
If passwords expire in just 30 days people will either stop picking good passwords or start writing them down (they'll probably do both). A password should be usable for several months at least.
> It's a chicken and egg situation. Do they advertise to women less because fewer women click ads for high paying jobs, or do fewer women click ads for high paying jobs because they advertise them to women less? Let's assume google is not completely retarded, surely they measure the effectiveness of an add by looking at how often it was clicked compared to how often the add was shown (click-through rate). Or do you really believe they only count the absolute numbers?
I heard they'll make you an offer you can't refuse.
* Note: if you set DNT=1, it is possible that you may not be receiving Suggested Tiles. You can very simply enable them on the new tab page with the cogwheel. We made the decision to opt users out of all sponsored Tiles experiences if they have DNT=1 quite early on, as we believe that most DNT early adopters are seeking to opt out of all advertising experiences. However, it’s important to understand that no tracking is involved in delivering Tiles.
Not that hard in Rust either:
let badref: &u32 = unsafe { std::mem::transmute(0 as *const u32)};
But doing this trick is UB in both C++ and Rust, so it's not really fair to hold it against either language. Having said that, one advantage of Rust would be that it is impossible to create such a bad reference without using an unsafe block, while in C++ it seems much easier to do so by mistake.
But C++ does not allow references to references, arrays of references, and pointers to references. Rust has all these things, while still being able to ensure that the references are valid.
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.
Do those smart pointers also solve iterator invalidation? :)
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.
> What will the performance penalties be to optimized C or C++ code? Some of the guarantees that the Rust type-system provides could theoretically allow better optimization than C/C++. For instance, when you have an immutable reference (&something)to a object of a type that does not have internal mutability (that means the vast majority), that object is guaranteed to be immutable for as long as your reference is alive (note that this guarantee is stronger than that offered by a const *). And when you have a mutable reference (&mut something) your pointer is guaranteed not to alias, so once again your object is immutable except for the changes that you choose to make. You could say that all &mut T references are T *restrict. In addition, references in Rust are guaranteed to be non-null. All this extra information offers opportunities for optimization. Note that (AFAIK) not all this information is being communicated to the LLVM back-end at this time. In short, I do not expect performance penalties.
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.
High speed internet is a relatively new thing. I think it's safe to say that there was barely any online movie piracy twenty or thirty years ago. Were movie tickets $3 back then (or really $1.95 / $1.38, when we adjust for inflation)?
Sure, disable javascript. Alternatively, run Firefox + NoScript and distrust everything by default.
It's not really a useful general purpose computer that you can carry around unless the keyboard, mouse, required usb-hub, cables, and screen also fit in your pocket. Whenever you get to a location where all that stuff is present, then there is probably already a computer present (otherwise why would all that stuff be lying around?). Now compare with a good usb memory stick: you don't have to connect all those cables, and it has much more storage for the same price.
Here in the Netherlands the government isn't even in the capital... :-)
No, because it would take some time for the far galaxy to interact with the mid-way galaxy, and it would take some time for the mid-way galaxy to interact with our galaxy, and if we add those times we find that while we were waiting the mid-way galaxy has also moved out of our range.
The Rust language is intended to reach version 1.0 soon (either before the end of the year or early 2015), which comes with the promise of being backwards compatible. However the Rust standard library is still undergoing stabilization and parts of it may still change for a while. Right now a lot of work is being done in that area, to stabilize the most important bits.
Mozilla is also working on Servo, a research-project to develop a browser engine in Rust. The goal is to experiment with more parallelization in the browser, and Rust is supposed to help by making it easier to write correct multithreaded code. To do this Rust has a strong focus on ownership of data.
Rust can run without a runtime and the standard library is split up into several parts (which is not invisible to users of the standard library) that can be used separately when you choose to compile without the standard library. The advantage is that when you target, say, a platform that does not support dynamic memory allocation, you can still use the parts of the standard library that do not require allocation (liballoc). Or you can go without libc bindings. So it is relatively easy to run Rust on bare metal. You could write an operating system in Rust if you wanted to (and I think some people are trying to do just that, but I haven't heard from them for a while).
C is great for low level stuff since it is capable of generating machine code that has zero dependencies. K&R even explicitly mentions "non hosted mode" with no libc and implementation defined entrypoint semantics. In fact, it is the only language in mainstream use today that has this feature (aside from assembly.)
I very much doubt that is true. For instance, I think Rust can also make that claim.
Said the Anonymous Coward...
Well someone has to make sure that the ads are actually unintrusive. Should the people from ABP do that for free, or should we take the advertisers word for it?
Also, memory protection creates lazy programmers. If you have to reboot every time you screw up you will quickly learn to screw up a lot less.
So what's it like programming on DOS in 2014?
Your statement is shit. "Some guy I knew a long time ago once used threads for some unspecified purpose and when he got to thousands of threads it become very slow". Well that is just great. What was he trying to do? How was he trying to do it? You act like your anecdote proves something but without this information it contributes nothing to what could have been an interesting discussion.
Since the discussion was originally about COBOL, are you suggesting that language is more suited to massive multithreading than Java? If so, why? And if you truly need thousands of threads, perhaps you need Erlang?
Are you seriously suggesting COBOL is more suitable for massive multi-threading than Java?
Irrelevant, an actual testdrive is also not going to cover all possible scenarios, and appears to be sufficient at this time. Remember, perfect is the enemey of good.
Someone who deliberately cuts off their own legs with a chainsaw don't get sympathy. So why should addicts?
I imagine someone who would do that on purpose must be suffering from some serious mental problem, or must have been blackmailed or under some kind of duress. Certainly they do deserve sympathy and help.