33 ms·

Rust is mostly safety

• steveklabnik 10y ago
  I'll probably be writing a slightly longer response post to this later, but for now... EDIT: here it is: http://words.steveklabnik.com/fire-mario-not-fire-flowers http://words.steveklabnik.com/fire-mario-not-fire-flowers I think the core of it is this: > Safety in the systems space is Rust's raison d'être. Especially safe concurrency (or as Aaron put it, fearless concurrency). I do not know how else to put it. But you just did! That is, I think "fearless concurrency" is a better pitch for Rust than "memory safety." The former is "Hey, you know that thing that's really hard for you? Rust makes it easy." The latter is, as Dave[1] says, "eat your vegetables." I'm not advocating that Rust lose its focus on safety from an implementation perspective. What I am saying is that the abstract notation of "safety" isn't compelling to a lot of people. So, if we want to make the industry more safe by bringing Rust to them, we have to find a way to make Rust compelling to those people. 1: https://thefeedbackloop.xyz/safety-is-rusts-fireflower/ https://thefeedbackloop.xyz/safety-is-rusts-fireflower/
  • kaoD 10y ago
    As someone watching from the sidelines... maybe it's the cynic in me, but I think you're giving too much credit to the "but I don't have safety problems" folk. Judging by how defensive they get, it's just a post-hoc rationalization to why they won't invest time learning it. That's fine but, IMHO, not a marketing problem and just good old resistance to change. There's an endless stream of excuses to choose from, no matter how you pitch Rust to them. I'm all up for a marketing shift though. I agree Rust is much more than safety and I think graydon2 missed your point there. The fireflower simile is excellent. Plus I've seen lots of people confused about Rust, including here on HN. Those are the people to whom marketing failed and should be targeted better.
    • braveo 10y ago
      Or we were severely disappointed when we realized Rust doesn't really give you that safety.
      • jibalt 10y ago
        No, that's not it.
  • bluejekyll 10y ago
    > I think "fearless concurrency" is a better pitch... I would go a step further, "fearless programming". Though I would hesitate on 'easy'. Rust gives you fearlessness in all the things, but it does mean learning new style and discovering new solutions to old problems. To fully understand 'Send' vs. 'Sync', for example, means really groking the Rust type system. Once you get the type system, then fully utilizing it with the expressive generics becomes unlocked, and then at that point you've transcended from Rust dabbler to fully fearless Rust user. Once this world of development is unlocked to you it is mind-blowing, but it is a journey to get there, and not everyone will have the heart to make it. It comes in stages, is wonderfully rewarding, will make you a better programmer in you other favorite languages, but I think we should be careful with statements like 'Rust makes it easy'. It does make hard things easy, but only after you've fully embraced Rust. This feels more accurate: "Hey, you know that thing that's really hard for you? Rust makes it fun."
    • nullc 10y ago
      Making software free of data races and memory safe (assuming you don't use any unsafe code...) is still a long way from being free of serious defects. Rust is cool enough that it doesn't need to be promoted with excess hype.
  • GolDDranks 10y ago
    I would argue that if the Rust project would have just one mission statement, it wouldn't be "create a safe systems programming language". It would be "move towards a world where safe systems programming is the norm". What's the difference? Both of the statements have the premise that Rust is – and ought to be – a safe systems programming language. However, the latter captures not only the REAL goal, but also the nuances and tensions: while safety is indispensable, we must do something else too, for the programming society to accept the safe tools we are trying to promote. That means ergonomics, that means performance, that means ease of use, that means wide availability – and that might also mean advocation of visions of a better world, which is what this blog post of Graydon's does.
    • steveklabnik 10y ago
      I really, really like this. Thank you. Well put.
    • btown 10y ago
      It's important to get the nuance of this statement right. Consider, for instance, the PSF's mission statement: > The mission of the Python Software Foundation is to promote, protect, and advance the Python programming language, and to support and facilitate the growth of a diverse and international community of Python programmers. "Facilitate the growth" does not imply that dominance of a certain practice (whether that is use of Python, or adoption of its core principals) is a goal. So you have an incentive for the PSF to say "our international community is growing at a sufficient rate" and focus instead on "advancing the language," which may or may not be aligned with adoption. In such a framework, it becomes easy to justify backwards-incompatible major releases that, regardless of whether their opinion is justified, many users consider to be user-hostile. Framing Rust towards a larger mission that implies user adoption of core principals as a fundamental goal seems much cleaner in that regard, and could conceivably avoid similar pitfalls.
  • nickpsecurity 10y ago
    I think the problem is that Graydon is better at technology than marketing. Getting language adoption is largely a marketing problem combining what those in control of the language push and how those in the community pull. Rust's success comes from doing that dynamic correctly. If it was just safe and not C/C++, it would be another Ada, Modula-2, D, etc. It's important to market all the key benefits of it in a way that lets potential users know it will help them solve problems faster and with less trouble down the road.
• amelius 10y ago
  Does Rust have template metaprogramming? And does it look more clean and organized than boost's C++ implementation?
  • steveklabnik 10y ago
    Rust has three main forms of metaprogramming: generics, which are kind of like templates, but more like concepts (in C++ terms), macros, and compiler plugins.
    • baq 10y ago
      worth noting that Rust generics aren't (by design!) as powerful as C++ templates. macros and compiler plugins OTOH...
    • cesarb 10y ago
      I don't think compiler plugins count yet, since they're currently not stable.
      • steveklabnik 10y ago
        That's an important point, yes, thank you. Their RFC was accepted two weeks ago. We'll see how long they take to make it into stable.
    • nurettin 10y ago
      Wait, Rust has macros that expand to code and mess up debugging, confuse tooling and everything else just like C++? Isn't that exactly what the language should have avoided?
      • carry_bit 10y ago
        Macros in Rust are very different than macros in C++. They're similar to syntax-rules in Scheme: https://doc.rust-lang.org/book/macros.html https://doc.rust-lang.org/book/macros.html
      • 10y ago
• jMyles 10y ago
  > countless lives lost I have no doubt that people have had their lives ruined, or even died, as the result of flaws in system programming, but is anyone actually tracking this? Is it "countless?"
  • ragebol 10y ago
    Well, if no one is tracking it, there is no count and that would thus be countless. But in all seriousness, I am curious about this as well.
    • moxious 10y ago
      It's not "countless" it's "uncountable" because we couldn't agree on what a software caused death was. In my CS program we had an ethics class that included stories of bad X-ray machine software that overdosed people. Bad, bad bad. I don't think many people died as a direct result, but 10 years later there was probably a spiked cancer incidence. Did software kill people? Well yeah....kinda. In airplane systems, there have been a number of cases where bad alerting / warning systems basically either misled the pilot or lulled them into a false sense of security prior to events that caused crashes. Did software kill people? Uhm, yes, I think, sort of, but not directly? It's only when we get fully sentient AI that arms itself and decides to clean up the human pestilence that we'll be able to draw a straight line there. :)
      • hyperpape 10y ago
        Three deaths from the Therac-25: https://en.wikipedia.org/wiki/Therac-25 https://en.wikipedia.org/wiki/Therac-25.
      • 1wd 10y ago
        Errors in the software of the radiation therapy machine Therac-25 directly lead to the death or serious injury of six patients. Three patients died within weeks or months. http://radonc.wdfiles.com/local--files/radiation-accident-therac25/Therac_UGuelph_TGall.pdf http://radonc.wdfiles.com/local--files/radiation-accident-th... Errors in the software of a MIM-104 Patriot resulted in failure to locate and intercept an incoming missile and the death of 28 soldiers. http://www.gao.gov/products/IMTEC-92-26 http://www.gao.gov/products/IMTEC-92-26 Errors in the software of a Chinook helicopter may have lead to a crash that killed 29 people. http://www.publications.parliament.uk/pa/ld200102/ldselect/ldchin/25/2504.htm http://www.publications.parliament.uk/pa/ld200102/ldselect/l... Errors in the software of Toyota's throttle control system may have lead to the death of 89 people. https://betterembsw.blogspot.ch/2014/09/a-case-study-of-toyota-unintended.html?m=1 https://betterembsw.blogspot.ch/2014/09/a-case-study-of-toyo... More: http://www.baselinemag.com/c/a/Projects-Processes/Eight-Fatal-SoftwareRelated-Accidents http://www.baselinemag.com/c/a/Projects-Processes/Eight-Fata...
