11 ms·

Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which build

• tcfhgj 11mo ago
  what makes it unreadable for you?
  • deleted 11mo ago
    [deleted]
  • forgotpwd16 11mo ago
    Legit question really. A comparative study on language readability using codes doing the same thing written idiomatically in different languages will be interesting. Beyond syntax, idioms/paradigm/familiarity should also play role.
  • thousand_nights 11mo ago
    nta you're replying to, but as someone who doesn't know rust, on first glance it seems like it's littered with too many special symbols and very verbose. as i understand it this is required because of the very granular low level control rust offers maybe unreadable is too strong of a word, but there is a valid point of it looking unapproachable to someone new
    • yoyohello13 11mo ago
      People often misuse unreadable when they mean unfamiliar. Rust really isn't that difficult to read when you get used to it.
      • kasabali 11mo ago
        Chinese isn't that difficult to read when you get used to it, too.
    • SAI_Peregrinus 11mo ago
      I think the main issue people who don't like the syntax have with it is that it's dense. We can imagine a much less dense syntax that preserves the same semantics, but IMO it'd be far worse. Using matklad's first example from his article on how the issue is more the semantics[1] pub fn read<P: AsRef<Path>>(path: P) -> io::Result<Vec<u8>> { fn inner(path: &Path) -> io::Result<Vec<u8>> { let mut file = File::open(path)?; let mut bytes = Vec::new(); file.read_to_end(&mut bytes)?; Ok(bytes) } inner(path.as_ref()) } we can imagine a much less symbol-heavy syntax inspired by POSIX shell, FORTH, & ADA: generic type P is Path containedBy AsRef public function read takes type Path named path returns u8 containedBy Vector containedBy Result fromModule io function inner takes type reference to Path named path returns u8 containedBy Vector containedBy Result fromModule io try let mutable file = path open fromModule File let mutable bytes = new fromModule Vector try mutable reference to bytes file.read_to_end bytes Ok return noitcnuf path as_ref inner return noitcnuf and I think we'll all agree that's much less readable even though the only punctuation is `=` and `.`. So "symbol heavy" isn't a root cause of the confusion, it's trivial to make worse syntax with fewer symbols. And I like RPN syntax & FORTH. [1] https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html
      • DenisM 11mo ago
        That might be an interesting extension to a dev environment or git - convert terse rust into semi-verbose explanation. Sort of like training wheels, eventually you stop using it.
• steveklabnik 11mo ago
  Syntax tends to be deeply personal. I would say the most straightforward answer to your question is "many people disagree that it is unreadable." Rust did build on the learnings of the past 20 years. Essentially all of its syntax was taken from other languages, even lifetimes.
  • handwarmers 11mo ago
    Are the many who disagree that it is unreadable more than the people who agree? I have been involved with the language for a while now, and while I appreciate what you and many others have done for it, the sense that the group is immune to feedback just becomes too palpable too often. That, and the really aggressive PR. Rust is trying to solve a really important problem, and so far it might well be one of the best solutions we have for it in a general sense. I 100% support its use in as many places as possible, so that it can evolve. However, its evolution seems to be thwarted by a very vocal subset of its leadership and community who have made it a part of their identity and whatever socio-political leverage toolset they use.
    • simonask 11mo ago
      This is such a weird take. What do you suggest? Should Rust’s syntax have been democratically decided?
    • tayo42 11mo ago
      > the sense that the group is immune to feedback Is complaining about syntax really productive though? What is really going to be done about it?
    • azdle 11mo ago
      I've found the rust core team to be very open to feedback. And maybe I've just been using Rust for too long, but the syntax feels quite reasonable to me. Just for my own curiosity, do you have an examples of suggestions for how to improve the syntax that have been brought up and dismissed by the language maintainers?
    • steveklabnik 11mo ago
