19 ms·

A friend of mine put it into good words: Go and Rust are two big conclusions, to big follow-ups to the C and C++ world. Go is an easy, fast, and very parallel

by tetha 10y ago

A friend of mine put it into good words: Go and Rust are two big conclusions, to big follow-ups to the C and C++ world. Go is an easy, fast, and very parallel language. Go is exactly what google needs, in all regards. It makes sense why Go exists, it makes sense why google is creating a way to migrate from python2 to go. Go is easier than hard C and Go is fast. Rust is the safe follow-up of C, but more familiar than Haskell, Caml and such. It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. But once rust runs, it works and there's a very very good chance it won't break. And that's also the reason why we'll probably build firewalls and hardened OS in derivatives of Haskell and Rust, and we'll build Google 2 and Facebook 2 in Go. And in my book, that's a good thing.

tatterdemalion 10y ago
> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. I could not disagree more! Rust is a great joy to program in. I would rather program in Rust than any other language. Rust is challenging for many people to learn. That is very different.
- zbobet2012 10y ago
  Language design is about trade-offs: The borrow checker and ownership model is a huge tradeoff. Even those very experienced in it still fight it from time to time. Go made a different trade, they chose GC. And GC _is_ easier. But it has computational overhead (well today anyway). Consider the cascading implications. Rust has a trait for Copy vs. Move types. This means every type has an implicit, and unknown behavior, on certain assignments: let v2 = v; println!("v is: {}", v); You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. But it is a trade-off. Go as a language must have a GC. It will never be suitable for certain tasks as a result. Go also has less compile time checking. This means faster compiles, quicker dev cycles but less compile time safety. Go chose easier here again. These trade-offs are what make rust seem "difficult" in comparison to go. I don't know if you can ever "fix" them.
  - tetha 10y ago
    Exactly this. If you're a massively parallel web service, who cares about some GCs, and who cares about crashing like 0.01% of all transactions? Monitor it, crash it, fix it, deploy it, move on. If you operated a nuclear reactor with this mentality, I'd be concerned. If you're operating acme.org with that mindset... godspeed?
    - AnimalMuppet 10y ago
      If you're running amazon.com with that mindset, 0.01% of transactions is millions of dollars a day.
      - woah 10y ago
        If you're running amazon.com, a project that takes 2 weeks longer to complete is hundreds of millions of dollars of lost sales.
  - vvanders 10y ago
    The thing is if you don't want to fight the borrow checker you can use RefCell and Arc/Rc. People are discouraged because then you lose a lot of architectural advantages that come with Rust but nothing is keeping you from writing unsafe{} and RefCell in the places where you know things are safe but can't formulate something that Rust understands.
    - empath75 10y ago
      I suspect that if you can't formulate it into something rust understands, you don't understand it well enough to know it's safe.
  - tatterdemalion 10y ago
    I am a member of the Rust language design team, I am very aware that language design is about trade offs. I find the ownership model has non-performance advantages in that I find it provides strong design pressure to factor my system well. I would not describe my experience as 'fighting' the borrow checker - I feel positively when the borrow checker sends me back to the drawing board, because it teaches me things about my system I had not properly comprehended. (There are areas where the borrow checker is overly conservative, but I never hit these in practice.) > You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. I'm sorry this is just silly. Here's some Go code: v2 := v + 1 You can't actually tell me if the above code compiles without consulting other parts of the code, because you don't know if `v` can be added to `1`. In Rust, type inference is only local to a function, so you will be able to determine from an actual compile-able code snippet whether or not that use after move is valid. Go also actually might not compile on the exact example you cited (translated to Go, of course) because that code contains an error if `v2` is never used after it is assigned. In general, you cannot reason about the correctness of incomplete code snippets. This is not specific to Rust.