• koja86 10y ago
  In case you missed that there's a big disillusioned C++ crowd out there. Just hear the pain: https://news.ycombinator.com/item?id=13276351 https://news.ycombinator.com/item?id=13276351 And some of them are watching you with great interest.
  • Ar-Curunir 10y ago
    And there's a tired security crowd watching Rust with great hope; C++ and C have created innumerable security holes at the expense of "convenience". Cryptographic libraries, codec libraries, image conversion libraries, OS kernels, sandboxes, virtual machines, browsers, (the list is endless) have all suffered glaring security holes from the lack of memory hygiene afforded by C and C++. Any time your code takes in untrusted input, it should not be written in an unsafe language.
    • moxious 10y ago
      > Any time your code takes in untrusted input, it should not be written in an unsafe language. So basically just about all programs, all of the time? https://www.owasp.org/index.php/Don't_trust_user_input https://www.owasp.org/index.php/Don't_trust_user_input
      • Ar-Curunir 10y ago
        I agree, but people seem to feel that their code should somehow be exempt from such advice, and so sacrifice safety for performance. This leads to today's sorry state of affairs.
        • llogiq 10y ago
          The problem is that safety doesn't sell. If you're getting a new IoT heat lamp you look at the price and not the firmware's code. To your surprise, the first hacker coming along toasts your cat.
    • gmjosack 10y ago
      There's also the tired sysadmin crowd who are tired of rebooting thousands of hosts for kernel, shell, libc, etc. patches. And tired of patching web, mail, dns, etc servers. I'm sure there are really smart C and/or C++ developers out there that never make mistakes but I've spent a large part of my career patching/upgrading really smart peoples code. For me, safety is the killer feature in Rust. It's also exciting because it brings systems level programming to a new generation of programmers without all the risk.
• kebolio 10y ago
  > [Go] failed to provide a safe concurrency model. What did he mean by this?
  • nothrabannosir 10y ago
    Go doesn't protect you against race conditions, it merely offers some concurrency tools. There is nothing to declare ownership of objects in memory. So the compiler doesn't (can't) complain if you share memory and access it simultaneously. At best, there are runtime checks. Rust does offer compiler protection against that. Edit: "merely", relatively to Rust :) on an absolute scale, still way better than C for concurrency.
    • VexorLoophole 10y ago
      As a total beginner (learning programming by myself since 2 or 3 years), i am always asking myself, how often "little" things like race conditions break something in production. Sure thing, some applications need to be safe-super-safe. But is it worth to switch over from go to rust as a beginner, since go is the unsafer language? I know, that there is no ultimate language. But i always asked myself i am missing a point, since i never really had problems like that occur. I also wrote something little in clojure (wanted to write something in lisp, and clojure presented itself somehow modern). But many people told me about how bad clojure is, because it is not type-safe. So i switched to go. And i have to say, it is really nice, to be forced to use the right types as input. But will i have the same experience when i switch over to rust and think to myself: "Whoa yes, i never though about that aspect, but it really helps me as a beginner who tends to write slobby programms!"?
      • Cyph0n 10y ago
        It becomes a problem when you're building applications with complex interactions, and is even worse with large codebases that are tough to debug and reason about.
      • camus2 10y ago
        > i am always asking myself, how often "little" things like race conditions break something in production It can basically corrupt the whole program. I bet half go apps out there have data race. People who boast about Go's simplicity can't even see the elephant in the room. A simplistic type system doesn't fix unsafe concurrency. You'd think that safe concurrency would be an important design goal for a highly concurrent language, well apparently it isn't.
• Ar-Curunir 10y ago
  I think it's a bit funny that in an industry that (supposedly) prides itself on "meritocracy", there are many people that refuse to use (or learn) performant memory-safe languages, when memory-safe code is always better than memory-unsafe code (in terms of resource usage, reduction of bugs, etc, etc.).
• raverbashing 10y ago
  Rust is great, however the safety aspect gets in the way sometimes The right granularity for error handling is important, as well as making it easy to handle (abort? providing a default value? doing something else?) It's not that it is not important, but code usability is important as well, lest it goes on the way of C++ hell (though I don't think it can get that bad, there are some warts - like "methods" and traits)
  • tomjakubowski 10y ago
    > The right granularity for error handling is important, as well as making it easy to handle (abort? providing a default value? doing something else?) Option<T> and Result<T,E> achieve just about the best level of granularity I could imagine for error handling. Suppose you're trying to fetch a value from a map (use case for Option<T>), or read some value over some fallible I/O stream (use case for Result<T,E>). Want to abort if the value is missing or an error occurred? Just call unwrap() and ready yourself for (completely safe!) crash reports. unwrap() is just a way to dynamically assert certain invariants. Want a default value in those cases? Just call or() or or_else() on the Option<T> or Result<T,E> value you have. Want to do something else? Use Rust's pattern matching features and branch depending on whether the value was obtained, on conditionals relating to the value (or error), and more!
    • raverbashing 10y ago
      My criticism might be due to a bit of impedance mismatch, that's for sure (Or maybe I'm just missing exceptions - because, as an example: I want to read a file and what I care about is getting a fd, anything before that "doesn't matter" and I don't want to care about every step) On the subject, this page is good for those curious about it https://doc.rust-lang.org/book/error-handling.html https://doc.rust-lang.org/book/error-handling.html
      • moosingin3space 10y ago
        That sounds like a good use case for the ? operator in Rust 1.13+.
