[ramon156]

As a rust dev I'm just as perplexed. I've seen preprocessors and stuff like tailwind being rewritten in Rust aswell. Why though (

[Tade0]

As a (nominally) front-end developer the RIIR movement's energy is similar to how the front-end community approaches things.

Overall Rust and its community have many traits that make them very approachable to people not expected to know anything about systems programming, namely:

-Package manager with a familiar philosophy behind it (and not the sort of hell you have to deal with setting up a C++ development environment).

-Outputs WASM without much bureaucracy and advertises it.

-Friendly compiler messages. I don't recall seeing "perhaps" in a compiler error message before.

The people designing Rust put much effort into making the language as approachable as possible and that's the net effect.

That is not to say this is going to be necessarily successful, but so far the enthusiasm is there.

[mtsr]

Some dev workflow tools really benefit from being very fast. And parsing and ast building and the like are actually things that rust is quite good for.

That doesn’t mean it couldn’t be done in other languages, but it’s a weighing of trade-offs. And of course, groups of people, such as developers on socials, are quite sensitive to popularity.

[vsnf]

> And parsing and ast building and the like are actually things that rust is quite good for.

Having built a compiler and typechecker in Rust, I don't know if I'd say that it was "quite good" for it. Going back, I'd still do it again, but it wasn't exactly a cakewalk. Rust's lifetime rules and visceral hatred of referential structs did not make my life easy at all. I definitely took the easy way out with a lot of string copies too.

[dbrgn]

Just as an example: Our eslint checks take 2 minutes to complete. Improving this would considerably improve developer productivity.

[biorach]

> I've seen preprocessors and stuff like tailwind being rewritten in Rust aswell. Why though

a) speed. On large codebases each preprocessor (and there may be many) can take a long time

b) Rust has several features which make it quite suitable for writing pasrers and suchlike

[fullspectrumdev]

If it speeds up a build/CI pipeline it’s a worthwhile investment for a lot of folks

[RamblingCTO]

You can get a big speedbump with go without introducing the overhead of object lifecycle management.

[xnorswap]

Your sentence is confusing; a speedbump is designed to slow you down.

[RamblingCTO]

Haha, you're right. I meant speed bump. As a German I'm used to chaining words together.

[xnorswap]

It wasn't the chaining that was an issue: https://en.wikipedia.org/wiki/Speed_bump .

Perhaps "speed boost" would be a better alternative for your intended meaning.

[jamincan]

Interestingly "bump in speed" would be fine, but "speed bump", means the exact opposite.

[jasonjmcghee]

It isn’t in this context. “got a speed bump” vs “hit a speed bump”

[crabmusket]

Then rewrite Prettier in Go and I'm sure people will use it :)

[RamblingCTO]

Not slightly interested. My point is: we have tools that fit the problem better instead of supporting the hype train of rust.

[jamincan]

What do you suggest would be better? Command-line tools, parsing and parallelism are all things that Rust excels at.

[RamblingCTO]

Why on earth would you need object lifecycle mem management for these things? These are points where Go excels as well. Rust is meant as a systems language, I'd love to have it as a general purpose lang as well, but it's not imho.