24 ms·

Two Weeks of Rust

323 points by omn1 11y ago

amelius 11y ago
How does Rust interoperate with C++? For example, would it be easy to integrate V8 into a Rust project?
- gbersac 11y ago
  It doesn't. C++ is too complex. Rust interoperate with c only.
- mseri 11y ago
  With specific C++ features there is still a lot of work to do, however the C FFI is solid and simple to use if that is enough for you (see e.g. https://doc.rust-lang.org/book/ffi.html https://doc.rust-lang.org/book/ffi.html). Interfacing Rust and python, ruby, node can be quite simple in fact (micro demo for node: http://calculist.org/blog/2015/12/23/neon-node-rust/ http://calculist.org/blog/2015/12/23/neon-node-rust/)
- rkangel 11y ago
  Not well. Interoperating with C++ is extremely difficult as the calling conventions are complicated. See this from the "D" documentation: "Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end" https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html
- vardump 11y ago
  When it comes to shared objects (.so, dll, dylib, etc.) not even C++ interoperates with C++, when two different compilers are involved. Name mangling is not standardized, so everyone does their own thing. This breaks binary compatibility.
- Manishearth 11y ago
  Aside from the other comments, https://github.com/michaelwu/rust-bindgen/tree/sm-hacks https://github.com/michaelwu/rust-bindgen/tree/sm-hacks somewhat works for binding to more complicated C++ code. C code, works fine, as always.
beerbajay 11y ago
I also tried rust for a couple of weeks, but holy hell is it ugly. Why improve on c++ and not improve the syntax or containers? It's like python never existed.
- gbersac 11y ago
  If syntax is still verbose (it's ok for me) at least it is clear. There is no ambiguity unlike c++.
- kiiski 11y ago
  If by that reference to Python you mean you want significant whitespace, I think that would make it unnecessarily difficult to work with different scopes. fn something() { foobar(); { bar(); foo(); } quux(); } That is much easier to understand, and easier for tools to work with (they can actually automatically indent your code without breaking it), than: def something(): foobar() bar() foo() quux() edit: And how would you even add a scope right after another block (like if)? That would require you to have a keyword anyway.
- Symmetry 11y ago
  There's always Nim if you want nice syntax but then you're working with a garbage collected language without a borrow checker.
- shmerl 11y ago
  > It's like python never existed. Whitespace / indentation used for scope delimiting in Python is a bad idea. No, thanks. I'm glad Rust isn't using anything like that.
  - beerbajay 11y ago
    I agree that whitespace scope delimiting is a bad idea, but I was thinking more about general syntactical clarity. Just because C++ uses every possible typographical symbol doesn't mean rust should. Simple example which had me WTFing: use std::collections::{HashMap, HashSet}; Are all those ::s and {}s adding to clarity? Why are there no easy to use initializers for maps? It's 2015! I have to do: let mut map = ::std::collections::HashMap::new(); map.insert("a".to_string(), "b".to_string()); ... or some such nonsense. Oh, right, I have to write a macro and basically learn another language. Also, using the macro system for basic things like println just seems bonkers to me; use macros when you really, really need to do something special, not everywhere.
lifthrasiir 11y ago
The submission and expanded discussion at /r/rust: https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_rust/ https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_r...
grabcocque 11y ago
I never found the borrow checker to be that hard to work with. For a start, if you're developing a systems language in a modern way, (say C++11/14) you're already used to thinking in terms of move semantics, const refs and shared vs unique pointers. Secondly, Rust's compiler gives INCREDIBLY detailed explanations of what the borrow checker doesn't like, where the conflicting scopes begin and end, and helpful suggestions of what to do to make it work.
- wuch 11y ago
  On one hand it indeed feels like more strict version of move semantics in C++, on the other hand it also prohibits what is central idea of STL - having multiple mutable references to the same object (almost all algorithms operate on at least two iterators from the same container). It seems there is no place for STL-like library in Rust - which is quite regrettable.
  - yati 11y ago
    Most algorithms that I use from the C++ stdlib take `container.begin()` and `container.end()`, and use the latter to check for the end condition in the main loop. Given that Rust has the `Iter` trait which allows you to iterate straight through any type that implements it, I do not see the point in having multiple mutable references. I mean, sure, it is useful sometimes, but it also brings in a lot of headaches with it :)
    - wuch 11y ago
      Right, in most cases you could replace begin(), end() with whole container / range, when considering arguments to the algorithm function. Though, there are some exceptions, like std::rotate, or just cases where you want to place result in the same container. Looking from the perspective of implementation of those algorithms, it is no longer that simple and single iterator is rarely sufficient, consider: std::unique, std::reverse, std::partition, std::sort, std::inplace_merge to name a few, where there is much more to it than just checking for end.
crncosta 11y ago
In 2016 I would like to see a Rust frontend for GCC, with LTO support and all the list of target backends GCC support.
- goodplay 11y ago
  There used to be gcc front end during Rust pre-1.0, but it seems that the language was too unstable for it to keep up. A gcc front-end would be great, if only to show that the language spec is mature and complete enough that other implementations can be built on it.
- viraptor 11y ago
  > with LTO support rustc already supports lto (lto=true in cargo manifest, or -C lto in rustc) > all the list of target backends GCC support. Which targets are you interested in specifically?
markque 11y ago
When you've worked with languages with a garbage collector, having to worry about memory management and all that jazz seems a step backwards just to save a few cycles. You want to be focusing on the domain problem not the machine. (This is directed at people who use Rust as a general purpose lang, im sure it's good for low level systems programming).
- amelius 11y ago
  It would be nice if the language itself provided hooks (or whatever you would call it) to implement your own GC (or, of course, to use a library for that purpose). I have not yet encountered such a language, though (LLVM has a low-level language that allows it, but I don't know the details).
  - viraptor 11y ago
    Rust does that. Rc type is implemented in Rust. (https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html) There's also arena allocation available as a library. (https://crates.io/crates/typed-arena/ https://crates.io/crates/typed-arena/) You can add your own memory management abstractions as libraries.
    - amelius 11y ago
      Very interesting. I'm also interested in one particular kind of memory abstraction: abstracted access to memory mapped files. Here the problem is that the base address of the memory mapped area might change whenever you perform the mapping. And you would like to use standard data-structures (like maps, lists, etc.) inside the memory mapped area.
      - viraptor 11y ago
        Mmaped files are already available it seems (https://crates.io/crates/mmap/ https://crates.io/crates/mmap/), although I've never tried it. You'd have to implement the interesting structures on top of that yourself however.
taliesinb 11y ago
"No segfaults, no uninitialized memory, no coercion bugs, no data races, no null pointers, no header files, no makefiles, no autoconf, no cmake, no gdb. What if all the problems of c/c++ were fixed with one swing of a magic wand? The future is here, people" It certainly is. The advantages over C++ seemingly never end. I'd add to the list: rigorous portability, non-broken macros, ADTs and pattern matching, a careful language stability protocol, standard test and doc tooling, flexible namespacing via visibility and modules, the absense of vast lacunas of undefined behaviour, simple numeric promotion rules, meaningful compile-time errors for generic code. Plus things already mentioned in the post like Cargo. People tend to focus on the safety side of Rust, but as impressive to me is just the... solidity on all these other axes. If you stripped out lifetimes and the borrow checker you would still have an incredibly compelling alternative to C++.
- gbersac 11y ago
  ADT -> Abstract Data Type for those who wonder. It means no need to explicitly define the type of a variable, the compiler infer it based on context.
  - evanpw 11y ago
    In this context, ADT probably means algebraic data type: https://en.wikipedia.org/wiki/Algebraic_data_type https://en.wikipedia.org/wiki/Algebraic_data_type. And I don't think your definition for abstract data type is right either: usually the language feature that automatically determines types from context is called type inference.
  - Robin_Message 11y ago
    In this case, I think they meant algebraic data type, since they mention it next to "pattern matching". An algebraic data type is generally made up of two things: 1) structs or tuples, which are useful but in most (but not all languages); C/C++ has them for example; and 2) tagged or disjoint unions, which are different from C unions in that you can tell which one of the union choices is being used (A variant is a particular tagged union). Tagged unions are super-useful for pattern matching, so you get code like: match rv { Ok(_) => { None } Err(CacheError::KeyNotFound) => { Some(Resp::NotFound) } Err(ref err) => Some(from_cache_err(err)) } which has a nice syntax, is type-safe and can be compiled reasonably efficiently. The algebraic part means that these two features can be used in any combination with each other, and also refers to the link that, roughly 0 is the empty type, 1 is the unit type, structs correspond to multiplies (and gets called the product type), and unions to plus (so is called a sum type). Why? Because if I have a tuple of a union of A or B or C, and another union of X or Y, I have 6 possible values in total, and (1+1+1) x (1+1) = 6.
