Things I hate about Rust

It's filesystem access, like the open file and read file functionality, so it needs some runtime support, and all filesystem access would fail on embedded microcontrollers, so I'm not seeing why it shouldn't be in the standard library.

Throw an exception or return null?

I agree completely that everything about string typing on Windows is worse, especially once you stray off of the happy path. But the post isn't intended to equivocate against a ecosystem with 40 years of legacy APIs in it; it's to nitpick a new ecosystem that I otherwise love ;)

Yeah, I guess maybe nothing will ever be as bad as strings in Windows with C++.

But rust should't go down this road any further.

I don't think them being heap allocated is the issue. I think the issue you're running into is that String doesn't implement the Copy trait, meaning they're not automatically copied for you. Which is what you want, because you don't want to be implicitly copying large strings without realizing it. But yes, it does mean you have to learn the borrow checker.

But I find that Go does not spark joy for me. ('.Dial'?!, first character case denotes public/private D:).

I guess that it is very subjective.

Also a fairly good development experience (compared to C++)

Like, I find it extremely pleasing to write any kind of prototype in Rust and make things work. I guess once you have borrow checker embedded in your head and your newly written code compiles without errors most of the time, it becomes more pleasing, but that's not even the main point. There's something about it that's "just right" for me, not anything in particular but a multitude of various things.

These days I'm working again with Rust to add a new feature to a project after not touching it for months, and that feeling of "oh dear god this is awful" that I felt when I was starting out with the language was back again. However, once everything clicked in, with the compiler telling me exactly what was wrong with the code, and the project compiling which meant that I could be damn sure that the code I wrote would work with little to no risk of breaking in unexpected ways... that sure did spark joy.

Just my experience.

It's crazy, because this is that part I love the most. Both Rust and Elm just blow my mind every time the compilers not only throw up something I never would've noticed, but even tell me how to fix it! It's crazy to think how far we've come, and it still makes me giddy with excitement every time I see it.

I'm primarily a C# dev, which normally has a pretty happy compiler.

But I've started playing with Websharper (Translates C#/F# code to JS.) One nice thing about the library is that once you understand the basics of composition, your JS -will- work as long as the compiler doesn't barf on what you did.

But, it has the drawback of seeing more errors from the compiler itself. While at first it was frustrating, I realized that the time I spent dealing with the compiler errors was still less time than I would have spent troubleshooting my own handwritten JS.

The package manager is a joy to work with and supports multiple versions of tools.

The edition mechanism allows the language not to be dragged down by old cruft.

The proc macros make it possible to have insanely reusable libraries, like serde.

The normal macros are part of the AST so you don't make stupid mistakes that are hard to trace.

Rust is just so good. But I think it's only obvious if you've worked with C++. Most of this doesn't seem special coming from C#. Except the performance that is possible.

The borrow checker might cost you a few minutes, but it can save you days or even weeks of debugging, and maybe it will save lives some day when Rust makes it to safety critical applications.

One thing that did bother me for a long time was RLS auto complete, which was just really slow and useless. This has been fixed with the advent of rust analyzer.

However, this sense is reducing every-time I see an example of some idiomatic Rust code. I appreciate that they've addressed a lot of C++ pain points.

