Is Rust getting it's message out?

This whole JS thing is bikeshed about semantics of vague terms, which doesn't lead to anywhere. Users don't care what is called part of the language, the runtime, or a framework. It's part of Node, and fuzzy edges of the terms don't change what these things do, and how people use them.

Node took off because it made it simple to build network-bound servers, at a time when microservices where hot, and other whatever-you-call-them web thingies struggled to make multiple HTTP requests in parallel.

Node then grew thanks to npm being the easiest way to share code, and distribute development tools. At that time competitors were barely recovering from an old model of manually-installed system-global dependencies with endless versioning and compatibility problems.

3 Likes

I count JS as interpretted. Even if it is JITed and optimized up the wazzo at run time. There is no compiled binary I can ship you!

Perhaps, but the whole language and it's standard API's are predicated on being non-blocking and hence calling for an event loop. From SetInterval() onward (Yes, there are some exceptions). This is not the case for languages like Rust, C/C++, Pascal, etc, etc.

By the way, what is the equivalent of SetInterval() in Rust without using anything out of std?

Yep, as I said "fluffy".

Not entirely useless, it's good to find out how we all use common terms so that we understand each other better in future.

SetInterval is provided by the Runtime (Node or the browsers) and is not a feature of the language itself. If we are to compare the runtime feature to standard library (which clearly is a part of the language itself), it's not apt IMO. Instead just like Node or browser provides SetInterval in the JS land, tokio or async-std provide it in the rust land.

At risk of further "bikesheding" I have to say that I consider things like SetInterval() in JS part of the language standard in the same way strcmp() is part of the ISO C specification.

The crucial difference language wise here is that in JS I can write a single call to SetInterval() and the work gets done. No other code required. In Rust and other languages not predicated on the async model I have to do some extra work to create a run time event loop and start it.

So how does one write the equivalent of "SetInterval(function () {console.log("Hello"), 1000})" in Rust.

I'm actually curious about that. I have not looked into async programming in Rust, or at least when I do it seems very confusing off the bat and I gave up.

There's probably a bunch of ways, but a little googling immediately got me to tokio::time::interval_at - Rust which seems about as simple as one could hope for, at least for the ticking interval half. The example code shown there:

use tokio::time::{interval_at, Duration, Instant};

#[tokio::main]
async fn main() {
    let start = Instant::now() + Duration::from_millis(50);
    let mut interval = interval_at(start, Duration::from_millis(10));

    interval.tick().await;
    interval.tick().await;
    interval.tick().await;

    // approximately 70ms have elapsed.
}
1 Like

Thanks. As much as I understand that example it does not do what I asked.

This is the closest you can get to reimplementing setInterval in Rust: playground.

For simple cases you can also do this, which evaluates to a Future that prints "Hello" once a second forever. You'd probably want to spawn the resulting future.

interval(Duration::from_millis(1000)).for_each(|_| async {
    println!("Hello");
})

Playground

1 Like

Wow, do I regret reading that comment section of the Slashdot article!
I wouldn't put too much thought into it though. Most commenters seem to be (almost) as clueless about C/C++ as about Rust. In the thread arguing whether Rust does GC or not the people arguing didn't even seem to know RAII.

Many thanks for that. But wow, it's likely to take me a year of study to grasp all of that!

I was about to make a post saying to forget the SetInterval() as such and asking how to get the job done. And there you have it. That is at least simple enough I can comprehend it. Thanks.

This all makes me very nervous, I had thoughts of shunting data between web sockets and a NATS connection all done using async. If this is how hard it is going to be I might never pull it off in Rust.

But that is perhaps a problem for another thread.

