18 ms·

Rust is more than safety

242 points by anp 10y ago

komali2 10y ago
I haven't found any reply blog posts yet but I'm curious about rust. Has anyone found a response to the call to action at the bottom of the post?
- masklinn 10y ago
  > Has anyone found a response to the call to action at the bottom of the post? The post was published ~1h ago according to the author's twitter broadcast/alert[0], so there probably aren't any lengthy responses yet (even the twitter responses have nothing). [0] https://twitter.com/steveklabnik/status/814165927478652929 https://twitter.com/steveklabnik/status/814165927478652929
- stymaar 10y ago
  It looks like this blog post is around an hour old, a bit short to write a response blog post ;)
- mmstick 10y ago
  Responses are on the official Rust reddit forum. https://www.reddit.com/r/rust/comments/5krhr0/rust_is_more_than_safety/ https://www.reddit.com/r/rust/comments/5krhr0/rust_is_more_t...
Ar-Curunir 10y ago
I like how "high level" Rust feels. It doesn't feel like C or something of that ilk.
- vvanders 10y ago
  Yes, the relentless focus on zero-cost abstractions is fantastic.
  - lngnmn 10y ago
    Could you, please, elaborate. In my opinion zero-cost abstraction is nothing but a catchy meme. Could you provide an example, so I would try to implement such a wonder in one of classic languages I know, like SML or Scheme?
    - steveklabnik 10y ago
      A simple one is Option. An Option<&T> is a pointer to some type T. Option is an enum, & is a reference, which has all of Rust's safety checking. This will all compile down to a regular old pointer, just like in C. Even though you have null checking and protection against dangling pointers, etc. It's all at compile time, zero run-time overhead.
      - lngnmn 10y ago
        So, typed pointers with an analog of the option type. Thank you. Could we say that Swift or even SML with typed refs has similar safety and zero-cost abstractions?
        steveklabnik 10y ago
        While they may have some features that are zero-cost, it's not a defining feature of either language, and so they don't take it as far as Rust does. This was only one example, there are many more that those languages do not do, for various reasons.
        masklinn 10y ago
        Similar safety, yes absolutely. Zero-cost abstraction not that I know of although I believe Swift has pretty good support for them and the long-term goal is to be in the same space as Rust (https://news.ycombinator.com/item?id=13077178 https://news.ycombinator.com/item?id=13077178)
        kibwen 10y ago
        Determining whether an abstraction is zero-cost or not is often buried deep in a language's implementation, so you'd need an expert to determine whether a given abstraction in Swift or SML qualifies. But regarding closures specifically, I can say that it's very unlikely that either Swift or SML have a zero-cost implementation, since having stack-allocated closures is an immense and deliberate decision in language design (AFAIK only C++ and Rust do this).
nickpsecurity 10y ago
"'[Rust is] Technology from the past come to save the future from itself' He goes on to elaborate a bit: 'Many older languages [are] better than new ones. We keep forgetting already-learned lessons.'" Loving how this Graydon person thinks already. Same stuff pjmlp and I are always saying. Except he built something that took off massively with Mozilla's help. Extra credit there to both. Now, what might happen if this kind of thinking was applied all over the stack? I need 100 volunteers. Start with VMS-style versioning for critical files (esp system or application), clustering, distributed locking, and app API to leverage all that easily. Put that in the good Linux or BSD disros. Maybe they'll stop eating my files or the services popular on HN will crash less. If they get that done, we're adding Microsoft's approach to drivers that work if they reject that of MINIX 3 or Genode. We can also use TLA+, Coq, SPARK, and/or Rust since those were things in the past that worked too on the kinds of problems this effort will introduce. Systems and services should get really reliable after this. I won't even care about Linux kernel crashes as it will be a VM that goes down with my critical work checkpointed into another on same machine on a microkernel. A little driver reset happens then new one gets focus while old VM resets in background then joins cluster. For some extra money, this happens with physical separation in a desktop with two motherboards, one on each side, similar to old SGI Octanes. :)
- qwertyuiop924 10y ago
  >Loving how this Graydon person thinks already. Same stuff pjmlp and I are always saying. Rust was bootstrapped by a compiler written in OCaML. Like you and pjmlp, Graydon is a massive fan of fanatically strong typing, and most of that stuff was actually in many older languages that lost because C was an optimal solution at the time. However, at scale, C is no longer an optimal solution. Thus Rust can start eating C/C++'s lunch, and people will stop using C for what it does badly, and using it for what it does well (namely, writing small programs that do one thing and do it well, doing embedded work, kernels, and other bit hacking, and bootstrapping better languages).
  - nickpsecurity 10y ago
    "Rust was bootstrapped by a compiler written in OCaML." Another wise choice. I gave them credit for that, too, when they told me. "because C was an optimal solution at the time." Whoa, we've talked about this before. It's closer to an optimal solution if you're squeezing max performance out of old hardware with a higher-than-assembly language. It wasn't optimal on ease of compilation, safety, large programs, or even performance optimization for general case. That all takes different design decisions than the personal preferences of its designers when building on Richards' work. It was also achieved by Wirth shortly after to point that C's remaining benefit could've been had as an option or tweak to Wirth's approach. Easier to tweak his for C's benefits than vice versa since his was actually designed and simple. Final proof of that was when C's inventors did that in their ideal language: an Oberon-2 improvement called Go. "Thus Rust can start eating C/C++'s lunch, and people will stop using C for what it does badly, and using it for what it does well" This is true. Again, though, due to social reasons more than tech. People been able to do that with GPL'd Ada. Rust takes off, though. The likely reason is a combo of developers preferring its syntax/semantics, how the community runs, and primarily Mozilla's effort [like Sun's Java & Microsoft's C# before it]. Like with the Richard Gabriel and the startups, details of execution matter more than how great the idea is.
bmalehorn 10y ago
I am a systems programmer working at a company with a largely C++ codebase. We don't use Rust. It has nothing to do with the reasons mentioned in the article or this thread. Here are a list of requirements for us to use Rust: - Does it support all of the following architectures? x86_64, ARM, MIPS, powerPC - Does it support soft float? - Can it link against uclibc instead of glibc? - Can it link against arbitrary C libraries? - Can I use a C library's header.h file without having to hand-recode it to Rust? - Will the code I write now continue to compile 5 years from now? Does Rust score a resounding "YES" on ALL of the above questions?
- w8rbt 10y ago
  All of that will come after rust gets an ISO standard (like C and C++). Joking aside, C++ will be around forever and to a lesser degree, C will be too. They have 45 years of experience and revision. 50 years from now they'll probably still run the world just as they do today. C++11 and beyond is just as safe as any language. Rust came to be about 10 years too late.
  - notriddle 10y ago
    > C++11 and beyond is just as safe as any language. That's just not accurate. This is UB, despite being done entirely using modern C++ API: #include <iostream> #include <vector> using namespace std; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); v.push_back(3); v.push_back(4); for (int i : v) { v.push_back(5); std::cout << i << std::endl; v.push_back(6); } return 0; } I ran it on https://code.sololearn.com/caR4o14MOCWr/#cpp https://code.sololearn.com/caR4o14MOCWr/#cpp and got this output: 1 8519872 3 4
- steveklabnik 10y ago
  1. Yes. https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html 2. Yes, though it's kind of awkward. 3. There were some patches in the queue, I forget if/how they landed. 4. Yes. 5. Sort of. You have to rely on a tool to do it; they work reasonably well but aren't perfect yet. 6. Unless you're relying on something with a soundness hole, which we reserve the right to fix, and will be trivial to upgrade for you.
xling 10y ago
It solves the following problems for me: 1. Fast program execution. Sometimes you just want the speed that a scripting language cannot provide. Although I have to admit that many times Python is fast enough. I also pick D sometimes to write fast "scripts". 2. Reliability. Rust is a language that puts an emphasis on correct and reliable programs. The compiler does a great job at pointing me at pieces of code that I should think about again. It is similar to Haskell in that "if it compiles, it is likely correct". You pay upfront for long "talk to the compiler" sessions, but from experience I'd say that it pays off. 3. A language that is a joy to use. There are some really great languages that I love to use. They include Clojure, Lua, Python and Rust. The first two languages are mostly the products from single inventors with good taste plus a couple of contributors. The last two are the product of their respective communities. The Rust community tries to bring together the best ideas and lessons from different programming languages and has a democratic development process that tries to create a language and an ecosystem that is nice to use and plays well together with Rust's goals. 4. A new language with stable releases. I like to try new programming languages from time to time. It is cool that you can pick between stable, beta and nightly, depending on your stability needs. Furthermore, you can count on Rust being around for longer because Mozilla is supporting the language.
mmstick 10y ago
I typically explain that Rust's safety has side effects that are beneficial outside the obviousness of merely being safe. Namely, Rust's safety allows for migrating runtime checks into compile-time checks when constructing state machines around the ownership mechanism. Additionally, Rust's safety allows for additional compiler optimizations, because that safety can make more guarantees about the safeness of certain internal compiler flags. These have a speed benefit in addition to the already existing convenience benefits of not having to fight with broken code. I'd much rather fight a borrow checker than to fight through gdb's and lldb's to figure out why everything's totally broken. Then I go on to explain that there's a lot of great features in Rust that make it more convenient than C/C++ in a wide range of general purpose programming tasks. The pattern matching, sum types (Option/Result), error handling strategy, and my favorite, the Iterator trait. For the performance-minded C/C++ software developers, I explain that the safety that Rust provides via lifetimes and ownership allows me to comfortably perform extreme performance optimizations that would otherwise be incredibly nasty and error prone in C/C++ codebases. I can feel safe knowing that if it compiles, it's almost always going to work how I expect. Then there's the whole test-driven development mentality to Rust software development that Rust provides with `cargo test` and `cargo bench`, and data-oriented programming approach that Rust takes versus the inferior object-oriented approach via protocol-oriented programming (traits) to feature ad-hoc polymorphism and generics. It's a bit more complicated to explain that though. Then there's the whole community/tooling/documentation pitch. I think this is one of the more important aspects of Rust as it demonstrates that Rust has a future and is more than just a niche. It has momentum which cannot be destroyed. It's a language invented during the age of the Internet and takes full advantage of that. Rust does not employ guerrilla warfare tactics like other languages have done in the past. You can think of C/C++/Java/etc. as long-running empires. Guerrilla warfare-style tactics simply don't work against them. Emerging languages have always targeted C/C++/Java/etc. through guerrilla warfare tactics -- a loose community that mostly does their own thing. Rust is ambitiously establishing an empire of it's own through it's community -- a plethora of official projects and services: rustup, cargo, crates.io, docs.rs, users forum, internals forum, reddit thread, official documentation, docs team, an official book, GitHub hosting, etc. It's a recipe for success.
catnaroek 10y ago
To me, any language is two things: (0) How easy it is to write a program that just does what I want. (1) How easy it is to avoid writing a program that seems to do what I want, but doesn't. Rust already scores highly in (0), but it truly excels in (1). Beating Haskell and ML at their own ”it compiles, it works” game is no small feat. As for whether GC or no GC, most of the time I don't really care either way. Garbage collection is incredibly helpful, but so is Rust's particular brand of resource management. As long as there is neither memory corruption nor resource leaks, I'm happy. :-)
accurrent 10y ago
The main problem for rust that comes to mind is the already huge codebase written in c. Personally I tend to use opencv and openssl a lot. I know there are rust wrappers around openssl and opencv it would be nice to see pure implementations. I think an application like tls would benefit from rust a lot. There are other things like advanced static analyzers such as frama c which exist only for c. Similar tooling would be helpful for rust. Then there's of course embedded where rust could really shine. However llvm doesn't have backends to many of the 8bit architectures. Furthermore industry standards such as misra c dont seem to have rust equivalents, although rust may be better suited for safety critical code. Finally, explaining the need of a borrow checker to a beginner is very difficult unless they already have experienced enough pain with segfaults. It took me ten minutes with a pen and paper to explain pointers to my 12yo brother. How can I explain the need for all of rusts safety checks unless he has experience with segfaults. Any suggestions here would be welcome.
- steveklabnik 10y ago
  > the already huge codebase written in c. This is something you can work with!. A big example happening right now is the work going on in the GNOME project. > I think an application like tls would benefit from rust a lot. https://crates.io/crates/rustls https://crates.io/crates/rustls still has some C at its core, in ring, but it will be eventually. > Similar tooling would be helpful for rust. Rustc already does a lot of things this kind of tooling does. More tools are good though! 8 bit is far off. Teaching is hard. I don't have easy answers for those ones :)
accurrent 10y ago
The main problem for rust that comes to mind is the already huge codebase written in c. Personally I tend to use opencv and openssl a lot. I know there are rust wrappers around openssl and opencv it would be nice to see pure implementations. I think an application like tls would benefit from rust a lot. There are other things like advanced static analyzers such as frama c which exist only for c. Similar tooling would be helpful for rust. Then there's of course embedded where rust could really shine. However llvm doesn't have backed to many of the 8bit architectures. Furthermore industry standards such as misra c dontbseen to have rust equivalent s, although rust may be better suited for safety critical code. Finally, explaining the need of a borrow checker to a beginner is very difficult unless they already have experienced enough pain with segfaults. It took me ten minutes with a pen and paper to explain pointers to my 12yo brother, how I can explain the need for all of rusts safety checks would be hard unless he has experience with segfaults. Any suggestions here would be welcome.
eridius 10y ago
One of my favorite things about Rust is one of the practical applications of the safety. Specifically, it's that I can write multithreaded code without fear because the compiler won't let me get it wrong. It's far far far too easy to screw up multithreaded code if you're using any kind of shared data, and Rust is the only language I know of that truly makes it safe without compromising on performance. As a trivial example, some time ago I fixed a subtle threading bug in fish-shell. The code used RAII and lock guards, which is good, but in this particular case the lock guard was created using the wrong lock. So it was locking, it just wasn't locking the correct lock, meaning the data it was mutating was subject to a data race. As I fixed that, I found myself wishing the program had been written in Rust, because that sort of bug simply won't happen in Rust.
- innocentoldguy 10y ago
  I just picked up a book on Rust yesterday and am looking forward to working with it. I'm glad to hear that Rust makes concurrency easy, since that is a huge requirement in my current project. Since you obviously know more about it than I do (I'm currently a chapter-one-level neophyte), does Rust's ease come via the compiler catching errors for you, or are there mechanisms in the language itself that protect you from the pitfalls of concurrent programming? There are other languages that make concurrent programming easy and less error prone. Elixir is the one I'm probably most familiar with. It achieves this ease, in part, because it doesn't allow you to store state in objects, the way, say, Java does. Instead, you pass data through a function chain that will always produce the same result, unlike object-oriented code. There's more to it than that, of course, but that's a good starting point for understanding how Elixir helps with concurrency. If you don't mind me asking, what about Rust makes concurrency less error prone?
  - steveklabnik 10y ago
    You might enjoy reading https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h... It's from before 1.0, so some of the method names have changed, and scoped threads are in an external library instead of std, but the principles are all the same.
