Rust

Mindblowing features are basically, by definition, a result of bad language design. They blow your mind, since they are totally unexpected behaviours. They may still be cool, but they are unexpected and hence unintuitive.

A language that are full of these is Perl. And one simple one is that you can take the string "AAAAA" and use addition on that, like "AAAAA"++ and you will get the result "AAAAB". Cool you may think, but is it really? Addition is normally used to increase the value of a number, that is a completely different operation than modifying a String. The string "AAAAA" cannot be said to be greater or less than "AAAAB", besides the very special case when we order it. But in general the name "John" is not considered to be higher/lower than "Mark", they are just different. So, even if it is cool to manipulate strings by using addition/subtraction, it is still bad language design and very unintuitive. Also, since perl is so loosely typed, it may also cause very unexpected bugs.

Not exactly the same thing but this is still pretty funny. This is code that is technically 100% legal Rust but you should definitely never write such code 😅.

You can manually implement PartialEq and Eq on an Enum that implements Hash to manually determine how the hashmap keys override/collide with one another.

Here's another Haskell example where I'd be interested to see a Rust counterpart. It's a red-black tree implementation where the tree invariants are enforced by types. The code would less ugly with more recent GHC features, but same idea.

https://gist.github.com/rampion/2659812

https://old.reddit.com/comments/ti5il

Something i didnt know for a long time (even though its mentioned in the book pretty sure) is that enum discriminants work like functions

#[derive(Debug, PartialEq, Eq)]
enum Foo {
    Bar(i32),
}

let x: Vec<_> = [1, 2, 3]
    .into_iter()
    .map(Foo::Bar)
    .collect();
assert_eq!(
    x,
    vec![Foo::Bar(1), Foo::Bar(2), Foo::Bar(3)]
);

Not too crazy but its something that blew my mind when i first saw it

A cool thing you can do, is to store values of all kinds of types in a big HashMap, basically by storing their TypeId and casting them to Box<dyn Any> (see std::any).
Then you can later retrieve those values by specifying the type (and optionally another ID for storing multiple values of the same type).

So, you can create an API which is used like this:

let value = MyType::new();
storage.insert(value);
let retrieved = storage.get::<MyType>();
assert_eq!(retrieved, value);

There's various ECS storage libraries which also implement such an API. Depending on what you're doing, you might prefer to use those rather than implementing it yourself, but it's not too difficult to implement yourself.

One thing I like a lot about Rust is that it rarely does blow my mind.

But one crate that actually did blow my mind is corosensei. It's not Rust per se that is so crazy here, but the way it's essentially implementing a new language feature with assembly code. This is how you know Rust really is a systems programming language. I invite you to read the source code.

Rust isn't really a language that lends itself to terse point-free functional idioms... The sort of examples I might want to share would probably require a bit more context, certainly more code. Like I think type guards and arena allocation are cool and useful tricks but I don't think I could write a neat little example showing or motivating either

I'd like to see a Rust solution to Tony Morris's tic tac toe challenge:

https://blog.tmorris.net/posts/scala-exercise-with-types-and-abstraction/index.html

His rant about it is here:

https://blog.tmorris.net/posts/understanding-practical-api-design-static-typing-and-functional-programming/

I did a Haskell GADT solution some time back and it's supposed to be doable in Java and in C++. Probably Rust too. I wonder about Ada.

The haskell examples look more like an arcane wizardry.

Can't think of anything.
The novelty must have worn off over time.
Or maybe my mind doesn't get blown easily.