Comment by Mond_

Comment by Mond_ a day ago

16 replies

View on Hacker News

This point has been litigated to death. Read this here: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html

Almost everything that people think is ugly about Rust's syntax exists for very specific reasons. Most of the time, imo Rust made a good decision, and is just making something explicit.

Some things take time to get used to (e.g. if let), but for most people that's less an issue of syntax, and more an issue of not understanding a powerful feature (e.g. pattern matching deconstructions).

johnisgood a day ago

The reasons do not matter here. It is still ugly / noisy / overly-complicated and probably could have been done better.

I understand pattern matching deconstructions, I have seen it in other languages. Funnily enough they were nowhere as ugly / noisy / complicated as Rust's is. Rust seems to have bolted on a lot of fancy shit that may be appealing to a lot of people and that is it.

In your link, the first one is fugly, the last one is fine. Maybe Rust just encourages ugly (i.e. complicated) code a bit too much.

Reply View 4 replies
  • embedding-shape a day ago

    As someone who mostly writes Clojure code professionally during the day, I agree, Rust's syntax is complicated for no good reason, ugly and overly-verbose. But then I think that about most Algol-like language too, not just Rust.

    And despite that I do use Rust when I want something simple to deploy/deliver, as handing over a binary that just runs is such a nice experience, and it's real easy to make fast. As long as I don't have to maintain in long-term, Rust is fine for what it is.

    Reply View 0 replies
  • LtdJorge 21 hours ago

    I like Rust’s syntax and dislike Elixir/Ruby’s. I also prefer Erlang’s to Elixir, lol.

    Reply View 0 replies
  • Mond_ 21 hours ago

    > It is still ugly / noisy / overly-complicated and probably could have been done better.

    I don't know, it feels like you're just saying that you don't like it, missed the point of the post, and are not giving us anything concrete. Can you list a very clear example of how you'd improve the syntax?

    Again, see the post: You can remove things, but you're losing explicitness or other things. If you want a language that's more implicit, this is fine. I don't.

    Reply View 1 reply
    • johnisgood 3 hours ago

      > Can you list a very clear example of how you'd improve the syntax?

      The demand that I must design a better language to have valid criticism is absurd - I don't need to be a chef to know food tastes bad, do I? I'm a user of languages, not a language designer. My job is to evaluate whether Rust's syntax serves my needs, not to solve the PL design problems that led to it.

      The syntax is noisy. That's not "missing the point" - that's the direct consequence of the design choices you're defending. If your argument is "the complexity is necessary for memory safety" fine, but don't pretend the cost doesn't exist or that pointing it out is invalid.

      You're conflating "can identify a problem" with "must solve the problem". Those are different skills. I'm evaluating Rust as a user, not auditioning as a language designer.

      Reply View 0 replies
mihaic a day ago

I'm actually fine with almost all the decisions that Rust made in terms of logic and concepts, but specifically don't like the synthax itself: the symbols, keywords like the consonant-only "fn" instead of "func" for instance, the fact that || {} starts a lambda instead of || -> void {}, the fact that you can return things by simply having them in an if branch. It's the main reason I don't use the language.

Reply View 5 replies
  • DrNefario a day ago

    Most of those are a matter of preference, implicit return is just plain better, and it would be absolutely insane if closures required the return type to be specified. I do agree that the toilet bowl `|_|()` syntax is ugly, though.

    Reply View 2 replies
    • magicalhippo 16 hours ago

      > implicit return is just plain better

      I really dislike them. Makes me wonder if you just got distracted and forgot to finish the function. Be explicit, don't make me have to spend time figuring it out.

      Reply View 0 replies
    • mihaic 21 hours ago

      Again, I think JS/Typescript has a better syntax, since the implicit syntax is better when unbranched, like x => expression, but it's harder to read the more branches there are, since it's hard to visually scan where results can be located.

      Reply View 0 replies
  • Mond_ 21 hours ago

    Meh, if these are the main reasons you don't use the language, I don't know what to tell you. I get having preferences, but whether the keyword is `fn` or `func` is such a banal, trivial thing that doesn't matter at all.

    Reply View 1 reply
    • mihaic 21 hours ago

      Each taken individually is something I can ignore. But there are so many of them that it's no longer trivial to ignore.

      Reply View 0 replies
bernds74 a day ago

"if let" just breaks my brain, it feels backwards to me and takes me a minute each time to work out what's going on. In 40 years of programming I've never seen a syntactic construct that I found less intuitive. And it would probably be easily fixable, if it was more along the lines of "if x matches Some(let z)".

Reply View 1 reply
  • ai_ 16 hours ago

    if let makes a lot more sense when you learn that a normal let expression also takes a pattern[1].

      let Coordinates(x, y) = get_coords();
    But this is intended for "exhaustive patterns". If you can't express an exhaustive pattern, like with an Option, then you can use let ... else

      let Some((x, y)) = get_coords() else { return };
    if let is just an extension of this "let pattern" system.

    Once you internalize how patterns work (and they really work everywhere) it all starts to really make sense and feels a lot cleaner.

    [1]: https://doc.rust-lang.org/reference/patterns.html

    Reply View 0 replies
[removed] a day ago
[deleted]
Reply View 0 replies
Asooka 21 hours ago

They could have at least put the types on the left. Types on the right are a good fit for mathematics, where everything is single-letter symbols, so your eyes do not have to go across the line to see the entire definition, but in programming function definitions often span an entire line on screen, so the most important information should be the first thing shown! Also most programmers do not have formal education in mathematics, so the whole "function : domain -> image" syntax is foreign to them. We really should strive to democratise programming for everyone, rather than make it isolated to a small clique of "properly" educated white men who all went to the same university.

The type of a variable and the return type of a function are the most important pieces of information regarding those, so they ought to be on the left. It also fits the data flow going right to left (i.e. how the '=' operator works). C's type declarations can get pretty gnarly, so there is definitely room for improvement there. I would say Java (and C#) got it as close to perfect as possible.

If you want to replace C/C++ you should make your language look as inviting as possible to users of the old one. I truly think this strange fetish for putting types on the right is what gives C programmers the ick when they see Rust for the first time and is hampering its adoption.

Reply View 1 reply
  • kelnos 17 hours ago

    After using C and Java for years and years I absolutely loved types on the right when I started using Scala. On the right just makes so much more sense to me, and I'm not a math guy.

    Each to their own, I guess.

    Reply View 0 replies