dispose13432 10y ago
You know what I would like? (Yeah, speaking of entitlement :) ) A "safe C". No classes, no functional programming (except function pointers, maybe anonymous functions), no exceptions, just plain C but 1. memory safe 2. optional array overflow detection (possibly unset by an operator in code, so [] is safe, but a^[] is unsafe. It's nice so if you _really_ need speed in a certain block and you know it's safe, you can turn it off). Maybe something like Go but with "manual" (c++ safe pointer style) memory management. Rust seems (to my untrained eye) too similar to C++ (it's quite a complicated/powerful language).
- zzzcpan 10y ago
  There are safe C dialects already. The problem is they are not compiling into C, so you can't leverage the whole C ecosystem with them. Although I would suggest a different road - C code generation with meta languages, you'll get all the benefits of C with total control and all the high-levelness and safety you might need.
  - nickpsecurity 10y ago
    I second that recommendation. It's what PreScheme, Ada, Chicken, and Nim did among others. All brought benefits in practice.
- icebraining 10y ago
  There are a few attempts like Cyclone: https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language)
- jerf 10y ago
  You really have pretty much spec'ed Go, except that when you want something manual you either use some []byte hacks or use the unsafe package to speak to some C code. Even when you want manual memory management it's rare that you need the entire program manually managed; usually there's some sort of hot data structure or code or something that you'd like to take over but that doesn't mean you want to fiddle with every last little character string manually. In particular, in the modern era, you're not going to find very many other languages that have anonymous functions but almost no functional programming capability like Go has. If you want to keep FP sealed away from your program... you know, for whatever reason, but to each their own... Go's got you about as well covered as you could hope for. Almost anything else that might come out is probably going to have FP constructs in it. (Especially after watching Go get raked over the coals for not having them.)
newsat13 10y ago
> The second is that, other than C# in 2000, 1995 or earlier is where most of our programming languages come from. Have we really not made any advancements significant enough in the last 20 years to have gotten people’s attention? This is like saying the bicycle was made in 1900 and modern bikes are the same. Has nothing changed in 100 years? Change for the sake of change is unnecessary and it most cases detrimental to the core product. Fact is that languages like PHP, Ruby and JavaScript are simple enough for most people to get their jobs done (read: 90% of all programming jobs) and to me this is the only requirement for a general purpose programming language. From a marketing point, rust needs to decide if this is for the power programmer or not. For example, Go has taken the niche of easy to understand and won't complicate life by adding unnecessary features so that it can pretend to be "modern" (I am looking at you ES6/7). Rust needs to understand that it simply cannot replace Ruby/PHP or JavaScript. It is not easy to understand and it's super power is simply not required for most programming tasks. My understanding is that it is meant for systems programming and this means that it should target C/C++ and stop comparing itself with scripting languages.
- cbrewster 10y ago
  Considering Rust's target audience, I think comparing Rust to scripting languages is ok. While Rust is aiming to compete in the system programming arena, it also aims to allow programmers who have experience using higher level languages to be able to get into systems programming without having to worry about safety. Rust has many features that make it almost feel like a high-level language and thus makes it much more approachable. That being said, Rust does not aim to really replace Ruby/PHP or Javascript, but rather a be a tool available to those programmers to write fast and safe code when needed.
- armitron 10y ago
  It'll have a hard time in systems programming too, at least as far as converting people from C/C++. It will attract new talent, but it's obvious to me that people who have invested years in C or C++ will not jump to Rust. The reasons for that are numerous, but the most important one to me is that in many cases __it is a lot harder in terms of mental load and time required to write safe Rust code than it is to write the equivalent C/C++__. Not to mention a complicated syntax and flow that turns your brain into mush. Imagine working with code that looks like this all day (1). Extrapolating from that we can probably say that Rust will be a failure (assuming goal of making a dent in the C/C++ entrenchment) in the near/medium term. (1) https://i.yuki.la/g/1479897150581.jpg https://i.yuki.la/g/1479897150581.jpg
