computerphage

Cruise was bought for a billion dollars. Argo got a billion dollar investment.

For context: there's a rewrite of the rust book in progress for a while now. This is a chapter of that book.

No, even in theory there's an advantage to having information only available at runtime. Some optimizations depend on the probability distribution of data coming in (eg. an optimization for a CSV parser that makes it faster when dealing with well-formed CSVs that would slow the program down if it starts getting a lot of mis-formatted CSVs). The compiler can choose one or the other, but not both. The JVM can effectively choose both by deciding during execution.

If the compiler is allowed to embed a JIT or other runtime system, then all bets are off.

I would recommend this link actually: https://github.com/rust-lang/rust/milestones?state=open

Sorry Manish, I had meant that you can have code that can be built using a stable compiler while still using Clippy via another means. I typically use stable, but I run clippy on my code anyway. I realize that my post is confusing, I'll edit.

Don't worry. The Rust community is sensitive to the desire to only install Rust with a package manager. There was even talk (a few days ago) of making an LTS version of the Rust compiler for use in more conservative distros that don't want to update it every 6 weeks.

On another front, Rust is working hard to get people off of nightly. This project, for example, uses 3 unstable features. Clippy can already work on stable (edit: code that is linted with Clippy can also build on stable in some setups), Custom Derive will be stable in less than a month, and inclusive ranges is a pretty minor feature.

I would expect this project to begin working on stable for Rust 1.15, but I'm not affiliated with it directly, that's just my guess.

Rust can already take advantage of the C ecosystem quite easily. Rust/C++ usability is a major goal for 2017. I'm hoping that by year end you can have the best of both worlds. The advantages of Rust for new code and the mountain of code that exists for C and for C++.

Can you explain why?

There are a lot of reasons. There's a terrific in-depth discussion of D on the Rust subreddit from a few weeks ago. https://www.reddit.com/r/rust/comments/5h0s2n/what_made_rust...

> at least one feature that won’t get stabilized ever: > #![feature(plugin)]

> This is how they are utilized by Diesel, for example, a popular ORM and SQL query interface; or Serde, a serialization framework.

Diesel and Serde are going to be fully available on Rust 1.15, which is < 6 weeks away. This is actually an example of the complete opposite: the Rust project is working hard to get important projects to work on stable Rust so that people don't need nightlies.

