24 ms·

Rust and Go

352 points by mperham 12y ago

codezero 12y ago
I was worried when I saw "I decided to write a little Rust and, because everyone in my world is seems swoony over it, Go." That's a pretty bad reason for using a language and usually leads to some pretty ridiculous criticism. This post was not that, I think they nailed a lot of the good and bad things about Go, in fact, they could have been a lot more harsh. There is a depth lacking in just checking out a language in this way though as there's no evaluation of some of the larger reasons Go exists, like concurrency and and fast compile times. Then again, most people probably don't even need/care about these.
- ryandvm 12y ago
  Hmm. Learning a language/framework that is exploding in popularity is probably one of the best things a dev can do to stay relevant (read: employed). Hell, very few of us would be using Javascript if it weren't for it's ubiquity/community/popularity. I sure as hell am not using it because it's a well designed language.
  - codezero 12y ago
    I agree that it's great to learn a language, I was thinking of this as more of an exercise to generate a good post, but it's probably more reasonable to assume he really wanted to learn Go :P
  - bad_user 12y ago
    Quite the contrary, learning a language because it is exploding in popularity is a nice way to ensure that you'll end up being abused, poorly paid and irrelevant. You can't possibly find a worse reason for learning a new language. On Javascript you're missing the causality. Some people are learning Javascript because it is popular of course, because they've read on some forum that learning popular things gets them hired, but those people are totally uninteresting in the pool of developers that learned Javascript because they had shit to do and things to build and Javascript was the answer. There's a big difference between learning X because you want to make your job easier, because you want to build things in a new way, because you want exposure to new ways of thinking, because there isn't an alternative to what you're trying to do, etc... and learning X because that's fashionable. In the former case, it's pretty much a gamble but you might actually get something out of it. In the later case all you're earning is the ability to slap another keyword on a resume that only mediocre HR people care about, being actually a time waist as it's keeping you from learning things that might actually be of interest for the things you're trying to accomplish (other than getting a shitty job of course). Just as people that learned PHP or Java back in the day found out, learning for the sake of getting a job is a sure way to land you a shitty and boring job in which you are replaceable cog. Managers love popular languages and frameworks, of course they do. And the interesting jobs that are out there, that make people happy and that pay well - well, let me tell you, those companies aren't looking for keywords on your resume, but for things that you've actually built. And after some years from now, when you'll be over 40, you'll find yourself either a manager that does LinkedIn searches for keywords, or an obsolete developer that can't find a job because everything you've learned is obsolete and you waisted your time in learning syntax, instead of learning new abstractions, algorithms and mathematics - you know, stuff that never gets old.
    - ChrisGaudreau 12y ago
      Personally, I like to learn any language, regardless of how popular it is. It's just fun.
      - holoway 12y ago
        Yeah, I was doing this for fun. I'm pretty secure in my day job. :)
    - bjz_ 12y ago
      > Quite the contrary, learning a language because it is exploding in popularity is a nice way to ensure that you'll end up being abused, poorly paid and irrelevant. Because I had the good fortune of starting with Rust early, I now have several foundational libraries under my belt in the Rust ecosystem. This has certainly been of great interest in interviews, and might just lead to me landing a pretty 'hip' internship over the Australian summer. Of course it won't be in Rust, but it's better than being at a hum-drum corporate placement. Being a pioneer definitely sets you apart from other candidates, and also culls the pack of potential employers to those that value curiosity and initiative, and actually care about exploring new ideas.
    - LunaSea 12y ago
      By learning new programming languages or frameworks you stand out from the crowd. Guess who's going to get a job: A) The fool who just learned JavaScript and Angular.js B) The university student who only knows Java The answer will be (A) every single time because companies don't have the time to train people for months.
      - codezero 12y ago
        This hasn't been my experience in practice but I guess it depends on what kinds of companies you've worked with. Everywhere I've worked, they hire engineers based on a lot of factors, and it has been more often the case that they'd go for someone who knows a different stack really well, than someone who knows all the newest stacks.
      - 12y ago
- deleted 12y ago
  [deleted]
- melling 12y ago
  I'm under the impression that Rust isn't near done and ready for production use. Go has been ready for a couple years. Rust could be 10 times better but I'm not going to touch it until they ship 1.0.
  - andolanra 12y ago
    The plan is to release 1.0 around the end of the year. In that sense, Rust isn't done, but it is near done.
    - TheHydroImpulse 12y ago
      Unlike other languages that are "done" at 1.0, Rust will still be improving and iterating. 1.0 defines a backwards-compatible release that you can depend on but the language won't be "done". "It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving. We will release new versions of Rust on a regular, frequent basis, and we hope that people will upgrade just as regularly. But for that to happen, those upgrades need to be painless." [0] [0]: http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html
      - melling 12y ago
        Go updates twice a year, which is actually a lot. I don't think a release every 6 weeks for Rust is a good idea. That'll never fly for enterprise software. Heck, for some companies the Java upgrade cycle is too fast.
        pjmlp 12y ago
        At Java ONE MongoDB developers mentioned they have clients still running on Java 5, thus they cannot fully embrace Java 8 for the time being.
      - NateDad 12y ago
        The stability guarantee given by rust is what scares me the most about starting up with it. "with a minimum of hassle" is really squishy language that is not at all comforting. Compared to the Go 1.0 promise: Your code will not break, period.
peterevans 12y ago
I really like the idea of testing a language by writing a small command-line utility with it, even one that -- as the author mentioned -- already exists. Way back when, when I first was learning C, I didn't comprehend it very well. I was OK with it. A friend gave me some CDs with FreeBSD on it, one with the OS, and one with program sources. It was that source code which really opened my eyes, and you could digest small programs (like chmod) and see, you know, this is working, production code, and it's not hard, and you can do this.
jff 12y ago
"Where line 9 there just blindly assumes the regex found a match, and causes quite the run-time error message." You blindly assume the regex found a match, because you ignored the part of the docs where they tell you how to check for a match: http://golang.org/pkg/regexp/#Regexp.FindStringSubmatch http://golang.org/pkg/regexp/#Regexp.FindStringSubmatch
- sswezey 12y ago
  The article didn't say there was no way to check, just that the compiler does not enforce checking. Rust's type system requires that all possible paths are accounted for when trying to extract the value from the option.
- humanrebar 12y ago
  The point is that Rust gives you a compiler error while Go assumes your sloppy code is intentional or unimportant.