Philipp__ 10y ago
Rust left big impression on me mostly because I was amazed that there exists functional language in Systems programming world! There, C is the absolute king, even Cpp doesn't cut it sometimes (when we are coming close to embedded world). Writing in Rust really feels like "programming" and not "systems programming", because of the way you approach the problems that are bound relatively close to metal. And community is amazing. So I just hope I gain more knowledge and time, so I can start playing with it properly. Disclaimer: I haven't programmed a lot in Rust, because I am busy learning other thing atm (student heh), but I am following it for 2 years now, and reading a lot about it, occasionally I write some small programs.
- nickpsecurity 10y ago
  If you like that concept, then check out this functional language in system programming that didn't require a LISP machine: https://en.wikipedia.org/wiki/PreScheme https://en.wikipedia.org/wiki/PreScheme The House and MirageOS operating systems also put Haskell and Ocaml to work for this respectively. House even did drivers in Haskell with a modified version of hop. Here's their site: http://programatica.cs.pdx.edu/House/ http://programatica.cs.pdx.edu/House/
tinco 10y ago
For me the main selling point is that it allows me to do code with performance constraints without having to resort to a programming language without modern package management, modern documentation or a modern ecosystem. I would have jumped at any chance to do modern programming that way, and dodge C and C++. It is a double blessing that besides satisfying these rather basic constraints, it's actually a great programming language as well, improving safety and reliability, having a concise but expressive syntax, a powerful type system, even a novel solution for enforcing some safety in shared memory situations.
aschampion 10y ago
A big non-safety selling point of Rust for me is a systems language with the tooling and ecosystem of a modern dynamic language. Dependency management and composition is a necessary part of complex programs, but a tedious, painful timesink in almost all systems languages. While CMake and similar tools improved the situation for C++, it's still an enormous pain and a barrier to sharing and reusing code. You are often forced to re-invent the wheel -- complete with your own bugs and maintenance obligation -- simply because getting a dependency to be built and detected cross-platform may be an even larger cost. Cargo is a wonder. It's more limited in scope than something like CMake, but for the vast majority of use cases that are just pulling in a library or binding from the same language, it's spectacular. Related to this, having an opinionated lint built into the tooling creates a common, readable dialect for the ecosystem. This is especially important for verbose syntax languages like Rust or C++. There are C++ libraries I can't understand simply because special snowflake formatting combined with complex template syntax renders it illegible.
- zzzcpan 10y ago
  Last time I checked cargo was still not handling external dependencies and the packages were simply wrapping system-wide dependencies, that you have to manage yourself. Same problem as with all CPAN-derived package managers.
  - steveklabnik 10y ago
    It's up to the implementer of the wrapper; some will compile a version if they can't find one on the system, for example.
  - the_mitsuhiko 10y ago
    It is intentionally not handling external dependencies. That's not what it's for. Many libraries and wrappers will compile the library if missing on the system (eg: rust-curl as a practical example will compile curl and statically link it if needed).
    - zzzcpan 10y ago
Xorlev 10y ago
For me, Rust is a return to performance without compromising on high-level abstractions (e.g. iterator methods). Rust is very expressive, but at the same time safe and has your back on performance and keeps you safe. Honestly, I feel safer writing in Rust than I do Java. Even Java has its footguns, especially with mutable state being shared across threads. I can't really comment on C++ as I have never written it professionally. Rust not being a garbage collected language leaves it free to focus on more important problems as well. Not knocking the difficulty of implementing the borrow checker, but once you have GC in a language you spend forever tuning to fit your users' workloads. Unless you're Go, then you optimize for latency at the cost of CPU, but that seems like a very acceptable tradeoff to make given how Go is most commonly used. I've never seen a single language with so much promise for both systems programming and service/application development. Edit: Forgot to mention, every time I tried to get into C++, I was always reminded how good I have dependency management in Java. Rust is even better than Java in that realm; Cargo is an amazing piece of software. In that context I like Rust for the same reason I like Go: opinionated tooling. I might not always agree with the decisions, but at least it's opinionated and easy to work with.
- vbezhenar 10y ago
  Not everyone have to tune GC. I never had to do that. I work with government project which serves the whole country now (small cluster with jboss servers), nobody tuned GC there, because there was no need (except -Xmx setting, of course). I wrote few simple programs with Rust, but its memory management model is much harder to use, than GC (no thinking about memory at all, just don't leak) or ARC (just think about cycles). While I understand why it's necessary to achieve higher performance, it's harder to use for developer. It might have uses for multithreading, but, honestly, I never had any problems with it. It's usually better to write single-thread code and avoid multithreading except in few carefully written places. So it solves a problem I never had. That's my perspective, I mostly did enterprise web development and iOS development. Probably from systems programming things look different.
  - steveklabnik 10y ago
    Rusts guarantees aren't just about multithreading: http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit...
steveklabnik 10y ago
This blog post was inspired by this comment: https://news.ycombinator.com/item?id=13266627 https://news.ycombinator.com/item?id=13266627
Animats 10y ago
A sales pitch asking others to help you with your sales pitch. That's a good marketing concept. It's similar to "ordinary people say why X is great" ads. Beyond the safety issue, I'm still not clear on how to think about Rust. It's mostly an imperative language at the language level, but it has so much functional programming stuff in templates that it looks like a functional one. It's often hard to visualize what all that stuff is doing. Did that ".collect" generate a big intermediate array? How can you tell without looking at the generated code? What kind of development environment would help? Rust uses closures very heavily for routine functions. That's a big change in thinking for C programmers. The module system seems clunky. There are modules, and crates, and TOML files, and module statements, and required directory structure. Adding a module seems to require editing about three files. The management of imported names seems unnecessarily obtuse, too. Having both "extern" and "use" seems overkill. Most languages get by with a single "import" statement. I see all this as an acceptable price to pay for safety, but it's rough on many programmers.
- stirner 10y ago
  > There are modules, and crates, and TOML files, and module statements, and required directory structure. I'm a fan of Rust but I also think Cargo seems pretty inelegant considering how carefully considered everything else in the language is. Maybe I'm just biased against Tom Preston-Werner.
  - steveklabnik 10y ago
    What would you have chosen instead? At the time, we weren't super big fans of TOML, but it was the least bad choice. It's grown on me.
    - stirner 10y ago
      I get what you mean by "least bad". I guess I'm wary of all configuration formats. Would plain old INI have been an option or is it too poorly specified?
      - 10y ago
sidlls 10y ago
The biggest flaw in Rust's marketing, as far as I can tell, isn't noting that it's safer than C or C++, or that it's a systems programming language, it's the simultaneous (implicit and explicit) confrontational bashing on languages that aren't Rust, but especially C and C++, and the egregious ego-inflating comparisons (x-in-Rust is y-times-as-fast-as-x-in-C-or-C++). I've only written a few relatively small ("toy") applications to completion in Rust. I have one application I'm working on in Rust at work, which is in an advanced stage of development and that will replace a significant part of our production-deployed current implementation (in python). I also have one application I'm working on in my spare time that is not a toy (although it is for entertainment purposes). My view is that for a good number of tasks Rust is nicer to use than C++, and probably I'd reach for Rust before C++ in instances where I'd normally choose C++. It would depend heavily on the context when comparing Rust vs. C. The safety argument simply doesn't register most of the time. No, this isn't because "I don't have problems writing safe C or C++ code," (although I certainly expect the above comment to be misinterpreted uncharitably in this way) this is because the kinds of safety guarantees Rust provides simply don't register on the list of reasons to explicitly choose it (over C or C++) in a large number of contexts. Even in contexts where it does matter, the current state of affairs is that those terrible languages, C and C++, run the world well enough. There are some pretty good examples of terrible safety flaws that may have been avoided with Rust's guarantees. These aren't universally applicable to all problems to be solved in programming. My advice, for all it's worth, is to stop hyper-focusing on safety and definitely stop the oblique insults to C, C++ (and other languages--some notable GC'd ones come to mind, from recent posts and comments I've seen around here). Rust has so much more to offer than an implementation detail (which is what "safety" is).
- wereHamster 10y ago
  > The safety argument simply doesn't register most of the time. Just like Steve said: > Rust is safer than C or C++. (“I never have problems with safety in the C++ code I write” is a common reply.) The CVE provides a pretty convincing argument that people can't write safe code in C/C++. And improving safety over C/C++ specifically is Rust's raison d'etre (you know, being developed by Mozilla which has a pretty large C/C++ codebase where safety is an important aspect). The bashing isn't based on people merely disliking C/C++. It's based on the fact that we observed 30 years of C/C++ being used in the industry and yet we still discover security holes caused by the same underlying flaws in the language. Yes, Rust may have other features to offer, too. But safety is a big one and is thus mentioned so often.
empath75 10y ago
I've done some rust tutorials, and I think the language is really interesting, but the reason I've never used it is I don't know what I would use it for, other than system programming. I've never had a work related problem where I searched for a way to solve it, and someone had said: "Oh, if you use rust it's easy, because of x,y and z." I'm sure if I were writing something like sshd from scratch today I'd use rust, but other than system-y sorts of applications like that, I don't know what I'd use it for.
- pornel 10y ago
  I think that's perfectly fair. Rust isn't the best language for everything. Not everyone writes databases, codecs, filesystems, kernels, protocol implementations, etc.
- stymaar 10y ago
  I can relate to this. I'm a web developer and Rust (mostly the ecosystem) is not ready for web dev (the future look bright though, tools like Diesel[1] or Rocket[2] looks incredibly promising). I recently found a place where Rust really shine : CLI tools. Rust multi-platform story is great, and the clap[3] crate makes it really straightforward to create helpful CLI tools. The blog post «Using Rust for scripting»[4] is really insightful in this regard. Now I use Rust any time I would have use Ruby to automate stuff with a little script. It's obviously more verbose, but the type system and error-handling story helps a lot. [1]: http://diesel.rs http://diesel.rs [2]: https://rocket.rs https://rocket.rs [3]: https://clap.rs https://clap.rs [4]: http://www.chriskrycho.com/2016/using-rust-for-scripting.html http://www.chriskrycho.com/2016/using-rust-for-scripting.htm...
rcthompson 10y ago
> Rust is] Technology from the past come to save the future from itself So Rust is the Terminator but in reverse.
softc 10y ago
A language's error-handling story is a central part of the experience of using that language. Especially if that language is a systems language. Rust's error handling still seems unnecessarily verbose to me. A specific error type is only necessary if the program can handle the error in question. Rust has acknowledged this but I still don't want every function call in my code to be prefixed with "try!" or suffixed with "?!" Rust error handling is also inefficient: in C++, if no error happens, then no code is run, whereas in Rust, even if no error happens a return code must be checked. I will sadly continue to happily use C++ until Rust improves its error-handling story.
- oconnor663 10y ago
  > Rust error handling is also inefficient: in C++, if no error happens, then no code is run, whereas in Rust, even if no error happens a return code must be checked. In this sense Rust's error handling is just like C (though harder to forget to check). Would you say C++ is more efficient than C in error handling?
  - softc 10y ago
    Yes I would. In modern C++ we use exceptions and RAII for automatic cleanup.
    - mmstick 10y ago
      Exceptions have high cost so I don't see where you are coming from. Rust's RAII goes further along than C++'s. C++ is playing a game of catchup to steal the move semantics from Rust.
      - olejorgenb 10y ago
        According to http://stackoverflow.com/a/13836329/1517969 http://stackoverflow.com/a/13836329/1517969 modern c++ exceptions are free when no throw occurs.
        10y ago