goodplay 11y ago
I'd like to echo the author in that Cargo is the best language package manager/build system I've had the pleasure to use. However, there is one serious problem with Cargo's packages: They simply aren't authenticated. Cargo's developers acknowledge this issue and there is a proposal to amend it by adopting the TUF [1]. but this issue doesn't seem to enjoy the attention it deserves. As a person living in a country that increasingly edging towards going the Kazakhstan route where all secure traffic will be MITMed, simply relying on transport security as a way to secure crates is not sufficient. and that's ignoring compromises due to server security failures. At present, my only options are to include the entire dependency tree in crate or avoid dependencies altogether. Even ignoring my problem (which wouldn't effect a large number of rust developers), Mixing transport security with authentication and integrity shouldn't happen in vital infrastructure like a language package system. There are other problems like not representing system libraries that a crate depends on in the project manifest, but unauthenticated crates are a ar more serious problem. [1]:https://github.com/rust-lang/crates.io/issues/75 https://github.com/rust-lang/crates.io/issues/75
- wuch 11y ago
  Is there a language package manager that you would consider a good role model in this respect?
  - viraptor 11y ago
    Not the OP, but both rpm and deb have a pretty good validation story. Deb repositories (== package hashes) are gpg-signed for verification, but are usually provided over http for better caching. Nothing stops you from putting them on https either. Rpms can be signed at the package level as well.
  - goodplay 11y ago
    I'm not aware of any language-specific package manager that gets close to having developer-package authentication, but chromium's add-on system comes pretty close as it requires add-ons be signed by the developer's private key (at least, that was the case before I stopped developing for it). I believe android's packages are secured in a similar fashion.
