Wednesday
Nov212018

A Harsh Criticism of Rust 

I really like the rust programming language.  It does so many things elegantly, beautifully, concurrently and safely.  I consider myself a rust-fanboy.  But what's not to like?   Here is my list of terrible things about rust (or perhaps computer science in general.) 

TLDR:  My list includes (1) Rust gets all "I can't let you do that dave." (2) I hate how slow I am learning rust (3) Rust brings new concepts and search words fail me (4) Documentation alone is not a teacher for beginners  (5) Simple mathematical ideas obscured by long verbage (6) Methods.are(not).easy(toprogram) but ever so easy to use. (7) the many ways to count and loop and collect and iterate can be unclear but maybe that is on English, (8) unsafe blocks because why have just one emensely complex computer language when you can have almost four between safe rust, unsafe rust, methods and macros (9). All the cool toys Nightly offers have uncertain prices (10) rust has a great community and you'll probably need it in order to learn rust.

  1. "I can't let you do that Dave."  Getting hung up on doing something the wrong way still works in most other languages - maybe slowly or with potential for errors or thousands more watts of cpu cycles burned than needed or uncertain behavior.  But they still work, you can go forward.  But Rust, Rust doesn't just get argumentative, it gets in your way. For me, I had trouble passing generic Vectors Vec to a function.  There is almost certainly a way to do it, maybe, right?  Rust stands in praise of don’t repeat yourself (DRY) code writing… and it should as it can be verbose.  But when it comes to random subsampling a population represented by a vector... For a full day I did't have a lot of hope that mere mortals could write a generic population polling function that works with on Vec, Vec,  Vec or any other Vec you can throw at it without lots of repeated code and unhelpful "I can't let you move what may have already been moved Dave" type errors.   See my comment in comment section for working code.  The frustration abated as I learned function required trait closures and how Rust's creators envisioned a solution.  Most languages don't treat you like a cat that just pooped outside its litter box merely because the cat and litter box both exist allowing the possibility of said fecal infraction, but Rust, rust fights even that possibility.   
    There is something "steep learning curve" about that harassment, from borrow checking to generics to implementing traits.  On the plus side I've picked up better practices... thank you Rust... even though I didn't really want my nose rubbed in it - and that's a terrible way to treat your programmer by the way. 
  2. A while ago I came across a 2015 reddit thread "Is Rust a good first programming language to learn?"  My answer is yes only if you are lucky enough to have a great human mentor or excellent course + classroom enviroment.  I hate how slowly I am learning Rust,  for me- knowing comes from doing but the bloody compiler won't let me do until I already know how.  I picked up python in a week.  I love Mathmatica because I can program small marvels in twenty lines of code.  And in rust, I keep at it for months and keep improving and learning and feel like I'm making progress but I am still in discovery.  I started by thinking, ok, structs are simple enough.. but when I wanted to sort generic vector A, (a list of things that may or may not make sense to talk about in terms of greater or less than),  by the values in Generic Vector B a partially ordinal vector that makes  does make sense in terms it parts being greater and less than other parts), I suddenly found myself needing to know almost everything about structs, traits, enums, generics and implementations and functions headers all at once to make any progress in coding (Hint: use a fn to return a tuple.  Then vectorize the collected tuples and don't try to learn every nuance of the type system).  Sometimes slow progress comes from Rust’s width alone between ?thousands? of macros or safe and unsafe features in the standard standard library.   This week I met the handy vector .retain(|x| x%5 ==0 ) function that lets you depopulate select elements from a vector array.    I should probably buy a rust book.  The online doc's are pretty good, but hard to scribble notes all over and easy to get lost in, and rust's autogenerated documentation has curation priorities that a human teacher mostly wouldn't.   And did I mention the rust path of learning the way through a maze by running into walls again and again? Where hard found wins work, I feel like I've learned something universal that could improve the way I write rust code and everything else. 
  3. Rust has certain concepts that are new and really conceptual. If you don't agree, type "Elison Function" into google and count results until you get something the pertains to coding.   New ideas arise from other ideas like ownership and no garbage collection and how those ideas create a moire effect of additional implications, many unnamed or at least rare outside rusts community.  When I wrote a rust prime number toy, there was a CS programming pattern that amounted to “2 is a prime.  Check new numbers for primality from last tested value to last known prime squared - across available CPU's.  After test phase, use new primes found to grow the original list of primes & transfer new knowledge across all CPU cores by borrowed pointer and repeat to inch the knowledge base larger.  (know2)->grow3!->sow3->(know2,3)->grow5!,6,7!,8->sow5,7->(know2,3,5,7)->grow(10..=48) ..." That sounds simple, and the prime number program wasn't complex and the idea not new... but "know/grow/sow/repeat" as a problem strategy would have a name had concurrent rust somehow predated C.  Blazingly fast too.  Maybe this paradigm does have a name and I just don’t know what it is called.   I still feel a little bit of pride the elegant high speed parallel solution rust's Rayon library crate allows.  But certain rust paradigms are still pretty opaque to me  - like functions returning boxed closure trait objects - each step makes sense but the whole makes me wonder.  Are there even words I can search Google for that describe what rust is doing there?  Others make me feel like coding rust walks me around some idea or pitfall that was deemed "not the rust way."   It is hard to explain, but there is a rust way and you learn the rust way mostly by letting the compiler beat you up and force you to debug perfectly reasonable code (in any other language) until you stop running into the invisible brick walls.  And it hurts to refactor and recode until you start to have useful cargo compiler conversations and have memorized enough of the documentation that even the autogenerated docs makes sense at a glance.  What is the rust path?  I’d guess it the rust path is bigger than most concise programming ideals, and might be something to do with what it means to be the computer or the computed.  
  4. RustDoc auto documentation.  Wonder of simplification and yet possible source of Rust's near freakishly large spool of mediocre documentation?   Meaningful connections between idea, convention and practice are hard to come by in autogenerated docs, aside from a few examples.  I get why semi-automatic documentation is a thing and that the goal is documentation, not teaching beginners.  Part of me thinks semi-automatic documentation is brilliant, and the other part of me snidely thinks  "If you were given a dictionary made from only the very words Shakepeare used, would you know any  Shakespeare?".to_string().string_replace("Shakepeare","Rust")  
  5. That rust thing where type conversion within complex mathematical ideas rapidly becomes deeply layered and indecipherable.   For me, mathematics is visual.  I understand “a=(b+c*d-e)/%65536” but
    let conv_b = b as f64;
    let conv_dc = (c as f64) * d;
    let conv_e = (conv_b  + (conv_dc as f64) - e) as usize;
    let a:u32 = (conv_e%65536usize ) as u32;

    Might be the same, but seems segmented and deeply murky.  Rust probably does this the right way by forcing blame for subtle typecasting errors on the programmer   But I have moments where I wish I could just type typeconversion!(a=(b+c*d-e)%65536) and follow with a proof of correctness by assertions. My brain works a specific way- I have trouble following parenthesis mazes without color clues so extra parentesis don't improve my comprehension and I have trouble following overarching mathematical goals and objectives when every step gets spoon fed and broken up by "here comes an airplane landing in the hanger."       How can a language that is so beautiful when it comes to "(2..).filter(|x| (x%6)==0 && (2 * x - 1)%11==0).take(100).collect()" be so grimly pedantic when it comes to the murky uncertainties of converting types?
  6. data.methods() seem really complicated to program.  Not to use, in that they are a joy.  Methods tie types of data to functions and memory lifetimes and often follow the flow of the programmer's thoughts.  If you have a list called vector, its pretty obvious what vector.ranked() might do compared with to vector.sort().ranked(), while  ranking_count_num_greater_function(vector) seems a bit clunky.  So how to go from a function to a vector?  Code the function, then create a trait and implment a method for a data structure - and hope and pray that you got lifetimes and lazy functional operations just so. Witness:
    The impl boiler plate to methodize a funtion .. for me, newbie, it burns.  It's tricksy to get each detail right for each situation.  One typo and multiple errors pop up across the impl that in sum do not clarify or point a newbie in the right direction.  I really wish there was a more automatic way to impl![rank_count_num_greater()] for the datatype and memory lifetimes the function rank_count_num_greater already uses.  I sense that there is great power in methods in rust, especially where it comes to extending what rust itself is and can do as a language.  Maybe I'll get a more complete understanding eventually - right now methods seem 'evolving boiler plate code meets deep wellspring of arcane magic' best not for newbies complex.    
  7. Another language, more numeration methods.    That CS disconnect issue of 0..10 being what humans think of as First=1  to Tenth=10 and what computers think of the ten elements 0,1,2,3,4,5,6,7,8,9 is unfortunate.  There are a considerable number of online rust help responses where a stymied rust beginner asks to loop between 1 and 10 and the helpful reply is a iteration of 1..10 (1,2...9) or 0..10 (0,1...9) or 2..9 (1,2...8), and even  sometimes 1..11 (1, 2...10), or ..=10 (0,1..10) or 1..=10 (1,2..10).  If you are a human your mind probably unfocused reading skipping that last line.  Insert hundreds of variant examples here involving for loops, slices , iter() or rand.   Once you start seeing the beginners and helpers make this lingual numeration communication clarification mistake in hundreds of different ways - you start to see it almost everywhere.  I conclude all humans have some weakness for this kind of lingual/CS bait and switch, much like dogs do for squeaky squeeze toys.    Sure, Rust lets you do Std::Ops::RangeInclusive::new(1,10) or Std::Ops::RangeBound::new(1,11) should you be willing to risk conciseness for ~30 additional characters.  So that's better, even if nobody will use it... um... I guess.  Maybe rustfmt auto-comments for undocumented ranges with "//enumerates start,start+1..end-2, end-1" could be a thing?
  8. Unsafe.  I approached rust as "learn safe first" bifurcation.  That approach seemed strongly recommended by the rust documentation itself.  That might not be wise, I'm not functioning at the level I want to just yet, and I still need to learn unsafe features to solve certain problems - or just use someone elses crate with unsafe buried in it anyway and cheat myself from learning rust the hard way.   Trying to only write safe rust is a mildly rewarding intellectual puzzle but there is no guarantee that the puzzle at hand actually has "ideal solution” in safe code.   If you need to pass through one of those invisible rust programming walls to solve a problem - just use the unsafe keyword and get to your madness.   I think I'd be farther along in learning rust if I just embraced unsafe earlier and often... but my work doesn't require mission critical safety either.  Unsafe is part of why rust is great.
  9. Cha-Cha-Cha-Changes and nightly only features... also known as "Can't compile the standard library with your incompatible nightly build of rust, so yea, good luck with that."  Rust is still changing from version to version.  Mostly healthy, almost all improvements with few downsides as far as I can tell.  I like the 2018 Use syntax.  I like the error handling sugar ?   But nightly is downright slippery and some nice if unstable features only available in nightly compiles seem destined to stay in nightly, or randomly wink out of existence.   Nightly lured me in with toys and tools I couldn't afford without a next-release rewrites.   Not such a big deal for me, I'm just learning rust with toy programs that I mostly just throw away - but my tip for rust newbie learners is try learning to ice skate on flat smooth ice, not the pretty shifting glacier that is rust nightly.  Nightly (may/could/will?) frostbite you eventually and perhaps in a way that makes leads a newbie to abandon their first rust project.  
  10. Easily the worst thing about Rust might be the people that love Rust.  At least to those that don't know Rust or its culture and would prefer java or C or Ruby or whatever.  Terrible self serving blog posts like this one that hint at a happy helpful rust community has gotta seem strangely mythical to some.  If your gut response is “What obvious utter drivel, the low level virtual machines are the same so why would the dev comunity be any different?”, if you are an unhappy troll living in a subterranean server farm or the like and want to share your inner pain with the world, if you are someone for whom the mere notion of asking for help would be difficult -  Rust might not be for you.   But if you are not a perfectionist, rust may well be absolutely perfect for you.  Rust's perfectionism requires some mentoring, so if you do manage to learn rust, maybe consider tutoring others as your skills come up to speed.  

PrintView Printer Friendly Version

EmailEmail Article to Friend

Reader Comments (1)

I did eventually find a way to do generics with Vectors in rust. Like a lot of rust things this looks simple but is easy enough to get wrong repeatedly for four hours in a row if you are particularly hard headed about trying to figure (fight?) it out yourself "so that you'll learn" or something. Thanks Rust community for 1 minute right answers to help. Cheers:

fn poll_ten<T:Clone>(vec: &Vec<T>)-> Vec<T> { // take about 10 items from a Vec that has clone implemented
let mut rng= thread_rng();
let about_ten = vec.choose_multiple(&mut rng, 10).cloned().collect();
return about_ten; //returns ten or less items from input vector
}

November 23, 2018 | Registered CommenterDustan Doud

PostPost a New Comment

Enter your information below to add a new comment.

My response is on my own website »
Author Email (optional):
Author URL (optional):
Post:
 
Some HTML allowed: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <code> <em> <i> <strike> <strong>
« Sacre Bleu, a Review of the Book By Christopher Moore | Main | Rust's rand::distributions »