agentgt 10y ago
Interestingly OCaml is 1996 (which is the language the original Rust compiler was written in). Maybe access to faster internet connections caused the rapid language explosion (I remember broadband cable starting to be available at that time)?
pjmlp 10y ago
Personally I don't have any use for Rust, other than occasionally dabbling on it, but I look forward to its adoption. Because Rust appears to be one of the ways for newer generations to rediscover how systems programming was done in safer systems programming languages before UNIX alongside C, enjoyed adoption across the industry. Also due to all the work on ownership management, that has already influenced future design decisions on C++, Swift, D, ParaSail and Pony. And eventually with time, even those of us that don't use it, might enjoy having a safer stack to work with.
ue_ 10y ago
Can someone tell me how this language is supposed to be any degree of 'safe' when things like this compile (without warning, on Nightly rustc) and "panic"? Rust is about as safe as C. fn main() { let a = 4; let v = [0,1,2,3]; println!("{}", v[a]); } result: rustc 1.15.0-nightly (71c06a56a 2016-12-18) thread 'main' panicked at 'index out of bounds: the len is 4 but the index is 4', <anon>:4 note: Run with `RUST_BACKTRACE=1` for a backtrace.
- dbaupp 10y ago
  Being safer isn't all or nothing. Even if a getting a guaranteed panic on array out of bounds was nearly as unsafe as the undefined behaviour of C in that case (it isn't, at all), Rust still mitigates many of C's other most dangerous problems.
- steveklabnik 10y ago
  A panic can not lead to memory unsafety, unlike the same code in C.
  - snakeanus 10y ago
    > unlike the same code in C. What makes you think so? I am aware of multiple implementations that add bounds checking. There is nothing in the standard that forces it to be unsafe.
    - szemet 10y ago
      Does the standard force it to be safe? If not, then the parent comment is true: "the same code in C ... can lead to memory unsafety"
    - deleted 10y ago
      [deleted]
    - steveklabnik 10y ago
      I have never worked with one or come across it, only libraries that can add it through a different syntax. Do you have some references, or projects that require using it? I didn't think such a thing was standards-compliant but I'm also not an expert on the standard.
vvanders 10y ago
As someone who's been in the system programming space for a while and played with Rust for ~1.5 years here's my highlights. 1. I haven't written any multithreading code yet but I love the borrow-checker since it does a fantastic job of dealing with mutable state. I find I get better architected programs with single-ownership long before I start writing Rust and I love to see the compiler enforce it. 2. ADTs. Simply the best way to represent State + Data bar none. Combine with pattern matching and it's just sublime. 3. Iterators. Never seen a language do them so well with so little overhead. The focus on zero-cost abstractions really shines here. 4. Cross platform support. This is a huge one. Having dealt with MSCV/GCC/LLVM/custom compiler toolchains I can't stress to wonderful it is to have a consistent compiler that can build other targets on a different host. 5. Cargo, other people have covered it, enough said. 6. The community. Truly one of the better ones out there who not only want to help but also provides releases like clockwork with clear semantics on stability and APIs.
- nialv7 10y ago
  > 3. Iterators. Never seen a language do them so well with so little overhead. The focus on zero-cost abstractions really shines here. Try some D, maybe? :)
  - vvanders 10y ago
    Haven't had a chance to play with D yet but a quick perusal shows quite a few things missing from their iterator lib(zip, enumerate, cycle, collect). I probably just need to spend some time with it at some point. That said the examples look much close to Rust than C++11(seriously did they think through how painful std::transform() is with all the begin/end pairs?). One thing that not a lot of people know is you can iterate over a Result<T,E> and collect::<Result<Vec<T>, E>>() which is a really elegant way to bail on a single error or get a collection of values.
    - nialv7 10y ago
      D does have zip, enumerate, cycle (https://dlang.org/phobos/std_range.html https://dlang.org/phobos/std_range.html). It doesn't have a universal collect like Rust, but you can create arrays from ranges using array(). And if the target container/collection type is an OutputRange, you can use the put()(https://dlang.org/phobos/std_range_primitives.html#.put https://dlang.org/phobos/std_range_primitives.html#.put) function to create collections from ranges.
pornel 10y ago
For me the best thing about Rust is that I can create beautiful APIs that are hard to misuse. With ownership rules I can enforce logic of how my API is supposed to be used, e.g. "you can call this method only once", "you can use that object only until you call destroy() on the parent" can be enforced at compile time. Same with levels of thread-safety of my code. Users of my libraries don't need to RTFM to use them correctly.
jondot 10y ago
Hi Steve, We've met at Rails conf, in Tel Aviv many years ago. You seemed nice, so I'm motivated to try to give you my 2c. I believe Rust can be more than safety but right now it isn't as you are imagining it. I've started off in the demoscene in the early 90's, and so I've had my share of assembly, C, and C++ as a kid. I've built demos, games, generative 3D art with 8-64kb executables, without access to Internet or any form of proper knowledge, and it's funny how scared I am of attempting this again today when I'm much older, and much, much more experienced. I think one of the scary factors are the time-to-value ratio: I'm used to several orders of magnitude more productivity, and have much less time. I think the most important take away from my background story that you can adopt is - make Rust playful. Fun is a a base element for curiosity, it what drives us where we're the most receptive - when we're kids - to learn, to experience, and to understand what will in be our toolbelt for the next dozen years. Make rust playful. Make a game framework. Make it build on a mobile device. Make it build on a Pi (without docker, and the entire diarrhea of toolchain you have to use). Make it build for the Arduino. Cross compile it to Javascript (for fun!). Often I try my hands at C and C++ again. When I do that, I'm not disappointed. I see a comforting place where I've spent my childhood at (and with C++ - some of my professional life). I'm happy with how C++ evolved and how CMake works. I'm not happy because productivity didn't change for the better that much. It still requires around the same amount of time to build things in C and C++ as it did years ago. Where I do see a change is with Go. It gives me the same comfort, with an insane productivity factor. It also had fun baked in from the start - it can run on mobile, it can run games, and it can compile to what ever I want without a fuss. I hope my thoughts will make a real change. I really do think this is the missing part with the Rust story.
- kibwen 10y ago
  Since you mentioned the demoscene, I think you may enjoy this fantastic 56kb demo written in Rust: https://www.reddit.com/r/rust/comments/597hhv/logicoma_elysian_1st_place_trsac_2016_pc_64kb/ https://www.reddit.com/r/rust/comments/597hhv/logicoma_elysi... :)
  - jondot 10y ago
    Wow! fantastic!
EwanToo 10y ago
I haven't fully thought this out yet, but it strikes me that with an AWS SDK, Rust would be an ideal language for high performance Lambda functions. * No JVM/Interpreter memory overhead * No garbage collection (I know this is controversial) * Compiled binaries with low startup time * High performance (assuming you write it well..) * Aware of multi-core systems * Good networking capabilities Currently if you want really high performance on Lambda with a SDK for AWS services, you have to go Java and all that comes with it, or launch Go or C++ binaries via a nodejs process.
- steveklabnik 10y ago
  https://crates.io/crates/rusoto https://crates.io/crates/rusoto is one of the bigger AWS SDK crates. There's been some interest in Rust on Lambda, but I forget if there's a tutorial or something.
- deleted 10y ago
  [deleted]
frozenport 10y ago
C++17: 2016
fjrieiekd 10y ago
I love Rust and I've been following it for a while now, hoping to use it more in my line of work. However, I still find that support for Rust on Android and iOS is still lacking, compared to C and C++. These platforms are technically supported, but they aren't tier one and don't seem to be widely used. This doesn't matter that much for hobby programming, but for production work I'd be happier if there was a clear and easy path for adding Rust to the build system, and having the tools integrate into my chain, with great support for debugging and testing. I'm happy to deal with the extra work myself when I'm doing it for fun, but otherwise, compared to the first class support in Xcode or even the NDK, Rust is still far behind. For me to feel comfortable in taking the risk in choosing a non-vendor-sponsored language like Rust, I need to be confident that my tools will work and won't break on me, integrate poorly or fail in unexpected ways. If Rust was on par with C/C++ support, it would definitely be a very compelling solution.

242 points by anp 10y ago

I haven't found any reply blog posts yet but I'm curious about rust. Has anyone found a response to the call to action at the bottom of the post?

masklinn 10y ago
> Has anyone found a response to the call to action at the bottom of the post? The post was published ~1h ago according to the author's twitter broadcast/alert[0], so there probably aren't any lengthy responses yet (even the twitter responses have nothing). [0] https://twitter.com/steveklabnik/status/814165927478652929 https://twitter.com/steveklabnik/status/814165927478652929
stymaar 10y ago
It looks like this blog post is around an hour old, a bit short to write a response blog post ;)
mmstick 10y ago
Responses are on the official Rust reddit forum. https://www.reddit.com/r/rust/comments/5krhr0/rust_is_more_than_safety/ https://www.reddit.com/r/rust/comments/5krhr0/rust_is_more_t...