• shmolyneaux 11mo ago
  I would encourage you to give it a try anyways. Unfamiliar syntax is off-putting for sure, but you can get comfortable with any syntax. Coming from Python, I needed to work on some legacy Perl code. Perl code looks quite rough to a new user. After time, I got used to it. The syntax becomes a lot less relevant as you spend more time with the language.
  • brettermeier 11mo ago
    Sure... but you don't want to spend time if it's such a mess to read it.
    • pohl 11mo ago
      Once one does spend some time to become comfortable with the language, that feeling of messiness with unfamiliar syntax fades away. That's the case with any unfamiliar language, not just Rust.
      • morshu9001 11mo ago
        I used Rust for a year and still wasn't used to the syntax, though this was v1.0 so idk what changed. I see why it's so complicated and would definitely prefer it over C or Cpp, but wouldn't do higher-level code in it.
• simonask 11mo ago
  What are you talking about? Rust’s function signature and type declaration syntaxes are extremely vanilla, unless you venture into some really extreme use cases with lots of lifetime annotations and generic bounds. I seriously don’t get it. fn add(a: i32, b: i32) -> i32 { … } Where’s the “Perl-esqueness”?
  • simonw 11mo ago
    trait Handler { fn handle<'a>(&self, input: &'a str) -> Result<&'a str, HandlerError>; } fn process_handler<'a>( handler: Box<dyn Handler + 'a>, input: &'a str, ) -> Result<&'a str, HandlerError> { handler.handle(input) }
    • simonask 11mo ago
      > > really extreme use cases with lots of lifetime annotations and generic bounds You choose as your example a pretty advanced use case.
      • nullpoint420 11mo ago
        Which is the exact use case someone would choose rust for over other languages
        • creata 11mo ago
          No, the use cases of Rust are pretty much the same as the use cases of C++. Most Rust code shouldn't have objects with complicated lifetimes, just like most code in any language should avoid objects with complicated lifetimes.
      • simonw 11mo ago
        Yeah, because if you exclude the bits that make Rust look like Perl then it won't look like Perl!
    • tcfhgj 11mo ago
      now show me an alternative syntax encoding the same information
• stingraycharles 11mo ago
  Seems like a fairly decent syntax. It’s less simple than many systems languages because it has a very strong type system. That’s a choice of preference in how you want to solve a problem. I don’t think the memory safety guarantees of Rust could be expressed in the syntax of a language like C or Go.
  • mbel 11mo ago
    > It’s less simple than many systems languages because it has a very strong type system. I don’t think that’s the case, somehow most ML derived languages ended up with stronger type system and cleaner syntax.
    • steveklabnik 11mo ago
      Rust's most complained about syntax, the lifetime syntax, was borrowed from an ML: OCaml.
    • yoyohello13 11mo ago
      One of the design goals of rust is explicitness. I think if Rust had type elision, like many other functional languages, it would go a long way to cleaning up the syntax.
    • stingraycharles 11mo ago
      Is ML a systems language? Sorry, maybe my definition is wrong, but I consider a systems language something that’s used by a decent amount of OS’es, programming languages and OS utilities. I assume you’re talking about OCaml et al? I’m intruiged by it, but I’m coming from a Haskell/C++ background. Rust is somewhat unique in terms of system language this because it’s the first one that’s not “simple” like C but still used for systems tools, more than Go is as far as I’m aware. Which probably has to do with its performance characteristics being close to the machine, which Go cannot do (ie based on LLVM, no GC, etc)
    • dontlaugh 11mo ago
      There is no other ML-like that is as low level. Except perhaps ATS, which has terrible syntax.
• Aurornis 11mo ago
  > Comparison: I often program in Python (and teach it) - and while it has its own syntax warts & frustrations - overall the language has a "pseudocode which compiles" approach, which I appreciate. I think this is why you don’t like Rust: In Rust you have to be explicit by design. Being explicit adds syntax. If you appreciate languages where you can write pseudocode and have the details handled automatically for you, then you’re probably not going to enjoy any language that expects you to be explicit about details. As far as “janky syntax”, that’s a matter of perspective. Every time I deal with Python and do things like “__slots__” it feels like janky layer upon layer of ideas added on top of a language that has evolved to support things it wasn’t originally planned to do, which feels janky to me. All of the things I have to do in order to get a performant Python program feel incredibly janky relative to using a language with first class support for the things I need to do.
  • morshu9001 11mo ago
    Both Python and JS evolved by building on top of older versions, but somehow JS did a way better job than Python, even though Py forced a major breaking change. Agree about Rust, all the syntax is necessary for what it's trying to do.
    • jamespo 11mo ago
      You mean typescript?
      • morshu9001 11mo ago
        Before that. The classes and stuff added in ES6 and earlier
    • adastra22 11mo ago
      JS is not something I would hold up in high regard.
  • mixmastamyk 11mo ago
    > Being explicit adds syntax. Not what they are talking about. Rather better to use words instead of symbols, like python over perl. Instead of “turbofish” and <‘a>, there could be more key words like mut or dyn. Semicolons and ‘c’har are straight out of the seventies as well. :: not useful and ugly, etc. Dunders avoid namespace collisions and are not a big problem in practice, all one char, and easy to read. I might remove the trailing part if I had the power.