• geodel 10y ago
  The original Rust author make great points about safety. I think this new thrust on marketing emerges from Rust Roadmap 2017 which puts Rust usage in industry as one of the major goal. Currently Rust is about Go's age but nowhere close in usage. As the roadmap says "Production use measures our design success; it's the ultimate reality check." I agree with that.
  • robin_reala 10y ago
    It might be Go’s age overall from initial inception, but a typical point at which people start paying attention is the 1.0 release. In Go this was March 2012, for Rust it May 2015, over three years later.
    • SomeStupidPoint 10y ago
      To be honest, Rust took so long to stop making breaking changes and stabilize, I sort of tuned out on it -- it was never at a point it made sense to start using. Has Rust actually settled down on some stability?
      • steveklabnik 10y ago
        A little over 18 months ago, 1.0 was released. We've had very strong compatibility guarantees since then.
        • nordsieck 10y ago
          While that is true, in Go, almost no libraries are written to use non-stable features. This is not the case in Rust.
          • steveklabnik 10y ago
            Right. Go and Rust have completely different development models, so that wouldn't make any sense. To recap, in Rust, to make additions to the language: 1. Small additions mean make a PR. 2. Big additions mean make an RFC, then a PR if accepted. 3. These PRs go behind a feature flag that lets us track the feature, and only allows it on nightly. 4. People who desire the new feature try it out. (This is what you refer to.) 5. If any issues are found, they're fixed, or, in the worst case, the feature is removed. 6. The feature is made available to stable users, the feature flag is removed, and backwards incompatible changes can no longer happen. What would be un-healthy is if everyone had to rely on nightly for everything. At the moment, most people use stable Rust. And of the people that use nightly, the largest single feature will be stable as of the next stable release for Rust. But some people are always going to be using nightly features, and that's a good thing: it means that by the time it hits stable, it's already undergone some degree of vetting.
• pron 10y ago
  I completely agree. This is what I wrote on Reddit in response to Klabnik's post: Rust can make such an important contribution to such an important slice of the software world, that I really fear that trying to make a better pitch and get as many adopters as quickly as possible might create a community that would pull Rust in directions that would make it less useful, not more. Current C/C++ developers really do need more safety. They don't need a more pleasant language. Non C/C++ developers don't really need a language with no GC. Now, by "don't need" I absolutely don't mean "won't benefit from". But one of the things we can learn from James Gosling about language design is, don't focus on features that are useful; don't even focus on features that are very useful; focus on features that are absolutely indispensable... and compromise on all the rest. The people behind Java were mostly Lispers, but they came to the conclusion that what the industry really, really needs, is garbage collection and good dynamic linking and that those have a bigger impact than clever language design, so they put all that in the VM and wrapped it in a language that they made as familiar and as non-threatening as possible, which even meant adopting features from C/C++ that they knew were wrong (fall-through in switch/case, automatic numeric widening), all so they could lower the language adoption cost, and sell people the really revolutionary stuff in the VM. Gosling said, "we sold them a wolf in sheep's clothing". I would recommend watching the first ~25 minutes of this talk[1] to anyone who's interested in marketing and maintaining a programming language. If Rust would only win over 10% of C/C++ programmers who today understand the need for safety, say, in the next 5-10 years, that would make it the highest-impact, most important language of the past two decades. In that area of the software world change is very, very slow, and you must be patient, but that's where Rust could make the biggest difference because that's where its safety is indispensable. A few articles on Rust in some ancient trade journals that you thought nobody reads because those who do aren't on Twitter and aren't in your circle may do you more good than a vigorous discussion on Reddit or the front page of HN. Even the organizational structure in organizations that need Rust looks very different from the one in companies that are better represented on Reddit/HN, so you may need to market to a different kind of people. So please, be patient and focus your marketing on those that really need Rust, not on those outside that group you think you can win over most quickly because they move at a faster pace. [1]: https://www.youtube.com/watch?v=Dq2WQuWVrgQ https://www.youtube.com/watch?v=Dq2WQuWVrgQ
  • 10y ago
• yjftsjthsd-h 10y ago
  I was surprised to see Ada in the list of unsafe languages, since it always was sold to me as being designed for safety. A bit of searching leads me to believe that Ada is better about memory even though it mostly uses types for safety, and better enforcement of bounds on array access should solve overflow issues regardless. Am I missing something?
  • staticassertion 10y ago
    I believe you have three choices with Ada: 1) No manual memory management, everything is static and you have memory safety 2) Garbage collection, you have memory safety 3) Manual memory management, you lose memory safety Rust provides memory safety in the case of manual memory management.
    • pjmlp 10y ago
      GC was dropped from the Ada2005 standard, because no Ada83 compiler ever implemented it. Ada provides more ways to automate memory management, though. Controlled types are Ada's version of RAII, used for arenas and smart pointers. Also in Ada you can dynamically allocate everywhere, so a common pattern is to use a subroutine parameter to do stack allocation. If it fails, by throwing an exception, recall the subroutine with a smaller size.
  • pjmlp 10y ago
    Ada still requires manual heap management, although it can be mostly automated. So you might occasionally see the unsafe package being used to deallocate memory, even though there are better ways to do it, e.g. controlled types. The other point, is that Rust prevents data races via the type system, while you can deadlock Ada tasks if the monitors aren't properly implemented.
    • jnbiche 10y ago
      > while you can deadlock Ada tasks if the monitors aren't properly implemented. It's not clear to me if you're suggesting otherwise, but you can definitely deadlock Rust as well (although it's true that Rust statically prevents data races).
