20 ms·

> This is a superficial complaint, but I found Rust syntax to be dense, heavy, and difficult to read I'm a huge Rust fan, but sort of agree. First, I dislike C

• jillesvangurp 4y ago
  Something like Kotlin but with a borrow checker might be the ultimate in developer ergonomics for me. I sat down at some point to wrap my head around Rust and ended up abandoning that project due to a lack of time. And because it was hard. The syntax is a hurdle. Still, I would like to pick that up at some point but things don't look good in terms of me finding the time. However, Rust's borrow checker is a very neat idea and one that is worthy of copying for new languages; or even some existing ones. Are there any other languages that have this at this point? I think the issue with Rust is simply that it emerged out of the C/C++ world and they started by staying close to its syntax and concepts (pointers and references) and it kind of went down hill from there. Adding macros to the mix allowed developers to fix a lot of issues; but at the price of having code that is not very obvious about its semantics to a reader. It works and it's probably pretty in the eyes of some. But too me it looks like Perl and C had a baby. Depending on your background, that might be the best thing ever of course.
  • cogman10 4y ago
    The borrow checker doesn’t really work without lifetime annotations. When I see complaints about rust, that’s seems to be the thing most are talking about. The issue is the notion of an object lifetime is a hard thing to express with familiar type systems. It’s an unfamiliar concept.
    • josephg 4y ago
      Yep. And the struggle learning rust is that you sort of need to learn the borrow checker and lifetimes all at once. You can’t use rust at all without any of that stuff, and there’s a lot to learn before you feel productive! Even a year in to rust I can still throw things together a lot faster in javascript. That may always be true. So I doubt rust will ever displace python and javascript for everyday app development. But it’s an excellent language for operating systems, game engines, databases, web browsers, IDEs and things like that where stability and performance matter more than cramming in ever more features.
      • pkolaczk 4y ago
        The trick is to avoid long living references as much as possible. You need to unlearn the Java/JS/Python style where everything is a reference. In Rust you should default to value (fully owned) types and move semantics and use references for temporary borrows only. Think about cloning first when you need the data in more than one place, before considering references. It is surprising how far you can get with that approach without ever writing a sigle lifetime annotation.
        • HowardStark 4y ago
          I’m nosy sure I agree. There definitely isn’t a “one-size-fits-all” to writing Rust, but I do think that falling back to a “error here? try .clone()” mentality ends up defeating the purpose. Maybe what Rust needs is a “build a program with lots of allocations” and then “whittle down allocations with smart use of references” section of the book.
          • 4y ago
  • zozbot234 4y ago
    Rust and Kotlin have very similar syntax. The main differences are semantics-related, such as Kotlin relying on GC.
  • cortesoft 4y ago
    Is the syntax really that much of a burden? I don't have a perfect grasp of the syntax and would have trouble if I was having to write rust code with zero reference, but as long as I have other rust code open it is pretty easy to remember what each part does.
    • iopq 4y ago
      It's just hard to parse fn apply<A, B, C, G>(mut f: impl FnMut(B) -> G, a: A) -> impl FnMut(&B) -> C // must still be `for<'r> impl FnMut(&'r B) -> C`, because that’s what filter requires where G: FnMut(A) -> C, B: Copy, // for dereferencing A: Clone, { move |b| f(*b)(a.clone()) // this must do any bridging necessary to satisfy the requirements } I wrote this code myself, and it's SLOW for me to read. Each part isn't hard, it's just too much crap
  • hazn 4y ago
    Swift is getting ownership/borrow checker mechanisms in Swift 6[1]. Kotlin and Swift have very similar ergonomics [2] (little outdated link). Together with Actors types/Distributed runtimes, Optional Automatic Reference Counting and good support on Linux, Swift is developing into a killer language imo. [1] https://forums.swift.org/t/a-roadmap-for-improving-swift-performance-predictability-arc-improvements-and-ownership-control/54206 https://forums.swift.org/t/a-roadmap-for-improving-swift-per... [2] http://nilhcem.com/swift-is-like-kotlin/ http://nilhcem.com/swift-is-like-kotlin/
• LAC-Tech 4y ago
  People seem allergic to anything that isn't superficially ALGOL like. I still remember Facebook had to wrap Ocaml in curly braces because it would apparently blow peoples minds.
• codebje 4y ago
  > That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, … I am not convinced that there's so more to Rust than there is to GHC Haskell to justify so much dense syntax. There's many syntax choices made in Rust based, I assume, on its aim to appeal to C/C++ developers that add a lot of syntactic noise - parentheses and angle brackets for function and type application, double colons for namespace separation, curly braces for block delineation, etc. There are more syntax choices made to avoid being too strange, like the tons of syntax added to avoid higher kinded types in general and monads in particular (Result<> and ()?, async, "builder" APIs, etc). Rewriting the example with more haskell-like syntax: Trying::to_read::<&'a heavy>(syntax, |like| { this. can_be( maddening ) }).map(|_| ())?; Trying.to_read @('a heavy) syntax (\like -> can_be this maddening) >> pure () It's a tortuous example in either language, but it still serves to show how Rust has made explicit choices that lead to denser syntax. Making a more Haskell-like syntax perhaps would have hampered adoption of Rust by the C/C++ crowd, though, so maybe not much could have been done about it without costing Rust a lot of adoption by people used to throwing symbols throughout their code. (And I find it a funny place to be saying _Haskell_ is less dense than another language given how Haskell rapidly turns into operator soup, particularly when using optics).
  • skavi 4y ago
    > In more plain terms, the line above does something like invoke a method called “to_read” on the object (actually `struct`) “Trying”... In fact, this invokes an associated function, `to_read`, implemented for the `Trying` type. If `Trying` was an instance `Trying.to_read...` would be correct (though instances are typically snake_cased in Rust). I'll rewrite the line, assuming `syntax` is the self parameter: syntax .to_read::<&'a heavy>(|like| this.can_be(maddening)) .map(|_| ())?; In my opinion, this is honestly not bad.
  • zozbot234 4y ago
    > like the tons of syntax added to avoid higher kinded types in general and monads in particular (Result<> and ()?, async, "builder" APIs, etc). Rust is not "avoiding" HKT in any real sense. The feature is being worked on, but there are interactions with lifetime checking that might make, e.g. a monad abstraction less generally useful compared to Haskell.