• short_sells_poo 11mo ago
  I'm writing this as a heavy python user in my day job. Python is terrible for writing complex systems in. Both the language and the libraries are full of footguns for the novice and expert alike. It has 20 years of baggage, the packaging and environment handling is nothing short of an unmitigated disaster, although uv seems to be a minor light at the end of the tunnel. It is not a simple language at this point. It has had so many features tacked on, that it needs years of use to have a solid understanding of all the interactions. Python is a language that became successful not because it was the best in it's class, but because it was the least bad. It became the lingua franca of quantitative analysis, because R was even worse and matlab was a closed ecosystem with strong whiffs of the 80s. It became successful because it was the least bad glue language for getting up and running with ML and later on LLMs. In comparison, Rust is a very predictable and robust language. The tradeoff it makes is that it buys safety for the price of higher upfront complexity. I'd never use Rust to do research in. It'd be an exercise in frustration. However, for writing reliable and robust systems, it's the least bad currently.
  • forgotpwd16 11mo ago
    Python had already become vastly popular before ML/AI. Scripting/tools/apps/web/... Only space that hasn't entered is mobile.
  • pxc 11mo ago
    What's wrong with R? I used it and liked it in undergrad. I certainly didn't use it as seriously as the users who made Python popular, but to this day I remember R fondly and would never choose Python for a personal project. My R use was self-taught, as well. I refused to use proprietary software for school all through high school and university, so I used R where we were expected to use Excel or MatLab (though I usually used GNU Octave for the latter), including for at least one or two math classes. I don't remember anything being tricky or difficult to work with.
    • SoftTalker 11mo ago
      R is the most haphazard programming environment I've ever used. It feels like an agglomeration of hundreds of different people's shell aliases and scripting one-liners. I'll grant my only exposure has been a two- or three-day "Intro to R" class but I ran screaming from that experience and have never touched it again. It maybe worked against me that I am a programmer, not a statistician or researcher.
• debo_ 11mo ago
  The family of languages that started with ML[0] mostly look like this. Studying that language family will probably help you feel much more at home in Rust. Many features and stylistic choices from ML derivatives have made their way into Swift, Typescript, and other non-ML languages. I often say that if you want to be a career programmer, it is a good idea to deeply learn one Lisp-type language (which will help with stuff like Python), one ML-type language (which will help with stuff like Rust) and one C-type language (for obvious reasons.) [0] https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
  • DeathArrow 11mo ago
    F# looks nothing like Rust. Is much more readable for me.
    • Daishiman 11mo ago
      F#'s semantics don't describe memory management and lifetimes to the degree that Rust does.
• fainpul 11mo ago
  > Is there a "Kotlin for Rust"? While it's not a systems language, have you tried Swift?
  • tsimionescu 11mo ago
    Swift is as relevant to this discussion as Common Lisp.
    • frizlab 11mo ago
      On the contrary, Swift is very relevant on this subject. It has high feature parity with rust, with a much readable syntax.
      • ModernMech 11mo ago
        But Swift is not "Kotlin for Rust" though, I can't see the connection at all. "Kotlin for Rust" would be a language that keeps you in the Rust ecosystem.
        • frizlab 11mo ago
          Ah yeah ok, makes sense in that way
        • fainpul 11mo ago
          The commenter I replied to seems to like Kotlin. Swift is extremely close to Kotlin in syntax and features, but is not for the JVM. Swift also has a lot of similarities with Rust, if you ignore the fact that it has a garbage collector.
          • adastra22 11mo ago
            A Kotlin for Rust would be a drop-in replacement where you could have a crate or even just a module written in this hypothetical language and it just works. No bridging or FFI. That’s not Swift.
