4 ms·

I've written a bit of Rust, and I was left with mixed feelings, that seem to be still the same here: - loved the memory safety patterns when compared to the hor

by mihaic 3y ago

I've written a bit of Rust, and I was left with mixed feelings, that seem to be still the same here: - loved the memory safety patterns when compared to the horrible things that you can do with C++ - found almost every thing where it was different to have a harder to parse syntax, that I could never get used to. The implicit return at the end of a statement for instance make it harder for me to visually parse what's being returned, since I really depend on that keyword. Code in general is hard for me to mentally read. I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, so something like "func" instead of "fn" would be mandatory. Also, using the permission keywords where I'd expect the type to be also seems a bit strange, as I'd imagine that keyword to prefix the variable -- that's just how I think though. It does seem like less decorator magic and symbol-based syntax would make it easier for beginners to grasp. I may sound like a curmudgeon, but I'd prefer only one type of language innovation at a time.

haswell 3y ago
I’m in the middle of working through The Rust Book, and I haven’t written any serious code with it yet, so interpret this through that lens. When I looked at rust code before, it all seemed a bit weird. I couldn’t immediately understand it, but I’ve since come to realize this was because the dozen or so languages I can read well don’t really resemble rust, so my pattern matching was a bit off. The more I learn about the syntax and core concepts, the more I’m learning that my brain absolutely loves it. Once I started to understand matches, lifetime syntax and the core borrowing mechanics, things clicked and I’m more excited about writing code than I’ve been since I taught myself GW-BASIC 25 years ago. Just sharing this anecdote because I find it interesting how differently people experience languages. I also have an ongoing friendly debate with a friend who absolutely hates Python, while I rather enjoy it. I’ve tried to understand why he hates it, and he’s tried to understand why I like it. And it all seems to come down to hard-to-define things that just rub us in different ways. I hope the benefits of rust find their way into more types of languages in the future.
- mihaic 3y ago
  Yeah, I think at some point we all have some internal wiring that is hard to change, while other parts are flexible. For instance, I'm fine to write C++, Javascript or Python (with types at least). Ruby or Rust for some reason do rub me the wrong way, no matter how much I try to tough it out.
  - haswell 3y ago
    It's interesting that you mention Ruby, because Ruby is another language that just fits the shape of my brain for some reason. I've always really struggled with the various Lisp variants.
bmitc 3y ago
> The implicit return at the end of a statement for instance make it harder for me to visually parse what's being returned, since I really depend on that keyword. Cutting my teeth on Schemes and MLs and now working in Python, I have the complete opposite experience. It's jarring to have to specify return. What else would I want to do at the end of an expression? It seems tautological. The real reason it's there in Python is early return, which is even more dangerous and jarring.
- mihaic 3y ago
  I know it's not very FP, but you might explicitly not want to return anything and just modify the data.
  - bmitc 3y ago
    That's perfectly acceptable and expected. F# supports OOP and imperative just as much as it does functional programming. In the case of such functions and expressions, the value returned is of type `unit` with a single value of `()`. In F#, expressions that return `unit` have the value explicitly ignored if they are not the last expression in a code block. Other expressions returning non-`unit` values that aren't at the end of an expression will generate a warning. In such cases, for example where a function performs a required side effect and returns a value other than `()` but you don't need that value, you can use `|> ignore` to get rid of the warning since it says you are explicitly wanting to ignore the returned value.
mattgreenrocks 3y ago
Give it time. The syntax differences are real, but not insurmountable. I grew to prefer the location of the return type in function syntax despite having 15 years of C++ under my fingers.
4star3star 3y ago
> all keywords should be obviously pronounceable I hear you. Internally, I always pronounced "var" as rhymes with "care", but then a colleague pronounced it "var" as rhymes with "car". I think the same guy pronounced "char" like char-broiled, whereas I had thought of it like "care". And he would say "jay-SON" for json, which I pronounced like Jason. How would you feel about a notation that is not meant to be pronounced at all? +Employee { } where + indicates a class definition. :Rename() where : indicates a class method. ~DoStuff() where ~ indicates a static function
- mihaic 3y ago
  Interesting, for all the examples you gave, I'd prefer to see a keyword, since you'd need to use a lot of symbols for a lot of different things in this way. I do find arrow notation or other symbol for lambdas fine, since it's a unique case and not a generic type of using symbols for keywords.
naasking 3y ago
> Code in general is hard for me to mentally read. I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, Have you tried Ada? > so something like "func" instead of "fn" would be mandatory. What about no keywords, like: x => ...func body
- mihaic 3y ago
  > Have you tried Ada? I have tried Pascal in that sphere, which was on the too verbose side. Arrow notations like in JS/Typescript are fine to parse for me. Some clear symbols are actually easier to read than an unpronounceable alphanumeric.
  - int_19h 3y ago
    IMO the main thing that made Pascal verbose is begin...end for all compound statements. If you ditch that - as even Wirth himself did in the next iteration, Modula-2 - the rest is much more palatable. Consider: (* Pascal *) if a > b then begin blah; blah; end else begin blah; blah; end; -- Ada if a > b then blah; blah; else blah; blah; end if; // C if (a > b) { blah(); blah(); } else { blah(); blah(); } Pascal is clearly very verbose here, but the other two are pretty similar. That said I think that punctuation to delimit blocks makes more sense because it makes program structure clearly distinct. Although by the same token I think I'd prefer conditionals and loops to also be symbolic operators, so that there are no keywords inside executable code, only identifiers. Basically something like "?" instead of "if", "@" instead of "while" etc.
    - zozbot234 3y ago
      {} are isomorphic to 'begin' and 'end' in that snippet, though. Part of the reason why early programming languages were comparatively heavy on keywords is that the symbol set was not standardized across machines, so you couldn't count on some symbols being available. It's why C still supports <% %> as digraphs for curly braces, or <: :> for square brackets. Also why languages such as COBOL go as far as supporting syntax like DIVIDE X INTO Y, because the machine character set might not have a slash or divide sign.
ordu 3y ago
> I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, so something like "func" instead of "fn" would be mandatory. Keywords only? How about function names like strspn or sbrk? And how do you feel about assembly language, using mnemonics like fsqrt or pcmpeqd? BTW, thinking about it, I notice, that I need all these lexemes to be pronounceable too, and I have my ways to pronounce sbrk or pcmpeqd. Probably if I do it aloud no one will understand me, but it doesn't matter because these pronunciations are for internal use only.
- mihaic 3y ago
  I'm not sure how many codebases started after 2010 I've seen that have "pcmpeqd" as a method name. This is something I think makes sense only in highly optimized code, but in business logic it's a pain to read.

by mihaic 3y ago

haswell 3y ago

I’m in the middle of working through The Rust Book, and I haven’t written any serious code with it yet, so interpret this through that lens. When I looked at rust code before, it all seemed a bit weird. I couldn’t immediately understand it, but I’ve since come to realize this was because the dozen or so languages I can read well don’t really resemble rust, so my pattern matching was a bit off. The more I learn about the syntax and core concepts, the more I’m learning that my brain absolutely loves it. Once I started to understand matches, lifetime syntax and the core borrowing mechanics, things clicked and I’m more excited about writing code than I’ve been since I taught myself GW-BASIC 25 years ago. Just sharing this anecdote because I find it interesting how differently people experience languages. I also have an ongoing friendly debate with a friend who absolutely hates Python, while I rather enjoy it. I’ve tried to understand why he hates it, and he’s tried to understand why I like it. And it all seems to come down to hard-to-define things that just rub us in different ways. I hope the benefits of rust find their way into more types of languages in the future.

mihaic 3y ago
Yeah, I think at some point we all have some internal wiring that is hard to change, while other parts are flexible. For instance, I'm fine to write C++, Javascript or Python (with types at least). Ruby or Rust for some reason do rub me the wrong way, no matter how much I try to tough it out.
- haswell 3y ago
  It's interesting that you mention Ruby, because Ruby is another language that just fits the shape of my brain for some reason. I've always really struggled with the various Lisp variants.

bmitc 3y ago

> The implicit return at the end of a statement for instance make it harder for me to visually parse what's being returned, since I really depend on that keyword. Cutting my teeth on Schemes and MLs and now working in Python, I have the complete opposite experience. It's jarring to have to specify return. What else would I want to do at the end of an expression? It seems tautological. The real reason it's there in Python is early return, which is even more dangerous and jarring.

