My personal code base is C++/cmake and Python.
It would be really nice with a way to slowly start writing code in Rust instead.
2017 Rust Roadmap
111–120 of 201 posts
Re: 2017 Rust Roadmap
#112Earlier quoted context omitted.
Arguably, programmer productivity is one consequence of safety (and productivity isn't necessarily only gained by increased safety either of course!). Are there different productivity levels between Go and Rust? Probably. But to say Rust wasn't "designed for programmer productivity" definitely isn't right from where I'm standing.
Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying…
Claiming that it is less productive when you barely know it isn't fair...
...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling.
Go has a lot of very polished tooling (eg. gocode) that is supported in multiple editors, and a variety of high level packages for all kinds of things.
Certainly I'm willing to acknowledge that if you're using vim without any plugins to write your code, or if you're evaluating the effectiveness of writing individual functions, it's a much more abstract kind of thing.
...but have you actually bench marked yourself coding a real world project, from scratch, in both, from idea to delivery? I have, and for me rust was an order of magnitude less productive than go. At least.
Once the tooling for rust gets up and going we'll be a much better position, but...
You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell...
Re: 2017 Rust Roadmap
#113Earlier quoted context omitted.
It doesn't have it, Go uses a different concurrency model.
I manage a Lua framework that wraps Linux epoll, BSD kqueue, and Solaris Ports. Lua provides asymmetric coroutines, which the framework uses as logical "threads" for execution state. A Lua coroutine is a just a couple hundred bytes of state, likely smaller than a JavaScript/NodeJS closure all things considered, though slightly larger than a Lua closure. Lua also has very clean and elegant bindings to C. Lua is design…
I think the difference is in how people define "async I/O". When saying "Go doesn't use async I/O", what that really expands to is: "While Go can use epoll[0], it doesn't abstract over epoll optimally." i.e. There is a difference between "zero-overhead async-I/O" and goroutines.
I'm not an expert but I'll try to describe why goroutines would have overhead (Someone correct me):
The posterboys of async I/O are Nginx and Redis. I'm probably simplifying, but this is the basics of how they work are: When using epoll directly, the optimal way to store state per connection is using a state machine. The state machine is usually some C-like struct which the compiler can give a fixed size. Each state machine is then constructed to have X memory, and is unable to grow. In theory (I don't believe anyone actually does this), if the program was comfortable with some fixed connection limit, you could fit all of these state machines on the program's stack, and require no heap allocations.
Meanwhile, Go's routines have stacks which can grow. Each goroutine has some max size, and some initial size, both of which are pre-set by the Go-lang team (I'm sure they are configurable). Since the stack can grow: They have to be heap allocated, and need to be either segmented or copied when they need more space[1]. Additionally, there is "internal fragmentation" because a growable stack needs to be consistently overallocated, which is a "waste" of memory.
Very quick Googling suggests that Lua has growable stacks as well.
[0] FWIW: Go could use M:N scheduling of kernel threads to achieve goroutines. Which is another reason why saying goroutines are async I/O could be incorrect. I don't know how its actually implemented.
[1] https://blog.cloudflare.com/how-stacks-are-handled-in-go/
Re: 2017 Rust Roadmap
#114Earlier quoted context omitted.
I'm not sure how valuable this type of thing really is. Templates tend to fall out of date, since they're not actively used, they're not actively updated to new practices. I've seen this with lots of templates in other languages. The libraries having excellent documentation and pointing to apps that are similarly implemented tends to be better maintained, IMO.
Maybe this could be some kind of cargo command: cargo template-gen name something
Re: 2017 Rust Roadmap
#115Earlier quoted context omitted.
Honestly, the more you program in rust, the more you get used to its mannerisms. I don't at this point find that I'm less productive in it than in Go, and with gennerics I'm generally able to reuse code more often meaning that I usually write less code. Similarly in C I lose time on screwing up basic things that I have to debug in testing, whereas in Rust I don't have to even worry about that. I'm actually not buying…
Claiming that it is less productive when you barely know it isn't fair... I'm really quite familiar with both go and rust, and I can say straight out that go is more productive than rust. ...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling. Go has a lot of very polished tooling (…
> You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell...
You could say something like "you're effectively saying that there is zero productivity drain from not having features like generics (which Rust currently does have); that's a pretty hard sell...
Tooling matters a lot, and that's why we're investing in it. But "tooling" is not a synonym for "productivity." There's a lot of factors.
Re: 2017 Rust Roadmap
#116I read through the Rust book, and the problem I was having with it and the other docs is that it was hard to map the Rust concepts with what actually runs when it is compiled. For a language that touts "uncompromising performance", it was difficult for me to find performance characteristics of the underlying abstractions and std library (for example, are algebraic data structures just tagged unions or does the compil…
This is an area in which I haven't quite figured out how to communicate properly; I feel like I have a good understanding of how Rust maps to asm, but I don't know how to transfer that understanding to other people.
I'll certainly be reading your link below, thanks for that!
Re: 2017 Rust Roadmap
#117Awesome. I have used Iron a few times to write small web services, but I can't wait for Rust to really have a strong story for the backend. If that happens it'll be the first language I reach for whenever I need to write a backend. I think it has a lot of great bonuses already. It's language ergonomics are that of a high-level language, yet it is extremely fast, and I can be very confident in my code if it compiles.…
Yup, happy to see everything on the list. If one thing more than any stands out it's Rust's commitment not just to building a language but building an incredible community. With how seriously the release processes are being taken to the way new people are welcomed. Serious kudos, I know it's not the most technically engaging work but it makes a huge difference.
Yes, as far I can tell, Rust is probably (pun intended) the gold standard in these areas. I only looked at Rust briefly, because the language itself felt too complex for my simple needs, but I was hugely impressed by how much concern and effort the core team seem to put into every aspect of the developer experience. The only other group that I know with that level of focus is the .NET people at Microsoft.
Re: 2017 Rust Roadmap
#118Earlier quoted context omitted.
Claiming that it is less productive when you barely know it isn't fair... I'm really quite familiar with both go and rust, and I can say straight out that go is more productive than rust. ...but because rust is in any way a worse or less productive language (that remains to be seen), but because it has an immature ecosystem with few high quality crates and virtually no tooling. Go has a lot of very polished tooling (…
> You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell... You could say something like "you're effectively saying that there is zero productivity drain from not having features like generics (which Rust currently does have); that's a pretty hard sell... Tooling matters a lot, and that's why we're investing in…
You'd have a much easier time arguing that go not having a package manager makes you less productive compared to cargo (very true); you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity.
Can you build something more quickly in go right now, than in rust?
For many applications, the answer is, right now: Yes.
Building (using the tooling that does exist, and the libraries that do exist) make completing a project successfully easier and quicker than in rust.
Does that make go 'more productive' than rust?
Or is 'productivity' just how effective you are at expressing logic as code?
Well, I guess it depends what word games you want to play.
My personal experience has been that using rust is great, fun (if verbose) and you can spend 5 or 6 hours writing a nice crate that doesn't do anything meaningful; and when you do have to do something meaningful, its a tonne of work to get it to compile (ugh, c libraries...) and you end up having to write or modify/fix the packages to do many of the things yourself.
That is not productive.
Perhaps you see a different side to it from where you sit, but I do think #rust suffers from a certain degree of confirmation bias.
I think 'productivity' depends on your problem domain.
For building actual applications rust simply isnt even in the same space as java, c++, c# or go at this point in terms of 'productivity'.
Re: 2017 Rust Roadmap
#119Earlier quoted context omitted.
> You're effectively saying that there is zero productivity boost in the extensive go tooling ecosystem (which rust currently doesn't have); that's pretty hard sell... You could say something like "you're effectively saying that there is zero productivity drain from not having features like generics (which Rust currently does have); that's a pretty hard sell... Tooling matters a lot, and that's why we're investing in…
You'd have a much easier time arguing that go not having a package manager makes you less productive compared to cargo (very true); you're kidding yourself if you think having generics makes up for having to write your own AWS client in terms of productivity. Can you build something more quickly in go right now, than in rust? For many applications, the answer is, right now: Yes. Building (using the tooling that does…
I'm arguing _against_ any one feature; I picked generics because it's the classic criticism of Go. I do think that package management might be a bigger factor, but my point is that there are multiple factors. You can't say "well Rust doesn't have tooling, so it's not productive."
I think we're mostly in agreement here, other than that I think your first post put too much weight on one specific part of a complex equation, and that you feel there's a clear-cut answer, and I don't.
(I do agree that "there's a package for this" vs "there isn't" is a huge factor of productivity. It's actually the one I personally cite most often when talking about my own productivity in Rust.)
Re: 2017 Rust Roadmap
#120> Rust should provide a solid, but basic IDE experience
After using IntelliJ IDEA plugin [1] (works in free community version too), I don't understand what else people need :) Plugin is pretty powerful. Also Racer works great in VS Code and other editors.
> Rust should have a lower learning curve
Rust is easy enough to learn, the only issue is a steep start. After couple of months everything is not harder than JS and smart compiler actually makes me more and more lazy :) So I think only thing we need is books/articles to help people switch from other languages, to help them overstep initial difficulties.