Ar-Curunir 10y ago

I like how "high level" Rust feels. It doesn't feel like C or something of that ilk.

vvanders 10y ago
Yes, the relentless focus on zero-cost abstractions is fantastic.
- lngnmn 10y ago
  Could you, please, elaborate. In my opinion zero-cost abstraction is nothing but a catchy meme. Could you provide an example, so I would try to implement such a wonder in one of classic languages I know, like SML or Scheme?
  - steveklabnik 10y ago
    A simple one is Option. An Option<&T> is a pointer to some type T. Option is an enum, & is a reference, which has all of Rust's safety checking. This will all compile down to a regular old pointer, just like in C. Even though you have null checking and protection against dangling pointers, etc. It's all at compile time, zero run-time overhead.
    - lngnmn 10y ago
      So, typed pointers with an analog of the option type. Thank you. Could we say that Swift or even SML with typed refs has similar safety and zero-cost abstractions?
      - steveklabnik 10y ago
        While they may have some features that are zero-cost, it's not a defining feature of either language, and so they don't take it as far as Rust does. This was only one example, there are many more that those languages do not do, for various reasons.
      - masklinn 10y ago
        Similar safety, yes absolutely. Zero-cost abstraction not that I know of although I believe Swift has pretty good support for them and the long-term goal is to be in the same space as Rust (https://news.ycombinator.com/item?id=13077178 https://news.ycombinator.com/item?id=13077178)
      - kibwen 10y ago
        Determining whether an abstraction is zero-cost or not is often buried deep in a language's implementation, so you'd need an expert to determine whether a given abstraction in Swift or SML qualifies. But regarding closures specifically, I can say that it's very unlikely that either Swift or SML have a zero-cost implementation, since having stack-allocated closures is an immense and deliberate decision in language design (AFAIK only C++ and Rust do this).

nickpsecurity 10y ago

"'[Rust is] Technology from the past come to save the future from itself' He goes on to elaborate a bit: 'Many older languages [are] better than new ones. We keep forgetting already-learned lessons.'" Loving how this Graydon person thinks already. Same stuff pjmlp and I are always saying. Except he built something that took off massively with Mozilla's help. Extra credit there to both. Now, what might happen if this kind of thinking was applied all over the stack? I need 100 volunteers. Start with VMS-style versioning for critical files (esp system or application), clustering, distributed locking, and app API to leverage all that easily. Put that in the good Linux or BSD disros. Maybe they'll stop eating my files or the services popular on HN will crash less. If they get that done, we're adding Microsoft's approach to drivers that work if they reject that of MINIX 3 or Genode. We can also use TLA+, Coq, SPARK, and/or Rust since those were things in the past that worked too on the kinds of problems this effort will introduce. Systems and services should get really reliable after this. I won't even care about Linux kernel crashes as it will be a VM that goes down with my critical work checkpointed into another on same machine on a microkernel. A little driver reset happens then new one gets focus while old VM resets in background then joins cluster. For some extra money, this happens with physical separation in a desktop with two motherboards, one on each side, similar to old SGI Octanes. :)

qwertyuiop924 10y ago
>Loving how this Graydon person thinks already. Same stuff pjmlp and I are always saying. Rust was bootstrapped by a compiler written in OCaML. Like you and pjmlp, Graydon is a massive fan of fanatically strong typing, and most of that stuff was actually in many older languages that lost because C was an optimal solution at the time. However, at scale, C is no longer an optimal solution. Thus Rust can start eating C/C++'s lunch, and people will stop using C for what it does badly, and using it for what it does well (namely, writing small programs that do one thing and do it well, doing embedded work, kernels, and other bit hacking, and bootstrapping better languages).
- nickpsecurity 10y ago
  "Rust was bootstrapped by a compiler written in OCaML." Another wise choice. I gave them credit for that, too, when they told me. "because C was an optimal solution at the time." Whoa, we've talked about this before. It's closer to an optimal solution if you're squeezing max performance out of old hardware with a higher-than-assembly language. It wasn't optimal on ease of compilation, safety, large programs, or even performance optimization for general case. That all takes different design decisions than the personal preferences of its designers when building on Richards' work. It was also achieved by Wirth shortly after to point that C's remaining benefit could've been had as an option or tweak to Wirth's approach. Easier to tweak his for C's benefits than vice versa since his was actually designed and simple. Final proof of that was when C's inventors did that in their ideal language: an Oberon-2 improvement called Go. "Thus Rust can start eating C/C++'s lunch, and people will stop using C for what it does badly, and using it for what it does well" This is true. Again, though, due to social reasons more than tech. People been able to do that with GPL'd Ada. Rust takes off, though. The likely reason is a combo of developers preferring its syntax/semantics, how the community runs, and primarily Mozilla's effort [like Sun's Java & Microsoft's C# before it]. Like with the Richard Gabriel and the startups, details of execution matter more than how great the idea is.

bmalehorn 10y ago

I am a systems programmer working at a company with a largely C++ codebase. We don't use Rust. It has nothing to do with the reasons mentioned in the article or this thread. Here are a list of requirements for us to use Rust: - Does it support all of the following architectures? x86_64, ARM, MIPS, powerPC - Does it support soft float? - Can it link against uclibc instead of glibc? - Can it link against arbitrary C libraries? - Can I use a C library's header.h file without having to hand-recode it to Rust? - Will the code I write now continue to compile 5 years from now? Does Rust score a resounding "YES" on ALL of the above questions?

w8rbt 10y ago
All of that will come after rust gets an ISO standard (like C and C++). Joking aside, C++ will be around forever and to a lesser degree, C will be too. They have 45 years of experience and revision. 50 years from now they'll probably still run the world just as they do today. C++11 and beyond is just as safe as any language. Rust came to be about 10 years too late.
- notriddle 10y ago
  > C++11 and beyond is just as safe as any language. That's just not accurate. This is UB, despite being done entirely using modern C++ API: #include <iostream> #include <vector> using namespace std; int main() { std::vector<int> v; v.push_back(1); v.push_back(2); v.push_back(3); v.push_back(4); for (int i : v) { v.push_back(5); std::cout << i << std::endl; v.push_back(6); } return 0; } I ran it on https://code.sololearn.com/caR4o14MOCWr/#cpp https://code.sololearn.com/caR4o14MOCWr/#cpp and got this output: 1 8519872 3 4
steveklabnik 10y ago
1. Yes. https://forge.rust-lang.org/platform-support.html https://forge.rust-lang.org/platform-support.html 2. Yes, though it's kind of awkward. 3. There were some patches in the queue, I forget if/how they landed. 4. Yes. 5. Sort of. You have to rely on a tool to do it; they work reasonably well but aren't perfect yet. 6. Unless you're relying on something with a soundness hole, which we reserve the right to fix, and will be trivial to upgrade for you.

xling 10y ago

It solves the following problems for me: 1. Fast program execution. Sometimes you just want the speed that a scripting language cannot provide. Although I have to admit that many times Python is fast enough. I also pick D sometimes to write fast "scripts". 2. Reliability. Rust is a language that puts an emphasis on correct and reliable programs. The compiler does a great job at pointing me at pieces of code that I should think about again. It is similar to Haskell in that "if it compiles, it is likely correct". You pay upfront for long "talk to the compiler" sessions, but from experience I'd say that it pays off. 3. A language that is a joy to use. There are some really great languages that I love to use. They include Clojure, Lua, Python and Rust. The first two languages are mostly the products from single inventors with good taste plus a couple of contributors. The last two are the product of their respective communities. The Rust community tries to bring together the best ideas and lessons from different programming languages and has a democratic development process that tries to create a language and an ecosystem that is nice to use and plays well together with Rust's goals. 4. A new language with stable releases. I like to try new programming languages from time to time. It is cool that you can pick between stable, beta and nightly, depending on your stability needs. Furthermore, you can count on Rust being around for longer because Mozilla is supporting the language.

mmstick 10y ago

I typically explain that Rust's safety has side effects that are beneficial outside the obviousness of merely being safe. Namely, Rust's safety allows for migrating runtime checks into compile-time checks when constructing state machines around the ownership mechanism. Additionally, Rust's safety allows for additional compiler optimizations, because that safety can make more guarantees about the safeness of certain internal compiler flags. These have a speed benefit in addition to the already existing convenience benefits of not having to fight with broken code. I'd much rather fight a borrow checker than to fight through gdb's and lldb's to figure out why everything's totally broken. Then I go on to explain that there's a lot of great features in Rust that make it more convenient than C/C++ in a wide range of general purpose programming tasks. The pattern matching, sum types (Option/Result), error handling strategy, and my favorite, the Iterator trait. For the performance-minded C/C++ software developers, I explain that the safety that Rust provides via lifetimes and ownership allows me to comfortably perform extreme performance optimizations that would otherwise be incredibly nasty and error prone in C/C++ codebases. I can feel safe knowing that if it compiles, it's almost always going to work how I expect. Then there's the whole test-driven development mentality to Rust software development that Rust provides with `cargo test` and `cargo bench`, and data-oriented programming approach that Rust takes versus the inferior object-oriented approach via protocol-oriented programming (traits) to feature ad-hoc polymorphism and generics. It's a bit more complicated to explain that though. Then there's the whole community/tooling/documentation pitch. I think this is one of the more important aspects of Rust as it demonstrates that Rust has a future and is more than just a niche. It has momentum which cannot be destroyed. It's a language invented during the age of the Internet and takes full advantage of that. Rust does not employ guerrilla warfare tactics like other languages have done in the past. You can think of C/C++/Java/etc. as long-running empires. Guerrilla warfare-style tactics simply don't work against them. Emerging languages have always targeted C/C++/Java/etc. through guerrilla warfare tactics -- a loose community that mostly does their own thing. Rust is ambitiously establishing an empire of it's own through it's community -- a plethora of official projects and services: rustup, cargo, crates.io, docs.rs, users forum, internals forum, reddit thread, official documentation, docs team, an official book, GitHub hosting, etc. It's a recipe for success.

catnaroek 10y ago

To me, any language is two things: (0) How easy it is to write a program that just does what I want. (1) How easy it is to avoid writing a program that seems to do what I want, but doesn't. Rust already scores highly in (0), but it truly excels in (1). Beating Haskell and ML at their own ”it compiles, it works” game is no small feat. As for whether GC or no GC, most of the time I don't really care either way. Garbage collection is incredibly helpful, but so is Rust's particular brand of resource management. As long as there is neither memory corruption nor resource leaks, I'm happy. :-)

accurrent 10y ago

The main problem for rust that comes to mind is the already huge codebase written in c. Personally I tend to use opencv and openssl a lot. I know there are rust wrappers around openssl and opencv it would be nice to see pure implementations. I think an application like tls would benefit from rust a lot. There are other things like advanced static analyzers such as frama c which exist only for c. Similar tooling would be helpful for rust. Then there's of course embedded where rust could really shine. However llvm doesn't have backends to many of the 8bit architectures. Furthermore industry standards such as misra c dont seem to have rust equivalents, although rust may be better suited for safety critical code. Finally, explaining the need of a borrow checker to a beginner is very difficult unless they already have experienced enough pain with segfaults. It took me ten minutes with a pen and paper to explain pointers to my 12yo brother. How can I explain the need for all of rusts safety checks unless he has experience with segfaults. Any suggestions here would be welcome.

steveklabnik 10y ago
> the already huge codebase written in c. This is something you can work with!. A big example happening right now is the work going on in the GNOME project. > I think an application like tls would benefit from rust a lot. https://crates.io/crates/rustls https://crates.io/crates/rustls still has some C at its core, in ring, but it will be eventually. > Similar tooling would be helpful for rust. Rustc already does a lot of things this kind of tooling does. More tools are good though! 8 bit is far off. Teaching is hard. I don't have easy answers for those ones :)

accurrent 10y ago

The main problem for rust that comes to mind is the already huge codebase written in c. Personally I tend to use opencv and openssl a lot. I know there are rust wrappers around openssl and opencv it would be nice to see pure implementations. I think an application like tls would benefit from rust a lot. There are other things like advanced static analyzers such as frama c which exist only for c. Similar tooling would be helpful for rust. Then there's of course embedded where rust could really shine. However llvm doesn't have backed to many of the 8bit architectures. Furthermore industry standards such as misra c dontbseen to have rust equivalent s, although rust may be better suited for safety critical code. Finally, explaining the need of a borrow checker to a beginner is very difficult unless they already have experienced enough pain with segfaults. It took me ten minutes with a pen and paper to explain pointers to my 12yo brother, how I can explain the need for all of rusts safety checks would be hard unless he has experience with segfaults. Any suggestions here would be welcome.

eridius 10y ago

One of my favorite things about Rust is one of the practical applications of the safety. Specifically, it's that I can write multithreaded code without fear because the compiler won't let me get it wrong. It's far far far too easy to screw up multithreaded code if you're using any kind of shared data, and Rust is the only language I know of that truly makes it safe without compromising on performance. As a trivial example, some time ago I fixed a subtle threading bug in fish-shell. The code used RAII and lock guards, which is good, but in this particular case the lock guard was created using the wrong lock. So it was locking, it just wasn't locking the correct lock, meaning the data it was mutating was subject to a data race. As I fixed that, I found myself wishing the program had been written in Rust, because that sort of bug simply won't happen in Rust.

innocentoldguy 10y ago
I just picked up a book on Rust yesterday and am looking forward to working with it. I'm glad to hear that Rust makes concurrency easy, since that is a huge requirement in my current project. Since you obviously know more about it than I do (I'm currently a chapter-one-level neophyte), does Rust's ease come via the compiler catching errors for you, or are there mechanisms in the language itself that protect you from the pitfalls of concurrent programming? There are other languages that make concurrent programming easy and less error prone. Elixir is the one I'm probably most familiar with. It achieves this ease, in part, because it doesn't allow you to store state in objects, the way, say, Java does. Instead, you pass data through a function chain that will always produce the same result, unlike object-oriented code. There's more to it than that, of course, but that's a good starting point for understanding how Elixir helps with concurrency. If you don't mind me asking, what about Rust makes concurrency less error prone?
- steveklabnik 10y ago
  You might enjoy reading https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.html https://blog.rust-lang.org/2015/04/10/Fearless-Concurrency.h... It's from before 1.0, so some of the method names have changed, and scoped threads are in an external library instead of std, but the principles are all the same.