- jandrese 10y ago
  I don't know, that is the kind of comment you used to hear from LISP programmers about how their program was really an elegant mathematical proof of its own correctness. That's great until you try to do some real world things with it and run into endless impedance mismatches. Rust isn't quite so far up its own butt, however the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile.
  - AlexCoventry 10y ago
    "Go is a blub language" was actually my hot take on this article.
  - AsyncAwait 10y ago
    > the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile. I don't think Servo and rustc itself are "toy example programs".
    - civility 10y ago
      Are Servo and rustc in the Rust documentation? Literate programming of some sort? Maybe you're replying to a different criticism. I've been through the Rust Documentation (doc.rust-lang.org) and Rust By Example (rustbyexample.com) several times now, and I have to jump on IRC to get answers to (what I think should be) some pretty simple questions.
      - AsyncAwait 10y ago
        If you think something important is missing from the docs, please open an issue. Steve Klabnik is very keen on making the documentation as useful as possible.
        civility 10y ago
tomjakubowski 10y ago
> It's a pain to get working, it sucks to program in, it requires so much though, it's just a bloody fucking fuck What sucks about programming in Rust? What makes it a bloody fucking fuck? I disagree on both these points: * Rust enums and move semantics make writing state machines a pure joy. Far nicer than in C++ or Go. * Pattern matching (both fallible + infallible) is very developer friendly. * Option<T> and Result<T,E> are totally brilliant. * It's trivial to add and version-fix a dependency on an external library with Cargo. * Rust's ownership and move semantics help you to write cleaner, easier to understand code.
- bmurphy1976 10y ago
  How does move semantics make writing state machines better? I can understand powerful enums, but I'm not familiar enough with move semantics to envision what you are referring to. Do you know of an example available somewhere?
  - bjz_ 10y ago
    It ensures that you consume a state at most once. You can kind of visualize state 'moving' through your functions - going in through the arguments and out through the returned value.
  - sinhpham 10y ago
    Example: http://insanitybit.github.io/2016/05/30/beyond-memory-safety-with-types http://insanitybit.github.io/2016/05/30/beyond-memory-safety... TL;DR: compile time checking that your state machine transition is correct.
    - bmurphy1976 10y ago
      Thanks, I'll take a look.
  - lordnaikon 10y ago
    I wrote you a little example but i think you need to know rust to really understand it :( https://is.gd/FlBCJ0 https://is.gd/FlBCJ0 you cannot uncomment the comments in the main function and use it wrong, the compiler prevents you to compile this code. these two sections from the book may help understad this https://doc.rust-lang.org/book/ownership.html https://doc.rust-lang.org/book/ownership.html https://doc.rust-lang.org/book/references-and-borrowing.html https://doc.rust-lang.org/book/references-and-borrowing.html if you're more into videos this may help http://intorust.com/tutorial/ownership/ http://intorust.com/tutorial/ownership/ http://intorust.com/tutorial/shared-borrows/ http://intorust.com/tutorial/shared-borrows/
zbobet2012 10y ago
This is one of the more reasoned differentiation I have seen between the two languages. Funnily enough, it's in both of their mission statements. It clearly shows too in the resulting languages.
- moosingin3space 10y ago
  "It's just a bloody fucking fuck" is reasoned?
zem 10y ago
i continue to be astonished that D gets left out of these discussions. it's more capable than go and easier to use than rust, which would make it look like the sweet spot for a lot of people moved to compare the two. (that said, every time i've tried to use the language the tooling around it has been a miserable experience. that might have changed in the last couple of years.)
- SomeCallMeTim 10y ago
  I've never used D, but I think it was written before the developer community was ready for a new language. Now that developers are ready for new languages, D is already an "old, failed" language. It reminds me of selling a house. If you put your house during a hot market and go into contract right away, but then your buyer can't come up with the money and it falls out of contract three weeks later, bringing your house back on the market it's now no longer "newly available!", and everyone thinks that, because it didn't sell in the first week, there must be something wrong with it. My personal entirely uninformed opinion of D is exactly that: It's an older, "failed" language. It's not on the upswing in popularity. It didn't catch peoples' hearts and minds. And if only because of network effects, therefore it's not worth learning, simply because no one else is learning it, and so therefore its ecosystem isn't expanding exponentially. Success of technologies is far less merit than one might expect. See: VHS vs. Beta.
  - qznc 10y ago
    You are right. D had some serious failures in the version 1 times, which tainted its image. However, the community is still growing. Slower than Rust, but moving in a positive direction. During the last year the D foundation was founded and is spinning up operations. The 2016 D conference had a visitor record again with over 100 people. Downloads are growing over the years [0]. The package manager dub is now fully integrated. You can find success stories on the blog [1] and companies using it [2]. There are books. [0] http://erdani.com/d/downloads.daily.png http://erdani.com/d/downloads.daily.png [1] https://dlang.org/blog/ https://dlang.org/blog/ [2] https://dlang.org/orgs-using-d.html https://dlang.org/orgs-using-d.html