• Annatar 10y ago
  Wow, I have to admit I have never seen anything pushed so aggressively here on Hacker News as Rust. Rust: "everybody who writes in anything but our invention has security holes, but we don't, because we know what we're doing! And although we broke users' programs in the past, we don't do that any more! We're all grown up now! Trust us!"
  • izym 10y ago
    When have they broken stuff post 1.0?
    • Annatar 10y ago
      Even once is one time too many.
      • steveklabnik 10y ago
        No programming language, even C or C++ or Java, lives up to that standard.
        • Annatar 10y ago
          ANSI Common LISP lives up to that standard. POSIX AWK lives up to that standard. C's versioning lives up to that standard. ksh93 lives up to that standard. All of those are backward compatible, and can churn through older versions of their own syntax with no problem. But that's not the point, and you know it: the point is you guys were hacking like crazy, without any engineering. That's why the syntax of Rust is insane, and why the language is incredibly complex, and expressions ugly, even for the simplest of things. And while we're at it: is there a formal specification for Rust, that would say, allow me to implement my own, standards-compliant compiler?
          • steveklabnik 10y ago
            > C's versioning lives up to that standard. C has introduced breaking changes into newer versions of the standard. I don't know as much about ANSI Common Lisp or AWK. By "formal" spec, that depends; do you mean "a spec", or "a spec proven with formal methods"? The latter is undergoing work at various universities. The former doesn't exist yet, but is a goal of next year, and we've already taken some steps towards having it exist. I'm not going to bother with the rest.
• bassislife 10y ago
  The issue with safety is that nothing is really safe. Once you have some level of safety in your programming language, you realize that there are still a lot of other sources of hazard (hardware errors, programming logic errors etc.) So I guess, it would be better to say that Rust is about decreasing unsafetyness or whatever the correct word for that is. edit: since I see posts about Go, this is evidently another approach toward decreasing unsafetyness by providing fewer and easier to understand primitives so that the programming logic is harder to write wrong. It might come at a moderate cost for some applications.
  • zzzcpan 10y ago
    True, they messed up in their PR a bit with bold claims about safety. It definitely would be better to be careful with the words they use. Like this "safe concurrency" claim sounds really fearless to me, even though I know they mean some guarantees towards thread safety and all that, not actual safe concurrency.
    • bassislife 10y ago
      Yes, for instance, it's easy to create concurrent programs that are semantically wrong (in other words inadequate for use) albeit correct in terms of "types" because the coder made an erroneous assumption about determinism somewhere. The type systems that we see nowadays do not help with that.
    • oconnor663 10y ago
      The docs are very clear about what safety means, but agreed that the subtleties can get lost in advertising. https://doc.rust-lang.org/book/unsafe.html#what-does-safe-mean https://doc.rust-lang.org/book/unsafe.html#what-does-safe-me...
  • stevedonovan 10y ago
    Exactly. There is always the danger of self-hypnosis, by repeating 'memory safety means safety, full stop' too often.
  • rkrzr 10y ago
• willtim 10y ago
  It's a shame there is no mention of ATS, which also attempts safe systems programming usings an advanced type system.
• pjmlp 10y ago
  > Modula-3, Eiffel, Sather Nice to see these languages on Rust's team radar, specially Sather. Just shows how you guys have researched prior work, congratulations.
  • agentgt 10y ago
    It is funny he doesn't mention OCaml (because of his work with it). Yes OCaml has a GC but from what I recall it has a rather low overhead GC (in terms of latency. I need to find source but I remember it being impressive compared to others). I believe there was some attempts to incorporate some real time libraries but it was a long time ago. Depending on what you define as system programming OCaml also has the whole bare metal Mirage OS [1] thing as well. And of course OCaml is a pretty darn safe language (albeit its threading/concurrency libraries are fragmented so the safety is more type safety than concurrency). [1]: https://mirage.io/ https://mirage.io/
    • pjmlp 10y ago
      Yeah, Caml Light (OCaml's predecessor) was my introduction to ML family of languages. All the languages on my snippet also have GC, but are less known than OCaml, maybe hence why he omitted it.
  • steveklabnik 10y ago
    To be clear, Graydon doesn't work on Rust anymore, and hasn't in years. His knowledge of the space is absolutely impressive, though. :)
    • nickpsecurity 10y ago
      Only inaccuracy I find is in his claim on safe concurrency in other languages. It existed in Concurrent Pascal (used in Solo OS), Ravenscar Ada (widely deployed), and Eiffel SCOOP (widely deployed). Rust isn't the first doing this. It's just apparently the best at it in system space. Ada camp is making a comeback, though, with ParaSail that looks interesting: http://www.embedded.com/design/other/4375616/ParaSail--Less-is-more-with-multicore?page=0 http://www.embedded.com/design/other/4375616/ParaSail--Less-...
• annastil 10y ago
  The services of a professional are at your disposal, you can send a message to pauleta.steelbreaker on gmail or text 19283233115 on more info on how to hire real hackers with discretion and top notch servicing.
• agentgt 10y ago
  I'm a lowly ancient Java programmer and I think Rust is far far more than safety. In my opinion Rust is about doing things right. It may have been about safety at first but I think it is more than that given the work of the community. Yes I know there is the right tool for the right job and is impossible to fill all use cases but IMO Rust is striving for iPhone like usage. I have never seen a more disciplined and balanced community approach to creating PL. Everything seems to be carefully thought out and iterated on. There is a lot to be said to this (although ironically I suppose one could call that safe)! PL is more than the language. It is works, community and mindshare. If Rust was so concerned with safety I don't think much work would be done on making it so consumable for all with continuous improvements of compiler error messages, easier syntax and improved documentation. Rust is one of the first languages in a long time that makes you think different. If it is just safety... safety is one overloaded word.
  • svckr 10y ago
    I absolutely agree. If you look at Rust from a systems programmer perspective and compare it with the systems languages OP lists then, yes, safety is THE most radical feature. But Rust can compete on so many more levels. Web services, user facing applications for example. Languages competing in that space usually bring memory safety, so it's kind of a non-issue. Safety enables Rust to be a viable choice for these tasks, but it needs more than that to be on-par with the other languages. And Rust's got plenty of things going for it, so there's nothing wrong with stopping to play the safety card (since that is expected anyways) and painting Rust as a language that is actually fun to work with.
    • jfaucett 10y ago
      IMO the biggest plus for rust is actually cargo. Building, versioning, and sharing modular code is essentially copy/paste in C/C++, and compared to that cargo is lightyears ahead. I actually wish rust would accept its systems niche even more and move the stdlib to crates and make nostd the default mode. Personally, I see no reason to market rust for webapps or gui stuff, it cant/wont compete with Rails/QT for years to come if ever there.
• mtgx 10y ago
  Even if Rust adds increasingly more "unsafe" features in order to appeal to new developer groups, I agree that it should remain a "100% safe by default language", and they should continuously try to improve the performance of the safe code, rather than get lazy and say developers can just use the unsafe syntax if they want 3x the performance. This would only lead more and more developers to increase the usage of unsafe code. It would be even worse if Rust would allow unsafe code by default for any future feature.
  • steveklabnik 10y ago
    There is no serious proposal to make anything unsafe by default, and I wasn't proposing we do such a thing. The change I'm talking about is how we talk about Rust, not making changes to the language at all.