purpled_haze 11y ago
I'm a little skeptical after first reading "Disclaimer: I'm digging Rust. I lost my hunger for programming from doing too many sad commercial projects. And now it's back. You rock, Rust!" and then seeing comparisons to Python in the text where it seems like the author might prefer writing in Python, especially with all of the Rust cons listed. Is the author saying Rust is a breath of fresh air from C++ or from all other programming languages? Ruby was my breath of fresh air for a while, but lately I've not been enthusiastic about any language or framework, really, so I curious how great Rust really is these days.
- omn1 11y ago
  As somebody who comes from the Python community just like the author, I can relate to some of his points: "In Python I try to avoid even having dependencies if I can, and only use the standard library. I don't want my users to have to deal with virtualenv and pip if they don't have to (especially if they're not pythonistas)" This rings so true to me. Package management in Rust is much better than in Python. Also, Rust feels a bit like "pythonic systems programming". I mean that it just feels like the right tool for the job. And it might feel a bit verbose in the beginning, but in reality it's explicit and precise. It feels pretty ergonomic just like Python. Isn't it fantastic that people start comparing Rust to more high level languages like Python and Ruby instead of C++ or C? It says a lot about the language design and its goals.
  - StavrosK 11y ago
    Am I the only one who doesn't find Python's dependency management a problem? "pip install -Ur requirements.txt" and you're done. A virtualenv is one extra line.
    - dikaiosune 11y ago
      Very easy when you're in control of the machine (and are a developer). A while back I had written a tool in Python purely for myself (mistake #1), and relied heavily on dependencies which needed to compile C extensions (mistake #2), and then it turned out to be very useful for others on my team (mistake #3), which consisted of mostly non-developers (mistake #4) using Windows/Mac (mistake #5). I've since left, and while they supposedly have a dev who can help them install the tool, I'm still running it for them on a regular basis because I don't want to be mean and they haven't sorted it out. Python's dependency management is great for devs who have a GCC toolchain, but it really sucks when you need to share code with non-developers.
EugeneOZ 11y ago
I'm working with Rust 2 months. In my opinion, pluses: + Compiler with very helpful error messages; + Cargo is the best package manager in the universe; + Result<> is the most correct way to return results from function, I dreamed about it; + Community of smart and friendly people. Minuses: - Functions are not first class citizens - you can't return function as result; - Violation of "explicit over implicit" rule in methods declarations: argument self/&self is implicitly omitted in call, but exist in signature. Because of this, for example, you can't use method of class as request handler in Iron, you need closure wrapper with same order and count of arguments. Pure ugliness; - Often you need just add lifetime definition to satisfy compiler, without doing anything with this lifetime anywhere else in code; - Extremely verbose syntax; - Rust has exceptions (panic), and you can't catch them. And with promised panic::recover you'll have limitations of supported structures; - Errors handling encourages copy-pasting; - Syntax is not intuitive, especially when traits and lifetimes comes into declaration - in such cases you can look at own code and think "I hope at least compiler can read it"; - Nested structures is pain; - Lack of optional and named arguments, lack of predefined values in structures; - Too few modules for web. Just 1 module for MySQL (thanks to it's author - actively maintained); - Usage of safe code can lead to out-of-bounds errors, with thread panic (hello to vec macros). And I still think it's best language we have:) Biggest advantage - most of errors can be found on compilation step. But price is all of these minuses.
- adrusi 11y ago
  Violation of "explicit over implicit" rule in methods declarations: argument self/&self is implicitly omitted in call, but exist in signature. Because of this, for example, you can't use method of class as request handler in Iron, you need closure wrapper with same order and count of arguments. Pure ugliness; Maybe that's ugly, but it's explicit. The method is statically compiled into the program to take the receiver as an argument. What you want to do is specify the receiver argument on the caller cide and the remaining arguments on the callee side, which is impossible to do. The closest you can get is to create a closure on the caller side and pass that to the callee. Languages that avoid this, like say, python, are just implicitly creating that closure. Creating a closure implicitly goes against the design goals of rust. At least rust doesn't have javascript's abominable semantics.
