15 ms·

Rust vs C Pitfalls

• gravypod 10y ago
  If you're fighting, you've lost. The way to convert everyone to Rust you need to be better the the competition. Not just better as in "look at my features that will make your code safer". People may see the value but think "I get on just fine without the borrow checker so it isn't too important". You need to be far better then the replacement by providing the following: * Great Tooling ( IDEs ) * Great Libraries ( Everything and a kitchen sink ) * Better Documentation Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move. No amount of language features will pull people who are doing well at their job, currently building everything they need to, and who maintain low level systems. You have to be able to entierly replace the old systems in a completely feature-complete way that's also easy to migrate to. Blog posts wont pull me away from C, tooling and docs will.
  • voidlogic 10y ago
    On similar note, why Rust over Go? If I look at everything I used to write in C, I'd say 80% is well suited for Go and the rest I would fallthrough to Rust for. For the stuff where having a GC and slightly less control is OK, I don't see why I would want to use Rust. Rust is just much more complex and I prefer to keep it simple stupid (KISS). Basically, Go is good for 90% of what I used to use Java for and 80% of what I used to use C for... trying to understand where it makes sense for Rust to fit in.
    • burntsushi 10y ago
      I don't use Rust just because I want to avoid GC. I also use it for algebraic data types, compile time elimination of data races, sophisticated polymorphism, a clear and simple module system, excellent tooling in the form of Cargo and an unrelenting focus on providing abstractions with as little overhead as possible. (I've used Go and Rust daily for the past few years. I love them both.)
      • santaclaus 10y ago
        > I don't use Rust just because I want to avoid GC. Go that is?
        • burntsushi 10y ago
          Hmm, not sure I understand? Re-reading, perhaps my phrasing wasn't clear. What I meant was that I use Rust, and it's not simply because it lacks GC. There are lots of other good reasons too. To be even clearer: I don't think Rust's value proposition depends on whether you absolutely must avoid GC or not.
          • empath75 10y ago
            Rust has gc, no?
            • colejohnson66 10y ago
              Depends on your Rust implementation. You can have an implementation without one and use it to make, say, an operating system.
              • steveklabnik 10y ago
                There is only one implementation of Rust, and it does not have tracing GC. The language does not include semantics for one, so it would be an extension of the language.
                • colejohnson66 10y ago
                  Right. I had that backwards. (I don't program Rust)
                  • TheDong 10y ago
                    > I don't program Rust If you don't know anything about rust, you shouldn't respond to a question about rust.
    • moosingin3space 10y ago
      The ownership system isn't strictly about memory management and can make it easier to catch yourself making larger architectural errors, and you can have more confidence in a refactor with Rust than Go. In fact, I'd argue Rust leads to simpler architectures that fit well into the ownership model as opposed the the "ad-hoc" architectures programs written in other languages seem to invariably turn into.
    • dispose13432 10y ago
      >On similar note, why Rust over Go? I was going to say that rust has performance advantages over Go (due to GC), but look at benchmarks: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=rust http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan... Go wins some and looses some, but it's all in the ballpark (except Binary trees [1] which it loses even to Java(!)). It's true that rust is a new language, but so is Go. [1]: I assume it's because it's a test of GC, but Go loses to Java (which, like Go, is a GC language)
      • merb 10y ago
        yeah of course, doing simple programs and checking their time is a good benchmark... oh wait.. also real world performance in bigger programs is mostly different, especially when you deal with big heaps. Btw. this site is extremly bad for benchmarks since it also measure's the startup time of the runtime in java/go/rust.
        • igouy 10y ago
          > startup time http://benchmarksgame.alioth.debian.org/sometimes-people-just-make-up-stuff.html#jvm-startup-time http://benchmarksgame.alioth.debian.org/sometimes-people-jus...
        • FreeFull 10y ago
          Rust doesn't have any significant runtime startup cost, but it certainly is an issue for Java (and presumably Go as well).
          • igouy 10y ago
            It is an issue for Java programs that complete in a few tenths of a second. So these do more work than a few tenths of a second.
      • mmstick 10y ago
        This is only because the Rust implementations are using particularly slow code paths, either because SIMD/AVX optimizations requires a nightly compiler, some optimizations would require unsafe code, or that other languages are using particularly hacky code that would never fly in real world software. For example, many of the Java/C/C++ benchmarks are using custom optimizations that should be illegal for the benchmarking. Case in point, some are featuring custom hash maps that feature hashing algorithms that, while fast, would never be useful as they provide no protection against collisions. You'll see a hashing algorithm in a C preprocessor, for example, that just fakes having an actual algorithm whereas Rust examples are sticking to the tried and tested production-grade algorithms shipping in the standard library.
    • mmstick 10y ago
      I was writing software in Go for a year before I switched to Rust. I've not felt a need to touch Go since. Basically, anything you can do in Go, you can also do in Rust, but Rust will let you do it with higher efficiency and with significantly less lines of code. In the end, it's just easier to write software with Rust than it is Go. Feature-wise, Rust features generics and functional programming via higher-order functions and iterators, which is something that Go especially lacks in. Go doesn't have nice concepts like `Option`, `Result`, or `Iterator`. That's not something I'd personally want to live without today. The Go method is effectively writing boiler plate code everywhere, which leads to much room for error prone implementations that require more testing. I haven't felt that Rust was more complex than Go, at least when you're actually writing software in Rust. Rust libraries feature semantic versioning and are automatically downloaded and verified at build time based on the contents of your `Cargo.toml` and `Cargo.lock` files. No importing of Git repositories directly required. Go does not provide an equal on that front. There are a lot of great libraries out there to bring you extreme performance, simply, such as the bytecount crate, which is just a library that features a single function, a function that counts the occurrence of a specific byte, 32 bytes at a time with AVX, with additional SSE/SIMD implementations depending on what the processor supports. All there is to truly know about Rust is the borrowing and ownership mechanism and how to implement a custom `Iterator`. If you have a solid understanding of both then you've pretty much mastered all you need to know about Rust. The borrowing and ownership mechanism can be simplified down to: - Passing a variable by value will move ownership, dropping the original variable from memory - Passing a variable by mutable reference will keep the original variable, but allow you to modify the variable. - You may only borrow a variable mutably once at a time, and you may not immutably borrow while mutably borrowing. - You may have as many immutable borrows as you want, so long as you aren't modifying that value. - You may mutably borrow a field in a struct, and then mutably borrow a different field in the same struct simultaneously, so long as you aren't also mutably borrowing the overall struct. - You can use `Cell` and `RefCell` to allow for mutably modifying an immutable field in a struct. - You may mutably borrow multiple slices from the same array simultaneously so long as there is no overlap. - Safe memory practices means that instead of mutably borrowing the same variable in multiple places, you queue the changes to make in a separate location and apply them serially one after another. Then for the `Iterator` trait, you would know that all traits have required methods, whereby as long as you implement the required methods for your type, you will automatically gain all of the other methods associated with the trait. For the `Iterator` type, you only need to implement the `next` method, and that looks something like so: ``` struct DataIterator<'a> { data: &'a [u8], index: usize, } enum Token<'a> { One(&'a [u8]), Two(&'a [u8]) } impl<'a> Iterator for DataIterator<'a> { type Item = Token<'a>; fn next(&mut self) -> Option<Token<'a>> { let start = self.read; for element in self.data.iter().skip(self.read) { self.read += 1; // if next value is found then return Some(&value[start..self.read]) } None } } ```
    • catnaroek 10y ago
      Go's GC isn't a big deal for most use cases. However, the loss of static guarantees regarding thread-safe manipulation of arbitrarily complex data structures is a big deal.
    • plandis 10y ago
      For me this is pretty easy. It's about leadership. The leaders of Go foster an attitude of exclusiveness (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups). The leaders of Rust are very receptive and helpful to new people. They are on IRC / Reddit and many other channels. I'd much rather invest my time into a truly open language and to me, that is not Go.
      • NoahTheDuke 10y ago
        > (just like a month ago they wanted to get rid of the Go subreddit in favor of a solely Google owned option of Google groups) Wow, really? Do you have a link to that discussion? That's wild.
        • gmjosack 10y ago
          I believe this post was stickied at the top of the golang subreddit for a bit: https://www.reddit.com/r/golang/comments/5eubdp/the_future_of_rgolang/ https://www.reddit.com/r/golang/comments/5eubdp/the_future_o... It should be a good summary of the event.
      • atombender 10y ago
        > just like a month ago they wanted to get rid of the Go subreddit To be fair, this was a proposal by a single person on the Go mailing list, and it was in reaction to Reddit's CEO publicly admitting to editing other users' comments. The person who proposed closing the Go subreddit was also under the mistaken impression that the subreddit was hosted by the Go team, which wasn't the case. In the end, there was a lot of discussion, and nothing was deleted. Tempest in a teapot, as usual. Go has a serious culture problem, but that's not a good example of it.
        • euyyn 10y ago
          What's a good example of it?
          • 10y ago
    • pornel 10y ago
      I write libraries. In Go I can only write libraries for Go programs. In Rust I can write libraries for any program. i.e. Rust can easily produce static and dynamic libraries that are linkable with C programs and any language with a C FFI. I can write Rust code that works for programmers using C, C++, C#, D, Go, Swift, Python, PHP, Java, etc.
      • shanemhansen 10y ago
        > In Go I can only write libraries for Go programs. That's not true. It's quite simple to create a loadable shared object in go and call it using anything with a c ffi.
        • TheDong 10y ago
          It's not quite simple because of the GC go brings. As proof, notice that it barely happens, and only as an oddity in Go, yet in rust there are actual uses (e.g. ruby and python library optimization)
        • lobster_johnson 10y ago
          Calling C from Go has significant overhead [1], doesn't that mean calling Go from C is equally slow? [1] https://www.cockroachlabs.com/blog/the-cost-and-complexity-of-cgo/ https://www.cockroachlabs.com/blog/the-cost-and-complexity-o...
          • hueving 10y ago
            It may be even worse calling Go from C since you are bring the whole Go runtime with GC and all when you call into Go.
      • thegeekpirate 10y ago
        You can do this with Go as well, and have been able to for a while now. http://www.darkcoding.net/software/building-shared-libraries-in-go-part-1/ http://www.darkcoding.net/software/building-shared-libraries... http://blog.ralch.com/tutorial/golang-sharing-libraries/ http://blog.ralch.com/tutorial/golang-sharing-libraries/
    • treehau5_ 10y ago
      4th law of HN: Whenever Rust is brought up, Go inevitably follows, and vice versa.
      • saghm 10y ago
        It's kind of a shame, because I don't really feel like the languages are used for similar things in practice, so the constant comparisons don't do either of them justice.
    • lobster_johnson 10y ago
      As someone who writes Go full time, once I'm done with my current big Go project I will be taking a break to investigate alternatives. Both Rust and Swift are at the top of my list. Go is good, even great, at many things. But it's a language largely defined by its limitations, usually intentionally. It's an engineering language, not made for big abstractions. For me, the largest frustration is that the language gets in the way, and the pain increases with the scale of the problem. Which is to say: I think Go scales to large projects just fine, but there are problems where you'd like to build big building blocks on top of smaller blocks on top of smaller blocks, and Go doesn't lend itself to certain kinds of big, composable, data-oriented abstractions. It's small building blocks all the way. I've bumped into several very real problems recently where Go's coarse, not-very-data-oriented imperative approach has revealed itself as a liability, and where I found myself fantasizing how I could have done it in just a few elegant lines in Haskell. Sometimes they're about expressing things simply in a composable manner, and sometimes these problems simply manifest themselves in immense blobs of boilerplate/repetition (for example, because you have to implement the same method a few dozen times on different data structures, which in a different language could be solved with a generic implementation), where Go's solution is to either eschew type safety, use slow reflection APIs, or programmatically generate the Go code as part of the build process. Go's is also frustrating in its selective pragmatism. Where Go has chosen to automate and sugarcoat some complicated things (memory management, goroutines), it's stubbornly unpragmatic about other things (error handling, working with polymorphic data, memory safety). Go has been ridiculed for its simplistic error system, but I'm not an extremist here; I'm all for errors being values, and not a fan of exceptions. But if you look at actual Go code, a huge amount of code has to interact with errors. When nearly every function is riddled with "if err != nil", you should know that your language is crying out for just a little syntactic sugar. Or a solid type-system solution for that matter. Enums (Rust-style) and pattern matching wouldn't go against Go's grain at all, but since Go is "done", we're stuck with how it is. I think Go's focus on simplicity is very important (I'm a big fan of the Wirth school of languages), and my worry about Rust and Swift is that they never learned this lesson. To me, both Rust and Swift looked more promising early in the design process than in their current state; Swift looks increasingly like Scala every time I visit it, whereas Rust often feels lost in a sea of punctuation. That said, my annoyance with Go is acute enough that I'm willing to deal with a few downsides if I can get a language that better matches the kinds of projects that I build.
    • EugeneOZ 10y ago
      Rust is not more complex, it just takes some more time to get used to.
    • estefan 10y ago
      I've literally just started learning Rust after following it for a few years. I wanted a language that was type-safe and produced binaries to simplify deployment. I chose Rust over Go because I wanted a functional language with generics. Go's repetitiveness regarding error handling just put me off. I've tried learning C/C++ at several times but I just don't have the inclination to have to bother about null-terminating strings, etc in 2016. I don't mind spending a little more time getting something to compile if it prevents silly mistakes. Having said all that, it's obviously too early for me to say whether I like Rust. I'm picking it up pretty quickly since I know FP thanks to Scala, but I'll see how much time I spend fighting the borrow checker.
    • fleetfox 10y ago
      I'm learning Rust. I considered Go but feature wise compared to Rust it seems really boring and plain. IMHO modern language has to have functional flavor.
  • htaunay 10y ago
    Well, I can't speak for tooling or productivity comparison to C/C++, but Rust has one of the best programming language documentations I have ever had the pleasure of reading [1]. [1] https://doc.rust-lang.org/stable/book/ https://doc.rust-lang.org/stable/book/
    • steveklabnik 10y ago
      Thank you! Carol and I are working on the second edition, you can read what we have so far here: http://rust-lang.github.io/book/ http://rust-lang.github.io/book/ (I think it's even better, but I'm biased)
      • sli 10y ago
        Count me excited. I've always liked the book, but I've also found it fairly lacking in ways I'm not sure I completely understand, I can likely lend part of that to my relative inexperience with Rust and systems programming in general. One I can note is that I really like the new sections. I've never quite liked that the current book is just a bunch of chapters all in a row. Not that that's necessarily bad in and of itself, but I do think the new way is better.
        • steveklabnik 10y ago
          Thanks! If you do check it out, don't hesitate to file issues.
          • copine 10y ago
            How far along is the new documentation? Would it be better to read https://doc.rust-lang.org/book/ https://doc.rust-lang.org/book/ or the github.io page? Maybe both?
            • steveklabnik 10y ago
              Both would be ideal, if you have the time. The new book is far enough along that you can learn the most basic stuff from it, and the intermediate bits are coming along. The more advanced stuff is only an outline. So if you start with new, and then switch to old, you'll get the best of both.
  • lacampbell 10y ago
    C is a very small and very portable language. Rust is not. I wondering why people bother comparing them at all.
    • gpderetta 10y ago
      I doubt that a significant amount of C programmers will switch to Rust. On the other hand, rust is very attractive for us C++ programmers.
      • Scuds 10y ago
        Do you think we'll see major games having significant engine components being written in Rust?
        • gpderetta 10y ago
          I don't work in that field, but I doubt game programmers will be early adopters of rust, as I think they mostly don't care about memory safety.
          • Crespyl 10y ago
            There's been some interest, but I think the likes of jblows Jai language that emphasize rapid development and programmer convenience over correctness will likely catch on faster.
        • mmstick 10y ago
          DICE and others have been investigating and using it to create tools for developing games. There is interest in using it within game engines, but there's just the issue of Rust support for major consoles. There is great interest in the PC gaming world though that's not constrained by console support.
      • lacampbell 10y ago
        I appreciate rust making a break from C++ and cleaning up some of the warts, immutability by default, having real modules etc. But I am not really impressed with its memory management thing. It's a bit tiresome to check stuff with valgrind, sure, but I don't have to worry about making cyclic data structures satisfy the borrow checker. I don't see the trade off as worth it.
  • manaskarekar 10y ago
    In addition to htaunay's post about docs, Rust also has cargo and crates.io which are fucking awesome. Blog posts are one way to showcase tooling, perhaps not this one, but they have their place.
    • santaclaus 10y ago
      > Rust also has cargo and crates.io Which is undersold in the propaganda! Safety, ehhh I'll take it but I'm not jonesing for it. A package manager that works and has adoption? Thank you! I've wasted far too much time wrangling C++ dependencies by hand...
      • masklinn 10y ago
        My guilty pleasure these days is running `cargo doc --open`. Generating local docs for my package and all its dependencies? I love.
  • mmstick 10y ago
    Rust has by far the best tooling and documentation support out of all languages I've seen. Library support is great too, at least in that Cargo is an amazing platform and it's too easy to import C libraries. What do you feel is actually missing from Rust? Nothing has stopped me from replacing C entirely on the low end, and even the high end for application software development.
    • santaclaus 10y ago
      > What do you feel is actually missing from Rust? A solid NumPy-like library, for one.
      • gravypod 10y ago
        Like you I need something like NumPy and SciPy for my work. I'd also like an IDE. An IDE goes a long way to helping me feel comfortable to use a language.
        • empath75 10y ago
          https://internals.rust-lang.org/t/introducing-rust-language-server-source-release/4209 https://internals.rust-lang.org/t/introducing-rust-language-...
          • gravypod 10y ago
            I don't care about the backend and how it's implemented. I don't write IDEs. I write software in IDEs. If the IDE is good, and by good I mean provide autocomplete and features on par with Eclipse for Java,and it needs to be fast and easy to use. Fast and easy to use are UI tricks that can't be handled by a server. Edit: I just realized that this may be read in a negative connotion and I didn't mean it like that. I just mean that I'm not the person who should be looking at those. I just know it doesn't exist yet and I'd like it to. Telling me of the Rust Server thing gives me no information as to how close the IDE is to being done.
            • 10y ago
  • zzzcpan 10y ago
    I think they are well aware of the problem at this point. Their best bet is to focus on high-performance networking software and networking ecosystem, where alternatives are still weak.
  • empath75 10y ago
    It's very rare that any programmer switches computer languages. You're probably going to retire as a c programmer. What are they going to teach in school? What are new systems programmers going to start with? I suspect it'll be rust and go, not c.
    • sfilargi 10y ago
      > It's very rare that any programmer switches computer languages. Do you have any data to support this claim?
    • gravypod 10y ago
      I'm 19, I started out with Java, I switched to JavaScript for some time, I move on to Python for which most of my projects exist in and sometimes I use C when the job counts for it. I'm also a pretty big fan of PHP and a few other technologies that are very nice. To recap this has been my life as a programmer: Java -> JavaScript -> PHP -> Python/C/Assembly This dream that most people have made up about programmers not switching languages is a dream. I switch whenever one language can do a task better then another. I don't get caught up in "best language" fights.
      • empath75 10y ago
        Yeah but you're just getting started. Talk to me after you've been paid to be a python developer for 20 years or whatever and tell me how interested you are in learning a new language. I play with a lot of languages but I've invested a lot of time into learning python and getting a nice python workflow going. It would take a lot for me to switch to another primary first language. I work at a tech company that's been around since the 90s and the guys that were writing perl and java in the 90s are still writing perl and java. You'd have to drag them kicking and screaming into using a different language.
        • SSTitan 10y ago
          Yeah I can use several languages (C,C++,python,go,rust,x64,perl,scala,etc...) But I always envision starting a project in C or C-like C++ because I learned it first and after decades I know that language inside and out and my brain's "workflow" and my actual tool setup and personal libraries means I can crank working solutions out extremely quickly.
  • steveklabnik 10y ago
    We've slowly been shifting how we talk about Rust as it evolves. I agree with you that these things matter, and they're all things we're actively working on.
  • all2well 10y ago
    I mean by that logic, no progress is possible at all in programming languages, because at some point every language had worse tooling than the competition. I'd say the greatest part about Rust is the community, which realizes all of the issues you've listed, and especially the really tough learning curve for beginners. Generally, use the right tool for the job. I don't think I'd really want to use Rust in production yet, but it's really great for side-projects and other more experimental things.
    • bluejekyll 10y ago
      > I don't think I'd really want to use Rust in production yet... Why not out of curiosity? I've already been showing off to people at work how much shorter Rust code is than our corresponding Java, how much easier it is to build and deploy, and how much more stable it is. Granted I've been using it at small micro service scale at the moment, but I see no reason not to go into production at the moment (well, except for the fact that I'm the only one that will be called at night if it fails... luckily it hasn't, and I'm not worried).
      • idobai 10y ago
        > Why not out of curiosity? I've already been showing off to people at work how much shorter Rust code is than our corresponding Java, how much easier it is to build and deploy, and how much more stable it is. And I can show you how shorter, simpler and safer code I can write in Scala. People really overrate rust - this language isn't that nice syntactically and the only "new" thing it brought is the compile-time "unique_ptr".
  • Manishearth 10y ago
    > If you're fighting, you've lost. I don't really get this attitude, it means that nothing new will ever overcome anything that's been established. > Anything that can be done easily in C or C++ will need to be easier in Rust for everyone to move You don't even need folks to move from C. Rust has had lots of success when it comes to folks completely new to systems programming learning it through Rust. Predominantly python/ruby/whatever shops are using Rust because they need a fast language, but don't want to deal with safety issues. > Blog posts wont pull me away from C, tooling and docs will. Then you are not the right audience for this blog post :) I find that such blog posts are extremely helpful in convincing people who have a choice between starting to use C and starting to use Rust, not folks who are already invested in C or C++. But I have seen such overviews to have impact on invested C/C++ programmers too; everyone is different!
    • tines 10y ago
      >> If you're fighting, you've lost. > I don't really get this attitude, it means that nothing new will ever overcome anything that's been established. I think he's trying to quote Dan Saks' "extern c: Talking to C Programmers about C++" when he said "If you're arguing, you've lost." Saks, at least, meant that if you're striving with someone, you've already lost because your partner is already in a "frame" of mind set against your arguments that is unbreakably strong, even by logic. The talk is really good just for that aspect.
      • Manishearth 10y ago
        Ah, I see. Yeah. I read that post more as a demonstration than a "fighting". But that's a valid point.
      • gravypod 10y ago
        I would have linked the video had I remembered the talk but exactly. This is what I meant.
    • adrianN 10y ago
      I'm currently trying to learn Rust, but if my motivation were "I need a fast language and don't want to deal with safety issues", I'd use Java. It's plenty fast (especially compared to something like Ruby!), the ecosystem is huge and tooling is extremely mature.
  • gigatexal 10y ago
    Disagree. Rust seems like all the things we have been wishing C/C++ was. It's on my list of languages to learn next for sure.
  • enygmata 10y ago
    > * Great Libraries ( Everything and a kitchen sink ) This is a must for me. I often give up on compiled languages because libfoobar isn't yet available on the language and I have no interest in writing (and maintaining) language bindings for third party libraries I use. My dream is that one day I'll be able to do something like: Foobar = link_cimport({"headers": ["foobar.h"], "packages": [ "foobar" ], "prefix": "foobar_"}); Foobar.do_something(); // would call foobar_do_something(); Foobar.hidden_function(); // would call hidden_function(); and the compiler will give me an executable that was linked against `foobar` instead of dlopen()ing it at runtime. Something like: Foobar = loadable_cimport({"headers": ["foobar.h"]}); foo = Foobar.load("/path/to/foo.so"); bar = Foobar.load("/path/to/bar.so"); would also be nice because I often have to load libraries that implement the same API/ABI.
    • psi-squared 10y ago
      It looks like the first part of what you want is nearly there - see https://github.com/Yamakaky/rust-bindgen https://github.com/Yamakaky/rust-bindgen It converts C headers to a Rust module containing the relevant type/function/etc. definitions. On stable you need to either pregenerate the module (not too bad if you're pinning particular versions of libraries anyway) or add a build script to autogenerate it. On nightly, there's also a compiler plugin that does all the work for you, and looks not-too-dissimilar to what you wanted. The only thing it lacks is the prefix removal stuff.
• sidlls 10y ago
  The kind of safety guarantees Rust provides are, in my opinion, insufficient justification for experienced developers to move from C or C++. Rust has other features that make it generally superior in certain (many) contexts. The safety is a nice "add-on" effect, I suppose, but my view is that constantly hyping safety as the biggest selling point is missing a mark.
  • db48x 10y ago
    If only these mythical experienced developers that never shoot themselves in the foot actually existed.
    • keldaris 10y ago
      Infallible developers don't exist, but use cases where the particular class of errors eliminated by Rust's safety guarantees is insignificant certainly do.
    • sidlls 10y ago
      I'm terribly sorry you've never encountered an experienced developer who uses C or C++ before, or think we're non-existent, or that using extremes like "never" is a reasonable position instead of an incredibly terrible hasty generalization. If there were as many blown off feet as comments on HN suggested technology even as it currently is simply wouldn't function. Do you even understand how much mission and safety critical software is written in C? I think if you did you'd either have a constant panic attack (given your apparent belief that it's impossible to write "safe" C) or else have to adjust your world view a little bit.
      • empath75 10y ago
        No one has ever argued that it's impossible to write c code, but just because you haven't found those kinds of bugs in your code, doesn't mean that it isn't there. We're still finding 10+ year old bugs in Linux.
        • 10y ago
• p0nce 10y ago
  >
  • jjnoakes 10y ago
    Accounts have to be created at some point, right? What is the issue?
  • dang 10y ago
    That counts as a personal attack, and those are not allowed on HN—especially not against brand new users, which most new accounts belong to. Please don't do this again. We detached this subthread from https://news.ycombinator.com/item?id=13266687 https://news.ycombinator.com/item?id=13266687 and marked it off-topic.
    • p0nce 10y ago
      Let's get real, this looks like classic astroturfing to me. (edit: ok, it was not)
      • steveklabnik 10y ago
        They have a long-running Reddit account, for one: https://www.reddit.com/user/mmstick https://www.reddit.com/user/mmstick Throwing around accusations of astroturfing with no evidence isn't a good look.
        • p0nce 10y ago
          OK, I stand corrected then. Sorry for the noise.
• pklausler 10y ago
  A more interesting question for me is: is there any reason why would I want to use Rust over Haskell on any task where Haskell is "fast enough"?
  • caconym_ 10y ago
    Rust seems to be more lightweight and portable in general. I think the compiler uses far less memory (and IIRC has better cross-compilation support too). The binaries are much smaller and the runtime is simpler. Cargo is amazing and I have much more confidence in it to not give me build trouble. In particular, you get a test framework including doc tests for free; I know Haskell tools offer similar functionality but in practice the setup cost is far higher. Haddock is not bad, but it uses its own weird syntax; Rust's documentation system uses Markdown IIRC. Also, some things are just easier to write in an imperative language. I expect that the performance and memory use of Rust programs is also easier to predict and understand, though generally I think Haskell gets a lot of unfair criticism in that department. I haven't used Haskell in a while so some of the things I mentioned may have been improved upon since then. In particular, Stack may have grown up a bit.
  • greatest-ape 10y ago
    The syntax for accessing records (dot notation) is a lot nicer in Rust in my opinion. This makes a huge difference in practice, since I don't have to have ridiculously long accessor functions. Though I haven't learned how to use lenses in Haskell yet, they're supposed to alleviate some of that pain. I know you left out performance, but it's very nice to have code that can be easily profiled.
  • paulddraper 10y ago
    Probably not. There's been a lot of work put into Haskell design, and a lot of work put into Rust design. A stand-out difference is that Rust put a lot of work into the borrow checker. But if a borrow checker is irrelevant (i.e. GC is fast/small enough), there isn't a huge reason. (To be clear, there are a number of differences, e.g. strict vs. lazy evaluation, but whether one is better than another is debatable.)
• chj 10y ago
  We are having new languages every year. Instead of debating which language is the best, why can't we invent a way to let components implemented in different languages talk with each other easily? We have pipes, sockets and message queues, but it's never simple enough to glue everything together.
  • choudanu4 10y ago
    This is an interesting idea that has been explored before in VMS, an old operating system I believe competed with UNIX. VMS had a feature called CLE (Common Language Enviornment) [1] which defined calling conventions for computing primitives (functions, registers, stacks...you get it) independent of any language. You could call bits of code from all sorts of languages like COBAL, FORTRAN, C, and some others I'm not really familiar with. Because the calling conventions were specifically designed for language interopperability in mind, VMS was implemented in several different languages. Different components were coded in whatever language best expressed them. This directly contrasts with Unix, which we all know champions C. I'm not too familiar with Unix calling convention specifics, but as I understand, it revolves around C and its memory model. I believe this is what gives some languages difficulty "talking" with each other; if a language doesn't have a memory or execution model close to C's, it needs to translate through a FFI (Foreign Function Interface) [2] before exchanging execution routines efficiently. [1](https://en.wikipedia.org/wiki/OpenVMS#Common_Language_Environment https://en.wikipedia.org/wiki/OpenVMS#Common_Language_Enviro...) [2] (https://en.wikipedia.org/wiki/Foreign_function_interface https://en.wikipedia.org/wiki/Foreign_function_interface)
    • chj 10y ago
      I think Unix's pipes are better examples that how components could communicate. It's a pity that due to terminal limits, the best we can do about connecting components in Unix is to pipe things through.
  • 0xcde4c3db 10y ago
    Microsoft has sort of been working on this for decades. It started as Dynamic Data Exchange in Windows 3.x, then evolved into Object Linking and Embedding and Component Object Model, which in turn became the basis for ActiveX, Distributed COM, and COM+. Reactions vary. I believe GNOME was originally envisioned as providing a GNU framework for this kind of functionality (whence the "Object Model Environment" in the original acronym expansion), but I think those particular ambitions have mostly been abandoned.
• gens 10y ago
  Since this is a "vs" can i assume that rust is better in all regards to C ? As in that rust is flawless ? Or should it be "Rust vs C's Pitfalls" ?
• Tempest1981 10y ago
  Stroustrup has proposed a way to add safety to C++. It's called "C++ Core Guidelines", and "GSL". https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-cpp-core-guidelines https://isocpp.org/blog/2015/09/bjarne-stroustrup-announces-... https://github.com/Microsoft/GSL https://github.com/Microsoft/GSL I watched his talk -- wondering if anyone is using it. https://www.youtube.com/watch?v=1OEu9C51K2A https://www.youtube.com/watch?v=1OEu9C51K2A Using GSL gives adds some safety to pointers and memory allocation -- while providing the bare-metal performance that C is known for. (It still feels very low-level.)
• smitherfield 10y ago
  To play the devil's advocate a bit, most of these are features you already get with C++, especially if you turn on all relevant warnings and treat them as errors. I can see the advantage of having things (sorta, given "unsafe") statically guaranteed for a shared codebase, but what are some compelling reasons to switch for personal projects?
  • isaacaggrey 10y ago
    Manishearth's response [1] plus Cargo [2] hits on a lot of great things about Rust. [1]: https://news.ycombinator.com/item?id=13268955 https://news.ycombinator.com/item?id=13268955 [2]: http://doc.crates.io/ http://doc.crates.io/
• michaelmior 10y ago
  > “Safe” code is guaranteed to be 100% safe. Not statistically safe. Not safe when the compiler feels like it. As long as your code compiles, it will be safe in terms of memory safety and data-race freedom. As far as I am aware, the Rust compiler has not been proved correct. So whether or not your code is correct still depends on the correctness of the compiler. Of course this is probably correct, but still not 100% guaranteed. Edit: Relevant discussion - https://github.com/rust-lang/rust/issues/9883 https://github.com/rust-lang/rust/issues/9883
  • millstone 10y ago
    I can make your code as safe as you like, if you only let me define what "safe" means!
• faragon 10y ago
  Author forgets some inconvenients of Rust: massive bloat, multi-platform issues, etc.
  • colemickens 10y ago
    What are you talking about? I don't get people making these posts without any detail whatsoever as to what they're talking about. I have a fully static binary that includes futures, nix, tokio, uuid, and more. Even statically compiled with Muslims it's less than three megs. And if I didn't use the nix package for a setsockopt call, it would be perfectly capable of running on Windows (and I could easily make it cross platform if I wanted to invest the effort in adding Windows support). Further, there are an abundance of great resources out there for extremely painless cross compilation. So far I've not heard of problems with multiplat or bloat so I'm hoping you'll elaborate.
    • faragon 10y ago
      There are more systems than POSIX and Windows. Also, even in popular Linux systems Rust is not even installable in a straightforward way (e.g. Ubuntu 15.10, my system), so go figure. Regarding Rust bloat, I don't know if has got any better recently, but it was crazy bloated in comparison to C.
      • Manishearth 10y ago
        The bloat issues are (a) a constant overhead and (b) a matter of defaults. See https://lifthrasiir.github.io/rustlog/why-is-a-rust-executable-large.html#takeaway https://lifthrasiir.github.io/rustlog/why-is-a-rust-executab... Rust statically links to libstd by default because it's not there as a dynamic lib on most platforms. On top of that, it links in jemalloc. This makes small Rust binaries look larger than they need to be. The overhead dwindles as you start looking at larger Rust programs. If you actually need to get rid of that overhead, the option is there, it's just not default. Addition to popular package managers is being worked on.
      • crossroads1112 10y ago
• fungos 10y ago
  You're so wrong that is laughably. That laughably hashing functions are highly specialized implementations for a proposed problem. There is NO MORAL there. I code C for living and if we can use "laughably hashing functions" to gain performance we WILL DO.
  • deleted 10y ago
    [deleted]
  • dang 10y ago
    > You're so wrong that is laughably. This comment breaks the HN guidelines by being uncivil. Please express your point substantively. If someone else is wrong, show them (and the rest of us readers) how. Then we all learn something. Also, please don't use uppercase for emphasis—that's in the site guidelines too. https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html We detached this comment from https://news.ycombinator.com/item?id=13269145 https://news.ycombinator.com/item?id=13269145 and marked it off-topic.
    • mSparks 10y ago
      please take your life somewhere else.