• krakensden 10y ago
  What about stack overflows? I heard that rust no longer protects against those for benchmark reasons.
  • steveklabnik 10y ago
    That's incorrect. On some platforms, stack probes are not yet implemented because the patch to LLVM hasn't been merged, and we need it to do this properly. Someone is working on getting that through right now.
    • brson 10y ago
      And stack probes are one corner case of stack overflow. Rust protects against stack overflow in most cases, on all platforms, in every case on Windows, and is intended and designed to protect against all stack overflow, but it has a bug due to missing features in LLVM that nobody has taken the time to fix.
    • krakensden 10y ago
      What is "some platforms"? There is plenty of stuff in github that seems to indicate "only windows".
  • zanny 10y ago
    There is a reason Rust has debug and release builds as well to what other commenters have said. In the debug builds there are safeguards against almost everything at performance cost, the way you are supposed to use it is to test your debug builds thoroughly and then you can trust the release builds to be safe because your code doesn't change, the compiler just doesn't insert as many guards.
    • steveklabnik 10y ago
      In general, this is less true than in other languages though; for example, assert! is still in release builds in Rust. If you want that semantic, you need debug_assert!
• rcthompson 10y ago
  I think Rust is mostly about safety in the same way that skydiving is mostly about safety. Having safety features that you know you can rely on allows you to take risks that you normally wouldn't in order to accomplish some really awesome things. (I guess in this analogy C is a parachute that you have to open manually, while Rust is a parachute that always opens at exactly the right altitude, but isn't any heavier than a normal parachute.)
  • dom0 10y ago
    A lot of C libraries and applications are more like a parachute that was folded by someone who saw a two minute video about parachute folding a couple years ago.
  • nercury 10y ago
    Rust safety is ultimately a productivity boost. For example, if I have a big string, I may create a hashmap where both keys and values are references to some portions to that original string. Then, I may pass this hashmap to another function that will transform this hashmap into structs that contain reused portions of those string references. Rust compiler will make sure that the original string is not destroyed or moved in any way in memory while this is happening. While it is certainly possible to do this in C and C++, the development cost there is way higher. In C++, one would be sensible to stick to a slower version that copies and allocates data, unless he/she is really sure that the need for performance justifies the code complication. Meanwhile, juggling the references this way in Rust is common and almost sloppy: the hashmap contains references to strings because it was probably created from iterator that iterated over references. The developer might not even need to notice it unless the string reference in result might be kept around longer than original. The compiler will tell about the type mismatch, and the developer will then create a new string from the reference, and then he/she will move on. There is a similar story when such code needs to be refactored. The word "sloppy" still works here, but in a good way: offloading "being very, very careful" stuff to compiler is deliciously fun.
    • Manishearth 10y ago
      I wrote about this concept a bit in http://manishearth.github.io/blog/2015/05/03/where-rust-really-shines/ http://manishearth.github.io/blog/2015/05/03/where-rust-real..., with an example of a situation where in Rust I was able to make things work but in C++ I'd be totally terrified and use a shared_ptr or something. I like to say that Rust lets you toe the line perfectly, and dance near it as much as you want. C++ does not, since you're afraid you may accidentally cross it.
• Thaxll 10y ago
  The daily post about Rust and Go is getting tiresome... every single day we've got one.
  • AsyncAwait 10y ago
    I read them all, you don't have to - just scroll by. I for example don't like the 'daily' snake oil salesman type of posts that pop up here, so I just skip them - easy.
  • Annatar 10y ago
    Yep, it's getting reeeaaalllyyy tiresome, and if people actually start programming en masse in Rust, you might soon end up having to maintain and debug programs written in that insane language. And you might even get to be really good at it. No sooner than you master it, someone else is going to come up with something new and shiny, and everybody will just move on to that, leaving you with holding the bag. But of course, that never happens in the computer industry. People never go for new and shiny. That's just... hypothetical.
• agumonkey 10y ago
  I think that safety is often doing small things clearly. When you read about thread safe computing, you end up with many rules FP make impossible. So even it's mostly safety, it encompasses a larger area in disguise.
• alkonaut 10y ago
  Its the safe and performant that attracts me. If you look at Rust from C then the point is safety, but if you look at it from the other direction, e.g from F# then what attracts you is that you will get the same safety guarantees (and perhaps a few more) but without the GC and heap overhead.
  • wyager 10y ago
    > e.g from F# then what attracts you is that you will get the same safety guarantees (and perhaps a few more) As a big rust fan, I wouldn't go that far. You can offload a lot more work to the type system in a language like F# or Haskell. Rust is very safe from e.g. a memory perspective (excepting unsafe operations), but there are additional levels of assurance you can get by aggressively forcing the type system to catch logic errors for you that you can't really do in Rust. As for performance, I agree, although a more accurate description would be that it's much easier to get C-level performance with Rust code while you have to put in some more effort to get it in any high-level functional language.
  • MichaelGG 10y ago
    Bingo. I've written high perf F# for a DB indexing and searching. The entire time I was wishing for allocation-free inlined closures and stack allocation. And for a few places, I'd really like an easy way to do asm or get really top notch codegen (integer decoding). Rust seems a lot like a fast ML. Not quite as concise as I'd like but worth it for the perf without being ugly mentally. And the perf will surpass C in some situations due to abstraction. One popular open source platform spends 30% CPU time on malloc and strcpy because tracking ownership was so difficult and it wasn't obvious it'd be a hotspot. In Rust that would be a non issue from beginning.
    • jules 10y ago
      You may be interested in MLton, which is an ML compiler that achieves high levels of optimisation by aggressively specialising your code: generic functions get specialised to the type and higher order functions get inlined to eliminate closure allocation.
• w8rbt 10y ago
  How is Rust better than and different from D? https://dlang.org/ Does anyone concerned about security use D?
  • computerphage 10y ago
    There are a lot of reasons. There's a terrific in-depth discussion of D on the Rust subreddit from a few weeks ago. https://www.reddit.com/r/rust/comments/5h0s2n/what_made_rust_more_popular_than_d/ https://www.reddit.com/r/rust/comments/5h0s2n/what_made_rust...
• childintime 10y ago
  I think Rust is not about safety, but about reusability. Do you like to take on a dependency on someone's code when it is in C? The answer is: roll your own code. Rust means the end of that. Rust means software that can be written once and used "forever". Thus it enables true open source. In comparison C/C++ pay a mere lip-service, by also giving you, along with the code, lots of reasons to worry. This is the real innovation behind Rust.
  • oconnor663 10y ago
    To be fair to C, I think C's answer here is dynamically linked shared libraries. They have lots of problems, but still they're very widely used. Even Rust programs dynamically link libc by default.