jeorgun 12y ago
Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. So far as I know the fail! macro still exists in Rust. Edit: Evidently I should have put a /s at the end of that first sentence. I know what the idea behind compile-time checking is, but I don't see that the given example actually illustrates it.
- Dewie 12y ago
  > Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. Of course any function can be forced to crash by inserting some crash-inducing code into the function. You can always make a function that assumes that value is of a certain form, and crashes the program if it is not (like unwrap for extracting a value from an Option, or crashing if it there is no value). In order to have "code that works if it compiles" (comparatively speaking; often used as an exaggeration), you have to have the discipline to use the facilities that the language provides you. I guess a language would need some kind of totality checker in order to make sure that you couldn't make function diverge in some way. Like for example Idris has. Rust also has the `!` type, aka bottom, for marking functions that diverge. > So far as I know the fail! macro still exists in Rust. What should that do? Crash the program? If so it should have been renamed to something like `panic!` now, since "fail" now is associated with Error types, while "panic" is associated with crashing the program/exceptions.
  - vertex-four 12y ago
    fail! has been renamed to panic! for much that reason.
  - masklinn 12y ago
    > What should that do? Crash the program? If so it should have been renamed to something like `panic!` now It crashes the current task (thread/process), not the whole program, and has in fact been renamed panic! recently: https://github.com/rust-lang/rust/pull/17894 https://github.com/rust-lang/rust/pull/17894
programminggeek 12y ago
Having spent a little time with Go, I ended up feeling like it was both better and worse than Ruby. In many ways it's many of the things that I want from a language - static typing, fast complier, pretty sensible defaults and so on. A lot of things I wish Ruby did, Go does great. I think Go does really well in tooling, but it doesn't feel as great in syntax or language features that I would really like. The two big ones I wish Go had were named parameters on functions, and immutable data structures. It's probably a blub paradox thing, but my ideal language has immutable data structures and named function parameters. Kotlin, Scala, and Swift all kind of nailed these features, but Go has not. For me, named parameters and a little verbosity goes a long way to allow me to communicate intent in my code. Immutability allows me to have a built in sense of safety that once the data is set, it stays that way. In my experience, a whole class of problems goes away when you have those two features (alongside the many other features we'd expect form a language like Go). What I felt from Go is that a year ago when I was playing with it, that they didn't care much about either of those two features, which is fine, but it keeps go from being my ideal language. Swift I wish was a bit more general purpose, Kotlin and Scala don't compile as fast as Go, and Ruby doesn't have a compiler to do some of the checking I wish it would. Go's fast compile times with something like Ruby's syntax and a feature set similar to Kotlin/Swift would be darn near perfect. For me, there is no perfect language.
- zem 12y ago
  the thing that has got me excited about learning go some day is that it's supposed to be really good at cross-compiling code into small, standalone binaries for the three major platforms (linux, windows, osx). haxe is another language on my radar for much the same write-once-deploy-all-over-the-place reason.
  - untothebreach 12y ago
    Rust has that too. You can cross-compile binaries that will run on any platform that LLVM supports.
    - zem 12y ago
amelius 12y ago
How mature is Rust and its compiler actually at this moment? Is it in a state ready to replace C++? Edit: Also, I missed a good overview of features in one language and lacking in the other. In that respect, I find the wikipedia page [1] deeply broken, but that aside. [1] http://en.wikipedia.org/wiki/Comparison_of_programming_languages http://en.wikipedia.org/wiki/Comparison_of_programming_langu...
- crazypyro 12y ago
  From my experience, not even close, if only because the ecosystem around it has to continuously update their own resources/libraries or risk being left behind every new patch because the language is not even at a stable 1.0 point. Trying to figure out new things tends to be an exercise in reading obsolete code examples and then asking for someone in #rust on irc.mozilla.org to translate. Stuff that gets deprecated isn't well documented in my experience and one of the best resources I came across (Rust by Example) also contains a lot of out of date or deprecated features. Obviously, this is a side-effect of a rapidly evolving language that is still in pre-1.0 phase, but anyone going into it should be aware of the potential breakage that tends to happen at a fairly high clip at the moment.
- grayrest 12y ago
  Depends on what you mean by solid. It uses LLVM for all the codegen and perf is generally in line with C++. The core ideas around traits/borrowing/inference/mutablility have been stable for a while. What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works got changed earlier this week. If you're interested in writing libraries for a new ecosystem, now is the time to get into the language. I've tried to get into Rust a couple times since the 0.4 timeframe and I couldn't keep up with the pace of change. My current attempt started at 0.11 and while there are steady chanes, I've found them to be manageable. If you want to have idioms and ecosystem relatively settled, hold off until the 1.2 or 1.3 timeframe (6 week cycles). I say this because a lot of the current RFCs are split between things that need to happen before 1.0 and things that need to happen after. This generally means the base functionality in-place for 1.0 with the sugar/convenience stuff to come later. I expect it'll take a few cycles after 1.0 before Rust settles into what most people are thinking when they think stable.
burntsushi 12y ago
> A good (trivial) example was a great command parsing library just doesn’t exist yet. There is a Docopt implementation in Rust[1], which is used by Cargo. It tracks master and is regularly updated. Interestingly, I've found people either love or hate Docopt, so maybe you knew about it but don't like it. :P /shameless plug [1] - https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs
- TheHydroImpulse 12y ago
  I've had a really good experience using that library in Rust. It just works without much code or hassle.
- Ygg2 12y ago
  Yeah, that whole part got the me the wrong way. Docopt is as far as I know the best. Also rust comes with a simpler getopt. It is broken now, but with the collection reform landing, what isn't broken.
  - burntsushi 12y ago
    It was only broken because I merged a PR that updated it to Rust master before the nightly was updated on Travis. :-) It's passing now that Travis updated to the new nightly. (But yup, it was collection reform.)
alkonaut 12y ago
If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSCHS0 https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.
- Dewie 12y ago
  I liked Rob Pike's driveby comment - programmers these days...
  - jfb 12y ago
    ... have come to expect some advances in programming languages from the last 50 years of research?
    - deleted 12y ago
      [deleted]
    - Dewie 12y ago
      Programming Language Research is Irrelevant, or at least in Pike's world.
- kyrra 12y ago
  There are a lot of comments in that thread, is there anything specific you think stands out? Some of Ian's initial comments were saying that they are being very very careful about what gets added to the language. Also, at this point the language syntax itself is basically locked. And from everything I've seen, they are focusing more on the runtime and tooling before they make any serious changes to the code language.
  - exacube 12y ago
    I think Ian (who works on Go) summed it up nicely. To paraphrase: yes map/reduce is useful but it's another built-in generic so it adds a lot of complexity and it's not worth the trade-off. This rounds back into Go's generics debate. If they give in with implementing map/reduce, they might as well start implementing some form on generics. I think Go is for people who are in-line with the golang crew's views on language design. For the rest, use any other strongly typed language that has sort form of type-abstraction/generics (which pretty much they all do).
Animats 12y ago
The article is a lightweight analysis by someone who writes small programs. He does get that, for Rust, "If the compiler accepted my input, it ran — fast and correctly. Period." That's was a common experience with the very tight languages, such as Ada and the various Modulas. It's been a while since a language that tight was mainstream. We need one now, badly. Go isn't bad for writing routine server-side web stuff that has to scale and run fast, which is why Google created it. Go is a modern language with a dated feel. No user-defined objects, just structs. No generics or templates. It was designed by old C programmers, and it looks it. Go has generic objects - maps and channels - and syntax for creating object instances - "Make". Only the built-in generics are available, though; you can't write new ones. Go's "reflection" package thus tends to be overused to work around the lack of generic. This means doing work for each data item at run time for things that could have been done once at compile time. "interface{}" (Go's answer to type Any from Visual Basic) tends to be over-used. Go (especially "Effective Go") has a lot of hand-waving about parallelism. Go's mantra is "share by communicating, not by sharing", but all the examples have data shared between threads. The channels are just used as a locking mechanism. Race conditions are possible in Go, and there's an exploit which uses this. (That's why Google AppEngine limits Go programs to single threads.) Go doesn't use immutability much, which is a lack in a shared-data parallel language with garbage collection. If you can make data immutable, you can safely share it, which is a way to avoid copying without introducing race conditions. Rust, like Erlang, takes a much harder line on enforcing separation and locking. I haven't used Rust myself yet, so I can't say more on what it's like to use it. My hope is that Rust will provide a solution to buffer overflows in production code. After 35 years of C and its discontents, it's time to move on. I really hope the Rust crowd doesn't fuck up.
- deleted 12y ago
  [deleted]
- eridius 12y ago
  I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I'm hoping that as Swift evolves over time, it will slowly become that sort of language. Right now it's pretty hard to write any real-world code in Swift that doesn't work with the Cocoa frameworks, and the Cocoa frameworks are typed in an objective-c-compatible way (even if new frameworks are written in Swift they'll need to maintain obj-c compatibility), which means you don't get the strong typing that's necessary for this property. Pure Swift code has the potential to behave like this, although you probably need to avoid the ImplicitlyUnwrappedOptional feature (the ! suffix on types), which of course primarily exists for ease of obj-c integration anyway. I'm bringing up Swift because, with Apple's backing, it's very quickly becoming a "mainstream" language. I put that in quotes because it is only usable with iOS and OS X programming (for now at least), but iOS is large enough that obj-c should be considered a mainstream language despite the fact that almost nobody outside of iOS/OS X uses it, and therefore as Swift supplants obj-c it becomes appropriate to call it mainstream. Regarding parallelism, I've been in love with Rust for a long time now, and one of the biggest reasons is because Rust makes parallelism safe. As an iOS/OS X programmer by trade, I think thread safety is far and away the biggest elephant in the room. Despite the fact that we've known that multithreading is the future for years, and despite the wonderful Grand Central Dispatch library on iOS/OS X, most programmers still think in a single-threaded mindset and don't even consider how their code should operate if invoked on a separate thread. This was one of my bugaboos with Go back when I was using that language (which was from the day it was announced right up until I discovered Rust, though admittedly my usage was in hobby projects and nothing serious). I applaud the fact that Go has a data race detector now, which I used to finally uncover a lurking data race that plagued one of my programs for months (and which was ultimately caused by the Go library using two goroutines where I expected one, and therefore data which I expected to be on a single goroutine was actually mutated from two goroutines simultaneously). But I think Rust is absolute proof that a modern language can be designed such that data races are prohibited at compile-time without sacrificing any language flexibility.
exacube 12y ago
I think to properly write a language comparison, you need to have extensively used both languages and with multiple use cases. For example: I've recently attempted writing a small service in Go and it only took a few hours for me to figure out how weak a language could be without some sort of type-abstraction or generics: I had to implement a FindValueInArray() twice for two different types. This should be a big issue in any respectable language. (I mostly like Go otherwise though!)
- freyr 12y ago
  I'm confused by your comment. Does it take extensive experience and multiple use cases to assess a language? Or a couple hours writing a small service?
  - exacube 12y ago
    The former. I'm not arguing that I have extensive experience or had multiple use cases (I had neither), but I am saying these very serious issues started to pop up just a couple of hours in. I'm surprised there is nothing here about these seemingly oft-occurring issues in this article, and makes me feel like the author hasn't used the language enough (again, not that I have).
- alkonaut 12y ago
  True, but you can assess how approachable a language is by simply approaching it. This is useful information. You could even argue that experience would disqualify you from reviewing using that angle!
  - exacube 12y ago
    hm.. but why would anyone want to read how approachable Go is for beginners on HN? Do all negative experiences disqualify anyone from publishing a comparison? which negative experiences qualify?
