C doesn't even have proper string handling. A string type doesn't even exist in C, it's handled by a pointer type and conventions. In-memory string formatting is a mess, it's not even possible to do it correctly in C89 (because snprintf() is C99 only, and sprintf() is trivially prone to buffer overflow). As such, this is one case where language-level simplicity actually makes life painful. I don't think that the "simplicity" of not even having a proper string type is fair to compare to the properly engineered APIs found in Rust.
And by explaining the details, my goal was to show that:
one doesn't actually need to use all these types all the time,
that they aren't that different and are convertible to each other,
and that the issue of error handling is not specific to strings, and deserves more learning, and attention in general.
As I said before, I do not disagree that more or better documentation is good. I only disagree with the sentiment or expectation that everything should be easy or even effortless.
This is right I was confronted with those difficulties when I first tried to develop a Real World Application beyond the "hello-world" Application for a real use case.
Since the question was "What stops Developers from using Rust?" I found it suiting to share a Newbie Experience
Actually there are Languages that let you be productive right from the first day (flat learning curve) and those that require a lot of study to do a simple task (steep learning curve).
As regarding to good documentation I always found that the Java Documentation is the best explained. Java has a lot of Class Complexity but the Documentation with Examples helps you to find your way around.
Working with Dates:
A little Example to launch a process and redirect the output to a file
The Example works and gets you already going.
But if you like you can dig deeper and add additional features.
But all this comes from the good documentation.
Where the documentation is scarce and the examples are few or not really practical people are not likely to work with it.
A Developer can work with any Language if the Documentation is good.
Otherwise he will have always have a hard time with it.
I always saw the idea of a language with a flat learning curve to be a myth.
Sure, one can fire up a Pyton REPL and start typing away without even knowing what a type is, but they'll have to repay that cost elsewhere. They'll have difficulties later when the code must be maintained, read, and understood. Or one can write a C program and enjoy that char * is the only kind of string, but it will be painful to debug the double free and use-after-free bugs which are present because ownership is only a convention in the language.
Writing correct code is hard, no matter the language, and I'd much rather find out about my mistakes sooner than later.
Java has been around much longer and has been invested heavily into by many-many large corporate groups. It's pretty much one of the de-facto language for most university programs related to computers. (I am aware of places where it is the first programming language introduced at 7/8 grade in school itself.)
For a community driven language like Rust, most of these come from volunteers (usually unpaid). Things will eventually improve (I'm hopeful).
What I can say is that, it's not really as daunting as first few of weeks of experience with learning the language will have one believe. At some stage of learning when borrow checker becomes clear, it feels not just intuitive but makes one wonder why more languages do not have it. Lifetimes can be another hurdle but what helped me was reproducing the the problem it was designed to solve in C and then thinking about how lifetime (if present in C) would fit as a solution.
Similarly, the wide variety of string types is just that - each one is designed to solve some problem and, here as well, it helps to reproduce the problem in a familiar language and thinking about solutions for it.
The whole thing was done in Scheme. A language I knew nothing about. Not his students either. I was amazed at how Brian introduced the language in lecture one and then the course immediately proceeded into talking about programming. Linked lists, trees, whatever data structures, parsing, language interpretation, algorithmic complexity. The whole deal.
I found myself checking out the same course, by a different lecturer some years later. It had been "upgraded" from Scheme to Java.
Good grief, some weeks into the course the lecturer was still having to explain the technical details the syntax and semantics of Java so that his students could get anything to work at all. They were far behind on all that good CS stuff they were supposed to be learning.
My conclusion at the time was that Java was a really bad idea as far as pedagogy goes.
Of course it does not matter today. All the universities have switched again. To Python.
As far as packaging concerns ( .deb, .yum, curl | sh, etc. ). You might also look into making a snap:
That runs on pretty much every Linux distro and doesn't require getting bought-into by distro maintainers. A snap maintained by the Rust automated builds would be updated for every distro whenever Rust puts out a new release.
I don't know exactly, but I saw some talk about a .debs or .rpms and though that if those were warranted, having a package that was distro agnostic that would be an improvement on that. This is a massive topic, but I figured I'd throw it out there in case somebody thought it was useful.
It doesn't work properly with package management software.
It can't be guaranteed to work exactly the same way in 10 years. Companies that have long-term support contracts for their software want to ensure they will be able to promptly release a security patch in 10 years from now, without upgrading anything. You can't be sure if rustup.rs domain will even exist in 10 years, and whether it'll install something that still works for a 10-year-old Rust project.
This is not a theoretical concern, build.snapcraft.io has already been broken by changes to the curl script (so ironically, I wasn't able to release snaps of my Rust software, because they weren't using Rust from a snap).
curl | sh has irrationally bad reputation. There are some movie-plot-like "undetectable" attacks it could perform. There are some bad failure scenarios encryption doesn't prevent. There are some other scripts out there that behave poorly. None of these actually apply in Rustup's case, but people have these prejudices.
For reasons that may be technical or ideological use of curl | sh may be disallowed as a matter of policy.
I've been a few times in a situation where I had to defend curl | sh. It's really hard to explain to someone that I want to use a tool that's "against company policy". It's really hard to explain to other people who are prejudiced against curl | sh to run it anyway. It wastes so much time, energy and goodwill to convince people to do something they don't want to do. I don't want to be forced to explain to people that their threat model is illogical. New Rust users should be installing it with excitement, not with "ugh, fine, I'll run the stupid thing, whatever".
Rational or irrational, it is a valid point to understand the way that people will perceive your software and the way that they have to interact/install/use it.
It is essentially marketing. It doesn't matter how good, bad, rational, or irrational something is if you can't sell it. So, if you can fix a perceived flaw that will impact people who want to use Rust, then you will instantly lower the entry barrier for anybody with that perception and potentially gain a user/ally that you might not have gained otherwise.
First impression in particular is very important to anybody who is trying something out.
If you liked the curl | sh install and would have preferred that to anything else, then that is also an argument to have that method available to install the software. There is no reason not to have both options if we have the ability to do so.
Documentation makes it clear when to use them. Most people will use String and str, with str being pointer/reference type to the String.
People coming from higher languages will have problem with Rust as Rust is still a low level language compared to, for example, Perl/Ruby.
Hence, when I compared, I compared Rust to C++, and it is the only language competing with C++. Maybe not officially but this is the only language I see if I want to replace my C++ coded software with any other language with better memory safety properties.
@ZiCog Some users have a firm policy of using only software from packages. Such policy may have many perfectly rational technical reasons, such as need for compatibility with preexisting system management software and build systems. For these users Rustup is a problem, and the Rust project fails to cater to this group of users.
I get it doesn't include you, but different users have different needs. Growing user base means catering to new users who weren't able to use it yet.
It's also worth keeping in mind that probably everyone in this forum is not representative of users who've chosen not to install Rust. If you're here, you've been able to use Rust. But there are users who are not here, who've been turned off by Rust failing to cater to their needs.
Rust is free to choose who it caters to. Some choices are important, such as not catering to users who want a GC-based language. But some choices or omissions IMHO are unnecessarily hurting Rust, such as de-facto requirement of using curl | sh, which is not a universally accepted method.
Some thoughts about Rust 2020 Grouth...What do think about supporting of modular conception (like Component Pascal, Nimrod, Oberon, Modula 2,3) that allows hot-swapping modules within running program.
From my point of view, Rust has already left the experimental field (my boss asked me what Rust is). Rust is built on an excellent foundation and the objective for the future years in my opinion is to keep on target: Simplicity and efficiency. Tools like the compiler, cargo, clippy are absolutely awesome for example compare a maven file and cargo.toml . When I do java again I realize how simple and efficient Rust is and I'm not even talking about an angular project with configuration files everywhere and if you don't touch it up for a year it doesn't compile anymore. I really hope that Rust stays with these objectives. Now that the async await and future elements are available in addition with the integration wasm Rust is mature for me. Today I still have a little trouble with the notion of API client/server REST type API I am not completely comfortable with Actix / Tokio but it already works well. In addition, the community is active and efficient. Grow? yes why ? but not to become an unmanageable mastodon taken over by a major technology group.
Thanks to all of you for making Rust so cool and efficient!