I can think of some reasons Rust adoption would be slow:

  • Lack of dead-simple but still impressive tutorials of how to do someing neat with Rust with no prior knowledge of the language.
    • Frameworks written in Rust could help with this.
  • "Security isn't sexy" (or to put it another way it doesn't provide a "wow" factor on an emotional level)
    • Developers/employers don't value Rust's unique tade-offs between ease of coding, and security/performance/etc. Or they aren't enough of a draw to make somebody become an early adopter. Or people simply don't know.
    • "I made an app, and it was about as fast as it should be, it was secure, and nothing blew up, nobody's data was compromised or corrupted, and nobody got fired" just isn't an exciting conversation, on an emotional level. Things not happening is hard for the human brain to really latch onto as a topic.
  • People who succeed at pariticpating deeply with the Rust ecosystem seem to be experts (advanced programmers and/or deeply familiar with Rust), IMO, creating a sense that one also has to be an expert to succeed with Rust.
    • Seeing other beginners around, and resources targeted at us, would be encouraging.
    • Project organizers being of and among the community seems like a good thing, but...
      • Top-down structures are easier for orgs to understand.
      • Scrappy vibe might be off-putting.
      • Rust leans on community discussions for what direction the language should take, so any/all Rust discussion has the spectre of being responsible for the fate of the language (intimidating).
        • Rust community is very meta IMO, and talks a lot about Rust itself, almost moreso than in-the-wild usages of Rust they need guidance on deploying/hacking. (Conversations devolve into "maybe the language should do this/that").
        • Constant meta discussion makes me feel like the language isn't finished, and the next big thing is always around the corner, so why start now when I'll soon be out of date if I hop off the train for a bit?
  • Someone else said "no killer app" is a reason. But I think Rust's association with Mozilla, and that similar ethos, tends toward a pro-social community of developers, but not "move fast/break things" disruptive, which has been more the zeitgeist as of late.
    • Rust community members are too nice to want to "break things" gratuitously, so they don't "disrupt" things gratutiously or for profit. And they're too ethical to want to come up with clever ways to part the masses from their money. So less chance of a quick money-maker business activity popping up around Rust. (Employment/profitability drives adoption in a world where programming as a day job neess to put food on the table.)
3 Likes

I'm curious where you got this impression, because I see a veritable barrage of anecdotes about how new contributors are succeeding but we also need to do X or Y to make it even easier for them.

It's commonplace for Rust conferences to have a talk by a new contributor to a Rust project or to Rust itself walking through their contribution experience. There's a whole mdbook just on how to contribute to rustc. Every TWIR has a "Call for Participation" section. There are entire blogs about topics like building "my first OS" entirely out of Rust, often written by people who've never done anything of the sort before. And maybe this example is unfair somehow, but I have an accepted RFC despite having basically no experience writing non-toy Rust programs or contributing to Rust in any way beyond some IRLO posts.

If all of that is so invisible to some community of programmers that they're getting exactly the opposite impression, and it's turning them off Rust, that's something we'd really like to know about so we can brainstorm some solutions.

4 Likes

To clarify my perspective: I like computers a lot, and spend a lot of time on them. I can do the slightest bit of programming, usually editing existing code for PRs. I try to approach Rust, but getting proficient at writing it has come slower than with Ruby/JS.

I do think it's trickier to pick up. (My expectation may be unfair, since these are interpreted languages. I'm much better with those than Rust or even C.)

As for my criticisms above: maybe it's just that I've spent so much time learning about the rust community/developer story that "knowing about [meta] Rust" takes up more space in my brain than actual programming knowledge/experience programming with it.

I blame "meta Rust stuff always being adjacent to docs/getting started resources" for that heavy association that I have between the two.

You can't look something up without being reminded that things are subject to change, and hey, maybe you personally will make the change! ("Why not! Go for it!") Which, cool, but I literally learned more about meta Rust stuff than using the language, so... This sounds weird to say, but it's distracting. (To be fair, I have ADHD, so maybe that's a part of it. I see something about meta that's framed as being exciting and I want to look it up.)

I was personally able to submit a PR to improve an error message. So yeah, I can contribute. (BTW, thanks everyone who helped with this or was encouraging!)

