4 ms·

What do you mean by not adequate? Go tooling is way better than Rust. The only thing that Rust does better in that field is package dependency and it's going to

by Thaxll 9y ago

What do you mean by not adequate? Go tooling is way better than Rust. The only thing that Rust does better in that field is package dependency and it's going to change soon for Go.

steveklabnik 9y ago
What parts of Go tooling do you miss in Rust?
- Kubuxu 9y ago
  go fmt
  - steveklabnik 9y ago
    https://github.com/rust-lang-nursery/rustfmt https://github.com/rust-lang-nursery/rustfmt It should be distributed along with the rest of the tooling in the coming months!
  - alexnewman 9y ago
    What’s wrong with cargo fmt
    - dullgiulio 9y ago
      It has options ;)
- Thaxll 9y ago
  - Fast / cross compile - Benchmark / profiling are much better ( https://blog.golang.org/profiling-go-programs https://blog.golang.org/profiling-go-programs ) - go fmt / go vet - go doc All of that that is supported by default by the Go team on all platforms, meaning it works well and I don't have to worry of using a 3rd party Cargo package.
  - alexnewman 9y ago
    Go doc and go fmt have rust equivalents. What’s better at profiling?
    - Thaxll 9y ago
      There is nothing out of the box for profiling ( but it's bit different since no GC and use C/C++ tools ). What's the equivalent of doc godoc -http=:6060 ( it sounds silly by last time I was in a plane and was able to browse the Go doc Like if I had internet access )
      - steveklabnik 9y ago
        Just cargo doc; I think it has a --open flag too. (Rust docs don't need a web server running)
        dullgiulio 9y ago
        Probably opens a "file://..." then. Go docs run their own embedded server, they don't need one, just to be precise.
        steveklabnik 9y ago
        Yeah, that's exactly what it does.
      - alexnewman 9y ago
        Total nonsense rust makes it trivial to profile
  - steveklabnik 9y ago
    Thanks! Compile speed is certainly a thing go is excellent at. Cross-compiling, Rust is almost as good, but not quite yet, working on it! Benchmark stuff is not yet stable, but for profiling, you don't need a special tool for Rust; all the C and C++ tooling works. fmt/vet is rustfmt and clippy, which work today, and soon will be distributed with Rust tool. rustdoc already ships with Rust. So, my takeaway is mostly, needs some polish and shipping with the compiler. Thanks!
- alexnewman 9y ago
  The other way around closed source development is weird in go.
  - Vendan 9y ago
    That's a plus in my books :)
- PopsiclePete 9y ago
  First, I want to say that I have great respect for you and everyone else in the Rust community. It's now my second-favorite language (after Go). I've been learning Rust over the past months and I don't think the borrow checker stuff is as scary as people make it sound, match is amazing, so are traits, enums, cargo.... But, I can't, for the life of me, wrap my head around Rust's "concurrency" story. Yet. Go concurrency is as close to trivial as one can get - channels, goroutines, select. That's it. And they compose nicely. I was doing concurrent networking stuff in a matter of days. Rust has channels, select (kind-of?), but then I discovered it has futures, and something called "mio", and now something called "tokio", also read something about generators and coroutines, saw that C#-like "async/await" stuff is also being worked on, and I'm not sure how these things interact with each other. I get the .NET async/await story, and always felt it was (good) syntactic sugar on top of "raw" JS-style futures, but how do all of them play with the CSP-style stuff like channels that's in the std. lib already? Is one being deprecated? I feel in general Go's CSP model is more "powerful" and more "generic" than futures - you can even emulate futures/promises with Go's primitives, but I don't see how you can do what I do in Go with bare futures - "streaming" type stuff is especially hard with the futures' "all-or-nothing" approach. I think Rust really nailed down the "one-thing-at-a-time" story - the docs, tutorials - all great. But for me it broke down quickly on the "easy concurrency" end - and maybe it's just a question of better tutorials/docs?
  - steveklabnik 9y ago
    Thanks! Yeah, so this is basically the result of two things: 1. Rust-the-language focused on making concurrency safe, and getting primtives right 2. The higher-level aspects of the story are still shaking out. The core primitives are very simple: Sync and Send, two traits which let you declare invariants. But most people don't want to be programming with primitives. So there's been a lot of iteration on what a higher-level story looks like. There are a ton of options, and we've been iterating through them to figure it out. The stuff you're seeing is the result of that process, so you're seeing how the sausage is made, which can definitely be confusing. It's all under active work, and then, once the pieces are in place, getting the right docs/tutorials there. So, yes. Thanks. It's a good reminder. We'll get there :) One last thing, as a small amount of food for thought: > I feel in general Go's CSP model is more "powerful" and more "generic" than futures In some senses, yes, but they also come with tradeoffs, like any technical choice. Specifically, in order to do concurrency this way, you must go with green threads. And green threads lead to smaller stacks, which leads to non-zero cost of calling into C code, which is a drawback that Rust can't sustain. It works great for Go, but can't really work in Rust, generally. I mean, you can do it, yes, but that drawback doesn't work for the majority of our audience. It's these kinds of tricky, in-the-weeds stuff that makes designs hard and take time.

by Thaxll 9y ago

What do you mean by not adequate? Go tooling is way better than Rust. The only thing that Rust does better in that field is package dependency and it's going to change soon for Go.

steveklabnik 9y ago

What parts of Go tooling do you miss in Rust?

Kubuxu 9y ago
go fmt
- steveklabnik 9y ago
  https://github.com/rust-lang-nursery/rustfmt https://github.com/rust-lang-nursery/rustfmt It should be distributed along with the rest of the tooling in the coming months!
- alexnewman 9y ago
  What’s wrong with cargo fmt
  - dullgiulio 9y ago
    It has options ;)
Thaxll 9y ago
- Fast / cross compile - Benchmark / profiling are much better ( https://blog.golang.org/profiling-go-programs https://blog.golang.org/profiling-go-programs ) - go fmt / go vet - go doc All of that that is supported by default by the Go team on all platforms, meaning it works well and I don't have to worry of using a 3rd party Cargo package.
- alexnewman 9y ago
  Go doc and go fmt have rust equivalents. What’s better at profiling?
  - Thaxll 9y ago
    There is nothing out of the box for profiling ( but it's bit different since no GC and use C/C++ tools ). What's the equivalent of doc godoc -http=:6060 ( it sounds silly by last time I was in a plane and was able to browse the Go doc Like if I had internet access )
    - steveklabnik 9y ago
      Just cargo doc; I think it has a --open flag too. (Rust docs don't need a web server running)
      - dullgiulio 9y ago
        Probably opens a "file://..." then. Go docs run their own embedded server, they don't need one, just to be precise.
        steveklabnik 9y ago
        Yeah, that's exactly what it does.
    - alexnewman 9y ago
      Total nonsense rust makes it trivial to profile
- steveklabnik 9y ago
  Thanks! Compile speed is certainly a thing go is excellent at. Cross-compiling, Rust is almost as good, but not quite yet, working on it! Benchmark stuff is not yet stable, but for profiling, you don't need a special tool for Rust; all the C and C++ tooling works. fmt/vet is rustfmt and clippy, which work today, and soon will be distributed with Rust tool. rustdoc already ships with Rust. So, my takeaway is mostly, needs some polish and shipping with the compiler. Thanks!
alexnewman 9y ago
The other way around closed source development is weird in go.
- Vendan 9y ago
  That's a plus in my books :)
PopsiclePete 9y ago
First, I want to say that I have great respect for you and everyone else in the Rust community. It's now my second-favorite language (after Go). I've been learning Rust over the past months and I don't think the borrow checker stuff is as scary as people make it sound, match is amazing, so are traits, enums, cargo.... But, I can't, for the life of me, wrap my head around Rust's "concurrency" story. Yet. Go concurrency is as close to trivial as one can get - channels, goroutines, select. That's it. And they compose nicely. I was doing concurrent networking stuff in a matter of days. Rust has channels, select (kind-of?), but then I discovered it has futures, and something called "mio", and now something called "tokio", also read something about generators and coroutines, saw that C#-like "async/await" stuff is also being worked on, and I'm not sure how these things interact with each other. I get the .NET async/await story, and always felt it was (good) syntactic sugar on top of "raw" JS-style futures, but how do all of them play with the CSP-style stuff like channels that's in the std. lib already? Is one being deprecated? I feel in general Go's CSP model is more "powerful" and more "generic" than futures - you can even emulate futures/promises with Go's primitives, but I don't see how you can do what I do in Go with bare futures - "streaming" type stuff is especially hard with the futures' "all-or-nothing" approach. I think Rust really nailed down the "one-thing-at-a-time" story - the docs, tutorials - all great. But for me it broke down quickly on the "easy concurrency" end - and maybe it's just a question of better tutorials/docs?
- steveklabnik 9y ago
  Thanks! Yeah, so this is basically the result of two things: 1. Rust-the-language focused on making concurrency safe, and getting primtives right 2. The higher-level aspects of the story are still shaking out. The core primitives are very simple: Sync and Send, two traits which let you declare invariants. But most people don't want to be programming with primitives. So there's been a lot of iteration on what a higher-level story looks like. There are a ton of options, and we've been iterating through them to figure it out. The stuff you're seeing is the result of that process, so you're seeing how the sausage is made, which can definitely be confusing. It's all under active work, and then, once the pieces are in place, getting the right docs/tutorials there. So, yes. Thanks. It's a good reminder. We'll get there :) One last thing, as a small amount of food for thought: > I feel in general Go's CSP model is more "powerful" and more "generic" than futures In some senses, yes, but they also come with tradeoffs, like any technical choice. Specifically, in order to do concurrency this way, you must go with green threads. And green threads lead to smaller stacks, which leads to non-zero cost of calling into C code, which is a drawback that Rust can't sustain. It works great for Go, but can't really work in Rust, generally. I mean, you can do it, yes, but that drawback doesn't work for the majority of our audience. It's these kinds of tricky, in-the-weeds stuff that makes designs hard and take time.