It would be nice to have access to an overloadable index operator that works on multiple dimensions at once (like C#'s [1, 2, 5] syntax). It's sometimes not easy to write something to be efficient if it has to go one-by-one like [1][2][5].

You don't have the ability to edit to your own source code.

Airgapped systems have been attacked in the past. Stuxnet is a good example. No magic required.

Otto did that test, not Freightliner.

No, they will charge you a fee called an overdraft fee for the "service" of allowing you to purchase the item. They basically extend you a small line of credit (there's some upper limit before they will deny the purchase) and then charge you, say, $35.

Credit cards are always overdrawn in the sense that the bank has extended you a line of credit, but they don't have a fee associated with typical use.

The bug depended on iterating through every item in a hashtable and putting it into a new hashtable AND the new hashtable had to not start with a known capacity. That's a pretty specific edge case, IMO. Plus it's been addressed.

"rumored memory issues" just sounds like FUD.

I don't agree that panics are exactly equivalent to exceptions in languages like Java or Python because the language doesn't support using them as a general purpose error handling technique by providing `try/catch/finally` or by documenting what exceptions may be thrown with `throws`. I agree that the implementation of unwinding is similar in both cases, but I'd argue that that's not sufficient in practice to be able to apply knowledge about the usage of exceptions in, say, Java to the usage of panics in Rust.

I'm aware of catch-panic and the unwinding related to panics. Nevertheless, the vast majority of panic usage I've seen is related to the semantic that a panic signals an error that is fatal to the context of the panic. (This is a more nuanced view of panics that didn't exist in my previous post.)

Yes, you can use catch-panic on a server that is meant to stay up even if one of its threads panics. Or you can replace unwinding with aborting to save on code size. But idiomatic Rust code doesn't use panics simply to signal to a caller that some sort of typical error occurred like a file not existing.

Edit: I realize that my post may come across as arguing over semantics. I really don't care whether they're called exceptions or panics or even if they're mechanically the same thing. What I'm trying to talk about is whether they cause code to become harder to understand because of implicit error cases that are invisible in the source.

2nd edit: I appreciate your several good points in your replies to my posts.

I think people would be more inclined to try to understand your perspective if you hadn't called Rust's design "jumping on the bandwagon", which, to me, implies a thoughtless act of conformity rather than a deliberate trade-off towards explicitness. To me, verbosity is bad, but implicitness is worse. I like the trade-off that ? (the question mark operator) has stuck for Rust.

I agree that OOM handling in Rust should be improved.

I don't agree with the way you talk about panics. They aren't just exceptions by another name because they're not intended to be used for handling expected errors (like exceptions are). Instead, they terminate the program. That's like attacking Java's System.exit() for not being just another exception. Many other environments share this distinction between fatal and recoverable errors. It can sometimes be a difficult choice to choose what to use, but having panics doesn't mean that all code must somehow try to handle them.

Incremental compilation is stabilizing on Nightly. It won't help the initial compile, but waiting even 5-10 Minutes when I start working on a new codebase doesn't really matter to me. It's only the incremental speed that I care about.

I consider "not having exceptions" to be a feature that the ? operator helps to enable. Go also doesn't have exceptions, but they don't have the ? operator, which I find to be a little repetitive while coding. My fingers are outrageously good at:

if err != nil { return err }

Comparing Rust to a language with exceptions, like Java, the only difference is that they places that the code can return is explicit rather than implicit, because of that one extra character. I find this extremely pragmatic since most of the time errors just need to be propagated up to a place where they can be handled, but you still need to know when that may happen.

Please don't say "no re/mote" because people search for "re/mote". Instead say "Onsite".

> function names are not subject to rot

I don't agree with this. I think often a function will drift from its name if functionality is added to an aspect of its implementation or because of refactoring.

This is the almost the same example. Function names also don't execute. The parent's point was that if the code has been tested or was considered working, and then you noticed this in the code, you should think twice before "fixing" the behavior to match the comment or function name.

It's outrageously unlikely that either of those people had a prion disease. See my reply to your previous comment for details. The median duration of CJD (which is the most similar to nvCJD and the best proxy for the statistic I could find easilty) is 4 months. That's duration of the disease before death. If the commenter had those symptoms because of prion disease, I'd estimate a greater than 50% chance he'll be dead by February. Again, it's extremely unlikely that he had prion disease.

Prion disease has a case-fatality rate of 100%. That's not an estimate or approximation and it's not rounded up. They are also untreatable.

There are only five well studied prion diseases (because of their rarity). Two are exclusively heritable: fatal-familial insomnia and Gerstmann–Sträussler–Scheinker syndrome. One, Kuru, is transmitted via cannibalism.

The incubation times are extremely long. Some estimates for Kuru go up to 20-50 years.

The most prevalent form of prion disease in humans is new variant Creutzfeldt–Jakob disease (nvCJD) or Human Mad Cow which has a lag of about 10 years based on CDC data. It is transmitted by eating tainted beef products. Let me stress that this is extremely rare: there have been 3 confirmed cases in the United States.

It is extremely unlikely that Soylent is a vector for prion disease, especially since it's been vegan since version 1.2 and never contained beef as an ingredient. Even if it somehow contained tainted beef, given that it's been available for less than 3 years, it's extremely unlikely that any cases of nvCJD (of which there have only a few in the last decade) or any other cases of prion disease were caused by Soylent.

There is good reason to question the safety of Soylent given its record but "prion disease rumors circulating on Twitter" are utterly ridiculous.

This is the closest to my use of the term. I'd go further and say that using more resources on a single box is vertical scaling, using more boxes is horizontal, and this thing is neither. How about density scaling?

What?

The name of a piece of data is cryptographically secure. It is permanent, but the data that is being named doesn't have to continue to exist on a hard drive just because its name exists.

More information about platform support can be found here: https://doc.rust-lang.org/book/getting-started.html

One thing that's nicer is that because Rust is a compiled language, Cargo produces a (statically-linked) binary. Python and your Python environment always needs to be set up on the machine that you're going to run it on.

statically-linked by default except for on Linux where it links to glibc dynamically by default IIRC, but going fully static there is easy, and going fully dynamic is easy too.

First of all, I agree that cargo blows the C/C++ tools out of the water in terms of ease of use. But I think it's even easier than newer stuff too. It's by far the best dependency manager I've used.

I haven't used pip-tools, but I have used pip, npm, bower, and other more modern dependency mangers that work for non-systems programming languages. Cargo has never given me any trouble. Pip has occasionally given me weird issues about things not being installed in the right places or on my path. NPM regularly required `rm -r node_modules` and starting from scratch. Bower has had the same trouble as npm. It's not that these tools don't work for me, I've always been able to google the error message and find someone with the same problem. It's that Cargo has never given me an error message that wasn't my fault like "This package doesn't exist" when it's a typo. It just works.