cikey 11y ago
Nice to see rust getting along. Coming from C and C++ is really dig the new ideas for better and more save low level languages. What really bugs me, is what the author describes as being'concise'. Shortcuts like fn, pub or vec, in my oppinion, hurt readability more than they help me to write code faster. But maybe thats just my brain, or lack of time using rust.
- lifthrasiir 11y ago
  As far as I understand, the length of keywords and common identifiers is roughly proportional to the reciprocal of frequency. `fn` and `pub` are used a lot; `return` is less used (Rust returns the last expression by default); `continue` is even less so, and it's familiar to C/C++ programmers.
  - cikey 11y ago
    thanks a lot for the info. I can perfectly see the reasoning behind it. Still, i find it harder to read. But as i said, that can be a lack of practice.
vitriol83 11y ago
The article is comparing Rust principally to Python (a new dynamically typed language) and C++ (an old statically typed language). It's certainly plausible that it can bring benefits over these. More interesting to me would be comparing it to a new-ish multi-paradigm language, of which there are many right now (e.g Swift, OCaml, Haskell, F#, Scala). It seems like in practical applications these newer FP languages will be much more productive than Rust, as memory management is much simpler. Rust's principle of zero-cost abstractions is great in theory, but can't think of many applications where it's the limiting factor except perhaps embedded devices and kernel development.
- ionforce 11y ago
  Python isn't "new".
  - scott_s 11y ago
    And neither are Haskell and OCaml. It's interesting how people's perceptions of programming language age work. For the record: OCaml is 20 years old, Python is 25 years old and Haskell is 26 years old.
    - wtetzner 11y ago
      Not particularly relevant to the discussion, but because I was curious, I looked up the age of ML: 43 years old. [1] [1] https://en.wikipedia.org/wiki/ML_%28programming_language%29 https://en.wikipedia.org/wiki/ML_%28programming_language%29
- scott_s 11y ago
  Rust is designed as a systems programming language, so it was explicitly made for situations where zero-cost abstractions and explicit memory management matter. Embedded devices and kernel development are two places that matters, but there are more: web browsers, web servers, databases and runtime systems all come to mind.
  - 11y ago
pjungwir 11y ago
I've been experimenting with Rust for a few weeks, and I really like it, but I hope they improve how you write functions that return iterators. I can't find all the discussion now, but here is some of it: http://stackoverflow.com/questions/27535289/correct-way-to-return-an-iterator http://stackoverflow.com/questions/27535289/correct-way-to-r... https://www.reddit.com/r/rust/comments/2h26cj/functions_returning_iterators/ https://www.reddit.com/r/rust/comments/2h26cj/functions_retu... https://github.com/rust-lang/rfcs/pull/105 https://github.com/rust-lang/rfcs/pull/105 https://github.com/rust-lang/rfcs/pull/1305 https://github.com/rust-lang/rfcs/pull/1305 Reading those RFCs can be frustrating, where a discussion goes on for over a year and people add more and more wants to an idea until it sinks. Same thing with the discussion about a `yield` keyword: https://github.com/rust-lang/rust/issues/7746 https://github.com/rust-lang/rust/issues/7746 https://github.com/rust-lang/rfcs/issues/388 https://github.com/rust-lang/rfcs/issues/388 It reminds me of the JCP in Java. I guess every standards committee is like this, and I actually like how careful the Rust team is about extending the language---but I think we should be prepared for it to evolve slowly. Right now I feel like Rust's pace will be more like Java than C#.
- steveklabnik 11y ago
  One reason you're seeing slowness is that the compiler is undergoing an internal refactoring that will _completely change_ the way these kinds of features will be implemented. So they're effectively on-hold-ish until after that's done. Also, this particular feature seems easy from a usage perspective, but the type theory behind it is actually pretty intense, and there's multiple possible ways of doing it. So those need to be explored, discussed, and figured out. This feature is one that's of high importance, and is coming sooner rather than later.
  - pjungwir 11y ago
    Thanks for the reassurance! Sorry if I sound critical. There will always be a tradeoff between speed and purity---Java vs C# is a actually a pretty interesting case study---and for a language that is as experimental as Rust, I think taking your time to make careful decisions is the right approach. I'm just trying to prepare myself for the wait. :-) Also thanks to you personally for your work making Rust accessible to us newbies. The book is very nice, and a few weeks ago you were really quick to answer a question of mine on IRC. Keep up the good work!
loaaa 11y ago
Future? well, 10 year later, quantum computer maybe come to reality which is much much faster than current computers. At that time who will care about Rust or C++? The easiest language will win.
- tarblog 11y ago
  You shouldn't expect quantum computers to bring a "free-lunch" speedup the way that clock-speed increases did for such a long time.

Two Weeks of Rust

323 points by omn1 11y ago

amelius 11y ago

