Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Why Rust is bad?

#1
(03-13-2019, 12:16 PM)martin-t Wrote: I see why you might be worried i wanna push for a "rewrite" in rust no matter what. From another person's perspective it might seem like i really like the lang. I don't. Well, a little. Rust is bad. It's just WAY less bad than all the others i've tried and i think it aligns pretty well with our needs.

Ok, I'm genuinely interesting what do you think is bad in Rust.
?️‍? <- that should be a rainbow flag emoji.
Reply

#2
For starters, there are the typical complaints about compile time and the resulting IDE experience (which depends on rustc for now, an on demand driven compiler frontend is WIP).

The syntax (as much as i hate people who focus on it as their only complaint). I heard it was different in ancient times but they changed it to appeal to c(++) devs more. It just sucks that the world can't seem move on from C-ish syntax. Rust is sometimes a bit noisy since its whole point is that it has more information about memory and mutability (a lot could be infered but it serves as docs and provides more localized errors) so if it has explicit lifetimes and references, it could at least cut down on {} and (). Something more pythonic or haskellish would be awesome. There could even be automatic converters like there are for style currently. You could write curly braces if you insist on them and then have it formatted to use indents. Or you could only format when commiting. Some people seem to hate indent based blocks but I have never heard a technical reason why it shouldn't be possible. I pretty much haven't even heard anyone else proposing it. Sad

Infix functions would be awesome `v1 dot v2` is much better than `v1.dot(v2)`. Kotlin has them.

Semicolons - kotlin shows you can have an expression based lang and not need semicolons (though it doesn't have implicit return of last expr, maybe that makes it ambiguous, though i doubt it, kotlin has implicit return in lambdas afaik).

The syntax has some dark corners around bit ops and patterns. Similarly https://github.com/dtolnay/rust-quiz will break your hope in rust or humanity's ability to design decent langs (at least clippy warns on a lot of those).

Enum variants are not their own types. I know it would be messy to implement properly (i guess in a way it's subtyping) and that's why it's not been done yet but haskell does it afaik. You run into it when writing compilers and parsers. If you want separate types for the variants you end up writing repetitive shit like this.

I'd like type annotations in some functions to be optional (and by optional i mean inferred, not some dynamic shit with unsound type systems). It can be done, the inference algo can handle most cases as evidenced by lambdas, but it's intentional because the types serve as documentation and they prevent you from accidentally changing the interface by changing the implementation. Neither should be an issue for private functions or when prototyping.

Type errors as warnings. This is a hard one because i am not 100% sure it can be done. I think this comment describes a similar issue that my suggestion would run into though i haven't given it much thought. Basically the code would panic when you enter the wrongly typed path but only when you enter it. This would make refactoring easier since you wouldn't need to comment out huge blocks of code when changing types if you're unsure about your changes.

The newtype pattern is too verbose. When you realize Ada can express some things more concisely (look for Types heading though the whole article is interesting) it makes you sad. Sometimes you wanna wrap a struct (or a few - the whole composition over inheritance thing) and forward some of its (their) methods. Currently you have to do it manually, i think Kotlin can do it using the `by` keyword but i can't find any good examples. Maybe it can't.

Similarly i'd like physical units as types. Xon had a bug because somebody was multiplying time by time instead of adding. That just shouldn't compile in 2019.

Some examples in The Book aren't the greatest - like associated types (can't find the bad example with graphs anymore, maybe it has been removed finally). Also i think it would benefit from a section about rust patterns - like using trait objects vs enums implementing traits - basically stuff you know how to do easily with inheritance (because pretty much all mainstream langs do it the same way) but rust has a slightly different pattern for it.

There's a couple more (implicit widening conversions, the whole "rust doesn't have inheritance so it sucks" thing, ...) but this is already getting long.
[Image: 30381.jpg]

<packer> when i see martin-t's name my blood pressure increases

<[BOT]Hоtdоg> anyone here lives near martin?
<[BOT]Hоtdоg> will pay monies for shooting him
Reply

#3
A very much subjective list of nitpicking. Personally I find haskell with its custom binary operators and whitespace-based syntax much less readable than Rust even with its explicit lifetimes and other syntax junk. It's really stupid to argue about that. Programming languages are meant to be used by multiple people simultaneously, so the syntax is always a compromise.
Style conversion may sound like a nice thing. It's already heavily used in the javascript world where people convert between cofeescript-typescript-ecmascriptVover9000 and other shit. Can't say I like it though. Perhaps there could be a better implementation ofc, idk.

There are some legit points in your list ofc (especially forwarding for the type wrappers), but would be better if you separated subjective nitpicking from the real issues.
Reply

#4

  1. Bad gamedesign thats only accounted for by regular server-wipes.
  2. You get better faster if you let others do the work.
  3. That forces you to build groups where at least one has to watch for your stuff all the time and be ready to warn you. So you have to keep yourself engaged all the time if you don't want to lose your stuff to ppl implicitly mentioned in 2).
  4. Repetitive survival gameplay. Wanna upgrade the house you farmed wood for, for hours? Just farm more of the more rare stuff till you got the rarest eventually before the server gets wiped(1)) again.

You mean the game, right? Right?  Huh

Well nvm.
Reply

#5
(03-15-2019, 11:34 AM)_para Wrote:
  1. Bad gamedesign thats only accounted for by regular server-wipes.
  2. You get better faster if you let others do the work.
  3. That forces you to build groups where at least one has to watch for your stuff all the time and be ready to warn you. So you have to keep yourself engaged all the time if you don't want to lose your stuff to ppl implicitly mentioned in 2).
  4. Repetitive survival gameplay. Wanna upgrade the house you farmed wood for, for hours? Just farm more of the more rare stuff till you got the rarest eventually before the server gets wiped(1)) again.

You mean the game, right? Right?  Huh

Well nvm.

The most annoying game ever Sad  always pops up in google results when I search smth related to rust
Reply



Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-