A Harsh Criticism of Rust 

I really like the rust programming language.  It does so many things elegantly, beautifully, concurrently and safely.  It feels like the future and 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, you are not my type (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 the function required trait and lifetime 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.  And "borrowing" in combo with other rust "features" like "lifetimes" intersect in ways that detours (or forbids?) common CS problem approaches that you'll need to unlearn as you learn rust.  On the plus side, generics and traits and implementations are really powerful in rust, and I've picked up better programming 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?" At first I thought Yes, because I'm a rust fan boy and think of all the messiness that could be avoided if only I learned rust first and skipped learning non-rust friendly programming techniques; part of my rust learning problem is rust's design create unseen patterns of 'easy', 'hard', and 'try climbing Everst instead' difficulty levels in the programming paradigms I already know.  
    My answer to "Is rust a good first programming language to learn" is to be reasonable, yes but 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.  a catch 22.  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 and learning those invisible patterns.   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, lifetimes, 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).  Perhaps rust was build by people that know everything for people that know everything or are are willing tolerate a learning curve shaped like the Cliffs of Zion.  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 (or invisible patterns) is by running into the maze 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. And backward from most  prime number search codes in that it was building the next prime numbers as much as finding them.  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.    The upside is compiled rust code just works and runtime errors are mostly a theoretical possibility rather than theoretical certainty.  
  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") 
    I wrote that last paragraph before I ever published a rustdoc, and now that I have the Frank "fetch and rank" crate on I can say doing rustdoc well is a minor effort, but there can suprises that increase doc disorder.  At least for newbies. 
  5. Conversions.  Character to 8bit value, String to Characters, vector of characters to strings - should be almost effortless.  Its not in rust.  And in mathemamatical calcualtion Rust has a 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 = u32::from((conv_e%65536usize ) );

    Might be the same, but seems segmented and deeply murky.  Rust doesn't let me just willy nilly type convert and I find myself writing code to do terribly simple math and conversions with alarming frequency.  Even worse, write a generic Mean fn for all primitive vectors types and experience serious hoop jumping.  Rust probably does this the right way by forcing blame for subtle typecasting errors on the programmer rather than just making it easy.   But I have moments where I wish I could just type typeconversion!(a=(b+c*d-e)%65536) or mylist.mean() or even let ascii:u8="a".chars() as u8; and follow with a proof of correctness by assertions.  I don't really want to be programming type conversions for every generic possible in my programs over and over again in rust.  Not just that, but my brain works a specific way- I grew up with one math idea fitting on one line.  Two lines and its little number story that unfolds.  But baby fed it becomes a story problem really obscures.  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?  
    Yes, type conversion is a wellspring of undefined behavior in many languages - that said I'm not sold that conversion must always be a wellspring of undefinied behavior or that the best way forward is to force the programmer into type minimalism or risk hours coding custom type conversion for each and every special little type of information encoded while forgoing broad generics and coding for all the typical and edge cases that can be imagined.                 
  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.  As mentioned in section 5, a primitivegenericvector.mean() function gets real complicated.  It's tricksy to get each detail right for each type situation, and actually easier to just write code for each of the vector primative.  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.  I'm still lured in by the "Joy to use" and presently risking "newbie burns" with methods every chance I get.    
  7. Another language, more numeration methods.   This is perhaps a complaint about human computer interface, but 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.  I can't even explain it easily because your human mind will naturally fight to skip the lines filled with numbers.  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).  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 numerical ranges with "// RangeInclusive 0 upto 9" and "//RangeBound 0 almost to 9" would help.   Squeeeeeeeeeeeeeek.
  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. Learning rust the easy way requires a community.  Easily the worst thing about Rust might be the people that love Rust, especially when you start rust and get so frustrated with it you are willing to write a ten point blog rant critical of rust and about how python, java or C or Ruby or whatever is so much better than rust because your sorry ass code just runs.  Terrible self serving blog posts like this one that hint at a happy helpful rust community has gotta seem strangely mythical to new arrivials.  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 even if you are not a perfectionist, rust may well be absolutely perfect for you.  Easily the best things about rust is near guarenteed correctness at runtime, great speed, safety and concurrency.  Rust's perfectionism is the root of why it 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):
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 »