In my mind I can boil down everything you have said to something like "We need people to do for Rust what people like Scott Meyers, Andrei Alexandrescu and dozens of others did, over many years, for C++".
That would be great. But Rust is still a very young language. Back in the day when C++ or Java arrived there was also little material, and no large code bases, to learn from. Only a bunch of hastily put together "Learn X in Y days" kind of books, churned out for a quick buck. I would claim Rust is already in a better situation in that regard than C++ or Java were in those early days.
My experience over many years is quite the opposite. Just say'in.
I'm a little surprised by your experience. I read The Book and started coding, even though I didn't know anyone else programming in Rust. I had trouble with the borrow checker until I stumbled on a blog post that helped me understand that it was about memory management, not just data races. That insight allowed me to understand what the compiler messages were telling me.
Within 2 months I had the basic parts of a simulator of a distributed system running. My strategy was to use only the basic parts of the language. No references in structs, extensive use of clone() to satisfy the borrow checker, no macros of my own, std::thread for concurrency, no interior mutability. Only after that did I introduce traits and generics.
My guess from your comments is that you are trying to contribute to a mature project that is likely using advanced features of the language. That sounds like jumping into the deep end of the pool after a single swimming lesson. Perhaps spending some time developing something from scratch can get you over the hurdle.
Hmm... you have spent a year with Rust, exhausted not one but multiple channels of learning, and are still struggling. This does not match with the experience of any Rust programmer I've encountered. Something is amiss.
Since you mention function signatures, are you struggling mainly with lifetimes? Can you perhaps paste an example code snippet which you found difficult to work with?
Buddy, based on your "requirements" and high attitude towards the language and community maybe Rust is not a right language for you? Based on your comments, feels like you demand things to be a certain way, like the language owe you something. It's not. No hard feelings, but It's okay if you didn't like the language, there's no perfect one.
I don't understand how you came to this conclusion. It seems to me like OP very much likes the language but is hitting roadblocks. Many of his complaints are very legitimate. Most of his problems boil down to rust not being mature, which I'm sure we all agree with.
I'd rephrase this part just a little bit to emphasize what exactly of Rust is immature. It's the learning material and library part of Rust that's not mature; the language part, on the other hand, is.
Pretty much anything other than the core language is immature, for example the entire async ecosystem. Mongodb's official async support is barely a month old, I was using the golang driver with FFI before. I'm still using some guy's pull request for serenity because the async variant hasn't been merged yet.
async await itself is pretty new, I don't see how this is considered mature. And these are just things I've run into doing one toy project in the last three months I've interacted with rust. What are people doing actual work with this facing?
Well, that is onlyasync though. The async-await syntax sugar is pretty new in Rust, yes, and apparently that discouraged library writers from writing async APIs. (It should not have, alas – futures have been around forever, and it's possible to write great async APIs around future combinators, but somehow Rust users are in general unwilling to).
A lot of other aspects of the language are, however, very mature. The borrow checker evolved enormously, and has become a lot smarter than it was in 2015, near 1.0. The same with std, a lot of minor inconveniences have been addressed. Const evaluation and UB-detection with MIRI are also developing fast. The type system is strong and smart. There are great libraries for general plumbing (serde, clap, structopt, libc, syn and quote, etc.) Speaking of syn and quote, procedural macros are now very powerful and general, and can take the form of a custom derive, an attribute, or a function-like macro.
Asking "how even people are doing actual work with this" is quite rude, I have to say. They are doing actual work with it because it's possible. The fact that you reduced the whole maturity argument to "but not enough async" is your problem, not that of the language or the ecosystem.
(By the way, what about languages without builtin async syntax? Would you say that any such language is by definition immature? That's pretty much not the case.)
I think I came off as much more irritated than I really am, I meant it like "people probably face plenty of inconveniences while working with rust which will probably become significantly easier in the future". I also wasn't necessarily disagreeing with the person I was responding to either, I also think the language itself is more or less in a feature complete state and it's the library ecosystem that needs to grow. Sorry if I came off as offensive, I am a big fan of rust, same as everyone else here.
Yes, I'm afraid there isn't one. Geo is quite a niche area, and Geo plus ORM is even more niche. You are essentially out of luck at the moment if this is a hard requirement for you. The closest thing that exists is postgis, but it is not an ORM.
You can achieve this by adding one or two crates to your project: The geo and geo-types crates exist and interact to provide all the usual geometry primitives, as well as a wide range of algorithms for working with geometries. There are also crates that allow you to work with Shapefiles, GeoJSON, and as mentioned above, PostGIS, all of which are based on or interact with geo and geo-types. The base libraries are extremely well documented (source: me. I wrote and maintain a lot of the documentation and examples, along with a small but active group of contributors), providing numerous examples to help get you started. In addition, there is a dedicated Georust Discord, though I should note that it's community-run.
Additionally diesel is designed in such a way that any third party crate can add support for any of their own types quite easily. Therefore I consider the statement that Geo + ORM does not exist in rust as false.
This sums up my experience. There are many things I ended up looking for hours because it's not documented. However I see this as obvious, when the community is not as big as others.
Anyway, I ended up witg golang, where I can do the same thing much faster.
I watched your talk, it's great, highly recommended. Your advice to be ok to write unidiomatic rust is the best one. I am going to read your book. Thank you for video. I'm not sure if this is the place, can you make video on writing extendable libraries ?
In my past programming experience inheritance and polymorphism gave me the power to reuse code and extend libraries, that was my struggle with rust multiple times. How can I make extendable and reusable libraries(e.g, someone can take my library and override my types and add them for their own use), in rust? If I use multiple non compatible (e g some libraries don't use serde, but others need it) libraries in my project, how can I make them ? These topics are difficult to me.
If you define a public trait, anyone can implement that trait for their own types to interoperate with your library.
The newtype pattern, and encapsulation more generally, allows users to use your library’s functionality to provide their own services.
Splitting things out like this is more flexible, but at the cost of some boilerplate when you want a mostly-transparent proxy: If the downstream developer needs to, they can write a completely new implementation of your trait, or their newtype can change behavior in ways that would then be incompatible with your library.
Usually, this involves writing some kind of adapter type that holds a type from one library and implements traits from the other.
I could see that. Rust being the only language I've properly learned, I had no ingrained preferences or resistance to anything in it. Lifetimes? Sounds good. References? Interesting. Borrow checker? Very helpful! <Lots<Of<Types<Enclosed<(Inside, Others)>>>>? Beautiful!
Sorry to say this, but some newcomers probably suppose that Rust should be easy to pick like a dynamic type language. That's no how Rust works, Rust force you to really be aware about what you are doing without guessing. That means you need to take your time learning, understanding and working with it in order to satisfy every time better the compiler.
It's not just the fact of why there is no a library o framework or why I can not do something easily with Rust. It depends.
Invest you time evaluating your use case requirements and then decide if Rust fit your needs.
If so, invest your time and be confident enough with it. Because from my point of view, there is no "Rust - The easily way", and I'm not a fully confident Rust dev yet, but working hard for that.
I don't want to discourage people interested on Rust, but have in mind that learning a new language has a cost that you need to "pay", and Rust is not the exception.
.