5 ms·

I say this with great respect, but the thing keeping me from Rust isn't the compiler, it's the language.

• echelon 4y ago
  What about the language do you dislike? It's a strongly typed Ruby with generics. Edit: trait-based OO is a breath of fresh air compared to tree-style class inheritance. Super flexible without having to overthink. Immutable by default is reassuring, Option/Result are fantastic null/exception replacements. Enums and match blocks are powerful and gracefully help ensure handling of all cases, have nice syntax, and work well for a systems language.
  • TylerE 4y ago
    The borrow checker. The syntax. It isn't a good fit for my needs. It'd be like using a forklift to move a few books. I'm not generally a fan of strong explicit typing/high ceremony in general.
    • MuffinFlavored 4y ago
      Curious, are you a fan of Typescript?
      • TylerE 4y ago
        Never used it. I don't even have the need to touch vanilla javascript that often.
        • MuffinFlavored 4y ago
          What do you primarily program in, Java? C#? Python?
          • TylerE 4y ago
            Python
            • satvikpendem 4y ago
              Then that makes a lot of sense why you might not like types. I'd say give Type Driven Development a try, where you layout the data flows for a program through its types, then you fill in the actual code which becomes very easy. I wrote about this in another comment before (in Rust, but you can even do it in Python with its type hinting): https://news.ycombinator.com/item?id=34454158#34492209 https://news.ycombinator.com/item?id=34454158#34492209
    • smt88 4y ago
      > strong explicit typing/high ceremony If you think strong typing is "ceremony" then you probably spend most of your time writing (and documenting) code and not reading, refactoring, or collaborating on it. The time people spend writing unnecessary, buggy unit tests (that static analysis can do in better languages) is far greater than the time to just use the type system. Most languages don't even force you to be explicit anymore. They infer the types, so you don't even write extra code. You just get better errors and speed.
      • josephg 4y ago
        For what it’s worth, I agree with the GP comment when it comes to network services and for quickly prototyping things out. I’ve been writing in rust almost exclusively for the last few years, but I still reach for typescript from time to time. JS/TS just requires fewer decisions per line of code. As a pithy example, in javascript I don’t have to decide whether I want a String / &str / SmartString / Rc<String>, etc. It’s just string. When I pass a callback I don’t have to decide between accepting a closure or FnOnce/Fn/FnMut. Or decide whether to accept a function pointer or take a generic parameter. In javascript I never have to think about the lifetime of the callee’s stack. I tried to implement my own server-sent events style protocol in rust a couple years ago. I spent 2 weeks trying a bunch of different approaches but I eventually gave up - I just couldn’t get it working. (Mind you, async was pretty new then - I don’t think it was ready). I moved to javascript and had the whole thing working correctly in about a day and ~50 lines of simple code. I think the resulting program is much better when I write it in rust than what I get when I build on top of nodejs. Rust programs can be orders of magnitude faster and I have a shockingly low defect rate in shipped rust code. But there’s a trade off. Rust programs take more effort to write. Rust is a brilliant systems programming language. I’d pick it over C or C++ any day of the week. But not all problems are systems programming problems.
        • zozbot234 4y ago
          Rust programs take more effort to write initially, but less effort throughout the software lifecycle. Unless you're writing code just to throw it away and not even run it once (which practically doesn't ever happen, at least not intentionally) Rust front-loading the effort is the right trade off. Never mind that some of these choices you can just avoid by thinking in general terms and deferring optimization for later. Just passing String and FnMut everywhere will be a lot more efficient than whatever the JS translates to on the machine.
    • echelon 4y ago
      You don't see the borrow checker. It manifests itself in encouraging RAII inspired writing and logical flow. Lifetime annotations help how you use and exchange certain data, but you can get away without them unless you need them. For shared data structures (when synchronization primitives are too much) and highly performant code. You can write high level Java, Ruby, and Python code in Rust if you want to. Writing Actix or Axum web handlers feels no different than Golang or Python/Flask.
    • posix86 4y ago
      Rust's type checker is very clever tough. You can omit types almost anywhere, and rust will infer it. Say you net a vector containing Foo object. You can just do let mut v = Vec::new(); v.push(m_foo); In fact it's so nice that you often rewrite code to keep clear what's actually happening, even though you could keep types largely implicit. Here's another example: let f: Vec<i32> = vec![1, 2]; let f2: HashSet<f32> = f.iter().map(|n|n.into()).collect();
  • sedatk 4y ago
    It's probably not the language syntax per se, but satisfying the compiler (borrow checker) can be tedious for beginners.
  • packetlost 4y ago
    Huh? Rust shares very little with Ruby??? Are you thinking Crystal?
    • woodruffw 4y ago
      Crystal is directly inspired by Ruby, so I don't think is too far of a bridge! I programmed Ruby for years before learning Rust, and aspects of Rust's library and language inspiration from Ruby are obvious to me: the closure syntax closely resembles Ruby's blocks, for example, and much of the core iterator APIs match their Ruby counterparts. It's a very different language overall, of course! (Then of course there's the part where many early Rust contributors came from the Ruby community.)
  • nonethewiser 4y ago
    Not OP but for me it's the syntax. I'm not even saying it's bad or could even be improved... I just don't find it intuitive. I've only sat down and walked through some of the learn rust book and tried to hack out a few small things. I'm not sure what it is - there just always seem to be random symbols that dont seem to follow conventions of other languages. Guess I am use to C-style (including C++, C#, JS) syntax and python. Its possible that there are just new concepts that aren't really represented in the languages I use too. Again, I don't necessarily think its bad. Just what I don't find intuitive.
    • mlindner 4y ago
      New syntax is pretty easy to pick up. It's just window dressing. What you're actually seeing is a trap a lot of programmers fall into where if something is unfamiliar then it's treated as if it's incorrect.
      • nonethewiser 4y ago
        > What you're actually seeing is a trap a lot of programmers fall into where if something is unfamiliar then it's treated as if it's incorrect. I said that I don't think it's bad or wrong.
    • nicoburns 4y ago
      Interestingly very little of Rust's syntax is novel (the exception being lifetimes which of course don't exist in other languages). The closest language syntacticly is probably TypeScript (you'd be surprised how many programs are actually valid in both Rust and Typescript!). And where syntax doesn't match TypeScript it usually matches something else common. For example the `self` parameter in methods comes from Pythong, and the closure syntax comes from Ruby
      • tcmart14 4y ago
        For me, its the lifetime syntax I don't like the most. It doesn't feel "ergonomic" to type something like <`a>. Its mostly the ` I wish were different.
  • afr0ck 4y ago
    In real world software, you need lots of freedom in order to design high performance scalable systems. This includes using non-trivial data structures, and being able to access and organise memory in subtle ways. The Linux kernel is an example of this. Look at the reclaim subsystem in the kernel, for instance, and how it interacts in subtle and very complex ways with various other subsystems, the page cache, the generic block layer, the memory control groups, the VFS and the filesystems. All of them are multi-threaded and run on complex high performance CPUs performing memory re-ordering, speculative execution, branch perdiction and parallel execution of both processes and instructions. You really need extremely smart smart data structures and organisation and very smart algorithms to manage the concurrency. C is a language where you have all that freedom to do whatever you want leading to high performance and low latency. In Rust, you can't even safely implement a doubly linked list. Now, if you have to use unsafe every time you need high performance or scalable data structures, then Rust is as unsafe as C and it's just making your life harder for no reason, except hype.
    • deleted 4y ago
      [deleted]
    • lalaithion 4y ago
      The key is that Rust lets you define safe interfaces, so you can separate your data races and union juggling, which need to be unsafe, from your business logic, which basically never needs to be unsafe.
      • nyanpasu64 4y ago
        "Object graph" architectures are common in C++ and sometimes necessary in Rust for business logic, when building GUI applications or emulators. But Rust doesn't allow mutating through a &/Rc, and throws a compile error if you create multiple &mut, and the workarounds are unreasonably boilerplate-heavy and RefCell carries runtime overhead, whereas C++ doesn't get in the way of making your code work. I've put together a playground at https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=3b5066c3f091b34b981d7d0ca8748c4d https://play.rust-lang.org/?version=stable&mode=debug&editio.... It's not just dereferencing invalid */& that's illegal in Rust, but constructing and dereferencing valid &/&mut in ways that don't respect tree-shaped mutability. Rust's pointer aliasing rules invalidate otherwise-correct code, placing roadblocks in the way of writing correct code. There's so much creation of &mut (which invalidates aliasing pointers for the duration of the &mut, and invalidates sibling &mut and all pointers constructed from them), that's so implicit I don't know what's legal and what's not by auditing code. (Box<T> used to also invalidate aliasing pointers, but this may be changed. The current plan for enabling self-reference is Pin<&mut T>, but the exact semantics for how and when putting a &mut T in a wrapper struct makes it not invalidate self-reference and incoming pointers, is still not specified.) (I've elaborated further at https://news.ycombinator.com/item?id=33658253 https://news.ycombinator.com/item?id=33658253.)
• vore 4y ago
  I felt this way about Rust for a really long time, but after sitting down and doing a few projects with Rust I've really come to appreciate how much the language stops me from being a dumbass.
• WinstonSmith84 4y ago
  Once you're done fighting with the compiler (Rust Analyzer), it's actually very enjoyable and one can be _relatively_ productive. The language allows so much flexibility that it's very easy to produce well organized code... But the compiler is really slow. Even an incremental build on a mid size project is never below 10s, whereas on a similar size project, Golang will take me less than 1 second to build incrementally. Also, I find cross-compilation (from/to major platforms) really challenging on Rust, as opposed to Golang where it's for my use cases super straightforward
  • stefncb 4y ago
    My personal issue with Rust isn't the borrow checker. I actually find it quite intuitive. What I don't like is the extreme complexity of everything. There's just so much... stuff. What I want is a Rust, but with almost everything stripped away. Complexity similar to Go.
    • TylerE 4y ago
      nim comes the closest of anything I've found, the infrastructure just isn't quite there. ocaml has potential but I strongly dislike the numeric operators, and I'm not a huge fan of the syntax in general. OCaml with python like syntax would be damn near perfect. I could even overlook the operator thing.
    • acedTrex 4y ago
      so you want Go then?
    • oconnor663 4y ago
      It's worth pointing out that if you say "Go except with Rust's guarantees for thread safety", a _lot_ of the complexity comes back. You need to pull in lifetimes and move semantics and the no-mutable-aliasing rule. You need the Send and Sync traits. You probably want Deref-based smart pointers too. (And you'd need to make extensive use of the new generics features that are already in Go.)
      • 4y ago
• LAC-Tech 4y ago
  It's the standard library & tooling for me. To be perfectly honest for must stuff I use rust for I'd prefer to have garbage collection. But the standard library and tooling I just too far ahead of the competition (diplomatically avoiding naming languages here)
• loeg 4y ago
  That's fine. It doesn't have to be everything to everyone. We probably don't need this kind of comment on every single article about Rust, though. (Or similar generic "I don't like this language" comments on any article related to any programming language.)
  • TylerE 4y ago
    Then we equally don’t need pro rust comments on literally every other thread Since a major thrust of the linked article is barriers to rust adoption it seemed relevant.
    • loeg 4y ago
      > Then we equally don’t need pro rust comments on literally every other thread Correct.
      • josephg 4y ago
        Eh. Every article about Go has the same thing - where regardless of the content of the article people discuss the pros and cons of the language itself. I think it’s a symptom of there not being enough places where adherents of different programming ecosystems can argue back and forth about our choices. I think there’s an unmet need in our community to have those conversations, and there’s probably something healthy in that. It definitely distracts from the specifics of the article though. The corresponding discussion on reddit is much more technical: https://reddit.com/r/rust/comments/10ld2vn/blog_post_next_rust_compiler/ https://reddit.com/r/rust/comments/10ld2vn/blog_post_next_ru...
    • jackmott 4y ago
      [dead]
• alphanullmeric 4y ago
  It would actually be such an amazing language if it wasn’t so verbose. There are so many places where more concise syntax wouldn’t even hurt safety and they forgo it anyways. But here we are, where macros are required for a hello world.
  • JoshTriplett 4y ago
    > There are so many places where more concise syntax wouldn’t even hurt safety and they forgo it anyways. Can you give some examples of this? If there are ways we could simplify the language without hurting existing use cases, we should consider doing so.
    • alphanullmeric 4y ago
      No default arguments, named parameters, variadic functions and generics, no C-style arrow operator, the whole default trait thing (why can’t you shorten it to just `..`?). And a bunch of awful reasoning to defend these decisions. Named function arguments are bad but `Iterator<Item=T>` is fine? Default arguments are bad but default trait implementations are fine? Something something implicit behaviour but type inference is ok? It’s to the point where idiomatic rust means writing a three different structs and enums to call a function.
  • spoiler 4y ago
    You don't technically need the macro to print hello world. However, the macro is useful due to format strings, which are also type-checked (eg to checks if the args implement `Display` or `Debug`, etc). The good thing about the default hello world example is that it introduces you to both language features without being overwhelming (IMO). You can read more about format strings here: https://doc.rust-lang.org/std/fmt/ https://doc.rust-lang.org/std/fmt/
    • tialaramex 4y ago
      Right, the canonical C "Hello, World!" uses C's formatted print, even though obviously it's not formatting anything, so it seems appropriate for Rust to do the same. It would be more impressive if Rust had an actual type checked variadic print format function like C++ 23's std::println - nobody should be under any false impression about how impressive that feature is, but the type safe macro is effective, that'll do pig.
• pizza234 4y ago
  If one wants control over everything and manual memory management as safe as achievable (ie. systems programming), currently, this is the only (major) way. IMO the market share for this profile is indeed small. Languages that trade off a part of that security for simplicity may have considerably more market share in the future, although on the other hand, the public may instead prefer a "fast-enough and dead-simple" language.