• djsumdog 10y ago
  This is a little off topic, but when I looked at his post I thought, "Wait .. is that LiveJournel?" .. and yes it is apparently. Or at least a fork of it called DreamWidth. Interesting to see forks of older OSS Perl web apps still in use today.
  • xb95 10y ago
    Caveat lector: I'm one of the two founders of Dreamwidth. Yes! Dreamwidth is a fork of the old LiveJournal code that is still being developed by a small team of folks who would rather see a small site run in an open, transparent fashion than be beholden to large corporate interests and the whims of monetization. We're a very happy little family and it's always exciting to see Dreamwidth links end up on HN. :)
• ocschwar 10y ago
  Rust is about letting the compiler slap you for your mistakes in the privacy of your own Xterm, instead of letting Jenkins do it 10 minutes later, in front of all your co-workers.
  • geodel 10y ago
    Maybe it will change in future. Currently slaps seems so hard that developers are still smarting and not producing code for production
    • steveklabnik 10y ago
      Rust is being used in a number of places in production for a wide variety of things: https://www.rust-lang.org/en-US/friends.html https://www.rust-lang.org/en-US/friends.html
      • geodel 10y ago
        I know and I would also try Rust if I can make some small but useful things at work. But I mostly deal with various combinations of XML, SOAP, HTTP, LDAP etc. Rust does not have anything over Java, which I use currently, in my usecases.
        • ocschwar 10y ago
          I have to deal with a pre-REST, pre-SOAP XML API, which I would love, love, to be able to handle in Rust. But until Serde-XML is able to deserialize more of that stuff and preferably handle XSDs, I'm stuck too.
          • yawaramin 10y ago
            Maybe you could call out to a C XML library in the interim?
        • nnethercote 10y ago
          It's perfectly reasonable to say "Rust isn't appropriate for my use case". Your comment higher up was more along the lines of "Rust isn't appropriate for anyone" which is far less reasonable.
• progman 10y ago
  The author states: "A few valiant attempts at bringing GC into systems programming -- Modula-3, Eiffel, Sather, D, Go -- have typically cut themselves off from too many tasks due to tracing GC overhead and runtime-system incompatibility, and still failed to provide a safe concurrency model." Nim follows a different approach. Details: http://nim-lang.org/docs/manual.html#threads http://nim-lang.org/docs/manual.html#threads Benchmark (with Rust): https://github.com/costajob/app-servers https://github.com/costajob/app-servers
• zpallin 10y ago
  I agree with the premise of the article. However, I feel that Steve Klabnik is trying to dispel myths about Rust not being anything "but" safety, to shape how other Rust developers talk about Rust, not denying that Rust's central purpose is around being a safe language. This is because there is a lot of miscommunication about Rust. A lot of people who aren't immediately sold on the language walk away thinking it's slow (it's not), it's complicated (not really), and not production ready (it actually is). And that's because Rust developers don't know how to talk about Rust. I am guilty, for one. Since Steve is such a huge part of RustLang development, it's his duty to direct the conscious effort to promote the language. No reason to get into a debate over click-baity titles. :)
• paulddraper 10y ago
  If you're a C++ programmer, Rust is mostly about memory safety. If you're a Java programmer, Rust is mostly about tighter resource usage. If you're a Python programmer, Rust is mostly about type safety and speed.
  • llogiq 10y ago
    I'm a polyglot programmer and for me Rust is mostly about the awesome abstractions and the great community.
    • paulddraper 10y ago
      > If you're a Javascript programmer, Rust is mostly about the awesome abstractions and the great community. ;)
  • Too 10y ago
    If you are a c++ programmer, rust is also a lot about developer ergonomics. Syntax is nicer, build system is built in, less UB to think about, package management comes built in, and finally getting rid of those damn header files is such a relief.
• StevePerkins 10y ago
  > "Safety in the systems space is Rust's raison d'être." I think this quote points to the REAL underlying issue here. Rust is a language primarily built for systems programming. It has many strengths to celebrate, and brings curated best practices as well as its own novel features to systems programming. However, most programmers in 2016 aren't "systems programmers" anymore. At the very least, most programmers who actively talk-up new technologies on web forums are not systems programmers. The majority (or at least the majority of the vocal and socially engaged) are web developers, mobile developers, CRUD apps and microservices, etc. As interesting as Rust may be in the systems space, it doesn't bring much compelling new hype to the table for web stuff. You have yet-another-concurrency-approach? That's great, but most web developers rely on an app server or low-level library for that, and seldom have to think about concurrency up at the level of their own code. You have an approach for memory safety without a garbage collector? That's great, but most web developers have never even had to think much about garbage collection. Java, Go, etc... the garbage collection performance of all these languages is on a level that makes this a moot point 99.999% of the time. You have a seamless FFI for integrating with C code? That's great, but after 20 years of web development I can count on one hand the number of times I've seen a project do this. And those examples were Perl-based CGI apps way back in the day. Rust people seem almost dumbfounded that everyone hasn't jumped all over their language yet. And from a systems programmer perspective, memory safety without garbage collection does sound amazing. But you guys really need to understand that Hacker News and Reddit hype is driven by web developers, and that community isn't even sure whether or not type safety is a worthwhile feature! So really, it's amazing that you've managed to draw as much hype as you have. It's not about the mainstream popularity of your language, it's about the mainstream popularity of your field.
  • echelon 10y ago
    I've written web services in Rust, and I'm quite happy with it. Iron is a pleasure to use, and the stuff I write is incredibly performant. There's also something amazing about compiling a project to a single binary and deploying. Rust is only about a year old. Once the library support grows, it's going to be a giant in just about every space I can think of.
  • lobster_johnson 10y ago
• orblivion 10y ago
  I haven't used Rust, but generally speaking wouldn't you say that safety in some sense includes the other nice features? For instance, if it were safe but not fast (like, say, a GC language) it wouldn't be useful. So it has to be safe and fast (which it sounds to me like it is). Okay, so what if it were safe, fast, but a real hassle to use? Well that's not very useful either. So it has to be safe, fast, and usable. Just like Moxie's approach to security: focus on usability, so people actually use the damn thing. And it sounds like all the other nice features make Rust more usable.