mihaic 3y ago
I know it's not very FP, but you might explicitly not want to return anything and just modify the data.
- bmitc 3y ago
  That's perfectly acceptable and expected. F# supports OOP and imperative just as much as it does functional programming. In the case of such functions and expressions, the value returned is of type `unit` with a single value of `()`. In F#, expressions that return `unit` have the value explicitly ignored if they are not the last expression in a code block. Other expressions returning non-`unit` values that aren't at the end of an expression will generate a warning. In such cases, for example where a function performs a required side effect and returns a value other than `()` but you don't need that value, you can use `|> ignore` to get rid of the warning since it says you are explicitly wanting to ignore the returned value.

mattgreenrocks 3y ago

Give it time. The syntax differences are real, but not insurmountable. I grew to prefer the location of the return type in function syntax despite having 15 years of C++ under my fingers.

4star3star 3y ago

> all keywords should be obviously pronounceable I hear you. Internally, I always pronounced "var" as rhymes with "care", but then a colleague pronounced it "var" as rhymes with "car". I think the same guy pronounced "char" like char-broiled, whereas I had thought of it like "care". And he would say "jay-SON" for json, which I pronounced like Jason. How would you feel about a notation that is not meant to be pronounced at all? +Employee { } where + indicates a class definition. :Rename() where : indicates a class method. ~DoStuff() where ~ indicates a static function

mihaic 3y ago
Interesting, for all the examples you gave, I'd prefer to see a keyword, since you'd need to use a lot of symbols for a lot of different things in this way. I do find arrow notation or other symbol for lambdas fine, since it's a unique case and not a generic type of using symbols for keywords.

naasking 3y ago

> Code in general is hard for me to mentally read. I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, Have you tried Ada? > so something like "func" instead of "fn" would be mandatory. What about no keywords, like: x => ...func body

mihaic 3y ago
> Have you tried Ada? I have tried Pascal in that sphere, which was on the too verbose side. Arrow notations like in JS/Typescript are fine to parse for me. Some clear symbols are actually easier to read than an unpronounceable alphanumeric.
- int_19h 3y ago
  IMO the main thing that made Pascal verbose is begin...end for all compound statements. If you ditch that - as even Wirth himself did in the next iteration, Modula-2 - the rest is much more palatable. Consider: (* Pascal *) if a > b then begin blah; blah; end else begin blah; blah; end; -- Ada if a > b then blah; blah; else blah; blah; end if; // C if (a > b) { blah(); blah(); } else { blah(); blah(); } Pascal is clearly very verbose here, but the other two are pretty similar. That said I think that punctuation to delimit blocks makes more sense because it makes program structure clearly distinct. Although by the same token I think I'd prefer conditionals and loops to also be symbolic operators, so that there are no keywords inside executable code, only identifiers. Basically something like "?" instead of "if", "@" instead of "while" etc.
  - zozbot234 3y ago
    {} are isomorphic to 'begin' and 'end' in that snippet, though. Part of the reason why early programming languages were comparatively heavy on keywords is that the symbol set was not standardized across machines, so you couldn't count on some symbols being available. It's why C still supports <% %> as digraphs for curly braces, or <: :> for square brackets. Also why languages such as COBOL go as far as supporting syntax like DIVIDE X INTO Y, because the machine character set might not have a slash or divide sign.

ordu 3y ago

> I know it sounds nitpicky, but to me all keywords should be obviously pronounceable, so something like "func" instead of "fn" would be mandatory. Keywords only? How about function names like strspn or sbrk? And how do you feel about assembly language, using mnemonics like fsqrt or pcmpeqd? BTW, thinking about it, I notice, that I need all these lexemes to be pronounceable too, and I have my ways to pronounce sbrk or pcmpeqd. Probably if I do it aloud no one will understand me, but it doesn't matter because these pronunciations are for internal use only.

mihaic 3y ago
I'm not sure how many codebases started after 2010 I've seen that have "pcmpeqd" as a method name. This is something I think makes sense only in highly optimized code, but in business logic it's a pain to read.