hueving 10y ago
Grumpy isn't a way to move from python2 to go. It's a way to keep using python2 with the performance benefits of no GIL.
- 0xFFC 10y ago
  Isn't it transpiler ? I think they trying hard to move away from python2 to go, but they had massive amount of code written in python2. I think your logic is not sound . If they wanted to use python2 (only with their own runtime which does not have GIL) instead of switching to go (eventually) they would write a runtime instead of transpiler ? Please correct me, I am not 100% sure.
bjz_ 10y ago
Once you get past the learning curve, Rust is a joy to work in, and you can switch your mind off to things that the compiler can help you with. The trouble is that it takes longer to grok than the four days most people give it. It's not really something you can bash into submission based on past experience with another language.
tossracct88 10y ago
Ah, this rings so true. I've tried to get into Rust on/off and each time I'm left feeling like I needed a semester of instruction just to write a trivial program. Each attempt to go back to it, I would immediately hit a wall. Go, on the other hand, felt quick to pick up. While I don't use it a lot, it's focus on a few composition patterns, and really sticking by that, made it easier for me to learn and come back to when I go back to my Python-centric existence. Rust on the other hand, I haven't thought about nor touched, outside seeing an HN headline.
derefr 10y ago
"Two big conclusions" is a good way to put it. I would phrase it like this: • Go is a useful, safe subset of C (with a rather expanded libc.) Go lets you do fewer things than C (e.g. hard real-time things; processor-optimized things) but for most people, they don't need those things, and delving into them was what seeded the bugs into their C/C++ projects in the first place, completely unnecessarily. • Rust is a formalization/codification of idiomatic C++. It's not a subset; it's a rethink, like Plan 9 is a rethink of Unix. You can do everything in Rust that you can do in C++, and the compiler will catch (nearly) all the bugs you would have left in the equivalent C++ project. In other words, Go says "you don't need this"; Rust says "if you're so sure you need this, let's ensure you do it right." For any given piece of code, either Go's assertion or Rust's assertion could be "correct." You either need the things only Rust lets you do, or you don't. For a large codebase, though, I expect the answer is actually nearly always going to end up somewhere between. Big apps or libraries always have that one part that does heavy lifting and has to go fast, but go fast correctly; and 99% that doesn't. Thus, I envision the future of many "systems software" codebases to look like this: 1. (1% of LOC) an "engine" library, written in Rust, which compiles to a C-ABI shared object; 2. (3% of LOC) an "engine wrapper" library, written in Go, which imports the "engine" object using Go's C FFI and then exposes a safe Go API to it—and also, the tests for the engine library, written in Go because it's easier; 3. (96% of LOC) the app itself, written in Go, which calls into the "engine wrapper."
- Thiez 10y ago
  Isn't calling into "C" (or Rust, in this case) expensive in Go because it seeds to switch stacks?
  - lobster_johnson 10y ago
    Expensive in Go, but not in Rust.
    - Thiez 10y ago
      I am aware, but the parent of my post suggested writing the "engine core" in Rust, and the other 99% in Go. Does using something that isn't Go for 1% of an application to do the "heavy lifting" and be "fast" really make sense when there is a significant cost that must be paid whenever moving between that core and the rest of the application? I imagine such a situation would need a lot of benchmarking to make sure that the end result is actually faster than writing the entire program in Go.
JoshTriplett 10y ago
> A friend of mine put it into good words: Go and Rust are two big conclusions, to big follow-ups to the C and C++ world. Go isn't a replacement for C; you can't use it for many forms of low-level systems programming, because it has a runtime. Go provides a high-performance replacement for things you might otherwise write in Python or similar, and in that capacity it works quite well. Rust can do anything C can; its capabilities build upwards from bare metal, not downwards from higher-level languages. It intentionally doesn't have a runtime, and its approach to avoiding garbage collection (namely borrow checking) provides safe memory handling without a runtime at the expense of being a novel language feature without analogue in other languages. Much of the learning curve in Rust comes from that.
- staticassertion 10y ago
  I think we like to say things like "C has no GC so it's good for kernels, Python has a GC so it's good for blah blah". In reality, we've definitely written plenty of "python level" (application level) software in C, and the same is happening in Rust.
  - JoshTriplett 10y ago
    > In reality, we've definitely written plenty of "python level" (application level) software in C, and the same is happening in Rust. Oh, absolutely; you can certainly write higher-level code in Rust, and it makes for a far more comfortable experience than writing higher-level code in C. I didn't intend to suggest otherwise. And the ongoing futures work helps Rust address several additional areas that Go does well. However, I don't think it makes sense to group Go and C together, syntax aside. Go cannot replace every use of C, because of its runtime and related expectations. (You can push it into some low-level environments if you make accommodations for its runtime, but you can do the same for languages like Python. You wouldn't necessarily want to do so in production, though.)
CalChris 10y ago
I agree with all of that except that I don't see Rust as the safe follow-up of C but rather as the anti-thesis of C. Indeed knowing C will not help you. They're both imperative and that's pretty much it.
disordinary 10y ago
I've found Rust to be quite enjoyable, sometimes the borrow checker is annoying but you get used to it pretty quickly. I only play around with it for personal projects but I would have thought that if I went from scratch and spent four days on it like the article stated that I'd be pretty productive.
shmerl 10y ago
I wouldn't put Go as a follow up to C world. More like to Java one. But Rust is indeed a follow up to C/C++ world.
- stevedonovan 10y ago
  Well yes: touted as 'a better C' but I suspect they've succeeded at 'a better Java'. But it's more fair to say that Rust is a _retry_ at creating a C++-like language organized around concepts of safety and ML-like features ('like C and Haskell had a baby' as one person put it.) You can get _quite confused_ applying C++ concepts blindly in Rust ;)
solidsnack9000 10y ago
> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. It's too bad that you feel that way but lots of people like programming in Rust and don't like programming in Go. I have never before had to pay so much -- in terms of type annoyances, packaging workflow and boilerplate -- for so little.

by tetha 10y ago

tatterdemalion 10y ago

> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. I could not disagree more! Rust is a great joy to program in. I would rather program in Rust than any other language. Rust is challenging for many people to learn. That is very different.

zbobet2012 10y ago
Language design is about trade-offs: The borrow checker and ownership model is a huge tradeoff. Even those very experienced in it still fight it from time to time. Go made a different trade, they chose GC. And GC _is_ easier. But it has computational overhead (well today anyway). Consider the cascading implications. Rust has a trait for Copy vs. Move types. This means every type has an implicit, and unknown behavior, on certain assignments: let v2 = v; println!("v is: {}", v); You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. But it is a trade-off. Go as a language must have a GC. It will never be suitable for certain tasks as a result. Go also has less compile time checking. This means faster compiles, quicker dev cycles but less compile time safety. Go chose easier here again. These trade-offs are what make rust seem "difficult" in comparison to go. I don't know if you can ever "fix" them.
- tetha 10y ago
  Exactly this. If you're a massively parallel web service, who cares about some GCs, and who cares about crashing like 0.01% of all transactions? Monitor it, crash it, fix it, deploy it, move on. If you operated a nuclear reactor with this mentality, I'd be concerned. If you're operating acme.org with that mindset... godspeed?
  - AnimalMuppet 10y ago
    If you're running amazon.com with that mindset, 0.01% of transactions is millions of dollars a day.
    - woah 10y ago
      If you're running amazon.com, a project that takes 2 weeks longer to complete is hundreds of millions of dollars of lost sales.
- vvanders 10y ago
  The thing is if you don't want to fight the borrow checker you can use RefCell and Arc/Rc. People are discouraged because then you lose a lot of architectural advantages that come with Rust but nothing is keeping you from writing unsafe{} and RefCell in the places where you know things are safe but can't formulate something that Rust understands.
  - empath75 10y ago
    I suspect that if you can't formulate it into something rust understands, you don't understand it well enough to know it's safe.