• ducktective 4y ago
  > I found Rust syntax to be dense, heavy, and difficult to read Reminds me of this section of Rich Hickey talk: https://www.youtube.com/watch?v=aSEQfqNYNAc https://www.youtube.com/watch?v=aSEQfqNYNAc
  • voorwerpjes 4y ago
    There are similar issues in Rust to the one Hickey talks about in Java, in terms of cognitive overload and difficulty in a human parsing the program. However, I've found rust largely avoids issues with a bunch of different classes and with their own specific interfaces with a bunch of getters and setters in the HTTP servlet example because of Trait interface reuse.
• dhosek 4y ago
  Familiarity also alleviates the issue. I can remember when I first encountered TeX in the 80s and Perl in the 90s and thought the code looked like line noise and now I no longer see that (even in Larry Wall–style use-all-the-abbreviations Perl).
  • sidlls 4y ago
    It alleviates the issue the way the frog doesn't notice in the "boiling frog" fable. That is, not in a good way. The cognitive load to parse and understand it is still there; you're just not as aware of it distracting from other matters. Some (me) would say it distracts from more important things, like how units of code compose and what the purpose of a program is.
  • cardanome 4y ago
    The problem is that familiarity needs to be maintained or you can lose it. As someone that doesn't get to use Rust at my day job that can be hard to keep fresh. I only occasionally dabble in Rust in my free time and coming back to a project of mine after months of not having used any Rust, yeah lets just say that line noise made me prematurely murder some of my pet-projects. Sure it gets probably better with time but still it is a cost that one pays.
  • riskable 4y ago
    > ...thought the code looked like line noise and now I no longer see that "I don't even see the code anymore. I just see blonde, brunette, ..." I myself have just started to get like that with my understanding of Rust: "I don't even see the `impl<P: 'static, const PS: usize> IndexMut<usize> for SomeThing<P, PS>` anymore. I just see a mutable iterator."