• raincole 11mo ago
  > Why are we pushing forward with a language that has a Perl-esque unreadability...? The reason is the same for any (including Perl, except those meme languages where obfuscation is a feature) language: the early adopters don't think it's unreadable.
• jjice 11mo ago
  Maybe I've Stockholm'd myself, but I think Rust's syntax is very pleasant. I also think a lot of C code looks very good (although there is some _ugly_ C code out there). Sometimes the different sets of angle and curly brackets adding up can look ugly at first, and maybe the anonymous function syntax of || {}, but it grows on you if you spend some time with the language (as do all syntaxes, in my experience).
• movpasd 11mo ago
  You might this blog post interesting, which argues that it's Rust semantics and not syntax that results in the noisiness, i.e.: it's intrinsic complexity: https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html https://matklad.github.io/2023/01/26/rusts-ugly-syntax.html I found it reasonably convincing. For what it's worth, I found Rust's syntax quite daunting at first (coming from Python as well), but it only took a few months of continuous use to get used to it. I think "Perl-esque" is an overstatement. It has some upsides over Python as well, notably that the lack of significant whitespace means inserting a small change and letting the autoformatter deal with syntax changes is quite easy, whereas in Python I occasionally have to faff with indentation before Black/Ruff will let me autoformat. I appreciate that for teaching, the trade-offs go in the other direction.
  • echelon 11mo ago
    That's it exactly. Once you're writing Rust at full speed, you'll find you won't be putting lifetimes and trait bounds on everything. Some of this becomes implicit, some of it you can just avoid with simpler patterns. When you write Rust code without lifetimes and trait bounds and nested types, the language looks like Ruby lite. When you write Rust code with traits or nested types, it looks like Java + Ruby. When you sprinkle in the lifetimes, it takes on a bit of character of its own. It honestly isn't hard to read once you use the language a lot. Imagine what Python looks like to a day zero newbie vs. a seasoned python developer. You can constrain complexity (if you even need it) to certain modules, leaving other code relatively clean. Imagine the Python modules that use all the language features - you've seen them! One of the best hacks of all: if you're writing HTTP services, you might be able to write nearly 100% of your code without lifetimes at all. Because almost everything happening in request flow is linear and not shared.
    • carlmr 11mo ago
      >When you write Rust code without lifetimes and trait bounds and nested types, the language looks like Ruby lite. And once you learn a few idioms this is mostly the default.
    • SoftTalker 11mo ago
• enriquto 11mo ago
  > I am thrown back by how... "janky" the syntax is. Well if you come from C++ it's a breath of fresh air! Rust is like a "cleaned-up" C++, that does not carry the historical baggage forced by backwards compatibility. It is well-thought out from the start. The syntax may appear a bit too synthetic; but that's just the first day of use. If you use it for a few days, you'll soon find that it's a great, beautiful language! The main problem with rust is that the community around it has embraced all the toxic traditions of the js/node ecosystem, and then some. Cargo is a terrifying nightmare. If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole. Concerning TFA, adding rust to apt might be a step in the right direction. But it should be symmetric: apt depends on rust, that's great! But all the rust that it depends on needs to be installed by apt, and by apt alone!
  • raincole 11mo ago
    > Cargo is a terrifying nightmare Really? Why? I'm not a Rust guru, but Cargo is the only part of Rust that gave me a great first impression.
    • freedomben 11mo ago
      GP mostly answered that in the comment already: > If you could install regular rust dependencies with "apt install" in debian stable, that would be a different story! But no. They want the version churn: continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole.
      • steveklabnik 11mo ago
        The problem, of course, is that "apt install" only works on platforms that use apt to manage their packages.
      • raincole 11mo ago
        I don't know, it doesn't explain how and why Cargo causes "continuously adding and removing bugs, like particle/anti-particle pairs at the boundary of a black hole."
