undefined | Better HN

0 pointszarzavat1y ago0 comments

My reading is: people use Rust because it’s fast but then they complain about the semantics that make it fast.

In other words, be careful what you wish for.

Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity. However, once you deviate from the goal of “as fast as possible”, then you have to choose which parts you want to sacrifice speed for productivity. Like Excel, everybody agrees that Rust is too complicated but nobody can agree on which 10% to remove.

0 comments

sk110011y ago

> people use Rust because it’s fast but then they complain about the semantics that make it fast.

I don't think most people use Rust because it's fast - fast is nice but Rust is being thrown at a bunch of use cases (e.g. backend services and APIs) for which it replaces "slower" garbage collected languages (the language being faster doesn't always make the overall product/service faster but that's a separate question).

What Rust gives you is a viable potential alternative to C and C++ in places where you absolutely can't have a GC language, and that's a huge deal, the problems and confusion start when people try to use Rust for everything.

> everybody agrees that Rust is too complicated

I don't think this is true either - a large part of the Rust community seem to think that it's as complicated as it needs to be. As a beginner/outsider, I found it kind of cumbersome to get started with, but that's certainly not everyone's opinion.

> Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity.

True, and such languages already exist and are widely used, Rust doesn't need to fit that use case.

zarzavatOP1y ago

> I don't think this is true either - a large part of the Rust community seem to think that it's as complicated as it needs to be. As a beginner/outsider, I found it kind of cumbersome to get started with, but that's certainly not everyone's opinion

With any language there’s an active part of the community and then there’s the “dark matter” of people who use the language but are not actively involved in shaping its direction, forums or subreddits, etc.

Of course the people who are actively involved are likely to be of the opinion that all the complexity is necessary, but I doubt that applies to the broader Rust userbase.

zerodensity1y ago

Personally I feel it's not complicated enough. Where is my function overloading, variadic templates and usable compile time reflection? (Sure you can sometimes use macros but ew macros)

swiftcoder1y ago

> Personally I feel it's not complicated enough. Where is my function overloading, variadic templates and usable compile time reflection? (Sure you can sometimes use macros but ew macros)

Indeed. Rust is really crying out for a real CTFE implementation + richer macros to replace the mess that is procmacros (I really don't want to have to run an arbitrary external binary with full system access just to manipulate the AST...)

d_tr1y ago

> Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity.

D maybe? D and Rust are the two languages which come to mind when I think about "possible C++ replacements".

cdogl1y ago

When GP said “most”, I interpreted it more broadly. Most applications simply do not require the guarantees of a non-GC language. When you expand that horizon, list of contenders becomes considerably larger - even when restricted to statically typed languages.

zarzavatOP1y ago

Yes for example many Python users switched to Go, a native code GC language, and are satisfied with the performance.

There’s also the middle ground of Swift’s memory management which uses compiler-elided refcounting - i.e. the compiler detects when a count goes up then down again and removes those operations.

1 more reply

j / k navigate · click thread line to collapse

0 comments

sk110011y ago

> people use Rust because it’s fast but then they complain about the semantics that make it fast.

> everybody agrees that Rust is too complicated

> Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity.

True, and such languages already exist and are widely used, Rust doesn't need to fit that use case.

zarzavatOP1y ago

Of course the people who are actively involved are likely to be of the opinion that all the complexity is necessary, but I doubt that applies to the broader Rust userbase.

zerodensity1y ago

Personally I feel it's not complicated enough. Where is my function overloading, variadic templates and usable compile time reflection? (Sure you can sometimes use macros but ew macros)

swiftcoder1y ago

> Personally I feel it's not complicated enough. Where is my function overloading, variadic templates and usable compile time reflection? (Sure you can sometimes use macros but ew macros)

d_tr1y ago

> Most people would probably be better served by a language that was a tiny bit slower but had better developer productivity.

D maybe? D and Rust are the two languages which come to mind when I think about "possible C++ replacements".

cdogl1y ago

zarzavatOP1y ago

Yes for example many Python users switched to Go, a native code GC language, and are satisfied with the performance.

There’s also the middle ground of Swift’s memory management which uses compiler-elided refcounting - i.e. the compiler detects when a count goes up then down again and removes those operations.

1 more reply

j / k navigate · click thread line to collapse