- tatterdemalion 10y ago
  I am a member of the Rust language design team, I am very aware that language design is about trade offs. I find the ownership model has non-performance advantages in that I find it provides strong design pressure to factor my system well. I would not describe my experience as 'fighting' the borrow checker - I feel positively when the borrow checker sends me back to the drawing board, because it teaches me things about my system I had not properly comprehended. (There are areas where the borrow checker is overly conservative, but I never hit these in practice.) > You can't actually tell me whether the above code compiles without consulting other parts of the code. That's not the case for Go. It is thus simpler and more intuitive to program in. I'm sorry this is just silly. Here's some Go code: v2 := v + 1 You can't actually tell me if the above code compiles without consulting other parts of the code, because you don't know if `v` can be added to `1`. In Rust, type inference is only local to a function, so you will be able to determine from an actual compile-able code snippet whether or not that use after move is valid. Go also actually might not compile on the exact example you cited (translated to Go, of course) because that code contains an error if `v2` is never used after it is assigned. In general, you cannot reason about the correctness of incomplete code snippets. This is not specific to Rust.
jandrese 10y ago
I don't know, that is the kind of comment you used to hear from LISP programmers about how their program was really an elegant mathematical proof of its own correctness. That's great until you try to do some real world things with it and run into endless impedance mismatches. Rust isn't quite so far up its own butt, however the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile.
- AlexCoventry 10y ago
  "Go is a blub language" was actually my hot take on this article.
- AsyncAwait 10y ago
  > the developer community doesn't seem to realize that there's a massive gap between the toy example programs in their documentation and the level of knowledge needed to build something worthwhile. I don't think Servo and rustc itself are "toy example programs".
  - civility 10y ago
    Are Servo and rustc in the Rust documentation? Literate programming of some sort? Maybe you're replying to a different criticism. I've been through the Rust Documentation (doc.rust-lang.org) and Rust By Example (rustbyexample.com) several times now, and I have to jump on IRC to get answers to (what I think should be) some pretty simple questions.
    - AsyncAwait 10y ago
      If you think something important is missing from the docs, please open an issue. Steve Klabnik is very keen on making the documentation as useful as possible.
      - civility 10y ago

tomjakubowski 10y ago

> It's a pain to get working, it sucks to program in, it requires so much though, it's just a bloody fucking fuck What sucks about programming in Rust? What makes it a bloody fucking fuck? I disagree on both these points: * Rust enums and move semantics make writing state machines a pure joy. Far nicer than in C++ or Go. * Pattern matching (both fallible + infallible) is very developer friendly. * Option<T> and Result<T,E> are totally brilliant. * It's trivial to add and version-fix a dependency on an external library with Cargo. * Rust's ownership and move semantics help you to write cleaner, easier to understand code.

bmurphy1976 10y ago
How does move semantics make writing state machines better? I can understand powerful enums, but I'm not familiar enough with move semantics to envision what you are referring to. Do you know of an example available somewhere?
- bjz_ 10y ago
  It ensures that you consume a state at most once. You can kind of visualize state 'moving' through your functions - going in through the arguments and out through the returned value.
- sinhpham 10y ago
  Example: http://insanitybit.github.io/2016/05/30/beyond-memory-safety-with-types http://insanitybit.github.io/2016/05/30/beyond-memory-safety... TL;DR: compile time checking that your state machine transition is correct.
  - bmurphy1976 10y ago
    Thanks, I'll take a look.
