Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This function signature is a work of art: https://docs.rs/effing-mad/0.1.0/effing_mad/fn.transform.htm...


Enough to make even a seasoned Haskell programmer blush.


Now the real question is blush in envy or embarrassment? ;)


What I worry the "Rust is hard" commentary and criticism makes people think of Rust.

99.9% of the time you're never going to touch voodoo like this. Unless you choose that path.


I struggled mightily with the borrow checker and lifetimes when I first got started until I got some good advice to just use the heap. String, Vec, .clone(), etc. Just write the code you want and don't worry about allocations. You can fix that all up later when you're more comfortable. It was kind of a cognitive game-changer for me. And now I love Rust and I've gotten better at it.


And then you decide to try nostd :)


This is the best Rust onboarding advice ever.


I don't think it is. I ran into the same pitfall. Instead of taking String and passing around &str, I did .clone() everywhere. Kind of gross? The better advice I think is "lean on passing around borrowed parameters as much as possible, otherwise you're going to run into Copy+Clone hell. I would be curious to learn from somebody "even better" at Rust if that is bad advice.

That and, I just wrap everything "hard" in some combination of lazy_static / Arc+Mutex.


I would put it as "when it isn't too tricky to do so write your program such that data flows one way".

When data flows downwards it's often simple to have the top layer own and then pass down references.

But if you start running into lots of issues doing that it's probably a fundamental issue with your architecture. So you need to either rethink it or give up and try a different kind of approach. Both are valid, but I think people who try to muddle through without either dramatic option are the ones who end up very frustrated with Rust.


I split my time between our hardware products (C and Rust) and our software product (JS everywhere, node in the back, React in the front).

Reading your comment I had two simultaneous thoughts....

1. <squinting appreciatively> Clever, cool way to think of it... ...and if you need information back at the top level, send it back via a Result....

2. <brows raised in horror, shuddering in React> State management hell!

:->


Great way to learn your bearings. Then once you get the lay of the land you recognize that's not the way to do things.

It'd be neat if the language had a "beginner mode" flag where the compiler could recommend simple things like abuse of the heap. All you need is a day or two with it, then you can take off the training wheels.

Write one to throw away. Learning is messy and hands-on, not rote and academic.


Or if you use a library that chose that path and you end up having to debug it.


I've saved most of this thread so that I can link it when someone asks me why I don't use Rust for systems development yet. In some ways Rust is worse than C++ with these completely out of orbit contrived math problems in the type system.

C is a simple language, but it's still difficult for beginners to understand systems software because it's complex. Adding something like this were people are inventing complexity in the language itself out of boredom is a recipe for disaster and is much worse than the terrible things than can happen in C.

Please just learn to write simple code and solve hard problems, rather than writing complex code to solve contrived problems.


you do realise this is essentially a joke right?

I'm sure every language has examples of code where it was written to be crazy on purpose, This is one of those.

Like when you write a raytracer in CMake, or Meson build, or C++ templates. Etc etc. Or when you compile your program to only mov instructions, because mov instructions are turing complete (should this be a reason we shouldn't use x86?). I'm sure there are plenty more examples.

Nobody is suggesting you actually use this stuff. Therefore it seems a bit silly to point at it and say 'don't use this language because people do silly things for fun in it!!!!11!!1'


> Adding something like this were people are inventing complexity in the language itself out of boredom is a recipe for disaster

Not really. This is a fun project to show what an effects system would look like. The consequences of this are pretty much strictly positive.

> and is much worse than the terrible things than can happen in C.

No. "Ugly code no one will use but that demonstrates a concept" is definitely not worse than "attacker has full control over the computer".


Complexity is where bugs hide. Do you really think Rust protects you from every class of bugs? It doesn't even protect you from all memory bugs.


Rust just exposes the complexity an equivalent program in C leaves you to find at runtime. It doesn't have to prevent every bug, just substantially more than the languages it might replace.

You can write simple or complex code in any language.

The Obfuscated C contests exist so I really don't see what points you think you're making.

Some people have fun pushing their tools to their limits. That doesn't mean they do the same thing in production code.


Rust is a very obvious security win.


Production Rust code doesn't look like this.


I don’t see any GATs. Color me unimpressed. (/s)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: