3 ms·
> The jury is out if thats is a good thing or a bad thing. My vote goes towards good thing. One of the things I like most about Rust is that it forces you to
by imron 6y ago
> The jury is out if thats is a good thing or a bad thing.
My vote goes towards good thing.
One of the things I like most about Rust is that it forces you to think through your design and address complex tradeoffs, and often won't even compile until you do.
What it costs you in development time, you'll make back in reduced maintenance. The former is a visible cost therefore you feel it more than the latter which is invisible when things run well.
This is why Rust can feel less productive even if it makes you more productive in the long term if you take in to account less maintenance.
- gfxgirl 6y agoright tool for the right job. I wouldn't want to spend that time one a one off script I only expect to run a few times. I also wouldn't want to spend that time only to find that my assumptions were wrong or the requirements changed and I have to throw it all away for a new class puzzle.
- dpc_pw 6y ago> I wouldn't want to spend that time one a one off script I only expect to run a few times. You don't have to. No generics, `.clone()` and `.unwrap()` everywhere, and the Rust code goes brrrrr. :D
- kortex 6y agoOr just...not deal with any of that, and literally bash my way through it. I hated the bash learning curve because it's so zany compared to "sane" langs, but once you hit a point in comfort, it's "muck around with syntax for a few minutes, applying to a test case of a few examples, dial it in, and let it rip on a few GBs of data and go work on other things". stringly typed pipes go brrrr XD. Composing unix utilities is horrific and beautiful all at once. Shellcheck helps a ton. Recently started getting into Xonsh cause it still makes piping programs super easy, while being still fairly easy to provision. Really wish there were a (stable) go-based scripting language and shell. There's tengo and some other things, but not primetime ready.
- entha_saava 6y agoThere are some python based ones.
- lenkite 6y agoI thing you may like https://github.com/borkdude/babashka https://github.com/borkdude/babashka
- kenhwang 6y agoI'm laughing at how true this is, but at the same time, if you're doing this, it's probably the one case go excels at.
- dpc_pw 6y agoI would do it with D, but sure: whatever rocks anyones boat. All I'm saying Rust is not particularly worse for writing "quick&dirty" scripts ignoring good design and corner cases. And if any quick&dirty script becomes " important part of our legacy production environment" the story of improving such a script is much better in Rust.
- entha_saava 6y ago> One of the things I like most about Rust is that it forces you to think through your design and address complex tradeoffs, and often won't even compile until you do. I have heard this bullshit enough times. "Orange crab god doesn't like it so you are doing it wrong". No, you shouldn't have to care about memory management nuisances when that's not relevant and rust being a language suited for systems domains with correct static memory management (Good thing for systems domain), makes those irrelevant details surface in implementation.. what you said isn't true for other domains. This kind of shilling is what leads to rust evangelism strike force memes.
- fluffything 6y agoI don't think they are talking about memory management here, but simple API design. In C++ you can write: template <typename Animal> void roar(Animal animal) { ... } and call it like this: roar(airplane); // How do Airplanes roar? You can try to fix that with an "Animal" concept, but it turns out that if someone adds a roar method to a Vehicle, you can still: roar(truck); // Trucks can roar... but roar expected Animal In Rust, these things just cannot happen. If you write: fn roar(animal: impl Animal); then trying to call it with anything that's not an animal will fail to compile. That's a good thing, but maybe somebody did wanted to call roar with a truck, and now you have to invest time into more precisely thinking which types should roar actually take, which types constraints make sense defining, how you categorize types, etc. In Rust thinking about these things costs time. In C++ it also costs time, usually more than Rust, because you have to go way out of your way to prevent mistakes like the above. In Go you don't have to think about these issues at all because the language does not allow you to do most of this (except for interfaces, but that's another story).
- entha_saava 6y agoI should first tell that I don't hate rust. It is a well designed language for what it aims for (statically guaranteed memory safety for systems programming). I have deep respect for rust creator and some members of core team for their technical work. What irritates me is claims like "If borrow checker rejects your code, it was wrongly structured anyway" and "rust's restrictions lead to good structured code". It is not wrong if program logic requires self referential structures, for example. Neither does it make sense to evangelize rust using blanket statements like this. I get the impression that some people are trying to evangelize rust as a language for everything. The mental overhead of rust (or maybe ATS, maybe Ada/SPARK, depending on requirements) makes sense for systems programming, where C/C++ will make stuff even more complicated, and you can't compromise on performance. The applications domain is realistically better served by something like F# / OCaml / Go once it gets generics..