31–40 of 132 posts
The annotated version of C# included in the blog post reminds me of Spec# http://research.microsoft.com/en-us/projects/specsharp/ Spec# has annotations and methods for object ownership. You can see an example of it in the "The Spec# Programming System: An Overview" slideshow (slide 39 onwards). Also: > C# has two families of data structures that dermine allocation behaviour: structs and classes. If a type is a struct…
Earlier quoted context omitted.
I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the backgro…
> because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do. And sometimes some people (like me) would argue that C++ (11&14) is actually that language. A subset of C++ is actually very perfomant and safe for most of the uses.
Earlier quoted context omitted.
It is so popular because it elegantly solves a set of problems that plague systems-level programming (use-after-free, dangling pointers, data races). It is so controversial because there are system programmers who have lived for so long with those problems that they now refuse their existence.
You're right on the pros but dead wrong (intentionally?) on the cons. The real reasons it's controversial are: (1) it requires what some people consider excessive amount of annotations for borrowed types, resulting in visual noise, (2) it has an overly restrictive memory safety model (e.g. it prevents concurrent modification, even when provably safe), (3) it claims to be (memory) "safe", but requires (see 2) the use…
That's pretty much the _only_ place you need when using unsafe, when implementing "basic collections". The point of Rust's unsafe is to be able to use it to design safe abstractions. This is not a con; this is the _point_ of unsafe.
(Also, one can argue that implementing a collection is not a basic task. It's taught very early on in courses as a way of teaching pointers, but collections aren't simple in general and especially when it comes to memory management. See also: http://cglab.ca/~abeinges/blah/too-many-lists/book/)
> it prevents concurrent modification, even when provably safe
Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios? You can alleviate some of the threaded restrictions via scoped threads. Most of the non-threaded ones can be fixed (without a performance penalty) using Cell (RefCell for non-Copy types, though there's a slight cost there).
I've been programming in Rust for a while now, and this doesn't turn out to be an issue in practice since the regular way of designing code avoids this pretty well. Programming in Rust as if it was C++ leads to these errors a lot more.
Could someone explain why Rust is so damn popular/controversial?
Technical reasons alone don't clarify what's happening. Everyone's explaining basically why "Rust is awesome", which is not what was asked. It's popular because Rust fans are heavily promoting it on HN as the solution to certain classes of programming errors. 2016 is probably going to be the year of Rust on HN, generally there's a new language every year such as Ruby, Javascript, etc. This year Go is a strong competi…
Dropbox using it sounds like a pretty good hero project...
Earlier quoted context omitted.
You're right on the pros but dead wrong (intentionally?) on the cons. The real reasons it's controversial are: (1) it requires what some people consider excessive amount of annotations for borrowed types, resulting in visual noise, (2) it has an overly restrictive memory safety model (e.g. it prevents concurrent modification, even when provably safe), (3) it claims to be (memory) "safe", but requires (see 2) the use…
The collections criticism is bizarre. How often do you actually have to use "unsafe" in practice? Collections is one example, but it seems to be quite atypical, and not something you'd typically implement yourself. The argument has always been that it reduces the amount of code you have to check for safety manually. Most of it will be checked by the compiler. Have you run into the problem that most of your code is un…
No, Rust's argument is that it eliminates memory unsafety. It even says so on it's front page: "guaranteed memory safety".
Except that it's not guaranteed. It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C.
I agree that this criticism is mostly a theoretical one; Rust is still a huge improvement (in safety, and probably other areas) over C. But some people (e.g. myself) oppose lies in principle, no matter how well-intentioned they are.
Earlier quoted context omitted.
The collections criticism is bizarre. How often do you actually have to use "unsafe" in practice? Collections is one example, but it seems to be quite atypical, and not something you'd typically implement yourself. The argument has always been that it reduces the amount of code you have to check for safety manually. Most of it will be checked by the compiler. Have you run into the problem that most of your code is un…
> The argument has always been that it reduces the amount of code you have to check for safety manually. No, Rust's argument is that it eliminates memory unsafety. It even says so on it's front page: "guaranteed memory safety". Except that it's not guaranteed. It relies on you trusting code that (supposedly) expert programmers have written, and which has been reviewed hundreds of times. Which is no better than C. I a…
This is a vast oversimplification.
It relies on you trusting tiny bits of unsafe code which have been carefully reviewed. This is opposed to entire C codebases which need reviewing. It's much, much easier to audit 10 lines of unsafe code than it is to audit an entire application.
The vast majority of Rust code is not unsafe.
Earlier quoted context omitted.
I think a lot of people are looking for a replacement for C++ that isn't C#/Java. As in a language that is still low-level enough to offer stuff like pointers, but without the pitfalls and minefield which is C++ (a lot of which is due to historic reasons and backwards compatibility with C). Some newer languages that try to fill the niche are D, Nim, Rust and Go. Can't say much about Nim, it seems to be in the backgro…
> because there is a place for a language that is safer to use than C++, yet performs at similar speeds and doesn't handhold you like C#/Java do. And sometimes some people (like me) would argue that C++ (11&14) is actually that language. A subset of C++ is actually very perfomant and safe for most of the uses.
Earlier quoted context omitted.
Technical reasons alone don't clarify what's happening. Everyone's explaining basically why "Rust is awesome", which is not what was asked. It's popular because Rust fans are heavily promoting it on HN as the solution to certain classes of programming errors. 2016 is probably going to be the year of Rust on HN, generally there's a new language every year such as Ruby, Javascript, etc. This year Go is a strong competi…
> The facts that Rust is quite young, has no shipping hero project as a case study Dropbox using it sounds like a pretty good hero project...
In one they say that Dropbox is investing multiple millions in a key piece of infrastructure written in Rust. One month later they say that the project is written in go with some Rust and it will "stay that way".
There was also a HN thread, maybe that contains more clues.
Earlier quoted context omitted.
Technical reasons alone don't clarify what's happening. Everyone's explaining basically why "Rust is awesome", which is not what was asked. It's popular because Rust fans are heavily promoting it on HN as the solution to certain classes of programming errors. 2016 is probably going to be the year of Rust on HN, generally there's a new language every year such as Ruby, Javascript, etc. This year Go is a strong competi…
> The facts that Rust is quite young, has no shipping hero project as a case study and there are basically no jobs available are adding fuel to the fire. That's a bit of a misrepresentation though. Rust code is shipping in Firefox, and more importantly, Servo will have an alpha release in June. The close integration between Rust and Servo development, as well as the rigorous pre 1.0 process also set it apart from oth…
Earlier quoted context omitted.
You're right on the pros but dead wrong (intentionally?) on the cons. The real reasons it's controversial are: (1) it requires what some people consider excessive amount of annotations for borrowed types, resulting in visual noise, (2) it has an overly restrictive memory safety model (e.g. it prevents concurrent modification, even when provably safe), (3) it claims to be (memory) "safe", but requires (see 2) the use…
> the use of "unsafe" features for the most basic tasks, such as implementing various collections. That's pretty much the _only_ place you need when using unsafe, when implementing "basic collections". The point of Rust's unsafe is to be able to use it to design safe abstractions. This is not a con; this is the _point_ of unsafe. (Also, one can argue that implementing a collection is not a basic task. It's taught ver…
It's not a con if you consider C; but it most definitely is a con for a language that advertises itself as having "guaranteed memory safety".
> Are you talking about non-lexical borrows here (that will be fixed soon), or about Rust's restrictions in threaded scenarios?
I'm talking about the fact that the programmer has to write the code/algorithms in such a way that Rust's very limited proof engine can handle them. This means using collections in a limited way - if the API doesn't support something, you can't do it (an example would be, splitting a vector and updating each element by a separate thread - IIRC that used to be a problem, maybe it has been fixed already?). This also means implementing concurrent algorithms using the (limited) API (Cells, Atomics, ...) - although that's probably the preferred way in C as well, I'm guessing even things like CAS can be abstracted away with zero cost while improving safety. I'm curious, though, how would I implement the following: I have multiple threads, and I only care about the last result (i.e. they can all write to the same memory location)?
I agree, though, that this is rarely a problem in practice, which is why Rust is an amazing language. The criticism/controversy is mostly coming from outsiders and/or people like me who disapprove of false advertising in principle.