• ModernMech 11mo ago
  > upon the learnings of the past 20+ years. That's the thing though... Rust does build on many of those learnings. For starters, managing a big type system is better when some types are implicit, so Rust features type inference to ease the burden in that area. They've also learned from C++'s mistake of having a context sensitive grammar. They learned from C++'s template nightmare error messages so generics are easier to work with. They also applied learnings about immutability being a better default that mutability. The reason Rust is statically linked and packages are managed by a central repository is based on decades of seeing how difficult it is to build and deploy projects in C++, and how easy it is to build and deploy projects in the Node / NPM ecosystem. Pattern matching and tagged unions were added because of how well they worked in functional languages. As for "Perl-esque unreadability" I submit that it's not unreadable, you are just unfamiliar. I myself find Chinese unreadable, but that doesn't mean Chinese is unreadable. > Is there a "Kotlin for Rust"? Kotlin came out 16 years after Java. Rust is relatively new, and it has built on other languages, but it's not the end point. Languages will be written that build on Rust, but that will take some time. Already many nascent projects are out there, but it is yet to be seen which will rise to the top.
• maximilianburke 11mo ago
  In your opinion how does Rust compare to C++ for readability?
  • adastra22 11mo ago
    C++ is vastly more readable. I will never go back to writing or maintaining C++ projects, but drop me into a C++ file to review something and it is usually very easy to grok. Part of this is style and conventions though. I have implemented an STL container before, and that templating hell is far worse than anything I’ve ever seen in the Rust ecosystem. But someone following modern C++ conventions (e.g. a Google library) produces very clean and readable code.
    • maximilianburke 11mo ago
      How do you handle understanding the semantics in the presence of custom overloaded operators?
      • adastra22 11mo ago
        That's not what "readability" generally means. Yes, Rust's semantics are more tightly locked down, and that's a big part of why I use it. But given two well-written source files, one in modern C++ and one in contemporary Rust, can you quickly skim and understand what each one is supposed to be doing, irregardless of bugs that might be lurking? If you made me guess right now which one I'd have an easier time understanding, I'd guess the C++ file.
  • teunispeters 11mo ago
    Honestly, rust is slightly more readable than obfuscated perl. I think I prefer K&R C, and I don't like K&R C. In terms of readability, maybe equivalent to early Win32 API? [3000 lines to set up API, then call to activate]. With C++ you have a range of readable from - easy and very approachable - to 2000s era Microsoft STL. (where not only is it close to unreadable, many many hidden bugs are ... somewhere. And behaviour is not consistent). I will admit I don't find Rust quite as unreadable as the 2000s era Microsoft STL, but the latter's one of the things that pushed me far more into Linux dev. Rust is the kind of language that would push me to write a new language that isn't rust. And maybe work on supporting all the zillion platforms rust doesn't support. Or maybe just stick to C. I'm not a fan, but there are worse, and yeah - there are some C++ libraries out there that are worse. Lots that are better, too, eg llvm source.
• EugeneOZ 11mo ago
  Does it really add any value to the conversation?
• whimsicalism 11mo ago
  I don’t program much in Rust, but I find it a beautiful syntax… they took C++ and made it pretty much strictly better along with taking some inspiration from ML (which is beautiful imo)
• WD-42 11mo ago
  I’ve been writing python professionally for over 10 years. In the last year I’ve been writing more and most Rust. At first I thought the same as you. It’s a fugly language, there’s no denying it. But once I started to learn what all the weird syntax was for, it began to ruin Python for me. Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right there beneath the surface: prolific duck typing, exceptions as control flow, dynamic attributes. All these now make me uneasy, like I can’t be sure what my code will really do at runtime. Rust is ugly but it’s telling you exactly what it will do.
  • mixmastamyk 11mo ago
    Those complaints have very little to do with the syntax.
  • ActorNightly 11mo ago
    >Now I begrudge any time I have to go back to python. It feels like its beauty is only skin deep, but the ugly details are right there beneath the surface: prolific duck typing, exceptions as control flow, dynamic attributes. All these now make me uneasy, like I can’t be sure what my code will really do at runtime. I feel like this sentiment is from people who haven't really took the time to fully see what the Python ecosystem is. Any language can have shittly written code. However languages that by default disallow it means that you have to spend extra time prototyping things, whereas in Python, you can often make things work without much issue. Dynamic typing and attributes make the language very flexible and easily adaptable.
    • WD-42 11mo ago
      Oh I’m familiar with the ecosystem. Yes the dynamic nature does make it easy to prototype things flexibly. The problem is when your coworker, or you, decide to flexibly and dynamically get the job on a Friday before a long weekend and then 3 months later you need to figure out how a variable is being set, or where a method is being called.
      • 11mo ago