- NateDad 12y ago
  What is to "implement" in FindValueInArray? for _, x := range foo { if someCriteria(x) { // do something } }
freyr 12y ago
It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is "amazing" at anything, its usually cited as a language of choice for (1) networked systems, and (2) large yet maintainable systems. I'm not sure his initial foray into the language would have provided enough experience to accurately assess those merits one way or the other. Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: (EDIT: removed pejoratives) if a programmer desired to switch from C/C++ to another language but hasn't by now, why not? 1. They require the performance benefits of C/C++ (and as humanrebar pointed out, manual memory management). 2. They're tied to legacy code, with too little incentive to switch. 3. They have an organizational mandate. Any programmer who wasn't subject to the above constraints and wanted to switch could have done so before Go showed up on the scene. And if a programmer uses C or C++ solely because the above constraints, Go isn't likely to change that. Rust may have a better chance of converting C++ programmers, if it offers the performance and control demanded by programmers who are using C++ by necessity. It will be interesting to see if people migrating from Python/Ruby to a higher performance language will choose Go or Rust in the future. Kind of like the OP, I like Go but I'm excited about Rust.
- agwa 12y ago
  > Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: who is still using C/C++ in 2014, and why? Here are some ideas: I (and many others) "still" use C++ (which is a very different language from C) in 2014 because it's an extremely powerful language that's still evolving and has produced many innovations that haven't been replicated by many other languages, such as destructors/RAII, strong compile-time type checking, generic programming, and ownership/move semantics. To me, Go looks like an update of C that has ignored all the good innovations of C++. It has no destructors, uses GC instead of ownership/move semantics, and requires runtime type checking instead of providing generics. I see it as a big step backward from C++, so unlike Rob Pike I'm not surprised it hasn't attracted C++ programmers. Rust, on the other hand, has taken many of the good parts from C++ and developed them even further, without the baggage of C++. Thus, while I haven't coded any Rust yet, it looks like a step forward from C++ and has me quite excited.
eridius 12y ago
Not a bad write-up. The Rust code snippets can be slimmed down very slightly though. Here's main(): fn main() { let args = os::args(); let washed_args = args.iter().map(|arg| arg.as_slice()).collect::<Vec<_>>(); match washed_args.as_slice() { [_, "review", opts..] => review(opts), _ => usage() } } although I might actually suggest the alternative approach: fn main() { let mut args = os::args().into_iter(); args.next(); // skip program name match args.next().map(|s| s.as_slice()) { Some("review") => review(args.collect::<Vec<_>>()), _ => usage() } } (this approach requires `review()` to take a `Vec<String>` instead of a `&[&str]`, but that's not a difficult change, and we could fix it using a second line of code if we wanted but at the cost of introducing a new allocation, like the original code does) For review() I'd suggest changing the original code: let cwd = os::getcwd(); let have_dot_git = have_dot_git(cwd.clone()); let dot_git_dir: &Path = match have_dot_git.as_ref() { Some(path) => path, None => { panic!("{} does not appear to have a controlling .git directory; you are not in a git repository!", cwd.display()) }, }; to the following: let cwd = os::getcwd(); let dot_git_dir = have_dot_git(&cwd).expect(format!("{} does not appear to have a controlling .git directory; you are not in a git repository!", cwd.display()).as_slice()); This actually leaves `dot_git_dir` as a `Path` instead of a `&Path`, but I think that's better anyway. It also requires `have_dot_git()` to take a `&Path` instead of (what I assume it takes now,) a `Path`, which is an appropriate change as there's no need for cloning the path.
- eridius 12y ago
  It's also worth pointing out that if you enable the `slicing_syntax` feature gate then all the `.as_slice()` calls can turn into the suffix operator `[]`.
- dbaupp 12y ago
  Your expect version changes behaviour: it does the allocation and string formatting unconditionally even if `have_dot_git(&cwd)` is `Some`. It is probably not a problem for this since the other operations are significantly more expensive, but it can be a gotcha if used inside a loop.
fideloper 12y ago
tl;dr: Guy who knows Rust better than Go prefers Rust over Go.
- oldmanjay 12y ago
  Since it's clear to anyone who read the post that this is an incorrect kneejerk summary, I am dying to know why? Do you feel an emotional attachment to go and have a deep-seated need to preemptively defend it even when no one is attacking it?
twtwtaway 12y ago
Comparing Go and Rust doesn't feel right. They are obviously designed for solving different kind of problems. Go is a simple language, maybe even too simple for my taste. But simplicity is its greatest strength. And I can understand people who would prefer Go as their go-to language for dealing with specific kind of problems. Go is a boring language but gets you where you want to be in a short time and without much suprises. Rust, on the other hand is designed for systems programming. It's got some nice features but it's also a lot more complex language than Go. I don't want to fight compiler all the time. Sometimes I don't need that kind of safety.
- bjz_ 12y ago
  I agree that it doesn't feel quite right, but this post seems to be more of a personal exploration of going from some ignorance of both languages, to having a better understand of where each language sits. His concluding section is nicely written.
toomanymike 12y ago
I wonder what actor library the author is using with Rust. Given the status of github issues like https://github.com/rust-lang/rust/issues/3573 https://github.com/rust-lang/rust/issues/3573 I thought there weren't any real options.
- steveklabnik 12y ago
  It's more that Rust _used_ to have that style of concurrency, but it has changed over the last year. That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.
bsaul 12y ago
I'm surprised at the paragraph about rust having erlang style actor based parallellism... From what i've read, parallel programming was still heavily a work in design in Rust ( had a very recent discussion on using rust for http server side coding on HN whith people confirming this to me). golang goroutine let me built a standalone binary with embedded https server and websocket support. Would Rust be able to do that even at 1.0 release without relying on low-level C library wrappers ?
- steveklabnik 12y ago
  Yeah, "Erlang style-actor" isn't exactly accurate anymore. A while ago, this was true, but it's not exactly true today. That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.
  - bsaul 12y ago
    Ok. I'm not a language designer so correct if i'm wrong, but doing anything remotely looking like actors implies being able to do m:n threading in some way, which rust decided not to do recently. Correct ?
    - dragonwriter 12y ago
      Not really. You can do actor model with 1:N or 1:1 threading. With 1:N you get actor-model concurrency without native-thread overhead per actor, but no parallelism; with 1:1 you get parallelism but you have native thread overhead for each actor. With M:N, you can limit your native thread overhead to whatever is useful given available hardware, while scaling out to as many actors as you need. OTOH, M:N and 1:N both require you to do more to handle actors in the runtime, which potentially adds overhead to everything, M:N may not always be a win compared to 1:1.
    - steveklabnik 12y ago
      I am not clear that "Actors" directly implies M:N threading. Rust's spawn() makes a 1:1 thread, but you still talk between threads with channels, and you can't get shared memory without going through an Arc<Mutex<T>> or something similar. > which rust decided not to do recently. It's more subtle than this. Rust's I/O libraries are being re-done to remove the M:N stuff, yes, but Rust is low enough that I/O is just a library; anyone can implement alternate I/O stuff, it's not privileged other than coming with Rust. See mio as an example of an in-progress alternative.
agapos 12y ago
I have seen it for many cases how Rust's strictness (no null pointers and other things) has a positive effect on safety, but I am curious: does this also affect reliability or stability to the better? I would like to know the thoughts of someone experienced with Rust.

352 points by mperham 12y ago

I was worried when I saw "I decided to write a little Rust and, because everyone in my world is seems swoony over it, Go." That's a pretty bad reason for using a language and usually leads to some pretty ridiculous criticism. This post was not that, I think they nailed a lot of the good and bad things about Go, in fact, they could have been a lot more harsh. There is a depth lacking in just checking out a language in this way though as there's no evaluation of some of the larger reasons Go exists, like concurrency and and fast compile times. Then again, most people probably don't even need/care about these.

ryandvm 12y ago
Hmm. Learning a language/framework that is exploding in popularity is probably one of the best things a dev can do to stay relevant (read: employed). Hell, very few of us would be using Javascript if it weren't for it's ubiquity/community/popularity. I sure as hell am not using it because it's a well designed language.
- codezero 12y ago
  I agree that it's great to learn a language, I was thinking of this as more of an exercise to generate a good post, but it's probably more reasonable to assume he really wanted to learn Go :P
- bad_user 12y ago
  Quite the contrary, learning a language because it is exploding in popularity is a nice way to ensure that you'll end up being abused, poorly paid and irrelevant. You can't possibly find a worse reason for learning a new language. On Javascript you're missing the causality. Some people are learning Javascript because it is popular of course, because they've read on some forum that learning popular things gets them hired, but those people are totally uninteresting in the pool of developers that learned Javascript because they had shit to do and things to build and Javascript was the answer. There's a big difference between learning X because you want to make your job easier, because you want to build things in a new way, because you want exposure to new ways of thinking, because there isn't an alternative to what you're trying to do, etc... and learning X because that's fashionable. In the former case, it's pretty much a gamble but you might actually get something out of it. In the later case all you're earning is the ability to slap another keyword on a resume that only mediocre HR people care about, being actually a time waist as it's keeping you from learning things that might actually be of interest for the things you're trying to accomplish (other than getting a shitty job of course). Just as people that learned PHP or Java back in the day found out, learning for the sake of getting a job is a sure way to land you a shitty and boring job in which you are replaceable cog. Managers love popular languages and frameworks, of course they do. And the interesting jobs that are out there, that make people happy and that pay well - well, let me tell you, those companies aren't looking for keywords on your resume, but for things that you've actually built. And after some years from now, when you'll be over 40, you'll find yourself either a manager that does LinkedIn searches for keywords, or an obsolete developer that can't find a job because everything you've learned is obsolete and you waisted your time in learning syntax, instead of learning new abstractions, algorithms and mathematics - you know, stuff that never gets old.
  - ChrisGaudreau 12y ago
    Personally, I like to learn any language, regardless of how popular it is. It's just fun.
    - holoway 12y ago
      Yeah, I was doing this for fun. I'm pretty secure in my day job. :)
  - bjz_ 12y ago
    > Quite the contrary, learning a language because it is exploding in popularity is a nice way to ensure that you'll end up being abused, poorly paid and irrelevant. Because I had the good fortune of starting with Rust early, I now have several foundational libraries under my belt in the Rust ecosystem. This has certainly been of great interest in interviews, and might just lead to me landing a pretty 'hip' internship over the Australian summer. Of course it won't be in Rust, but it's better than being at a hum-drum corporate placement. Being a pioneer definitely sets you apart from other candidates, and also culls the pack of potential employers to those that value curiosity and initiative, and actually care about exploring new ideas.
  - LunaSea 12y ago
    By learning new programming languages or frameworks you stand out from the crowd. Guess who's going to get a job: A) The fool who just learned JavaScript and Angular.js B) The university student who only knows Java The answer will be (A) every single time because companies don't have the time to train people for months.
    - codezero 12y ago
      This hasn't been my experience in practice but I guess it depends on what kinds of companies you've worked with. Everywhere I've worked, they hire engineers based on a lot of factors, and it has been more often the case that they'd go for someone who knows a different stack really well, than someone who knows all the newest stacks.
    - 12y ago
deleted 12y ago
[deleted]
melling 12y ago
I'm under the impression that Rust isn't near done and ready for production use. Go has been ready for a couple years. Rust could be 10 times better but I'm not going to touch it until they ship 1.0.
- andolanra 12y ago
  The plan is to release 1.0 around the end of the year. In that sense, Rust isn't done, but it is near done.
  - TheHydroImpulse 12y ago
    Unlike other languages that are "done" at 1.0, Rust will still be improving and iterating. 1.0 defines a backwards-compatible release that you can depend on but the language won't be "done". "It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving. We will release new versions of Rust on a regular, frequent basis, and we hope that people will upgrade just as regularly. But for that to happen, those upgrades need to be painless." [0] [0]: http://blog.rust-lang.org/2014/10/30/Stability.html http://blog.rust-lang.org/2014/10/30/Stability.html
    - melling 12y ago
      Go updates twice a year, which is actually a lot. I don't think a release every 6 weeks for Rust is a good idea. That'll never fly for enterprise software. Heck, for some companies the Java upgrade cycle is too fast.
      - pjmlp 12y ago
        At Java ONE MongoDB developers mentioned they have clients still running on Java 5, thus they cannot fully embrace Java 8 for the time being.
    - NateDad 12y ago
      The stability guarantee given by rust is what scares me the most about starting up with it. "with a minimum of hassle" is really squishy language that is not at all comforting. Compared to the Go 1.0 promise: Your code will not break, period.

peterevans 12y ago

I really like the idea of testing a language by writing a small command-line utility with it, even one that -- as the author mentioned -- already exists. Way back when, when I first was learning C, I didn't comprehend it very well. I was OK with it. A friend gave me some CDs with FreeBSD on it, one with the OS, and one with program sources. It was that source code which really opened my eyes, and you could digest small programs (like chmod) and see, you know, this is working, production code, and it's not hard, and you can do this.

jff 12y ago

"Where line 9 there just blindly assumes the regex found a match, and causes quite the run-time error message." You blindly assume the regex found a match, because you ignored the part of the docs where they tell you how to check for a match: http://golang.org/pkg/regexp/#Regexp.FindStringSubmatch http://golang.org/pkg/regexp/#Regexp.FindStringSubmatch

sswezey 12y ago
The article didn't say there was no way to check, just that the compiler does not enforce checking. Rust's type system requires that all possible paths are accounted for when trying to extract the value from the option.
humanrebar 12y ago
The point is that Rust gives you a compiler error while Go assumes your sloppy code is intentional or unimportant.

jeorgun 12y ago

Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. So far as I know the fail! macro still exists in Rust. Edit: Evidently I should have put a /s at the end of that first sentence. I know what the idea behind compile-time checking is, but I don't see that the given example actually illustrates it.

Dewie 12y ago
> Does 'the language prevents errors at compile time' really mean 'better function signatures in the standard library'? Because that's all I'm getting out of the regex example given. Of course any function can be forced to crash by inserting some crash-inducing code into the function. You can always make a function that assumes that value is of a certain form, and crashes the program if it is not (like unwrap for extracting a value from an Option, or crashing if it there is no value). In order to have "code that works if it compiles" (comparatively speaking; often used as an exaggeration), you have to have the discipline to use the facilities that the language provides you. I guess a language would need some kind of totality checker in order to make sure that you couldn't make function diverge in some way. Like for example Idris has. Rust also has the `!` type, aka bottom, for marking functions that diverge. > So far as I know the fail! macro still exists in Rust. What should that do? Crash the program? If so it should have been renamed to something like `panic!` now, since "fail" now is associated with Error types, while "panic" is associated with crashing the program/exceptions.
- vertex-four 12y ago
  fail! has been renamed to panic! for much that reason.
- masklinn 12y ago
  > What should that do? Crash the program? If so it should have been renamed to something like `panic!` now It crashes the current task (thread/process), not the whole program, and has in fact been renamed panic! recently: https://github.com/rust-lang/rust/pull/17894 https://github.com/rust-lang/rust/pull/17894

programminggeek 12y ago

Having spent a little time with Go, I ended up feeling like it was both better and worse than Ruby. In many ways it's many of the things that I want from a language - static typing, fast complier, pretty sensible defaults and so on. A lot of things I wish Ruby did, Go does great. I think Go does really well in tooling, but it doesn't feel as great in syntax or language features that I would really like. The two big ones I wish Go had were named parameters on functions, and immutable data structures. It's probably a blub paradox thing, but my ideal language has immutable data structures and named function parameters. Kotlin, Scala, and Swift all kind of nailed these features, but Go has not. For me, named parameters and a little verbosity goes a long way to allow me to communicate intent in my code. Immutability allows me to have a built in sense of safety that once the data is set, it stays that way. In my experience, a whole class of problems goes away when you have those two features (alongside the many other features we'd expect form a language like Go). What I felt from Go is that a year ago when I was playing with it, that they didn't care much about either of those two features, which is fine, but it keeps go from being my ideal language. Swift I wish was a bit more general purpose, Kotlin and Scala don't compile as fast as Go, and Ruby doesn't have a compiler to do some of the checking I wish it would. Go's fast compile times with something like Ruby's syntax and a feature set similar to Kotlin/Swift would be darn near perfect. For me, there is no perfect language.