As a programmer in any other language, I spend much more time thinking "how do I make my code run/stop erroring" but with Rust I think a lot about "where is the language going" and "what component updated that makes me have to look where for docs" (aside: everything is super modular in the Rust ecosystem and seems to have its own independent, near-rolling release schedule)... All these blog posts/proposals have interesting stuff in them, do I have to know about this?

I have often been told when I say things like my above comment that I'm wrong, that Rust is super accessible. Maybe everything is so accessible that hitting a first snag feels worse, as my expectation are high. Or... maybe the experts in the room are inclined to think everything is hunky-dory, despite them being too advanced to see the snags a total beginner runs into. (I admit it is difficult to see outside of my perspective to see if I might be wrong about the "experts," because I consider myself not part of that group.)

As it stands, my skill in reading Ruby/JS is higher than my ability to read Rust. And I feel like I may have spent equal time learning about each.

tl;dr Learning about meta stuff is required for actually contributing to improving the language. But it doesn't necessarily make you a better programmer. I have found myself side-tracked by meta stuff/community, because it's maybe more interesting than buckling down and learning to code Rust.

All told, I am still really fond of the community, I just think it's ironic I like them so much without my being able to code Rust very much.

P.S. In having to defend this view (here and in a couple of previous posts), I'm starting to realize I like the social aspects of programming, and helping people by submitting PRs, and I might naturally gravitate to the more social side of programming than the nitty-gritty systems code side of things. Rust stands out for having a lot to do socially. I wish I could write it better, but I never learned a ton of C either, so it could just be that these languages are harder to learn than the ones I'm better with. In which case the social stuff being "a lot to take in" could be a red herring, regarding whether there's a blocker to learning to write Rust proficiently.

5 Likes

Honestly I think WASM is Rust's killer app. It's still early days, but in time it will have a larger reach than JavaScript. Browser vendors will ensure it.

2 Likes

Related reddit post. Link

1 Like

Could somebody who does reddit try and correct the last post in that link that asserts that Rust is "...good for everything except for system development .." apparently on performance grounds.

Why oh why do people make such assertions when they clearly don't know and have not tried for themselves?

Note that it's a 2 month old post at "0 points", i.e. someone already downvoted it from the default 1 point, which is why it's displayed as the last post. At this point responding to it in any way is probably worse than letting it sit there as-is. Plus, the post's writing is confused enough that I'm genuinely unsure if the post author believes Rust is bad for system development or if they're talking about a claim they've seen elsewhere... perhaps that unclarity is what got it the downvote.


Back on topic, @DeeDeeG for what it's worth I do agree that Rust discussion has a lot of meta stuff in it. I know I'm one of the people actively contributing to this, but I also genuinely believe that for a language this young and this actively evolving it is more constructive to answer questions with "not yet, but there's an RFC for that" then a flat "Rust can't do that." I don't think anyone would disagree with the claim that Rust is still "incomplete" in a very deep and fundamental sense, and for many projects it just isn't ready yet.

I also think everyone would agree that Rust is a harder language than Python, Ruby, Javascript, etc. I'm personally fond of saying that "Rust is the best second language we have", because it's far easier to learn and get productive in (i.e. without reimplementing basic data structures or spreading unintended UB everywhere) than other systems languages like C or C++, but the essential and unavoidable complexity of a systems language (e.g. stack vs heap, thread-safety, lifetimes, owning vs non-owning types, all of the string types) is still overkill for someone's first programming language and a lot of real software.

4 Likes

You're absolutely right. People want to use X on the front end. How do they get X to run in the browser? Wasm via Rust. So driving adoption from that standpoint means working on making that as painless as possible. Initially, many people will use Rust out of necessity, as their real priority is getting language X in their stack where JS used to be - but using Rust to enable that exposes people to all of its power/benefits. Perhaps they then choose to write something in Rust, even where they have other options. Perhaps they will discover existing front end Frameworks in Rust and decide not to bother compiling X to Wasm. The work that has been done to facilitate Wasm as a target is not something many people will want to implement from scratch, so it's likely Rust will be the default pathway for some time.

1 Like

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.