• nawgz 11mo ago
  Python users don’t even believe in enabling cursory type checking, their language design is surpassed even by JavaScript, should it really even be mentioned in a language comparison? It is a tool for ML, nothing else in that language is good or worthwhile
• sorcercode 11mo ago
  Kotlin programmer here who is picking up Rust recently. you're right, it's no Kotlin when it comes to the elegance of APIs but it's also not too bad at all. In fact there are some things about the syntax that are actually nice like range syntax, Unit type being (), match expressions, super explicit types, how mutability is represented etc. I'd argue it's the most similar system level language to Kotlin I've encountered. I encourage you to power through that initial discomfort because in the process it does unlock a level of performance other languages dream of.
• torben-friis 11mo ago
  Have you considered that part of it is not the language but the users? I'm learning rust and the sample code I frequently find is... cryptically terse. But the (unidiomatic, amateurish) code I write ironically reads a lot better. I think rust attracts a former c/c++ audience, which then bring the customs of that language here. Something as simple as your variable naming (character vs c, index vs i) can reduce issues already.
• dimgl 11mo ago
  > Every time I consider learning Rust, I am thrown back by how... "janky" the syntax is. It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. I said this years ago and I was basically told "skill issue". It's unreadable. I shudder to think what it's like to maintain a Rust system at scale.
  • yoyohello13 11mo ago
    You get used to it. Like any language.
  • JuniperMesos 11mo ago
    The syntax has relatively little to do with how easy or hard it is to maintain a rust system at scale. If you get something wrong the compiler will alert you, and most of the syntax is there for good reasons that anyone maintaining any kind of software system at scale needs to understand (and indeed the syntax helps you be clear about what you mean to the compiler, which facilitates helpful compiler error messages if you screw something up when modifying code).
• dev_l1x_be 11mo ago
  I would argue that anything that is not Lisp has a complicated syntax. The question is: is it worth it? With Rust for the answer is yes. The reliability, speed, data-race free nature of the code I get from Rust absolutely justifies the syntax quirks (for me!).
• deleted 11mo ago
  [deleted]
• bicarbonato 11mo ago
  What do people actually mean when they say "the syntax is janky"? I often see comparisons to languages like Python and Kotlin, but both encode far less information on their syntax because they don't have the same features as Rust, so there's no way for them to express the same semantics as rust. Sure, you can make Rust look simpler by removing information, but at that point you're not just changing syntax, you're changing the language's semantics. Is there any language that preserves the same level of type information while using a less "janky" syntax?
  • NoGravitas 11mo ago
    I don't know if there is, but there certainly needs to be. All of Rust's syntax seems to be needed to support its semantics, but it also undeniably crosses a threshold of "too much syntax". Though I do agree with the person above who said that every language that's not Lisp has too much syntax.
• SquibblesRedux 11mo ago
  As an official greybeard who has written much in C, C++, Perl, Python, and now Rust, I can say Rust is a wonderful systems programming language. Nothing at all like Perl, and as others have mentioned, a great relief from C++ while providing all the power and low-level bits and bobs important for systems programming.
• hedora 11mo ago
  The sigils in Rust (and perl) are there to aid readability. After you use it a bit, you get used to ignoring them unless they look weird. All the python programs I've had to maintain (I never choose python) have had major maintainability problems due to python's clean looking syntax. I can still look at crazy object oriented perl meta-programming stuff I wrote 20 years ago, and figure out what it's doing. Golang takes another approach: They impoverished the language until it didn't need fancy syntax to be unambiguously readable. As a workaround, they heavily rely on codegen, so (for instance) Kubernetes is around 2 million lines of code. The lines are mostly readable (even the machine generated ones), but no human is going to be able to read them at the rate they churn. Anyway, pick your poison, I guess, but there's a reason Rust attracts experienced systems programmers.