zem 12y ago
the thing that has got me excited about learning go some day is that it's supposed to be really good at cross-compiling code into small, standalone binaries for the three major platforms (linux, windows, osx). haxe is another language on my radar for much the same write-once-deploy-all-over-the-place reason.
- untothebreach 12y ago
  Rust has that too. You can cross-compile binaries that will run on any platform that LLVM supports.
  - zem 12y ago

amelius 12y ago

How mature is Rust and its compiler actually at this moment? Is it in a state ready to replace C++? Edit: Also, I missed a good overview of features in one language and lacking in the other. In that respect, I find the wikipedia page [1] deeply broken, but that aside. [1] http://en.wikipedia.org/wiki/Comparison_of_programming_languages http://en.wikipedia.org/wiki/Comparison_of_programming_langu...

crazypyro 12y ago
From my experience, not even close, if only because the ecosystem around it has to continuously update their own resources/libraries or risk being left behind every new patch because the language is not even at a stable 1.0 point. Trying to figure out new things tends to be an exercise in reading obsolete code examples and then asking for someone in #rust on irc.mozilla.org to translate. Stuff that gets deprecated isn't well documented in my experience and one of the best resources I came across (Rust by Example) also contains a lot of out of date or deprecated features. Obviously, this is a side-effect of a rapidly evolving language that is still in pre-1.0 phase, but anyone going into it should be aware of the potential breakage that tends to happen at a fairly high clip at the moment.
grayrest 12y ago
Depends on what you mean by solid. It uses LLVM for all the codegen and perf is generally in line with C++. The core ideas around traits/borrowing/inference/mutablility have been stable for a while. What's not stable is everything around the core ideas. Many things are in flight at the moment in anticipation of 1.0 stability. The core collection libraries had a major refactor land last night. How error handling works got changed earlier this week. If you're interested in writing libraries for a new ecosystem, now is the time to get into the language. I've tried to get into Rust a couple times since the 0.4 timeframe and I couldn't keep up with the pace of change. My current attempt started at 0.11 and while there are steady chanes, I've found them to be manageable. If you want to have idioms and ecosystem relatively settled, hold off until the 1.2 or 1.3 timeframe (6 week cycles). I say this because a lot of the current RFCs are split between things that need to happen before 1.0 and things that need to happen after. This generally means the base functionality in-place for 1.0 with the sugar/convenience stuff to come later. I expect it'll take a few cycles after 1.0 before Rust settles into what most people are thinking when they think stable.

