Rust 2020: Growth

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:

  1. one doesn't actually need to use all these types all the time,
  2. that they aren't that different and are convertible to each other,
  3. 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.

7 Likes

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.

2 Likes

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.

15 Likes

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.

4 Likes

That is an interesting observation.

Here is mine:

A few years back I was fascinated to see what goes on in CS education now a days. So I watched a whole undergrad lecture series by Professor Brian Harvey of UC Berkeley on Youtube. Perhaps it was this one: https://www.youtube.com/watch?v=4leZ1Ca4f0g&list=PLhMnuBfGeCDNgVzLPxF9o5UNKG1b-LFY9

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.

9 Likes

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.

Why do we need snaps when we have:

curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh

?

Which works a treat.

There were some concerns about it:

I did not understand what the concerns were.

How is having to download a some random Snap from some random somewhere better than the curl thing?

I'd probably be using curl to fetch the snap anyway ! :slight_smile:

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. :slight_smile:

Yeah. I don't know. As usual if there is ten ways to do the same thing then obviously the way to unify them all is to invent an eleventh way!

It's a damming indictment of the whole computing field that after half a century we still cannot do the simplest thing:

a) I write a program.

b) I can run it on any computer.

1 Like
  • 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".

13 Likes

kornel

So, if I understand you correctly, none of the arguments against installing Rust as we do have any basis in rationality.

But somehow Rust should accommodate the insanity by popular demand.

I was delighted and excited when that curl thing worked. I was amazed how easy it was to get going with Rust.

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.

4 Likes

There is no selling going on here.

I agree, it's irrational to do a lot of work for money making, commercial enterprises for free.

Why are we even discussing this?

I mean that when driving adoption of Rust, we are "selling" it to people. Trying to get them interested and using it so that it can grow.

10 Likes

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.

2 Likes

@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.

18 Likes

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.

1 Like

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!

3 Likes