• yoyohello13 11mo ago
  > It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years I mean, Rust does. I builds on 20+ years of compiler and type system advancements. Then Syntax is verbose if you include all then things you can possibly do. If you stick to the basics it's pretty similar to most other languages. Hell, I'd say a lot of syntax Rust is similar to type-hinted Python. Having said that, comparing a GC'd dynamic language to a systems programming language just isn't a fair comparison. When you need to be concerned about memory allocation you just need more syntax.
• creata 11mo ago
  I think this is subjective, because I think Rust's syntax is (mostly) beautiful. Given the constraint that they had to keep it familiar to C++ people, I'd say they did a wonderful job. It's like C++ meets OCaml. Do you have any particular complaints about the syntax?
• nixpulvis 11mo ago
  Aside from async/await which I agree is somewhat janky syntaxtically, I'm curious what you consider to be janky. I think Rust is overall pretty nice to read and write. Patterns show up where you want them, type inference is somewhat limited but still useful. Literals are readily available. UFCS is really elegant. I could go on. Ironically, I find Python syntax frustrating. Imports and list comprehensions read half backwards, variable bindings escape scope, dunder functions, doc comments inside the function, etc.
• e12e 11mo ago
  > It seems to me that we ought to have a system-level language which builds upon the learnings of the past 20+ years. Maybe Ada, D or Nim might qualify?
• paulddraper 11mo ago
  Perl’s most notable syntax feature is sigils on all variables. So it’s strange to hear a comparison. Maybe there’s something I’m missing. It seems closer to C++ syntax than Perl.
• JuniperMesos 11mo ago
  I prefer Rust syntax to Python's purely on the grounds that Rust is a curly-brace language and Python is an indentation-sensitive language. I like it when the start and end of scopes in code are overtly marked with a non-whitespace character, it reduces the chances of bugs caused by getting confused about what lines of code are in what scope and makes it easier to use text editor tools to move around between scopes. Beyond that issue, yeah most of Rust's syntactic noise comes from the fact that it is trying to represent genuinely complicated abstractions to support statically-checked memory safety. Any language with a garbage collector doesn't need a big chunk of Rust's syntax.
  • mixmastamyk 11mo ago
    The rust syntax problem is not the braces but about all the #[()] || ::<<>> ‘stuff.
    • metaltyphoon 11mo ago
      Attribute, lambda and turbofish?
      • mixmastamyk 10mo ago
        And 'lifetime. ;-)
• pessimizer 11mo ago
  I think the problem for people is the traditional problem that a lot of people have had with a lot of languages since C took off: it doesn't look like ALGOL, and doesn't have the semantics of ALGOL. The reason python looks like procedural pseudocode is because it was designed to look like procedural pseudocode. Rust is not just a new skin over ALGOL with a few opinionated idioms, it's actually different - mostly to give hints of intention to the compiler, but I don't even think it started from the same place. It's more functional than anything imo, but without caring about purity or appearance, and that resulted in something that superficially looks sufficiently ALGOL-like to confuse people who are used to python or Kotlin. > I genuinely believe that languages ought to start with "newbie friendliness", and would love to hear challenges to that idea. In conclusion, I think this is a red herring. Computer languages are hard. What you're actually looking for is something that is ALGOL-like for people who have already done the hard work of learning an ALGOL-like. That's not a newbie, though. Somebody who learned Rust first would make the same complaint about python.
• cb321 11mo ago
  You might enjoy https://nim-lang.org/ https://nim-lang.org/ which has a Python-like syntax with even more flexibility really (UFCS, command-like calls, `fooTemplate: stuff` like user-defined "statements", user-defined operators, term-rewriting macros and more. With ARC it's really just about as safe as Rust and most of the stdlib is fast by default. "High quality" is kind of subjective, but they are often very welcoming of PRs. Anyway, to your point, I think a newbie could pick up the basics quickly and later learn more advanced things. In terms of speed, like 3 different times I've compared some Nim impl to a Rust impl and the Nim was faster (though "at the extreme" speed is always more a measure of how much optimization effort has been applied, esp. if the language supports inline assembly). https://cython.org/ https://cython.org/ , which is a gradually typed variant of Python that compiles to C, is another decent possibility.
• gaanbal 11mo ago
  sounds like something that could be solved with more learning I wrote python for 15 years I don't want to write python anymore. mainly rust if I can