burntsushi 12y ago

> A good (trivial) example was a great command parsing library just doesn’t exist yet. There is a Docopt implementation in Rust[1], which is used by Cargo. It tracks master and is regularly updated. Interestingly, I've found people either love or hate Docopt, so maybe you knew about it but don't like it. :P /shameless plug [1] - https://github.com/docopt/docopt.rs https://github.com/docopt/docopt.rs

TheHydroImpulse 12y ago
I've had a really good experience using that library in Rust. It just works without much code or hassle.
Ygg2 12y ago
Yeah, that whole part got the me the wrong way. Docopt is as far as I know the best. Also rust comes with a simpler getopt. It is broken now, but with the collection reform landing, what isn't broken.
- burntsushi 12y ago
  It was only broken because I merged a PR that updated it to Rust master before the nightly was updated on Travis. :-) It's passing now that Travis updated to the new nightly. (But yup, it was collection reform.)

alkonaut 12y ago

If you are considering Go, or just want a good laugh, just read discussions where higher order functions are discussed. Or for that matter, generics. Here is a gem: https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSCHS0 https://groups.google.com/forum/#!topic/golang-nuts/RKymTuSC... There's a chance you'll laugh at the people dismissing higher order functions as nonsense, in which case Go might not be for you. This is a good test of whether you want to try it out or not.

Dewie 12y ago
I liked Rob Pike's driveby comment - programmers these days...
- jfb 12y ago
  ... have come to expect some advances in programming languages from the last 50 years of research?
  - deleted 12y ago
    [deleted]
  - Dewie 12y ago
    Programming Language Research is Irrelevant, or at least in Pike's world.
kyrra 12y ago
There are a lot of comments in that thread, is there anything specific you think stands out? Some of Ian's initial comments were saying that they are being very very careful about what gets added to the language. Also, at this point the language syntax itself is basically locked. And from everything I've seen, they are focusing more on the runtime and tooling before they make any serious changes to the code language.
- exacube 12y ago
  I think Ian (who works on Go) summed it up nicely. To paraphrase: yes map/reduce is useful but it's another built-in generic so it adds a lot of complexity and it's not worth the trade-off. This rounds back into Go's generics debate. If they give in with implementing map/reduce, they might as well start implementing some form on generics. I think Go is for people who are in-line with the golang crew's views on language design. For the rest, use any other strongly typed language that has sort form of type-abstraction/generics (which pretty much they all do).