How does Rust interoperate with C++? For example, would it be easy to integrate V8 into a Rust project?

gbersac 11y ago
It doesn't. C++ is too complex. Rust interoperate with c only.
mseri 11y ago
With specific C++ features there is still a lot of work to do, however the C FFI is solid and simple to use if that is enough for you (see e.g. https://doc.rust-lang.org/book/ffi.html https://doc.rust-lang.org/book/ffi.html). Interfacing Rust and python, ruby, node can be quite simple in fact (micro demo for node: http://calculist.org/blog/2015/12/23/neon-node-rust/ http://calculist.org/blog/2015/12/23/neon-node-rust/)
rkangel 11y ago
Not well. Interoperating with C++ is extremely difficult as the calling conventions are complicated. See this from the "D" documentation: "Being 100% compatible with C++ means more or less adding a fully functional C++ compiler front end" https://dlang.org/spec/cpp_interface.html https://dlang.org/spec/cpp_interface.html
vardump 11y ago
When it comes to shared objects (.so, dll, dylib, etc.) not even C++ interoperates with C++, when two different compilers are involved. Name mangling is not standardized, so everyone does their own thing. This breaks binary compatibility.
Manishearth 11y ago
Aside from the other comments, https://github.com/michaelwu/rust-bindgen/tree/sm-hacks https://github.com/michaelwu/rust-bindgen/tree/sm-hacks somewhat works for binding to more complicated C++ code. C code, works fine, as always.

beerbajay 11y ago

I also tried rust for a couple of weeks, but holy hell is it ugly. Why improve on c++ and not improve the syntax or containers? It's like python never existed.

gbersac 11y ago
If syntax is still verbose (it's ok for me) at least it is clear. There is no ambiguity unlike c++.
kiiski 11y ago
If by that reference to Python you mean you want significant whitespace, I think that would make it unnecessarily difficult to work with different scopes. fn something() { foobar(); { bar(); foo(); } quux(); } That is much easier to understand, and easier for tools to work with (they can actually automatically indent your code without breaking it), than: def something(): foobar() bar() foo() quux() edit: And how would you even add a scope right after another block (like if)? That would require you to have a keyword anyway.
Symmetry 11y ago
There's always Nim if you want nice syntax but then you're working with a garbage collected language without a borrow checker.
shmerl 11y ago
> It's like python never existed. Whitespace / indentation used for scope delimiting in Python is a bad idea. No, thanks. I'm glad Rust isn't using anything like that.
- beerbajay 11y ago
  I agree that whitespace scope delimiting is a bad idea, but I was thinking more about general syntactical clarity. Just because C++ uses every possible typographical symbol doesn't mean rust should. Simple example which had me WTFing: use std::collections::{HashMap, HashSet}; Are all those ::s and {}s adding to clarity? Why are there no easy to use initializers for maps? It's 2015! I have to do: let mut map = ::std::collections::HashMap::new(); map.insert("a".to_string(), "b".to_string()); ... or some such nonsense. Oh, right, I have to write a macro and basically learn another language. Also, using the macro system for basic things like println just seems bonkers to me; use macros when you really, really need to do something special, not everywhere.

lifthrasiir 11y ago

The submission and expanded discussion at /r/rust: https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_rust/ https://www.reddit.com/r/rust/comments/40d8ca/two_weeks_of_r...

grabcocque 11y ago

I never found the borrow checker to be that hard to work with. For a start, if you're developing a systems language in a modern way, (say C++11/14) you're already used to thinking in terms of move semantics, const refs and shared vs unique pointers. Secondly, Rust's compiler gives INCREDIBLY detailed explanations of what the borrow checker doesn't like, where the conflicting scopes begin and end, and helpful suggestions of what to do to make it work.

wuch 11y ago
On one hand it indeed feels like more strict version of move semantics in C++, on the other hand it also prohibits what is central idea of STL - having multiple mutable references to the same object (almost all algorithms operate on at least two iterators from the same container). It seems there is no place for STL-like library in Rust - which is quite regrettable.
- yati 11y ago
  Most algorithms that I use from the C++ stdlib take `container.begin()` and `container.end()`, and use the latter to check for the end condition in the main loop. Given that Rust has the `Iter` trait which allows you to iterate straight through any type that implements it, I do not see the point in having multiple mutable references. I mean, sure, it is useful sometimes, but it also brings in a lot of headaches with it :)
  - wuch 11y ago
    Right, in most cases you could replace begin(), end() with whole container / range, when considering arguments to the algorithm function. Though, there are some exceptions, like std::rotate, or just cases where you want to place result in the same container. Looking from the perspective of implementation of those algorithms, it is no longer that simple and single iterator is rarely sufficient, consider: std::unique, std::reverse, std::partition, std::sort, std::inplace_merge to name a few, where there is much more to it than just checking for end.

crncosta 11y ago

In 2016 I would like to see a Rust frontend for GCC, with LTO support and all the list of target backends GCC support.

goodplay 11y ago
There used to be gcc front end during Rust pre-1.0, but it seems that the language was too unstable for it to keep up. A gcc front-end would be great, if only to show that the language spec is mature and complete enough that other implementations can be built on it.
viraptor 11y ago
> with LTO support rustc already supports lto (lto=true in cargo manifest, or -C lto in rustc) > all the list of target backends GCC support. Which targets are you interested in specifically?

markque 11y ago

When you've worked with languages with a garbage collector, having to worry about memory management and all that jazz seems a step backwards just to save a few cycles. You want to be focusing on the domain problem not the machine. (This is directed at people who use Rust as a general purpose lang, im sure it's good for low level systems programming).