1. Traits are awesome. (Simon Brand: How Rust gets polymorphism right - https://www.youtube.com/watch?v=VSlBhAOLtFA)

2. The lazy pipeline styled programming is idiomatic and produces optimal assembly. (Ranges in C++20 )

3. Extremely powerful enums. Straight out of functional langs.

These are only a few of the things top of my mind but it makes me appreciate Rust more and more.

If I was working on something where the best alternative is C++, I'd probably feel different. Right tool for the job and all of that.

I hope it's not the tone, but rather how nitpicky the language feels, but the target is for most of the seemingly pedantic or arbitrary restrictions to give you guidance on what needs to be done instead.

Can anyone expand on this? I'm not well versed in Rust lore and have just used that module in a recent learning project.

str is to String

as &[] is to Vec

as Path is to PathBuf

... and the names should reflect that.

Yep! My understanding is that `AsRef<str>` is the right way to do this automatic conversion but I learned that by reading library code, not from the standard documentation. It'd be awfully nice if the compiler could do those sorts of conversions automatically; injecting `AsRef` everywhere adds a lot of visual clutter.

I think the nuance is between "makes sense" and "fits into the mental model Rust otherwise encourages," i.e. thinking about `T` and `&T` as the fundamental building blocks for ownership semantics. In that context, being unable to directly instantiate a `str` (or having `&String` be a thing that you can occasionally produce when you mean `&str) is deeply confusing to newcomers.

This non-behavioral stuff matters. Almost literally no one who comes to rust understands the string types with any intuition initially. And strings are really important!

Much the same thing can be said about the evolution of other areas of rust syntax (macros and attributes come immediately to mind). The final result is a collection of syntactic soup with (mostly) well-defined and internally consistent behavior, but with a syntactic expression that bears the archaeological scars of its evolution.

https://docs.google.com/presentation/d/1q-c7UAyrUlM-eZyTo1pd...

Although it could really do with some more expository text!

This is a hard restriction in place on purpose. The compiler could perform inference for the input and output types as part of the language but that means that the actual low level signature of your function could change by changing either the implementation or the callers. This is a compromise we must have to avoid surprises in real programs that have public APIs. On the flip side the compiler doesn't have this restriction for inferring the return type. If you write a function signature `fn foo() -> _` with a body that can resolve to an unambiguous type, the compiler will give you a structured suggestion for the correct type. This way you get the benefit of inference when developing and the benefit of type safety and unambiguous documentation of your code at the cost of mild inconvenience.

> Array's by themselves are nearly useless, might have just made Vec<> the default array type.

I'm not sure what the actionable recommendation is here. Is it to have made [] the syntax for Vec? If so, that would have made Vec special from the language's point of view, when it doesn't need to. Today you can reimplement all of Vec in your own Rust code, but you can't for arrays, because the compiler and language need specific memory layout information about them.

> Mismatch braces

Could you expand? I'm intrigued what you mean by this.

> Trait declarations that are scattered everywhere rather than being centralized like a C++ class.

This enables very flexible design and composition of behavior. It feels very weird when coming from an OOP background, but I've come to prefer it after a while.

What is verbose about declaring arrays of structs?

Arrays are fundamentally different than vectors, the same is true in Rust as in C++.

Types are only inferred for variable declaration, that works for closures too. You can't have an inferred type in a struct declaration either. It doesn't make sense for a function declaration imho, and having worked in languages that do it - I hate it. Horrible practice to drop type args from functions.

I think method chaining is really helpful, particularly the builder pattern. It's also supremely useful for abstracted logic or patterns like iterator combinatory, something that you don't find as cleanly in other systems languages.

Not sure what you mean about traits being scattered? They're interfaces like a pure virtual base class - implementing them is very similar to implementing a base class in C++. Except you can use generic arguments for implementations which makes for some really expressive mechanisms for abstraction.

The first case is related to ownership/borrowing as these concepts are fundamental in systems languages.

The second case is a hint that filepaths are more complex than a single string type can represent.

The first is the distinction between "owned" (i.e., heap-allocated) and "borrowed" (types). Arguably, there could have been better language support for this to fix this issue.

The second is the fact that the underlying OS rules for strings and paths do not conform to any sane string requirements on most systems. If you collapse this into normal strings, then you end up with situations where you can't interact with your OS properly.

Coming from C, you should be thinking about lifetimes and mutability and sharing. If you dont, your program may work but be buggy. Rust forces you to think about that.

Go does the same thing in different ways at different costs. It trades memory/performance so that you don't have to worry about allocations and simply doesnt use standard shared mutability patterns (not exactly, but channels take up most of the same space).

[0]: https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild...

The key there is "as possible." What is possible depends on the constraints and the goals. Rust does "impose as little cognitive load as possible" generally, given its goals as a language. You can nitpick about some parts of this, but at least all of the examples in the post have good reasons why they need to be this way, thanks to the goals for the language.

Rust and Go have different goals, and so "as possible" is something that means different things for each language.

On the subjective side:

> Rust seems like it makes you think a lot about Rust, which means you are not thinking about the problem you are trying to solve. Brain cycles are a finite resource.

This is true at the start, but once you get over the hump, you don't really spend any time thinking about this. The strictness is what lets you not need to care as much: the compiler will check your work, so you don't have to think about things very hard. It takes a while to get there though.