dispose13432 10y ago

You know what I would like? (Yeah, speaking of entitlement :) ) A "safe C". No classes, no functional programming (except function pointers, maybe anonymous functions), no exceptions, just plain C but 1. memory safe 2. optional array overflow detection (possibly unset by an operator in code, so [] is safe, but a^[] is unsafe. It's nice so if you _really_ need speed in a certain block and you know it's safe, you can turn it off). Maybe something like Go but with "manual" (c++ safe pointer style) memory management. Rust seems (to my untrained eye) too similar to C++ (it's quite a complicated/powerful language).

zzzcpan 10y ago
There are safe C dialects already. The problem is they are not compiling into C, so you can't leverage the whole C ecosystem with them. Although I would suggest a different road - C code generation with meta languages, you'll get all the benefits of C with total control and all the high-levelness and safety you might need.
- nickpsecurity 10y ago
  I second that recommendation. It's what PreScheme, Ada, Chicken, and Nim did among others. All brought benefits in practice.
icebraining 10y ago
There are a few attempts like Cyclone: https://en.wikipedia.org/wiki/Cyclone_(programming_language) https://en.wikipedia.org/wiki/Cyclone_(programming_language)
jerf 10y ago
You really have pretty much spec'ed Go, except that when you want something manual you either use some []byte hacks or use the unsafe package to speak to some C code. Even when you want manual memory management it's rare that you need the entire program manually managed; usually there's some sort of hot data structure or code or something that you'd like to take over but that doesn't mean you want to fiddle with every last little character string manually. In particular, in the modern era, you're not going to find very many other languages that have anonymous functions but almost no functional programming capability like Go has. If you want to keep FP sealed away from your program... you know, for whatever reason, but to each their own... Go's got you about as well covered as you could hope for. Almost anything else that might come out is probably going to have FP constructs in it. (Especially after watching Go get raked over the coals for not having them.)

newsat13 10y ago

> The second is that, other than C# in 2000, 1995 or earlier is where most of our programming languages come from. Have we really not made any advancements significant enough in the last 20 years to have gotten people’s attention? This is like saying the bicycle was made in 1900 and modern bikes are the same. Has nothing changed in 100 years? Change for the sake of change is unnecessary and it most cases detrimental to the core product. Fact is that languages like PHP, Ruby and JavaScript are simple enough for most people to get their jobs done (read: 90% of all programming jobs) and to me this is the only requirement for a general purpose programming language. From a marketing point, rust needs to decide if this is for the power programmer or not. For example, Go has taken the niche of easy to understand and won't complicate life by adding unnecessary features so that it can pretend to be "modern" (I am looking at you ES6/7). Rust needs to understand that it simply cannot replace Ruby/PHP or JavaScript. It is not easy to understand and it's super power is simply not required for most programming tasks. My understanding is that it is meant for systems programming and this means that it should target C/C++ and stop comparing itself with scripting languages.

cbrewster 10y ago
Considering Rust's target audience, I think comparing Rust to scripting languages is ok. While Rust is aiming to compete in the system programming arena, it also aims to allow programmers who have experience using higher level languages to be able to get into systems programming without having to worry about safety. Rust has many features that make it almost feel like a high-level language and thus makes it much more approachable. That being said, Rust does not aim to really replace Ruby/PHP or Javascript, but rather a be a tool available to those programmers to write fast and safe code when needed.
armitron 10y ago
It'll have a hard time in systems programming too, at least as far as converting people from C/C++. It will attract new talent, but it's obvious to me that people who have invested years in C or C++ will not jump to Rust. The reasons for that are numerous, but the most important one to me is that in many cases __it is a lot harder in terms of mental load and time required to write safe Rust code than it is to write the equivalent C/C++__. Not to mention a complicated syntax and flow that turns your brain into mush. Imagine working with code that looks like this all day (1). Extrapolating from that we can probably say that Rust will be a failure (assuming goal of making a dent in the C/C++ entrenchment) in the near/medium term. (1) https://i.yuki.la/g/1479897150581.jpg https://i.yuki.la/g/1479897150581.jpg

Philipp__ 10y ago

Rust left big impression on me mostly because I was amazed that there exists functional language in Systems programming world! There, C is the absolute king, even Cpp doesn't cut it sometimes (when we are coming close to embedded world). Writing in Rust really feels like "programming" and not "systems programming", because of the way you approach the problems that are bound relatively close to metal. And community is amazing. So I just hope I gain more knowledge and time, so I can start playing with it properly. Disclaimer: I haven't programmed a lot in Rust, because I am busy learning other thing atm (student heh), but I am following it for 2 years now, and reading a lot about it, occasionally I write some small programs.

nickpsecurity 10y ago
If you like that concept, then check out this functional language in system programming that didn't require a LISP machine: https://en.wikipedia.org/wiki/PreScheme https://en.wikipedia.org/wiki/PreScheme The House and MirageOS operating systems also put Haskell and Ocaml to work for this respectively. House even did drivers in Haskell with a modified version of hop. Here's their site: http://programatica.cs.pdx.edu/House/ http://programatica.cs.pdx.edu/House/

tinco 10y ago

For me the main selling point is that it allows me to do code with performance constraints without having to resort to a programming language without modern package management, modern documentation or a modern ecosystem. I would have jumped at any chance to do modern programming that way, and dodge C and C++. It is a double blessing that besides satisfying these rather basic constraints, it's actually a great programming language as well, improving safety and reliability, having a concise but expressive syntax, a powerful type system, even a novel solution for enforcing some safety in shared memory situations.

aschampion 10y ago

A big non-safety selling point of Rust for me is a systems language with the tooling and ecosystem of a modern dynamic language. Dependency management and composition is a necessary part of complex programs, but a tedious, painful timesink in almost all systems languages. While CMake and similar tools improved the situation for C++, it's still an enormous pain and a barrier to sharing and reusing code. You are often forced to re-invent the wheel -- complete with your own bugs and maintenance obligation -- simply because getting a dependency to be built and detected cross-platform may be an even larger cost. Cargo is a wonder. It's more limited in scope than something like CMake, but for the vast majority of use cases that are just pulling in a library or binding from the same language, it's spectacular. Related to this, having an opinionated lint built into the tooling creates a common, readable dialect for the ecosystem. This is especially important for verbose syntax languages like Rust or C++. There are C++ libraries I can't understand simply because special snowflake formatting combined with complex template syntax renders it illegible.

zzzcpan 10y ago
Last time I checked cargo was still not handling external dependencies and the packages were simply wrapping system-wide dependencies, that you have to manage yourself. Same problem as with all CPAN-derived package managers.
- steveklabnik 10y ago
  It's up to the implementer of the wrapper; some will compile a version if they can't find one on the system, for example.
- the_mitsuhiko 10y ago
  It is intentionally not handling external dependencies. That's not what it's for. Many libraries and wrappers will compile the library if missing on the system (eg: rust-curl as a practical example will compile curl and statically link it if needed).
  - zzzcpan 10y ago

Xorlev 10y ago

For me, Rust is a return to performance without compromising on high-level abstractions (e.g. iterator methods). Rust is very expressive, but at the same time safe and has your back on performance and keeps you safe. Honestly, I feel safer writing in Rust than I do Java. Even Java has its footguns, especially with mutable state being shared across threads. I can't really comment on C++ as I have never written it professionally. Rust not being a garbage collected language leaves it free to focus on more important problems as well. Not knocking the difficulty of implementing the borrow checker, but once you have GC in a language you spend forever tuning to fit your users' workloads. Unless you're Go, then you optimize for latency at the cost of CPU, but that seems like a very acceptable tradeoff to make given how Go is most commonly used. I've never seen a single language with so much promise for both systems programming and service/application development. Edit: Forgot to mention, every time I tried to get into C++, I was always reminded how good I have dependency management in Java. Rust is even better than Java in that realm; Cargo is an amazing piece of software. In that context I like Rust for the same reason I like Go: opinionated tooling. I might not always agree with the decisions, but at least it's opinionated and easy to work with.

vbezhenar 10y ago
Not everyone have to tune GC. I never had to do that. I work with government project which serves the whole country now (small cluster with jboss servers), nobody tuned GC there, because there was no need (except -Xmx setting, of course). I wrote few simple programs with Rust, but its memory management model is much harder to use, than GC (no thinking about memory at all, just don't leak) or ARC (just think about cycles). While I understand why it's necessary to achieve higher performance, it's harder to use for developer. It might have uses for multithreading, but, honestly, I never had any problems with it. It's usually better to write single-thread code and avoid multithreading except in few carefully written places. So it solves a problem I never had. That's my perspective, I mostly did enterprise web development and iOS development. Probably from systems programming things look different.
- steveklabnik 10y ago
  Rusts guarantees aren't just about multithreading: http://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/ http://manishearth.github.io/blog/2015/05/17/the-problem-wit...

steveklabnik 10y ago

This blog post was inspired by this comment: https://news.ycombinator.com/item?id=13266627 https://news.ycombinator.com/item?id=13266627

Animats 10y ago

A sales pitch asking others to help you with your sales pitch. That's a good marketing concept. It's similar to "ordinary people say why X is great" ads. Beyond the safety issue, I'm still not clear on how to think about Rust. It's mostly an imperative language at the language level, but it has so much functional programming stuff in templates that it looks like a functional one. It's often hard to visualize what all that stuff is doing. Did that ".collect" generate a big intermediate array? How can you tell without looking at the generated code? What kind of development environment would help? Rust uses closures very heavily for routine functions. That's a big change in thinking for C programmers. The module system seems clunky. There are modules, and crates, and TOML files, and module statements, and required directory structure. Adding a module seems to require editing about three files. The management of imported names seems unnecessarily obtuse, too. Having both "extern" and "use" seems overkill. Most languages get by with a single "import" statement. I see all this as an acceptable price to pay for safety, but it's rough on many programmers.

stirner 10y ago
> There are modules, and crates, and TOML files, and module statements, and required directory structure. I'm a fan of Rust but I also think Cargo seems pretty inelegant considering how carefully considered everything else in the language is. Maybe I'm just biased against Tom Preston-Werner.
- steveklabnik 10y ago
  What would you have chosen instead? At the time, we weren't super big fans of TOML, but it was the least bad choice. It's grown on me.
  - stirner 10y ago
    I get what you mean by "least bad". I guess I'm wary of all configuration formats. Would plain old INI have been an option or is it too poorly specified?
    - 10y ago

sidlls 10y ago

The biggest flaw in Rust's marketing, as far as I can tell, isn't noting that it's safer than C or C++, or that it's a systems programming language, it's the simultaneous (implicit and explicit) confrontational bashing on languages that aren't Rust, but especially C and C++, and the egregious ego-inflating comparisons (x-in-Rust is y-times-as-fast-as-x-in-C-or-C++). I've only written a few relatively small ("toy") applications to completion in Rust. I have one application I'm working on in Rust at work, which is in an advanced stage of development and that will replace a significant part of our production-deployed current implementation (in python). I also have one application I'm working on in my spare time that is not a toy (although it is for entertainment purposes). My view is that for a good number of tasks Rust is nicer to use than C++, and probably I'd reach for Rust before C++ in instances where I'd normally choose C++. It would depend heavily on the context when comparing Rust vs. C. The safety argument simply doesn't register most of the time. No, this isn't because "I don't have problems writing safe C or C++ code," (although I certainly expect the above comment to be misinterpreted uncharitably in this way) this is because the kinds of safety guarantees Rust provides simply don't register on the list of reasons to explicitly choose it (over C or C++) in a large number of contexts. Even in contexts where it does matter, the current state of affairs is that those terrible languages, C and C++, run the world well enough. There are some pretty good examples of terrible safety flaws that may have been avoided with Rust's guarantees. These aren't universally applicable to all problems to be solved in programming. My advice, for all it's worth, is to stop hyper-focusing on safety and definitely stop the oblique insults to C, C++ (and other languages--some notable GC'd ones come to mind, from recent posts and comments I've seen around here). Rust has so much more to offer than an implementation detail (which is what "safety" is).

wereHamster 10y ago
> The safety argument simply doesn't register most of the time. Just like Steve said: > Rust is safer than C or C++. (“I never have problems with safety in the C++ code I write” is a common reply.) The CVE provides a pretty convincing argument that people can't write safe code in C/C++. And improving safety over C/C++ specifically is Rust's raison d'etre (you know, being developed by Mozilla which has a pretty large C/C++ codebase where safety is an important aspect). The bashing isn't based on people merely disliking C/C++. It's based on the fact that we observed 30 years of C/C++ being used in the industry and yet we still discover security holes caused by the same underlying flaws in the language. Yes, Rust may have other features to offer, too. But safety is a big one and is thus mentioned so often.

empath75 10y ago

I've done some rust tutorials, and I think the language is really interesting, but the reason I've never used it is I don't know what I would use it for, other than system programming. I've never had a work related problem where I searched for a way to solve it, and someone had said: "Oh, if you use rust it's easy, because of x,y and z." I'm sure if I were writing something like sshd from scratch today I'd use rust, but other than system-y sorts of applications like that, I don't know what I'd use it for.

pornel 10y ago
I think that's perfectly fair. Rust isn't the best language for everything. Not everyone writes databases, codecs, filesystems, kernels, protocol implementations, etc.
stymaar 10y ago
I can relate to this. I'm a web developer and Rust (mostly the ecosystem) is not ready for web dev (the future look bright though, tools like Diesel[1] or Rocket[2] looks incredibly promising). I recently found a place where Rust really shine : CLI tools. Rust multi-platform story is great, and the clap[3] crate makes it really straightforward to create helpful CLI tools. The blog post «Using Rust for scripting»[4] is really insightful in this regard. Now I use Rust any time I would have use Ruby to automate stuff with a little script. It's obviously more verbose, but the type system and error-handling story helps a lot. [1]: http://diesel.rs http://diesel.rs [2]: https://rocket.rs https://rocket.rs [3]: https://clap.rs https://clap.rs [4]: http://www.chriskrycho.com/2016/using-rust-for-scripting.html http://www.chriskrycho.com/2016/using-rust-for-scripting.htm...

rcthompson 10y ago

> Rust is] Technology from the past come to save the future from itself So Rust is the Terminator but in reverse.

softc 10y ago

A language's error-handling story is a central part of the experience of using that language. Especially if that language is a systems language. Rust's error handling still seems unnecessarily verbose to me. A specific error type is only necessary if the program can handle the error in question. Rust has acknowledged this but I still don't want every function call in my code to be prefixed with "try!" or suffixed with "?!" Rust error handling is also inefficient: in C++, if no error happens, then no code is run, whereas in Rust, even if no error happens a return code must be checked. I will sadly continue to happily use C++ until Rust improves its error-handling story.

oconnor663 10y ago
> Rust error handling is also inefficient: in C++, if no error happens, then no code is run, whereas in Rust, even if no error happens a return code must be checked. In this sense Rust's error handling is just like C (though harder to forget to check). Would you say C++ is more efficient than C in error handling?
- softc 10y ago
  Yes I would. In modern C++ we use exceptions and RAII for automatic cleanup.
  - mmstick 10y ago
    Exceptions have high cost so I don't see where you are coming from. Rust's RAII goes further along than C++'s. C++ is playing a game of catchup to steal the move semantics from Rust.
    - olejorgenb 10y ago
      According to http://stackoverflow.com/a/13836329/1517969 http://stackoverflow.com/a/13836329/1517969 modern c++ exceptions are free when no throw occurs.
      - 10y ago

agentgt 10y ago

Interestingly OCaml is 1996 (which is the language the original Rust compiler was written in). Maybe access to faster internet connections caused the rapid language explosion (I remember broadband cable starting to be available at that time)?

pjmlp 10y ago

Personally I don't have any use for Rust, other than occasionally dabbling on it, but I look forward to its adoption. Because Rust appears to be one of the ways for newer generations to rediscover how systems programming was done in safer systems programming languages before UNIX alongside C, enjoyed adoption across the industry. Also due to all the work on ownership management, that has already influenced future design decisions on C++, Swift, D, ParaSail and Pony. And eventually with time, even those of us that don't use it, might enjoy having a safer stack to work with.

ue_ 10y ago

Can someone tell me how this language is supposed to be any degree of 'safe' when things like this compile (without warning, on Nightly rustc) and "panic"? Rust is about as safe as C. fn main() { let a = 4; let v = [0,1,2,3]; println!("{}", v[a]); } result: rustc 1.15.0-nightly (71c06a56a 2016-12-18) thread 'main' panicked at 'index out of bounds: the len is 4 but the index is 4', <anon>:4 note: Run with `RUST_BACKTRACE=1` for a backtrace.

dbaupp 10y ago
Being safer isn't all or nothing. Even if a getting a guaranteed panic on array out of bounds was nearly as unsafe as the undefined behaviour of C in that case (it isn't, at all), Rust still mitigates many of C's other most dangerous problems.
steveklabnik 10y ago
A panic can not lead to memory unsafety, unlike the same code in C.
- snakeanus 10y ago
  > unlike the same code in C. What makes you think so? I am aware of multiple implementations that add bounds checking. There is nothing in the standard that forces it to be unsafe.
  - szemet 10y ago
    Does the standard force it to be safe? If not, then the parent comment is true: "the same code in C ... can lead to memory unsafety"
  - deleted 10y ago
    [deleted]
  - steveklabnik 10y ago
    I have never worked with one or come across it, only libraries that can add it through a different syntax. Do you have some references, or projects that require using it? I didn't think such a thing was standards-compliant but I'm also not an expert on the standard.

