4 ms·

I don't have a problem with Rust syntax. Actually I can't imagine any developer with more than a year or two's experience has much trouble with any language syn

I don't have a problem with Rust syntax. Actually I can't imagine any developer with more than a year or two's experience has much trouble with any language syntax (unless it's something truly weird like APL). After a few days use you barely notice surface details anyway - it's just one possible representation of an AST. My problem with using Rust is the way its complexity creeps into everything. There are large numbers of stdlib utility traits whose idiomatic use you have to remember to read almost any real world code. There's hardly a Rust library in common use that isn't a huge sprawling mass of over abstracted generics and macros. Even command line parsing is made to be a vastly complex endeavour. There are admittedly sugary niceties (eg derive attributes) that can make use of many of these libraries tractable for easy cases. But overall any substantial Rust program makes cognitive and memory demands on the programmer far in excess of what most languages require for the equivalent in my experience.

alpaca128 3y ago
I can agree with that, I don't like overly abstract stuff either. That said in my projects I'm in control of the code and so I tend to avoid traits where they're not really necessary, I find Rust very pleasant to use that way and the compiler messages are simply outstanding. Often lifetime annotations can be replaced with heap allocations, which isn't always that efficient but it's a damn fast language and often you're not even going to measure a difference. > Even command line parsing is made to be a vastly complex endeavour. Yes, I even wrote a library for that once but then realized it only complicates everything and adds limitations. Nowadays I just do that by hand. For one it's guaranteed to be shorter than any parsing library, but also it's a good opportunity to think about what kind of arguments I need and in which form. And copy-pasting the parser from the previous project and adapting it is quick & easy.
- crispinb 3y ago
  Sure, despite my frustrations with it (and with the often frankly false claims about it tirelessly repeated by people who identify too strongly with it - it's a programming language, not a signed-in-blood manifesto for world peace and ubiquitous sex), I'm actually still quite engaged in using and learning Rust. It's even my main language for my own projects right now (I no longer work in tech/dev). Some of that is just stubbornness (because I find it hard), but some practical (performance, WASMability etc). I do like the way the type system makes it seem like things snick precisely into place when you get things right. My beef (such as it is) is that I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. It takes me probably 4x as long to do anything compared to any other language I've used (and although I'm not a talented programmer, I am a polyglot). Oddly on the cli parsing thing, I did end up finding a library I like - bpaf. It's kind of abstract but seems more conceptually principled than the near-universal clap. The kind of abstraction where once you have grasped a small set of orthogonal concepts, you can just combine them at will, seems OK to me. As contrasted with the type which has dozens of small rules, and special cases that rely heavily on (human) memory and/or constant doc lookups.
  - alpaca128 3y ago
    > I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. I know what you mean. I feel much more productive with it nowadays and many things just make sense now, but it took me a long, long time to get to that point. Rust is very much not beginner-friendly, and while I think it was worth it this is why it will never replace certain other languages. I don't mind the compilation speed as much as some people seem to do, but the learning curve definitely is a problem.
    - pkolaczk 3y ago
      Prior experience and preferred style of programming can affect severely the difficulty of learning Rust. For me it was mostly 1 week of struggling a bit with the borrow-checker and even that only in places where I really wanted to avoid copies / allocations at all cost - achieving something I wouldn't be able to do at all in other languages. Later I realized that if you are ok with an occasional clone here and there, the borrow checker almost never stands in the way. And realizing I can move owned stuff around cheaply instead of copying/referencing was also another huge enabler. However I can imagine when Rust borrowing rules can be a huge pain. This happens when you expect to continue using the same style of programming that relies on big piles of (often cyclic) object graphs built with references/pointers, shared mutability, heavy (runtime) indirection and inheritance. A style that is so prevalent in OOP projects written in Java, JS, Python. I don't like this style at all, and always tried to avoid it even when coding in those languages, because I believe it causes more harm than good. Rust will simply force you to unlearn it. And some people won't need to unlearn much, and some will have to unlearn a lot. Changing habits is always pain. I think it should be simply considered a different paradigm.
      - crispinb 3y ago
        > I think it should be simply considered a different paradigm. I addressed this above and believe it to be an unconvincing explanation of Rust's difficulty. Many polyglot programmers comfortable with, and experienced in, switching (and learning new) paradigms, still find Rust more difficult than other languages they have learned. In my experience most just give up. I haven't, but neither have I become remotely productive in the language. Of course my experience is just one person's sample. There isn't much else to go one. But the Rust Foundation clearly agrees with me, given its 2024 roadmap. In our view, Rust is hard to learn and use, more than most languages, and problematically so for many.

alpaca128 3y ago

I can agree with that, I don't like overly abstract stuff either. That said in my projects I'm in control of the code and so I tend to avoid traits where they're not really necessary, I find Rust very pleasant to use that way and the compiler messages are simply outstanding. Often lifetime annotations can be replaced with heap allocations, which isn't always that efficient but it's a damn fast language and often you're not even going to measure a difference. > Even command line parsing is made to be a vastly complex endeavour. Yes, I even wrote a library for that once but then realized it only complicates everything and adds limitations. Nowadays I just do that by hand. For one it's guaranteed to be shorter than any parsing library, but also it's a good opportunity to think about what kind of arguments I need and in which form. And copy-pasting the parser from the previous project and adapting it is quick & easy.

crispinb 3y ago
Sure, despite my frustrations with it (and with the often frankly false claims about it tirelessly repeated by people who identify too strongly with it - it's a programming language, not a signed-in-blood manifesto for world peace and ubiquitous sex), I'm actually still quite engaged in using and learning Rust. It's even my main language for my own projects right now (I no longer work in tech/dev). Some of that is just stubbornness (because I find it hard), but some practical (performance, WASMability etc). I do like the way the type system makes it seem like things snick precisely into place when you get things right. My beef (such as it is) is that I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. It takes me probably 4x as long to do anything compared to any other language I've used (and although I'm not a talented programmer, I am a polyglot). Oddly on the cli parsing thing, I did end up finding a library I like - bpaf. It's kind of abstract but seems more conceptually principled than the near-universal clap. The kind of abstraction where once you have grasped a small set of orthogonal concepts, you can just combine them at will, seems OK to me. As contrasted with the type which has dozens of small rules, and special cases that rely heavily on (human) memory and/or constant doc lookups.
- alpaca128 3y ago
  > I doubt I will ever get to the level of fluency where I 'just code' with it, rather than intermittent stripes of coding & fuming. I know what you mean. I feel much more productive with it nowadays and many things just make sense now, but it took me a long, long time to get to that point. Rust is very much not beginner-friendly, and while I think it was worth it this is why it will never replace certain other languages. I don't mind the compilation speed as much as some people seem to do, but the learning curve definitely is a problem.
  - pkolaczk 3y ago
    Prior experience and preferred style of programming can affect severely the difficulty of learning Rust. For me it was mostly 1 week of struggling a bit with the borrow-checker and even that only in places where I really wanted to avoid copies / allocations at all cost - achieving something I wouldn't be able to do at all in other languages. Later I realized that if you are ok with an occasional clone here and there, the borrow checker almost never stands in the way. And realizing I can move owned stuff around cheaply instead of copying/referencing was also another huge enabler. However I can imagine when Rust borrowing rules can be a huge pain. This happens when you expect to continue using the same style of programming that relies on big piles of (often cyclic) object graphs built with references/pointers, shared mutability, heavy (runtime) indirection and inheritance. A style that is so prevalent in OOP projects written in Java, JS, Python. I don't like this style at all, and always tried to avoid it even when coding in those languages, because I believe it causes more harm than good. Rust will simply force you to unlearn it. And some people won't need to unlearn much, and some will have to unlearn a lot. Changing habits is always pain. I think it should be simply considered a different paradigm.
    - crispinb 3y ago
      > I think it should be simply considered a different paradigm. I addressed this above and believe it to be an unconvincing explanation of Rust's difficulty. Many polyglot programmers comfortable with, and experienced in, switching (and learning new) paradigms, still find Rust more difficult than other languages they have learned. In my experience most just give up. I haven't, but neither have I become remotely productive in the language. Of course my experience is just one person's sample. There isn't much else to go one. But the Rust Foundation clearly agrees with me, given its 2024 roadmap. In our view, Rust is hard to learn and use, more than most languages, and problematically so for many.