- lordnaikon 10y ago
  I wrote you a little example but i think you need to know rust to really understand it :( https://is.gd/FlBCJ0 https://is.gd/FlBCJ0 you cannot uncomment the comments in the main function and use it wrong, the compiler prevents you to compile this code. these two sections from the book may help understad this https://doc.rust-lang.org/book/ownership.html https://doc.rust-lang.org/book/ownership.html https://doc.rust-lang.org/book/references-and-borrowing.html https://doc.rust-lang.org/book/references-and-borrowing.html if you're more into videos this may help http://intorust.com/tutorial/ownership/ http://intorust.com/tutorial/ownership/ http://intorust.com/tutorial/shared-borrows/ http://intorust.com/tutorial/shared-borrows/

zbobet2012 10y ago

This is one of the more reasoned differentiation I have seen between the two languages. Funnily enough, it's in both of their mission statements. It clearly shows too in the resulting languages.

moosingin3space 10y ago
"It's just a bloody fucking fuck" is reasoned?

zem 10y ago

i continue to be astonished that D gets left out of these discussions. it's more capable than go and easier to use than rust, which would make it look like the sweet spot for a lot of people moved to compare the two. (that said, every time i've tried to use the language the tooling around it has been a miserable experience. that might have changed in the last couple of years.)

SomeCallMeTim 10y ago
I've never used D, but I think it was written before the developer community was ready for a new language. Now that developers are ready for new languages, D is already an "old, failed" language. It reminds me of selling a house. If you put your house during a hot market and go into contract right away, but then your buyer can't come up with the money and it falls out of contract three weeks later, bringing your house back on the market it's now no longer "newly available!", and everyone thinks that, because it didn't sell in the first week, there must be something wrong with it. My personal entirely uninformed opinion of D is exactly that: It's an older, "failed" language. It's not on the upswing in popularity. It didn't catch peoples' hearts and minds. And if only because of network effects, therefore it's not worth learning, simply because no one else is learning it, and so therefore its ecosystem isn't expanding exponentially. Success of technologies is far less merit than one might expect. See: VHS vs. Beta.
- qznc 10y ago
  You are right. D had some serious failures in the version 1 times, which tainted its image. However, the community is still growing. Slower than Rust, but moving in a positive direction. During the last year the D foundation was founded and is spinning up operations. The 2016 D conference had a visitor record again with over 100 people. Downloads are growing over the years [0]. The package manager dub is now fully integrated. You can find success stories on the blog [1] and companies using it [2]. There are books. [0] http://erdani.com/d/downloads.daily.png http://erdani.com/d/downloads.daily.png [1] https://dlang.org/blog/ https://dlang.org/blog/ [2] https://dlang.org/orgs-using-d.html https://dlang.org/orgs-using-d.html

hueving 10y ago

Grumpy isn't a way to move from python2 to go. It's a way to keep using python2 with the performance benefits of no GIL.

0xFFC 10y ago
Isn't it transpiler ? I think they trying hard to move away from python2 to go, but they had massive amount of code written in python2. I think your logic is not sound . If they wanted to use python2 (only with their own runtime which does not have GIL) instead of switching to go (eventually) they would write a runtime instead of transpiler ? Please correct me, I am not 100% sure.

bjz_ 10y ago

Once you get past the learning curve, Rust is a joy to work in, and you can switch your mind off to things that the compiler can help you with. The trouble is that it takes longer to grok than the four days most people give it. It's not really something you can bash into submission based on past experience with another language.

tossracct88 10y ago

Ah, this rings so true. I've tried to get into Rust on/off and each time I'm left feeling like I needed a semester of instruction just to write a trivial program. Each attempt to go back to it, I would immediately hit a wall. Go, on the other hand, felt quick to pick up. While I don't use it a lot, it's focus on a few composition patterns, and really sticking by that, made it easier for me to learn and come back to when I go back to my Python-centric existence. Rust on the other hand, I haven't thought about nor touched, outside seeing an HN headline.

derefr 10y ago