• dbcurtis 10y ago
  What about bare-metal options? Is there any development effort in that direction? Most of the C that I do these days is Arm Cortex-Mx work. Realtime cooperative multi-tasking using an RTOS on the bare metal. It seems like Rust would be a great option for that kind of work if the low-level ecosystem were complete enough.
  • steveklabnik 10y ago
    There's a lot of interesting stuff, including http://www.tockos.org/ http://www.tockos.org/. Some osdev stuff still needs nightly, but there's been really great movement on tooling, with stuff like xargo, and https://github.com/rust-embedded/ https://github.com/rust-embedded/ is a group of people trying to work towards improving things generally by identifying common needs, etc.
  • johnny22 10y ago
    https://github.com/hackndev/zinc https://github.com/hackndev/zinc is one effort in that vein. I'm not sure what else exists though.
    • dbcurtis 10y ago
      That actually looks very good. They are supporting STM32F4, which is one part I use a lot. I see they are using the GNU linker (and presumeably binutils) which makes total sense. No reason to reinvent all of that, and that tool chain is robust.
• stcredzero 10y ago
  I do not mean to pick on C++: the same problems plague C, Ada, Alef, Pascal, Mesa, PL/I, Algol, Forth, Fortran ... show me a language with manual memory management and threading, and I will show you an engineering tragedy waiting to happen. I think if programming is to make progress as a field, then we need to develop a methodology for figuring out how to quantify the cost-benefit trade-offs around "engineering tragedies waiting to happen." The fact that we have all of these endless debates that resemble arguments about religion shows that we are missing some key processes and pieces of knowledge as a field. Instead of developing those, we still get enamored of nifty ideas. That's because we can't gather data and have productive discussions around costs. There are significant emergent costs encountered when "programming in the large." A lot of these seem to be anti-synergistic with powerful language features and "nifty ideas." How do we quantify this? There are significant institutional risks encountered when maintaining applications over time spans longer than several years. There are hard to quantify costs associated with frequent short delays and lags in tools. There are difficult to quantify costs associated with the fragility of development environment setups. In my experience most of the cost of software development is embodied in these myriad "nickel and dime" packets, and that much of the religious-war arguing about programming languages is actually about those costs. (For the record, I think Rust has a bunch of nifty ideas. I think they're going down the right track.)
  • runT1ME 10y ago
    > A lot of these seem to be anti-synergistic with powerful language features and "nifty ideas." I think this is a pretty big myth that only applies to some of these language features.
    • stcredzero 10y ago
      I think this is a pretty big myth that only applies to some of these language features. If you admit that it applies to some language features, then it's not a myth by definition. In Smalltalk, #doesNotUndertand: handlers and proxies and unfortunate "clever" use of message sends synthesized within custom primitives could result in outsized costs. (It's where method_missing comes from in Ruby.) It's not that you couldn't do powerful and useful things with those facilities. It's that large projects that were around for years tended to accumulate "clever" hacks from bright young developers with a little too much hubris. Often, those costs would be incurred years after the code was written. Yes, it only applies to some language features. But it clearly does apply to some of them. I don't think it's easy to come by quantified costs for these. Doesn't this strike you as a problem for our field?
• maxpert 10y ago
  I have been anxious about using Rust as webserver. But so far there is no mature framework that I think can use. I had a look at few like mio and iron framework etc. It has no mature Websocket implementation or an http package mature enough to be used in production. I am looking forward to make an ultra efficient PubSub server that supports HTTP poll and Websockets. Hope my dream comes true :)
  • steveklabnik 10y ago
    Expect lots of movement in this space, with tokio coming out with an initial release soon!
• sh_tinh_hair 10y ago
  Safety stopped here: "curl https://sh.rustup.rs https://sh.rustup.rs -sSf | sh" So did my interest.
  • PudgePacket 10y ago
    It's convenient for the majority of people. There are regular downloads available (https://www.rust-lang.org/en-US/other-installers.html https://www.rust-lang.org/en-US/other-installers.html) and you can probably also get Rust through your system package manager.
    • nnethercote 10y ago
      "I trust your binaries but I don't trust your shell script for installing those binaries."
  • theseoafs 10y ago
    There's nothing stopping you from downloading the script and peeking at it yourself. There's also nothing stopping you from using the many other installation methods available.
  • deathanatos 10y ago
    This is effectively what most package managers do too. If you're going to be running code from a third party, you need to be able to trust that command, or there's really nothing you can do, as some equivalent of it is going to run.
• sh_tinh_hair 10y ago
  io::stdin().read_line(&mut guess).expect("failed to read line"); My eyes have seen the glory of RUST, it's really javascript, right?