• cies 4y ago
  Maybe we've reached the limits of the complexity we can handle in a simple text-based language and should develop future languages with IDEs in mind. IDEs can hide some of the complexity for us, and give access to it only when you are digging into the details.
  • pjmlp 4y ago
    Like Common Lisp, Smalltalk, SELF, Delphi, C++ Builder, Java, C#, Visual Basic,.... The problem is that most on FOSS community tend to design languages for VI/Emacs workflows.
  • flohofwoe 4y ago
    This just plasters over the underlying problem, which in case of Rust is IMO that features that should go into the language as syntax sugar instead are implemented as generic types in the standard library (exact same problem of why modern C++ source code looks so messy). This is of course my subjective opinion, but I find Zig's syntax sugar for optional values and error handling a lot nicer than Rust's implementation of the same concepts. The difference is (mostly): language feature versus stdlib feature.
    • vlovich123 4y ago
      I’m not familiar with zig. Can you give some examples to illustrate your point?
      • flohofwoe 4y ago
        An optional is just a '?' before the type: For instance a function which returns an optional pointer to a 'Bla': fn make_bla() ?*Bla { // this would either return a valid *Bla, or null } A null pointer can't be used accidentally, it must be unwrapped first, and in Zig this is implemented as language syntax, for instance you can unwrap with an if: if (make_bla()) |bla| { // bla is now the unwrapped valid pointer } else { // make_bla() returned null } ...or with an orelse: const bla = make_bla() orelse { return error.InvalidBla }; ...or if you know for sure that bla should be valid, and otherwise want a panic: const bla = make_bla().?; ...error handling with error unions has similar syntax sugar. It's probably not perfect, but I feel that for real-world code, working with optionals and errors in Zig leads to more readable code on average than Rust, while providing the same set of features.
• shadowofneptune 4y ago
  The same information can be communicated in different ways, trading one form of noise for another. I have a personal preference for Pascal-like or PL/I syntax. Instead of int *char x or int&& x, there's x: byte ptr ptr. It's more to type and read, sure, but sometimes having an english-like keyword really helps clarify what's going on.
  • Banana699 4y ago
    The english words preference is a cliché that has been argued back and forth, to heaven and hell, since Cobol. I'm sympathetic to your opinion in some cases, but ultimately it fails in my view. Terse notations requires an investment in the beginning but then pay off massively with increased bandwidth, you can hold more of the code in your head. You don't see math being done by (x.plus(y)).pow(3), you see it done by (x+y)^3, it gets even worse when expressions increase in size. Ideally, the language should have enough syntax-bending facilities so that you can still simulate what you want, this is mostly just operator overloading and not treating custom types like second class citizens. For example, your example of byte ptr ptr can be easily done in C++ by a bytePtrPtr struct, or even better, a Ptr<Ptr<Byte>> instantiated class from the template Ptr<T> for any T. Overloading the dereference and conversion operators will completely hide any trace of the fact it's not a built in type, and compiler optimization and inlinning will (hopefully, fingers crossed) ensure that no extra overhead is being introduced by the abstraction. As for the 'byte ptr ptr' syntax specifically, in F# generic instantiation can be done by whitespace concatenation of type names in reversed C++/Java/C# order, so the above C++ type would (if translated to F# somehow) literally be written out as you want it to be, so even what seems like it would require language support (whitespace between related identifiers, generally a tricky thing in PL design) can actually be accomplished with clever and free minded syntax.
    • shadowofneptune 4y ago
      That is a good point about typedefs, and I would hate to be using 'ADD 1, a, b TO x ROUNDED' instead of 1 + a + b + round(x). I'll also have to check out F#.
  • nu11ptr 4y ago
• fulafel 4y ago
  From the modern systems programming languages set, Go does better in this respect. But admittedly it doesn't reach to quite as low in fitness for low level programming as Rust.
  • weatherlight 4y ago
    Go is a systems programming language?
    • anfilt 4y ago
      Yes it is, but not a a good low level systems language mainly due to garbage collection and runtime requirements. It still is used for writing keyword here systems.
    • goodpoint 4y ago
      No, due to its runtime. You can write a database with it but that makes it an application language, not system. Otherwise you could call every language a "system language" and the distinction would lose all meaning.
    • UnpossibleJim 4y ago
      It can be, but I wouldn't recommend it personally: https://golangdocs.com/system-programming-in-go-1 https://golangdocs.com/system-programming-in-go-1 EDIT: formatting
    • fulafel 4y ago
      Yes, as it's used for that a lot. Eg many databases (CockroachDB, Prometheus, InfluxDB, dgraph etc), gVisor, Kubernetes, Fuchsia, etcd, and so on. And also in the origin story it was aiming to compete with C++ for many use cases IIRC.
    • mindcrime 4y ago
      That's tricky to answer, because it depends a lot on what you count as "system software". If you mean literally "the operating system", then arguably not. But if you include middleware, databases and other "infrastructure" stuff, then arguably yes.
• hawski 4y ago
  I find that Rust tends to have code that goes sideways more than downward. I prefer the latter and most C code bases, that I find elegant are like that. It is like that, because of all the chaining that one can do. It is also just a feeling.
  • est31 4y ago
    There are two upcoming features, let chains and let else, to counter the sideways drift. Sometimes it's also the formatter though that outputs intensely sideways drifting code: https://github.com/rust-lang/rust/blob/1.60.0/compiler/rustc_borrowck/src/diagnostics/region_name.rs#L772-L794 https://github.com/rust-lang/rust/blob/1.60.0/compiler/rustc...
    • UmbertoNoEco 4y ago
      • est31 4y ago
        While generally, yes, features are bloating up a language, one could argue these two particular features reduce complexity. Like why am I forbidden to use && in a if let? And why does if let support both irrefutable and refutable patterns but deconstructing let requires them to be irrefutable?
        • UmbertoNoEco 4y ago
          There is surely some "law" in some place of the internet that says something like: "Every programming language valid construction no matter how ugly, obscure,verbose,old,etc will find its way to lots of codebases". See C++.
          • estebank 4y ago
            Yes, John Carmack has said as much, at least in the context of syntactically and semantically valid constructs that are actually bugs making it into codebases. What does that have to do with let chains and let else?
• queuebert 4y ago
  Completely agree. I think of the extra syntax as us helping the compiler check our code. I have to write a few more characters here and there, but I spend way less time debugging. Although I may have PTSD from Rust, because lately I find myself preferring Qbasic in my spare time. ¯\_(ツ)_/¯
  • agumonkey 4y ago
    Probably a very general response to overload of any kind.. you start to reevaluate the opposite side of the spectrum.
    • smegsicle 4y ago
      the dialectical method
      • agumonkey 4y ago
        I'd have used the 'banging on both guard rails but yours sounds better.
• runevault 4y ago
  Your summary is the thing I struggle with as well. How do you deal with the issues of density without either making it more verbose by a wide margin (which also hampers readability) or hiding information in a way that makes the code less obvious which is, IMO, worse. Software is becoming more and more complex and unless there are entirely different design patterns we have failed to find, managing and understanding that during both the writing and the maintenance of software is the fundamental problem of our time. Someone else in these comments mentioned leaning more heavily into IDE tooling and I do wonder if we are coming to a point where that makes sense.
  • ModernMech 4y ago
    > unless there are entirely different design patterns we have failed It’s not that we’ve failed to find different design patterns, it’s that we found these patterns in the 70s and haven’t done much with them since. Since C there has been a pretty constant march toward more imperative programming, but imperative programming I feel has reached its peak for the reasons you describe. We’re only just starting to explore the functional programming space and incorporate those learnings into our work. But what about logic programming, dataflow programming, reactive programming, and other paradigms that have been discovered but not really fully explored to the extent imperative programming has been? I think there’s a lot of room for improvement just by revisiting what we’ve already known for 50 years.
    • infogulch 4y ago
      The imperative design matches the hardware too well to just dispense with. Rust's abstractions are probably the closest we've gotten to a composable design that fits closely to the hardware while mechanically preventing writing the most common bugs at that level. That said I agree that we've barely scratched the surface of the space of good paradigms; I'm partial to logic programming but most are underexplored. Perhaps other approaches can use Rust or its IR (MIR?) as a compilation target. As an example, this strategy is being used by DDlog ( https://github.com/vmware/differential-datalog https://github.com/vmware/differential-datalog ).
• api 4y ago
  IMHO it's at least somewhat better than "modern" C++ where you end up having to wrap virtually every single thing in some kind of template class, and that's without the benefit of much stronger memory and thread safety. Overall I think Rust is a hands-down win over C and C++. People who want it to be like Go are probably not doing systems-level programming, which is what Rust is for, and I have severe doubts about whether a rich systems-level language could be made much simpler than Rust and still deliver what Rust delivers. If you want full control, manual memory management with safety, other safety guarantees, a rich type system, high performance, and the ability to target small embedded use cases, there is a certain floor of essential complexity that is just there and can't really be worked around. Your type system is going to be chonky because that's the only way to get the compiler to do a bunch of stuff at compile time that would otherwise have to be done at runtime with a fat runtime VM like Go, Java, C#.NET, etc. have. Go requires a fat runtime and has a lot of limitations that really hurt when writing certain kinds of things like high performance codecs, etc. It's outstanding for CRUD, web apps, and normal apps, and I really wish it had a great GUI story since Go would be a fantastic language to write normal level desktop and mobile UI apps.
  • Night_Thastus 4y ago
    For what purpose would you need to wrap everything in a template class? In my work, I've only touched templates a couple of times in years. They're useful, but I don't see how it's always needed.
    • ben-schaaf 4y ago
      std::unique_ptr and std::shared_ptr are templated wrapper classes.
      • Night_Thastus 4y ago
        Oh. I misunderstood. I was thinking of user-made templates, not the built-in ones from the standard library. I don't see the issue though. Something like vector feels intuitive. I have a vector<int> or a vector<myType> etc. A pointer to an int, a unique_ptr<int>. It's convenient and fairly flexible. I don't really see the downside, or how it could be done better given static typing.
• sph 4y ago
  There's definitely a space for native languages that are not as dense and performant possibly as Rust. I will trade some readability when I need strict memory guarantees and use Rust, but most of my time I'd like to use something readable and fun to use, which Rust ain't. I used to use Go, not much of a fan anymore, but I'm liking Crystal a lot to fill this space. Eventually Zig when it's more mature.
  • sbmthakur 4y ago
    Just started learning Go. If I may ask, why did you loose interest in Go?
    • sph 4y ago
      Not enough syntax sugar, not functional enough, and a few smaller papercuts. It feels dry, like a humourless android. Not very fun to write but probably the most pragmatic choice for the problem. I prefer having fun when I program.
      • merely-unlikely 4y ago
        I tend to see that as an advantage - the language gets out of the way and lets me just have fun with the problem itself. Especially if I'm referencing code other people wrote (ie libraries) where I can pretty much instantly grok what's going on and focus on the logic. Different strokes
        • xigoi 4y ago
          I wouldn't call a huge mountain of `if err != nil` “gets out of the way”.
• SemanticStrengh 4y ago
  What kind of meaningful data is passed (besides lifetimes) that isn't passed in Kotlin or scala 3 extension methods?
  • masklinn 4y ago
    Ah yes, "what kind of meaningful data is passed besides the most important concept in the language?" Also, the ownership mode, a concept entirely missing from Kotlin or Scala. As GP says, Rust's syntax is pretty noisy, but much of the noise is answers to questions other languages don't even ask. And many complains are requests for additional noise for things which are just regular in Rust, like additional syntactic sugar for Option and Result.
• logicchains 4y ago
  >That said, I've mostly reached the conclusion that much of this is unavoidable. Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python, and trait impls on arbitrary types after the fact is very powerful and not something I would want to give up. Have you checked out C++20 concepts? It supports aliases and doesn't require explicit trait instantiations, making it possible to right such generic code with much less boilerplate.
  • loeg 4y ago
    My experience in C++ prior to 20 is that it is a lot more verbose/boilerplatey than Rust. I'd love to see that get better, but I think C++ is starting from significantly behind.
    • jcelerier 4y ago
      C++17: template<typename T, std::enable_if_t<std::is_floating_point_v<T>, int>* = nullptr> void func(T fp) { ... } C++20: void func(std::floating_point auto fp) { ... }
      • Frizi 4y ago
        There is an equivalent syntax in Rust to both of those examples, and in both cases I find it less verbose. The template variant is roughly equivalent to: fn func<T: FloatingPoint>(fp: T) { ... } And the "auto" variant is similar to impl argument in Rust: fn func(fp: impl FloatingPoint) { ... }
        • jcelerier 4y ago
          I really don't see in which way the second case is less verbose especially if you add a non-void return type, e.g. i32. The first case would also be doable like this, which is pretty munch the exact same than your first example with the added "template" keyword template<std::floating_point T> void func(T t) { ... } (also, it's not really equivalent - if I'm not mistaken with traits you can only use what the trait declares ; in C++ you can for instance do something like template<typename T> concept CanBlah = requires (T t) { t.blah(); }; and still be able to do void func(CanBlah auto t) { log << "func:" << t; t.blah(); } instead of polluting the prototype with all possible side concerns)
• dingoegret12 4y ago
  I love Rust and use it everyday but the syntax bloat is something I will never get over. I don't believe there's nothing that could be done about it. There are all sorts of creative grammar paths one could take in designing a language. An infinite amount, in fact. I would really like to see transpiler that could introduce term rewriting techniques that can make some of that syntax go away.
  • zozbot234 4y ago
    "Creative" grammar introduces parsing difficulties, which makes IDE tooling harder to build and less effective overall. My overall guess is that Rust made the right choices here, though one can endlessly bikeshed about specifics.
    • KptMarchewa 4y ago
      Tooling should not depend on code text, but on language's AST.
      • tripa 4y ago
        Comments tending to skip on being a part of the AST make that harder.
      • bobbylarrybobby 4y ago
        In practice though, getting the AST from the text is a computational task in and of itself and the grammar affects the runtime of that. For instance, Rust's "turbofish" syntax, `f::<T>(args)`, is used to specify the generic type for f when calling it; this is instead of the perhaps more obvious `f<T>(args)`, which is what the definition looks like. Why the extra colons? Because parsing `f<T>(args)` in an expression position would require unbounded lookahead to determine the meaning of the left angle bracket -- is it the beginning of generics or less-than? Therefore, even though Rust could be modified to accept`f<T>(args)` as a valid syntax when calling the function, the language team decided to require the colons in order to improve worst case parser performance.
• singularity2001 4y ago
  I think making things syntactically explicit which are core concepts is stupid: ```pub fn horror()->Result{Ok(Result(mut &self))}``` A function returns a Result. This concept in Rust is so ubiquitous that it should be a first class citizen. It should, under all circumstances, be syntactically implicit: ```pub fn better->self``` No matter what it takes to make the compiler smarter.
  • dragonwriter 4y ago
    > A function returns a Result. That is not, in fact, a core concept in Rust. Plenty of functions have no reason to return Result. (And some that do also have a reason for the inner class to be a result.) > This concept in Rust is so ubiquitous that it should be a first class citizen. It should, under all circumstances, be syntactically implicit: “Implicit” is an opposed concept to “first-class citizen”. Result is first-class in Rust, and would not be if function returns were implicitly Result.
    • singularity2001 4y ago
      > Result is not a core concept in Rust. If you don't see std::result::Result as a core concept in Rust, which might be fair, one can still argue that it _should_ be a core concept, given its ubiquitous usage.
      • dragonwriter 4y ago
        You misquoted, I never said Result is not a core concept. What I said is that “A function returns Result” in the universal sense (that is, everything that is a function returns Result) is not a core concept in Rust. Some functions return Result<T,E> for some <T,E>. Some functions return Option<T> for some T. Some functions have no reason to use that kind of generic wrapper type (a pure function that handles any value in its range and returns a valid value in a simple type for each doesn't need either; Option/Result are typically needed with otherwise non-total functions or functions that perform side effects that can fail.)
    • jherico 4y ago
• singularity2001 4y ago
  >>> I'm not convinced much could have been done about it. Are you sure? What stops Swift with its beautiful syntax and safe optionals from becoming a systems language?
  • tayistay 4y ago
    Perhaps not that that much. Swift’s arrays are refcounted. And you can’t store an array on the stack. Classes are refcounted too, but you could avoid them. It also has a bit of a runtime, and you don’t know when it will take locks or allocate (though there is work to tag functions so they can’t do either).
  • Sirened 4y ago
    As someone who has actually tried writing a kernel in Swift, the issue is purely the runtime. While you can technically build a module without it needing to link to external Swift standard library binaries, the second you try and do anything with an array or optionals, you suddenly need to link in a 15MB behemoth that requires SIMD to even compile (at least on x64 and arm64). Porting this to bare metal is possible (and some have done it for a few microcontrollers) but its a pain in the ass. I do love Swift and would use it for systems stuff in a heartbeat if I could, but there are also some downsides that make it pretty awkward for systems. The performance isn't always the best but it's (generally) very clear and ergonomic.
  • pjmlp 4y ago
    Nothing, that is even Apple's official wording for Swift.
• amelius 4y ago
  > Systems languages need to have lots of detail you just don't need in higher level languages like Haskell or Python True, but Rust is being used for a lot more than just system programming, judging from all the "{ARBITRARY_PROGRAM} written in Rust" posts here on HN.
• pjmlp 4y ago
  System languages on the Algol/Wirth branch prove otherwise. They can be ergonomic high level, while providing the language features to go low level when needed.
  • titzer 4y ago
    Agree, and even C got really far without traits. Traits are a lot of rope for building confusing abstractions, IMHO.
• codegeek 4y ago
  I wanted to learn Go while working professionally with PHP and Python. I loved the simplicity and syntax of Go overall. I learned Go enough to build a small internal tool for our team and it is Production ready (at least internally). Then I wanted to learn Rust since it is so popular and always compared with Go and the syntax made me lose interest. Rust may be amazing and I will be more open minded to try later but it didn't spark the interest. Superficial I know since the real power is in functionality etc but just an anecdote from an amateur.
  • worik 4y ago
    Yes. Go is better unless you need the features of Rust.
  • skrtskrt 4y ago
    Another point is just about the maturity of language and libraries. I started learning Rust recently and when searching how to do some pretty basic stuff, the answers are like "well you used to do this but now you do this and soon you'll be able to do this but it's not stabilized" I figure I'll just check back in 5 years, I don't have the time or patience to be on the bleeding edge when I'm trying to get things done.
    • pstuart 4y ago
      Between this and the syntax/learning curve I've not gotten around to learning it (and maybe some Squirrel! as well). One of these days. In the meantime I'm rather happy with Go because it's easy for a code monkey like myself to do the needful.
    • codegeek 4y ago
      Good point. In software especially web world, I am usually wary of tech that is not at least 10 years mature/old.
      • sangnoir 4y ago
        > In software especially web world... The frontend frameworks used to have really short lifecycles "Oh,you're still using FooJS? That's so last year. Everyone's on Bar.js now- it's so much better"
• Animats 4y ago
  The main Rust syntax is OK, but as the author points out, macros are a mess. The "cfg" directive is closer to the syntax used in ".toml" files than to Rust itself, because some of the same configuration info appears in both places. The author is doing something with non-portable cross platform code, and apparently needs more configuration dependencies than most.