amelius 11y ago
It would be nice if the language itself provided hooks (or whatever you would call it) to implement your own GC (or, of course, to use a library for that purpose). I have not yet encountered such a language, though (LLVM has a low-level language that allows it, but I don't know the details).
- viraptor 11y ago
  Rust does that. Rc type is implemented in Rust. (https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html https://doc.rust-lang.org/nightly/std/rc/struct.Rc.html) There's also arena allocation available as a library. (https://crates.io/crates/typed-arena/ https://crates.io/crates/typed-arena/) You can add your own memory management abstractions as libraries.
  - amelius 11y ago
    Very interesting. I'm also interested in one particular kind of memory abstraction: abstracted access to memory mapped files. Here the problem is that the base address of the memory mapped area might change whenever you perform the mapping. And you would like to use standard data-structures (like maps, lists, etc.) inside the memory mapped area.
    - viraptor 11y ago
      Mmaped files are already available it seems (https://crates.io/crates/mmap/ https://crates.io/crates/mmap/), although I've never tried it. You'd have to implement the interesting structures on top of that yourself however.

taliesinb 11y ago

"No segfaults, no uninitialized memory, no coercion bugs, no data races, no null pointers, no header files, no makefiles, no autoconf, no cmake, no gdb. What if all the problems of c/c++ were fixed with one swing of a magic wand? The future is here, people" It certainly is. The advantages over C++ seemingly never end. I'd add to the list: rigorous portability, non-broken macros, ADTs and pattern matching, a careful language stability protocol, standard test and doc tooling, flexible namespacing via visibility and modules, the absense of vast lacunas of undefined behaviour, simple numeric promotion rules, meaningful compile-time errors for generic code. Plus things already mentioned in the post like Cargo. People tend to focus on the safety side of Rust, but as impressive to me is just the... solidity on all these other axes. If you stripped out lifetimes and the borrow checker you would still have an incredibly compelling alternative to C++.

gbersac 11y ago
ADT -> Abstract Data Type for those who wonder. It means no need to explicitly define the type of a variable, the compiler infer it based on context.
- evanpw 11y ago
  In this context, ADT probably means algebraic data type: https://en.wikipedia.org/wiki/Algebraic_data_type https://en.wikipedia.org/wiki/Algebraic_data_type. And I don't think your definition for abstract data type is right either: usually the language feature that automatically determines types from context is called type inference.
- Robin_Message 11y ago
  In this case, I think they meant algebraic data type, since they mention it next to "pattern matching". An algebraic data type is generally made up of two things: 1) structs or tuples, which are useful but in most (but not all languages); C/C++ has them for example; and 2) tagged or disjoint unions, which are different from C unions in that you can tell which one of the union choices is being used (A variant is a particular tagged union). Tagged unions are super-useful for pattern matching, so you get code like: match rv { Ok(_) => { None } Err(CacheError::KeyNotFound) => { Some(Resp::NotFound) } Err(ref err) => Some(from_cache_err(err)) } which has a nice syntax, is type-safe and can be compiled reasonably efficiently. The algebraic part means that these two features can be used in any combination with each other, and also refers to the link that, roughly 0 is the empty type, 1 is the unit type, structs correspond to multiplies (and gets called the product type), and unions to plus (so is called a sum type). Why? Because if I have a tuple of a union of A or B or C, and another union of X or Y, I have 6 possible values in total, and (1+1+1) x (1+1) = 6.

goodplay 11y ago

I'd like to echo the author in that Cargo is the best language package manager/build system I've had the pleasure to use. However, there is one serious problem with Cargo's packages: They simply aren't authenticated. Cargo's developers acknowledge this issue and there is a proposal to amend it by adopting the TUF [1]. but this issue doesn't seem to enjoy the attention it deserves. As a person living in a country that increasingly edging towards going the Kazakhstan route where all secure traffic will be MITMed, simply relying on transport security as a way to secure crates is not sufficient. and that's ignoring compromises due to server security failures. At present, my only options are to include the entire dependency tree in crate or avoid dependencies altogether. Even ignoring my problem (which wouldn't effect a large number of rust developers), Mixing transport security with authentication and integrity shouldn't happen in vital infrastructure like a language package system. There are other problems like not representing system libraries that a crate depends on in the project manifest, but unauthenticated crates are a ar more serious problem. [1]:https://github.com/rust-lang/crates.io/issues/75 https://github.com/rust-lang/crates.io/issues/75