vvanders 10y ago

As someone who's been in the system programming space for a while and played with Rust for ~1.5 years here's my highlights. 1. I haven't written any multithreading code yet but I love the borrow-checker since it does a fantastic job of dealing with mutable state. I find I get better architected programs with single-ownership long before I start writing Rust and I love to see the compiler enforce it. 2. ADTs. Simply the best way to represent State + Data bar none. Combine with pattern matching and it's just sublime. 3. Iterators. Never seen a language do them so well with so little overhead. The focus on zero-cost abstractions really shines here. 4. Cross platform support. This is a huge one. Having dealt with MSCV/GCC/LLVM/custom compiler toolchains I can't stress to wonderful it is to have a consistent compiler that can build other targets on a different host. 5. Cargo, other people have covered it, enough said. 6. The community. Truly one of the better ones out there who not only want to help but also provides releases like clockwork with clear semantics on stability and APIs.

nialv7 10y ago
> 3. Iterators. Never seen a language do them so well with so little overhead. The focus on zero-cost abstractions really shines here. Try some D, maybe? :)
- vvanders 10y ago
  Haven't had a chance to play with D yet but a quick perusal shows quite a few things missing from their iterator lib(zip, enumerate, cycle, collect). I probably just need to spend some time with it at some point. That said the examples look much close to Rust than C++11(seriously did they think through how painful std::transform() is with all the begin/end pairs?). One thing that not a lot of people know is you can iterate over a Result<T,E> and collect::<Result<Vec<T>, E>>() which is a really elegant way to bail on a single error or get a collection of values.
  - nialv7 10y ago
    D does have zip, enumerate, cycle (https://dlang.org/phobos/std_range.html https://dlang.org/phobos/std_range.html). It doesn't have a universal collect like Rust, but you can create arrays from ranges using array(). And if the target container/collection type is an OutputRange, you can use the put()(https://dlang.org/phobos/std_range_primitives.html#.put https://dlang.org/phobos/std_range_primitives.html#.put) function to create collections from ranges.

pornel 10y ago

For me the best thing about Rust is that I can create beautiful APIs that are hard to misuse. With ownership rules I can enforce logic of how my API is supposed to be used, e.g. "you can call this method only once", "you can use that object only until you call destroy() on the parent" can be enforced at compile time. Same with levels of thread-safety of my code. Users of my libraries don't need to RTFM to use them correctly.

jondot 10y ago

Hi Steve, We've met at Rails conf, in Tel Aviv many years ago. You seemed nice, so I'm motivated to try to give you my 2c. I believe Rust can be more than safety but right now it isn't as you are imagining it. I've started off in the demoscene in the early 90's, and so I've had my share of assembly, C, and C++ as a kid. I've built demos, games, generative 3D art with 8-64kb executables, without access to Internet or any form of proper knowledge, and it's funny how scared I am of attempting this again today when I'm much older, and much, much more experienced. I think one of the scary factors are the time-to-value ratio: I'm used to several orders of magnitude more productivity, and have much less time. I think the most important take away from my background story that you can adopt is - make Rust playful. Fun is a a base element for curiosity, it what drives us where we're the most receptive - when we're kids - to learn, to experience, and to understand what will in be our toolbelt for the next dozen years. Make rust playful. Make a game framework. Make it build on a mobile device. Make it build on a Pi (without docker, and the entire diarrhea of toolchain you have to use). Make it build for the Arduino. Cross compile it to Javascript (for fun!). Often I try my hands at C and C++ again. When I do that, I'm not disappointed. I see a comforting place where I've spent my childhood at (and with C++ - some of my professional life). I'm happy with how C++ evolved and how CMake works. I'm not happy because productivity didn't change for the better that much. It still requires around the same amount of time to build things in C and C++ as it did years ago. Where I do see a change is with Go. It gives me the same comfort, with an insane productivity factor. It also had fun baked in from the start - it can run on mobile, it can run games, and it can compile to what ever I want without a fuss. I hope my thoughts will make a real change. I really do think this is the missing part with the Rust story.

kibwen 10y ago
Since you mentioned the demoscene, I think you may enjoy this fantastic 56kb demo written in Rust: https://www.reddit.com/r/rust/comments/597hhv/logicoma_elysian_1st_place_trsac_2016_pc_64kb/ https://www.reddit.com/r/rust/comments/597hhv/logicoma_elysi... :)
- jondot 10y ago
  Wow! fantastic!

EwanToo 10y ago

I haven't fully thought this out yet, but it strikes me that with an AWS SDK, Rust would be an ideal language for high performance Lambda functions. * No JVM/Interpreter memory overhead * No garbage collection (I know this is controversial) * Compiled binaries with low startup time * High performance (assuming you write it well..) * Aware of multi-core systems * Good networking capabilities Currently if you want really high performance on Lambda with a SDK for AWS services, you have to go Java and all that comes with it, or launch Go or C++ binaries via a nodejs process.

steveklabnik 10y ago
https://crates.io/crates/rusoto https://crates.io/crates/rusoto is one of the bigger AWS SDK crates. There's been some interest in Rust on Lambda, but I forget if there's a tutorial or something.
deleted 10y ago
[deleted]

frozenport 10y ago

C++17: 2016

fjrieiekd 10y ago

I love Rust and I've been following it for a while now, hoping to use it more in my line of work. However, I still find that support for Rust on Android and iOS is still lacking, compared to C and C++. These platforms are technically supported, but they aren't tier one and don't seem to be widely used. This doesn't matter that much for hobby programming, but for production work I'd be happier if there was a clear and easy path for adding Rust to the build system, and having the tools integrate into my chain, with great support for debugging and testing. I'm happy to deal with the extra work myself when I'm doing it for fun, but otherwise, compared to the first class support in Xcode or even the NDK, Rust is still far behind. For me to feel comfortable in taking the risk in choosing a non-vendor-sponsored language like Rust, I need to be confident that my tools will work and won't break on me, integrate poorly or fail in unexpected ways. If Rust was on par with C/C++ support, it would definitely be a very compelling solution.