131–140 of 201 posts
I know the list isn't necessarily prioritized, but these 3 feel backwards.
A good IDE will provide can help facilitate easier edit/compile/debug cycle which makes learning the language faster because it's cheaper (time wise) to figure things out.
Earlier quoted context omitted.
> > any nontrivial project will make use of unsafe blocks. I don't think that's actually true? Most projects make use of no unsafe outside of stdlib and a handful of crates.io crates.
This has been my experience also. I've written at least 40kloc of rust over the past couple years (including complex graphs with cycles, low-level DSP) and I could probably count the number of unsafe blocks I've needed on one hand. edit: This is not counting FFI though.
I would love to see Rust with a REPL. I use Python professionally a lot and have done a fair amount of OCaml in my spare time and both have excellent REPls in the form of `ipython` and `coretop`. Quick experiments with auto-complete is incredibly helpful for exploring a language. That's the only thing I really miss from those languages; when I want to wrap my head around a bit of syntax or a library feature in Rust,…
I assume you mean OCaml's "utop" ?
> Rust should have a lower learning curve Rust should have a pleasant edit-compile-debug cycle Rust should provide a solid, but basic IDE experience I know the list isn't necessarily prioritized, but these 3 feel backwards. A good IDE will provide can help facilitate easier edit/compile/debug cycle which makes learning the language faster because it's cheaper (time wise) to figure things out.
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.
Earlier quoted context omitted.
> for example, are algebraic data structures just tagged unions They're tagged unions with no implicit heap allocations. I guess we should at least document that in the reference (though we don't want to overspecify, because we do some tricks in the compiler to try to avoid leaving space for the tag if we can). But I don't think it'd be a good idea to document this straight away in the book: the goal is to make Rust…
Speaking of "guaranteed not to allocate", is there a way that you could express that in a type? Seems like that might be nice to have.
>1 in 4: learning curve
>1 in 7: lack of libraries
>1 in 9: general “maturity” concerns
>1 in 19: lack of IDEs (1 in 4 non-users)
>1 in 20: compiler performance
>None of these obstacles is directly about the core language or std; people are generally happy with what the language offers today. Instead, the connecting theme is productivity—how quickly can I start writing real code? bring up a team? prototype and iterate? debug my code? And so on.
I don't really see how this conclusion was reached from that data. The "learning curve" is almost certainly a reflection of the language being a little esoteric and the demands of the borrow checker. And "lack of libraries" is partly a comment on the ecosystem, but also partly shows that std is obviously lacking for some needs. Finally, "general maturity concerns" refers to worries that the language or std will keep changing, as is assumed they have not been perfected yet.
Those are the top 3 concerns and to me, both seem to relate directly to the language or standard library.
Earlier quoted context omitted.
It's also important to note that Go was designed for programmer productivity and Rust wasn't. GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Compile times in Go are a fraction of Rust compile times, which is another productivity boost. Go gives you one good way to do concurrency, Rust believes in tyranny of choice. Without mentioning that you don't pai…
> GC is incredible productivity boost which is why no recent language (except Rust) does manual memory management. Swift is a recent high-level productive language without a GC.
Earlier quoted context omitted.
> Are you saying that Rust, a system programming language, can compete with the scripting languages in speed of developing features?! I'll say it. At work, the backend is Rails, and I am a Rust contributor in my freetime. I am in the early stages of working on a framework for web apps in Rust & I believe it will be comparatively productive to Rails. Only your code will be faster and many bugs will be caught at compil…
Bold. :-) I do hope you're correct. (Given a modest test suite and checking parameters at external API interfaces, scripting languages didn't have much problems with bugs that could be found at compile time, imho.)
>We asked both current and potential users what most stands in the way of their using Rust, and got some pretty clear answers: >1 in 4: learning curve >1 in 7: lack of libraries >1 in 9: general “maturity” concerns >1 in 19: lack of IDEs (1 in 4 non-users) >1 in 20: compiler performance >None of these obstacles is directly about the core language or std; people are generally happy with what the language offers today.…