wuch 11y ago
Is there a language package manager that you would consider a good role model in this respect?
- viraptor 11y ago
  Not the OP, but both rpm and deb have a pretty good validation story. Deb repositories (== package hashes) are gpg-signed for verification, but are usually provided over http for better caching. Nothing stops you from putting them on https either. Rpms can be signed at the package level as well.
- goodplay 11y ago
  I'm not aware of any language-specific package manager that gets close to having developer-package authentication, but chromium's add-on system comes pretty close as it requires add-ons be signed by the developer's private key (at least, that was the case before I stopped developing for it). I believe android's packages are secured in a similar fashion.

purpled_haze 11y ago

I'm a little skeptical after first reading "Disclaimer: I'm digging Rust. I lost my hunger for programming from doing too many sad commercial projects. And now it's back. You rock, Rust!" and then seeing comparisons to Python in the text where it seems like the author might prefer writing in Python, especially with all of the Rust cons listed. Is the author saying Rust is a breath of fresh air from C++ or from all other programming languages? Ruby was my breath of fresh air for a while, but lately I've not been enthusiastic about any language or framework, really, so I curious how great Rust really is these days.

omn1 11y ago
As somebody who comes from the Python community just like the author, I can relate to some of his points: "In Python I try to avoid even having dependencies if I can, and only use the standard library. I don't want my users to have to deal with virtualenv and pip if they don't have to (especially if they're not pythonistas)" This rings so true to me. Package management in Rust is much better than in Python. Also, Rust feels a bit like "pythonic systems programming". I mean that it just feels like the right tool for the job. And it might feel a bit verbose in the beginning, but in reality it's explicit and precise. It feels pretty ergonomic just like Python. Isn't it fantastic that people start comparing Rust to more high level languages like Python and Ruby instead of C++ or C? It says a lot about the language design and its goals.
- StavrosK 11y ago
  Am I the only one who doesn't find Python's dependency management a problem? "pip install -Ur requirements.txt" and you're done. A virtualenv is one extra line.
  - dikaiosune 11y ago
    Very easy when you're in control of the machine (and are a developer). A while back I had written a tool in Python purely for myself (mistake #1), and relied heavily on dependencies which needed to compile C extensions (mistake #2), and then it turned out to be very useful for others on my team (mistake #3), which consisted of mostly non-developers (mistake #4) using Windows/Mac (mistake #5). I've since left, and while they supposedly have a dev who can help them install the tool, I'm still running it for them on a regular basis because I don't want to be mean and they haven't sorted it out. Python's dependency management is great for devs who have a GCC toolchain, but it really sucks when you need to share code with non-developers.

EugeneOZ 11y ago

I'm working with Rust 2 months. In my opinion, pluses: + Compiler with very helpful error messages; + Cargo is the best package manager in the universe; + Result<> is the most correct way to return results from function, I dreamed about it; + Community of smart and friendly people. Minuses: - Functions are not first class citizens - you can't return function as result; - Violation of "explicit over implicit" rule in methods declarations: argument self/&self is implicitly omitted in call, but exist in signature. Because of this, for example, you can't use method of class as request handler in Iron, you need closure wrapper with same order and count of arguments. Pure ugliness; - Often you need just add lifetime definition to satisfy compiler, without doing anything with this lifetime anywhere else in code; - Extremely verbose syntax; - Rust has exceptions (panic), and you can't catch them. And with promised panic::recover you'll have limitations of supported structures; - Errors handling encourages copy-pasting; - Syntax is not intuitive, especially when traits and lifetimes comes into declaration - in such cases you can look at own code and think "I hope at least compiler can read it"; - Nested structures is pain; - Lack of optional and named arguments, lack of predefined values in structures; - Too few modules for web. Just 1 module for MySQL (thanks to it's author - actively maintained); - Usage of safe code can lead to out-of-bounds errors, with thread panic (hello to vec macros). And I still think it's best language we have:) Biggest advantage - most of errors can be found on compilation step. But price is all of these minuses.

adrusi 11y ago
Violation of "explicit over implicit" rule in methods declarations: argument self/&self is implicitly omitted in call, but exist in signature. Because of this, for example, you can't use method of class as request handler in Iron, you need closure wrapper with same order and count of arguments. Pure ugliness; Maybe that's ugly, but it's explicit. The method is statically compiled into the program to take the receiver as an argument. What you want to do is specify the receiver argument on the caller cide and the remaining arguments on the callee side, which is impossible to do. The closest you can get is to create a closure on the caller side and pass that to the callee. Languages that avoid this, like say, python, are just implicitly creating that closure. Creating a closure implicitly goes against the design goals of rust. At least rust doesn't have javascript's abominable semantics.