Animats 12y ago

The article is a lightweight analysis by someone who writes small programs. He does get that, for Rust, "If the compiler accepted my input, it ran — fast and correctly. Period." That's was a common experience with the very tight languages, such as Ada and the various Modulas. It's been a while since a language that tight was mainstream. We need one now, badly. Go isn't bad for writing routine server-side web stuff that has to scale and run fast, which is why Google created it. Go is a modern language with a dated feel. No user-defined objects, just structs. No generics or templates. It was designed by old C programmers, and it looks it. Go has generic objects - maps and channels - and syntax for creating object instances - "Make". Only the built-in generics are available, though; you can't write new ones. Go's "reflection" package thus tends to be overused to work around the lack of generic. This means doing work for each data item at run time for things that could have been done once at compile time. "interface{}" (Go's answer to type Any from Visual Basic) tends to be over-used. Go (especially "Effective Go") has a lot of hand-waving about parallelism. Go's mantra is "share by communicating, not by sharing", but all the examples have data shared between threads. The channels are just used as a locking mechanism. Race conditions are possible in Go, and there's an exploit which uses this. (That's why Google AppEngine limits Go programs to single threads.) Go doesn't use immutability much, which is a lack in a shared-data parallel language with garbage collection. If you can make data immutable, you can safely share it, which is a way to avoid copying without introducing race conditions. Rust, like Erlang, takes a much harder line on enforcing separation and locking. I haven't used Rust myself yet, so I can't say more on what it's like to use it. My hope is that Rust will provide a solution to buffer overflows in production code. After 35 years of C and its discontents, it's time to move on. I really hope the Rust crowd doesn't fuck up.

deleted 12y ago
[deleted]
eridius 12y ago
I could not agree more with your first paragraph. The only other language I've used that I've had that experience with was Haskell, and while there are good arguments to be made for using Haskell in production, it should be obvious that's not a language that will ever become mainstream. I'm hoping that as Swift evolves over time, it will slowly become that sort of language. Right now it's pretty hard to write any real-world code in Swift that doesn't work with the Cocoa frameworks, and the Cocoa frameworks are typed in an objective-c-compatible way (even if new frameworks are written in Swift they'll need to maintain obj-c compatibility), which means you don't get the strong typing that's necessary for this property. Pure Swift code has the potential to behave like this, although you probably need to avoid the ImplicitlyUnwrappedOptional feature (the ! suffix on types), which of course primarily exists for ease of obj-c integration anyway. I'm bringing up Swift because, with Apple's backing, it's very quickly becoming a "mainstream" language. I put that in quotes because it is only usable with iOS and OS X programming (for now at least), but iOS is large enough that obj-c should be considered a mainstream language despite the fact that almost nobody outside of iOS/OS X uses it, and therefore as Swift supplants obj-c it becomes appropriate to call it mainstream. Regarding parallelism, I've been in love with Rust for a long time now, and one of the biggest reasons is because Rust makes parallelism safe. As an iOS/OS X programmer by trade, I think thread safety is far and away the biggest elephant in the room. Despite the fact that we've known that multithreading is the future for years, and despite the wonderful Grand Central Dispatch library on iOS/OS X, most programmers still think in a single-threaded mindset and don't even consider how their code should operate if invoked on a separate thread. This was one of my bugaboos with Go back when I was using that language (which was from the day it was announced right up until I discovered Rust, though admittedly my usage was in hobby projects and nothing serious). I applaud the fact that Go has a data race detector now, which I used to finally uncover a lurking data race that plagued one of my programs for months (and which was ultimately caused by the Go library using two goroutines where I expected one, and therefore data which I expected to be on a single goroutine was actually mutated from two goroutines simultaneously). But I think Rust is absolute proof that a modern language can be designed such that data races are prohibited at compile-time without sacrificing any language flexibility.

exacube 12y ago

I think to properly write a language comparison, you need to have extensively used both languages and with multiple use cases. For example: I've recently attempted writing a small service in Go and it only took a few hours for me to figure out how weak a language could be without some sort of type-abstraction or generics: I had to implement a FindValueInArray() twice for two different types. This should be a big issue in any respectable language. (I mostly like Go otherwise though!)

freyr 12y ago
I'm confused by your comment. Does it take extensive experience and multiple use cases to assess a language? Or a couple hours writing a small service?
- exacube 12y ago
  The former. I'm not arguing that I have extensive experience or had multiple use cases (I had neither), but I am saying these very serious issues started to pop up just a couple of hours in. I'm surprised there is nothing here about these seemingly oft-occurring issues in this article, and makes me feel like the author hasn't used the language enough (again, not that I have).
alkonaut 12y ago
True, but you can assess how approachable a language is by simply approaching it. This is useful information. You could even argue that experience would disqualify you from reviewing using that angle!
- exacube 12y ago
  hm.. but why would anyone want to read how approachable Go is for beginners on HN? Do all negative experiences disqualify anyone from publishing a comparison? which negative experiences qualify?
NateDad 12y ago
What is to "implement" in FindValueInArray? for _, x := range foo { if someCriteria(x) { // do something } }

freyr 12y ago

It's not clear how much experience the author really acquired with each language, and whether that experience was sufficient experience to justify his statement: Go felt that way to me — it was good at everything, but nothing grabbed me and made me feel excited in a way I wasn’t already about something else in my ecosystem. He's apparently using each language to write relatively small command-line utilities. If Go is "amazing" at anything, its usually cited as a language of choice for (1) networked systems, and (2) large yet maintainable systems. I'm not sure his initial foray into the language would have provided enough experience to accurately assess those merits one way or the other. Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: (EDIT: removed pejoratives) if a programmer desired to switch from C/C++ to another language but hasn't by now, why not? 1. They require the performance benefits of C/C++ (and as humanrebar pointed out, manual memory management). 2. They're tied to legacy code, with too little incentive to switch. 3. They have an organizational mandate. Any programmer who wasn't subject to the above constraints and wanted to switch could have done so before Go showed up on the scene. And if a programmer uses C or C++ solely because the above constraints, Go isn't likely to change that. Rust may have a better chance of converting C++ programmers, if it offers the performance and control demanded by programmers who are using C++ by necessity. It will be interesting to see if people migrating from Python/Ruby to a higher performance language will choose Go or Rust in the future. Kind of like the OP, I like Go but I'm excited about Rust.

agwa 12y ago
> Rob Pike once expressed surprise that people migrating to Go weren't C++ programmers, but Ruby/Python/etc. programmers who needed more performance. That leads you to wonder: who is still using C/C++ in 2014, and why? Here are some ideas: I (and many others) "still" use C++ (which is a very different language from C) in 2014 because it's an extremely powerful language that's still evolving and has produced many innovations that haven't been replicated by many other languages, such as destructors/RAII, strong compile-time type checking, generic programming, and ownership/move semantics. To me, Go looks like an update of C that has ignored all the good innovations of C++. It has no destructors, uses GC instead of ownership/move semantics, and requires runtime type checking instead of providing generics. I see it as a big step backward from C++, so unlike Rob Pike I'm not surprised it hasn't attracted C++ programmers. Rust, on the other hand, has taken many of the good parts from C++ and developed them even further, without the baggage of C++. Thus, while I haven't coded any Rust yet, it looks like a step forward from C++ and has me quite excited.

eridius 12y ago

Not a bad write-up. The Rust code snippets can be slimmed down very slightly though. Here's main(): fn main() { let args = os::args(); let washed_args = args.iter().map(|arg| arg.as_slice()).collect::<Vec<_>>(); match washed_args.as_slice() { [_, "review", opts..] => review(opts), _ => usage() } } although I might actually suggest the alternative approach: fn main() { let mut args = os::args().into_iter(); args.next(); // skip program name match args.next().map(|s| s.as_slice()) { Some("review") => review(args.collect::<Vec<_>>()), _ => usage() } } (this approach requires `review()` to take a `Vec<String>` instead of a `&[&str]`, but that's not a difficult change, and we could fix it using a second line of code if we wanted but at the cost of introducing a new allocation, like the original code does) For review() I'd suggest changing the original code: let cwd = os::getcwd(); let have_dot_git = have_dot_git(cwd.clone()); let dot_git_dir: &Path = match have_dot_git.as_ref() { Some(path) => path, None => { panic!("{} does not appear to have a controlling .git directory; you are not in a git repository!", cwd.display()) }, }; to the following: let cwd = os::getcwd(); let dot_git_dir = have_dot_git(&cwd).expect(format!("{} does not appear to have a controlling .git directory; you are not in a git repository!", cwd.display()).as_slice()); This actually leaves `dot_git_dir` as a `Path` instead of a `&Path`, but I think that's better anyway. It also requires `have_dot_git()` to take a `&Path` instead of (what I assume it takes now,) a `Path`, which is an appropriate change as there's no need for cloning the path.

eridius 12y ago
It's also worth pointing out that if you enable the `slicing_syntax` feature gate then all the `.as_slice()` calls can turn into the suffix operator `[]`.
dbaupp 12y ago
Your expect version changes behaviour: it does the allocation and string formatting unconditionally even if `have_dot_git(&cwd)` is `Some`. It is probably not a problem for this since the other operations are significantly more expensive, but it can be a gotcha if used inside a loop.

fideloper 12y ago

tl;dr: Guy who knows Rust better than Go prefers Rust over Go.

oldmanjay 12y ago
Since it's clear to anyone who read the post that this is an incorrect kneejerk summary, I am dying to know why? Do you feel an emotional attachment to go and have a deep-seated need to preemptively defend it even when no one is attacking it?

twtwtaway 12y ago

Comparing Go and Rust doesn't feel right. They are obviously designed for solving different kind of problems. Go is a simple language, maybe even too simple for my taste. But simplicity is its greatest strength. And I can understand people who would prefer Go as their go-to language for dealing with specific kind of problems. Go is a boring language but gets you where you want to be in a short time and without much suprises. Rust, on the other hand is designed for systems programming. It's got some nice features but it's also a lot more complex language than Go. I don't want to fight compiler all the time. Sometimes I don't need that kind of safety.

bjz_ 12y ago
I agree that it doesn't feel quite right, but this post seems to be more of a personal exploration of going from some ignorance of both languages, to having a better understand of where each language sits. His concluding section is nicely written.

toomanymike 12y ago

I wonder what actor library the author is using with Rust. Given the status of github issues like https://github.com/rust-lang/rust/issues/3573 https://github.com/rust-lang/rust/issues/3573 I thought there weren't any real options.

steveklabnik 12y ago
It's more that Rust _used_ to have that style of concurrency, but it has changed over the last year. That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.

bsaul 12y ago

I'm surprised at the paragraph about rust having erlang style actor based parallellism... From what i've read, parallel programming was still heavily a work in design in Rust ( had a very recent discussion on using rust for http server side coding on HN whith people confirming this to me). golang goroutine let me built a standalone binary with embedded https server and websocket support. Would Rust be able to do that even at 1.0 release without relying on low-level C library wrappers ?

steveklabnik 12y ago
Yeah, "Erlang style-actor" isn't exactly accurate anymore. A while ago, this was true, but it's not exactly true today. That said, Rust does encourage message passing by default, but also gives you the ability to safely do shared-memory concurrency if you need.
- bsaul 12y ago
  Ok. I'm not a language designer so correct if i'm wrong, but doing anything remotely looking like actors implies being able to do m:n threading in some way, which rust decided not to do recently. Correct ?
  - dragonwriter 12y ago
    Not really. You can do actor model with 1:N or 1:1 threading. With 1:N you get actor-model concurrency without native-thread overhead per actor, but no parallelism; with 1:1 you get parallelism but you have native thread overhead for each actor. With M:N, you can limit your native thread overhead to whatever is useful given available hardware, while scaling out to as many actors as you need. OTOH, M:N and 1:N both require you to do more to handle actors in the runtime, which potentially adds overhead to everything, M:N may not always be a win compared to 1:1.
  - steveklabnik 12y ago
    I am not clear that "Actors" directly implies M:N threading. Rust's spawn() makes a 1:1 thread, but you still talk between threads with channels, and you can't get shared memory without going through an Arc<Mutex<T>> or something similar. > which rust decided not to do recently. It's more subtle than this. Rust's I/O libraries are being re-done to remove the M:N stuff, yes, but Rust is low enough that I/O is just a library; anyone can implement alternate I/O stuff, it's not privileged other than coming with Rust. See mio as an example of an in-progress alternative.

agapos 12y ago

I have seen it for many cases how Rust's strictness (no null pointers and other things) has a positive effect on safety, but I am curious: does this also affect reliability or stability to the better? I would like to know the thoughts of someone experienced with Rust.