• keldaris 10y ago
  As someone looking at this influx of discussion from the point of view of a curious bystander, I can't help but be annoyed by two persistent misconceptions that keep being perpetuated in many statements of this kind. 1) Memory safety is or should be a top priority for all software everywhere. The OP goes so far as to state: "When someone says they "don't have safety problems" in C++, I am astonished: a statement that must be made in ignorance, if not outright negligence." This is borderline offensive nonsense. There are plenty of areas in software design where memory safety is either a peripheral concern or wholly irrelevant - numerical simulations (where crashes are preferable to recoverable errors and performance is the chief concern), games and other examples abound. It's perfectly true that memory safety issues have plagued security software, low level system utilities and other software, it's true that Rust offers a promising approach to tackle many of these issues at compile time and that this is an important and likely underappreciated advantage for many usecases. There's no need to resort to blatant hyperbole and accusations of negligence against those who find C++ and other languages perfectly adequate for their needs and don't see memory safety as the overriding priority everywhere. Resorting to such tactics isn't just a bad PR move, it actively prevents people from noticing the very real and interesting technical properties that Rust has that have little to do with memory safety. 2) Rust is just as fast or faster than C++. Rust is certainly much closer to C++ in performance than to most higher level interpreted languages for most usecases and is often (perhaps even usually) fast enough. Leave it at that. From the point of view of high performance programming, Rust isn't anywhere close to C++ for CPU-bound numerical work. For instance, it does not do tail call optimizations, has no support for explicit vectorization (I understand that's forthcoming), no equivalent to -ffast-math (thereby limiting automatic vectorization, use of FMA instructions in all but the most trivial cases, etc.), no support for custom allocators and so on. I'm also not sure if it's possible to do the equivalent of an OpenMP parallel-for on an array without extra runtime overhead (compared to C/C++) without resorting to unsafe code, perhaps someone can correct me if it's doable. Over the past week or so, motivated largely by a number of more insightful comments here on HN from the Rust userbase, I've tried out Rust for the first time, and found it to be quite an interesting language. The traits system faciliates simple, modular design and makes it easy to do static dispatch without resorting to CRTP-like syntactic drudgery. The algebraic/variant types open up design patterns I hadn't seriously considered before in the context of performance-sensitive code (variant types feature in other languages, but are usually expensive or limited in other ways). The tooling is genuinely excellent (albeit very opinionated) and easily comparable to the best alternatives in other languages. I'm not yet sure if I have an immediate use for Rust in my own projects (due to the performance issues listed above and easier, higher level alternatives in cases where performance is irrelevant), but I will be closely following the development of Rust and it's definitely on my shortlist of languages to return to in the future. However, I would have never discovered any of this had I not objected to the usual "memory/thread safety" story in a previous HN discussion and received a number of insightful comments in return. I think focusing on the safety rationale alone and reiterating the two hyperbolized misconceptions I listed above does a real disservice to the growth of a very promising language. I think Steve Klabnik's blog post to which the OP responds is a real step in the right direction and I hope the community takes it seriously. Personally, I know a few programmers who've entirely ignored Rust due to the existing perception ("it's about memory safety and nothing else") and in the future I'll suggest Rust as worthy of a serious look as an interesting alternative to the prevailing C++-style designs. I'm certainly glad I tried it.
• zerofan 10y ago
  > Well, I just re-read your list of 'clever' features, and can't really see how any of them is incidental Couldn't find one thing that could be simpler, eh? I think you just said you wouldn't admit you're wrong under any circumstances. > Not sure what to make of this comparison, given that Rust beat Swift in the majority of the benchmark tasks. Are we looking at the same page? Swift wins the first 3, ties on the next 2 and loses on the last 4. You can call that 6 to 3 if you want, but it seems pretty neck and neck for languages with comparable safety promises. > Also, you have to look at the quality of the compilers themselves. Rust is universally acknowledged to be a high-quality compiler, while Swift (especially together with Xcode) are often bemoaned as buggy and crashy. Now you're just showing your ignorance. Rust uses LLVM for it's code generator. The Swift language is headed up by Chris Lattner, who started the LLVM project. Swift and Rust use the same code generator. Rust is riding on LLVM's coat tails. I have no idea who's in charge of Xcode, but I don't currently program on a Mac or use IDEs, so I don't care if that crashes. > Well, I have to say they are an extremely lucky bunch. Most systems programmers don't have the luxuxy of writing script-sized programs which use the OS as their garbage collector. Most programmers don't have the discipline to keep their programs simple. So yes, I'm lucky to be in a place where lines of code is considered a cost instead of a benefit. > 'Would you like to do high-performance concurrency with statically guaranteed no data races?' No, we also tend to use multiple processes instead of multiple threads. This scales very easily across a cluster of computers, something Rust won't do for you. Go ahead and have the last word if you like - I won't reply. I've clearly made you defensive, and I don't think this discussion is likely to turn friendly again.
  • yawaramin 10y ago
    re: https://news.ycombinator.com/item?id=13282559 https://news.ycombinator.com/item?id=13282559 > Couldn't find one thing that could be simpler, eh? I think you just said you wouldn't admit you're wrong under any circumstances. I'll happily acknowledge being wrong. Please point out how any of the features you mentioned could be simplified or removed without compromising on safety. > You can call that 6 to 3 if you want, but it seems pretty neck and neck.... In any case, this is the problem with benchmarks--even with hard numbers we won't agree on who's winning because everything is up for argument. > Swift and Rust use the same code generator. Rust is riding on LLVM's coat tails. The code generator backend (LLVM) is not the same thing as the compiler frontend (lexer, parser, typechecker, AST tree shaker, etc.). I am specifically referring to the Swift compiler frontend. If you don't believe me, here's a dedicated repo for tracking Swift compiler crashes: https://github.com/practicalswift/swift-compiler-crashes https://github.com/practicalswift/swift-compiler-crashes > Most programmers don't have the discipline to keep their programs simple. So yes, I'm lucky to be in a place where lines of code is considered a cost instead of a benefit. I think we're talking about different things here. I'm visualising long-running software that drives automation of your systems. You're talking about quick jobs that do some task and then exit. > ... we ... tend to use multiple processes instead of multiple threads. This scales very easily across a cluster of computers, something Rust won't do for you. I mean, which language does scale multiple processes across clusters easily for you? I'm very curious to find out. > Go ahead and have the last word if you like - I won't reply. I've clearly made you defensive, and I don't think this discussion is likely to turn friendly again. If you won't engage in discussion, then how am I the defensive one? ¯\_(ツ)_/¯
• jinmingjian 10y ago
  The memory safety of Rust is over consumed. 1. several small languages also introduce the type system to try to solve the memory safety problem. But all of them are less famous. Because there are many reasons that makes a language being accepted massively from other tons. 2. in many cases, it is not hard to do manual memory management. There are many great software done with manual memory management. Although I admit the quest to memory management is always wonderful for system. But go to the follow #3. 3. linear/affine type system[1] is not the panacea. The case of "used exactly once" is just a small case. Forcely to this pattern makes large boilerplates. And constraints and verifications to system can not be done many levels and aspects. Is this truly valuable to add all into type system? 4. memory safety of Rust comes with price, which have added many complexities and language burdens to itself. Who like to read the following function declaration?(just borrowed as example): fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'a str 5. So, finally, the question arises: does the current form of the memory safety of Rust deserve as the hope of next industry language? I'm afraid... [1] https://en.wikipedia.org/wiki/Substructural_type_system https://en.wikipedia.org/wiki/Substructural_type_system
  • Retra 10y ago
    >Who like to read the following function declaration?(just borrowed as example): > fn foo<'a, 'b>(x: &'a str, y: &'b str) -> &'a str Anybody who cares about the validity of pointers would like to read that. It very explicitly tells you what must be true of the arguments for them to be valid and for how long the result will be valid. In general, you seem to be over-valuing conciseness. If you think conciseness is more important than memory safety, feel free to not use Rust. But frankly, it is trivial to make a language more concise. That's not a hard problem whatsoever.
• zerofan 10y ago
  Who are you fooling? I'm well aware of the author's history with Rust. Sorry if I confused you. Do you support his "experienced" view that all of the C or C++ programmers who don't put a particularly high value on safety are either ignorant or negligent? Now's your chance - take a stand and support your team mate! > Can you give me an example of a comment in this thread that you find to be from a pretentious beginner? No great examples in this thread. Does that mean I'm wrong?
  • dang 10y ago
    You've repeatedly become uncivil in this thread. That's against the rules here. We ban accounts that do this, so please post civilly and substantively, or not at all. We detached this comment from https://news.ycombinator.com/item?id=13282695 https://news.ycombinator.com/item?id=13282695 and marked it off-topic.
    • mSparks 10y ago
      please take your life somewhere else.
• luckydude 10y ago
  "Our engineering discipline has this dirty secret, but it is not so secret anymore: every day the world stumbles forward on creaky, malfunctioning, vulnerable, error-prone systems software and every day the toll in human misery increases. Billions of dollars, countless lives lost." Billions of dollars and countless lives lost? I'm not saying that buffer overruns aren't a thing but this seems like marketing claims without substance. Yes, I read through the examples below, still think he's overstating it.