cikey 11y ago

Nice to see rust getting along. Coming from C and C++ is really dig the new ideas for better and more save low level languages. What really bugs me, is what the author describes as being'concise'. Shortcuts like fn, pub or vec, in my oppinion, hurt readability more than they help me to write code faster. But maybe thats just my brain, or lack of time using rust.

lifthrasiir 11y ago
As far as I understand, the length of keywords and common identifiers is roughly proportional to the reciprocal of frequency. `fn` and `pub` are used a lot; `return` is less used (Rust returns the last expression by default); `continue` is even less so, and it's familiar to C/C++ programmers.
- cikey 11y ago
  thanks a lot for the info. I can perfectly see the reasoning behind it. Still, i find it harder to read. But as i said, that can be a lack of practice.

vitriol83 11y ago

The article is comparing Rust principally to Python (a new dynamically typed language) and C++ (an old statically typed language). It's certainly plausible that it can bring benefits over these. More interesting to me would be comparing it to a new-ish multi-paradigm language, of which there are many right now (e.g Swift, OCaml, Haskell, F#, Scala). It seems like in practical applications these newer FP languages will be much more productive than Rust, as memory management is much simpler. Rust's principle of zero-cost abstractions is great in theory, but can't think of many applications where it's the limiting factor except perhaps embedded devices and kernel development.

ionforce 11y ago
Python isn't "new".
- scott_s 11y ago
  And neither are Haskell and OCaml. It's interesting how people's perceptions of programming language age work. For the record: OCaml is 20 years old, Python is 25 years old and Haskell is 26 years old.
  - wtetzner 11y ago
    Not particularly relevant to the discussion, but because I was curious, I looked up the age of ML: 43 years old. [1] [1] https://en.wikipedia.org/wiki/ML_%28programming_language%29 https://en.wikipedia.org/wiki/ML_%28programming_language%29
scott_s 11y ago
Rust is designed as a systems programming language, so it was explicitly made for situations where zero-cost abstractions and explicit memory management matter. Embedded devices and kernel development are two places that matters, but there are more: web browsers, web servers, databases and runtime systems all come to mind.
- 11y ago

pjungwir 11y ago

I've been experimenting with Rust for a few weeks, and I really like it, but I hope they improve how you write functions that return iterators. I can't find all the discussion now, but here is some of it: http://stackoverflow.com/questions/27535289/correct-way-to-return-an-iterator http://stackoverflow.com/questions/27535289/correct-way-to-r... https://www.reddit.com/r/rust/comments/2h26cj/functions_returning_iterators/ https://www.reddit.com/r/rust/comments/2h26cj/functions_retu... https://github.com/rust-lang/rfcs/pull/105 https://github.com/rust-lang/rfcs/pull/105 https://github.com/rust-lang/rfcs/pull/1305 https://github.com/rust-lang/rfcs/pull/1305 Reading those RFCs can be frustrating, where a discussion goes on for over a year and people add more and more wants to an idea until it sinks. Same thing with the discussion about a `yield` keyword: https://github.com/rust-lang/rust/issues/7746 https://github.com/rust-lang/rust/issues/7746 https://github.com/rust-lang/rfcs/issues/388 https://github.com/rust-lang/rfcs/issues/388 It reminds me of the JCP in Java. I guess every standards committee is like this, and I actually like how careful the Rust team is about extending the language---but I think we should be prepared for it to evolve slowly. Right now I feel like Rust's pace will be more like Java than C#.

steveklabnik 11y ago
One reason you're seeing slowness is that the compiler is undergoing an internal refactoring that will _completely change_ the way these kinds of features will be implemented. So they're effectively on-hold-ish until after that's done. Also, this particular feature seems easy from a usage perspective, but the type theory behind it is actually pretty intense, and there's multiple possible ways of doing it. So those need to be explored, discussed, and figured out. This feature is one that's of high importance, and is coming sooner rather than later.
- pjungwir 11y ago
  Thanks for the reassurance! Sorry if I sound critical. There will always be a tradeoff between speed and purity---Java vs C# is a actually a pretty interesting case study---and for a language that is as experimental as Rust, I think taking your time to make careful decisions is the right approach. I'm just trying to prepare myself for the wait. :-) Also thanks to you personally for your work making Rust accessible to us newbies. The book is very nice, and a few weeks ago you were really quick to answer a question of mine on IRC. Keep up the good work!

loaaa 11y ago

Future? well, 10 year later, quantum computer maybe come to reality which is much much faster than current computers. At that time who will care about Rust or C++? The easiest language will win.

tarblog 11y ago
You shouldn't expect quantum computers to bring a "free-lunch" speedup the way that clock-speed increases did for such a long time.