"Two big conclusions" is a good way to put it. I would phrase it like this: • Go is a useful, safe subset of C (with a rather expanded libc.) Go lets you do fewer things than C (e.g. hard real-time things; processor-optimized things) but for most people, they don't need those things, and delving into them was what seeded the bugs into their C/C++ projects in the first place, completely unnecessarily. • Rust is a formalization/codification of idiomatic C++. It's not a subset; it's a rethink, like Plan 9 is a rethink of Unix. You can do everything in Rust that you can do in C++, and the compiler will catch (nearly) all the bugs you would have left in the equivalent C++ project. In other words, Go says "you don't need this"; Rust says "if you're so sure you need this, let's ensure you do it right." For any given piece of code, either Go's assertion or Rust's assertion could be "correct." You either need the things only Rust lets you do, or you don't. For a large codebase, though, I expect the answer is actually nearly always going to end up somewhere between. Big apps or libraries always have that one part that does heavy lifting and has to go fast, but go fast correctly; and 99% that doesn't. Thus, I envision the future of many "systems software" codebases to look like this: 1. (1% of LOC) an "engine" library, written in Rust, which compiles to a C-ABI shared object; 2. (3% of LOC) an "engine wrapper" library, written in Go, which imports the "engine" object using Go's C FFI and then exposes a safe Go API to it—and also, the tests for the engine library, written in Go because it's easier; 3. (96% of LOC) the app itself, written in Go, which calls into the "engine wrapper."

Thiez 10y ago
Isn't calling into "C" (or Rust, in this case) expensive in Go because it seeds to switch stacks?
- lobster_johnson 10y ago
  Expensive in Go, but not in Rust.
  - Thiez 10y ago
    I am aware, but the parent of my post suggested writing the "engine core" in Rust, and the other 99% in Go. Does using something that isn't Go for 1% of an application to do the "heavy lifting" and be "fast" really make sense when there is a significant cost that must be paid whenever moving between that core and the rest of the application? I imagine such a situation would need a lot of benchmarking to make sure that the end result is actually faster than writing the entire program in Go.

JoshTriplett 10y ago

> A friend of mine put it into good words: Go and Rust are two big conclusions, to big follow-ups to the C and C++ world. Go isn't a replacement for C; you can't use it for many forms of low-level systems programming, because it has a runtime. Go provides a high-performance replacement for things you might otherwise write in Python or similar, and in that capacity it works quite well. Rust can do anything C can; its capabilities build upwards from bare metal, not downwards from higher-level languages. It intentionally doesn't have a runtime, and its approach to avoiding garbage collection (namely borrow checking) provides safe memory handling without a runtime at the expense of being a novel language feature without analogue in other languages. Much of the learning curve in Rust comes from that.

staticassertion 10y ago
I think we like to say things like "C has no GC so it's good for kernels, Python has a GC so it's good for blah blah". In reality, we've definitely written plenty of "python level" (application level) software in C, and the same is happening in Rust.
- JoshTriplett 10y ago
  > In reality, we've definitely written plenty of "python level" (application level) software in C, and the same is happening in Rust. Oh, absolutely; you can certainly write higher-level code in Rust, and it makes for a far more comfortable experience than writing higher-level code in C. I didn't intend to suggest otherwise. And the ongoing futures work helps Rust address several additional areas that Go does well. However, I don't think it makes sense to group Go and C together, syntax aside. Go cannot replace every use of C, because of its runtime and related expectations. (You can push it into some low-level environments if you make accommodations for its runtime, but you can do the same for languages like Python. You wouldn't necessarily want to do so in production, though.)

CalChris 10y ago

I agree with all of that except that I don't see Rust as the safe follow-up of C but rather as the anti-thesis of C. Indeed knowing C will not help you. They're both imperative and that's pretty much it.

disordinary 10y ago

I've found Rust to be quite enjoyable, sometimes the borrow checker is annoying but you get used to it pretty quickly. I only play around with it for personal projects but I would have thought that if I went from scratch and spent four days on it like the article stated that I'd be pretty productive.

shmerl 10y ago

I wouldn't put Go as a follow up to C world. More like to Java one. But Rust is indeed a follow up to C/C++ world.

stevedonovan 10y ago
Well yes: touted as 'a better C' but I suspect they've succeeded at 'a better Java'. But it's more fair to say that Rust is a _retry_ at creating a C++-like language organized around concepts of safety and ML-like features ('like C and Haskell had a baby' as one person put it.) You can get _quite confused_ applying C++ concepts blindly in Rust ;)

solidsnack9000 10y ago

> It's a pain to get working, it sucks to program in, it requires so much thought, it's just a bloody fucking fuck. It's too bad that you feel that way but lots of people like programming in Rust and don't like programming in Go. I have never before had to pay so much -- in terms of type annoyances, packaging workflow and boilerplate -- for so little.