[HN Gopher] My negative views on Rust (2023)
___________________________________________________________________
My negative views on Rust (2023)
Author : rc00
Score : 110 points
Date : 2024-10-09 19:34 UTC (3 hours ago)
(HTM) web link (chrisdone.com)
(TXT) w3m dump (chrisdone.com)
| henning wrote:
| > People waste time on trivialities that will never make a
| difference.
|
| Depending on the situation, memory layout could be trivial
| (copying 200 bytes once at startup vs. not in a way that should
| never be user-perceptible and difficult to even measure) or
| actually a big deal (chasing down pointers upon pointers in a
| tight inner loop). It's entirely situational. To dismiss all of
| that as "trivial" and saying it will "never" make a difference is
| not helpful. There are a lot of shitty apps that are impossible
| to get running reasonably without a total rewrite and their
| shitty use of memory is part of that.
| andrepd wrote:
| Thinking like that is how we get 12MB of javascript to read a
| news article, or mobile apps that are jankier than Word 97.
|
| I don't get how someone can criticise a systems programming
| language by saying "I have to think about memory layout"....
| bachmeier wrote:
| There's a response to your comment in the post:
|
| > I feel like Rust is self-defined as a "systems" language,
| but it's being used to write web apps and command-line tools
| and all sorts of things.
|
| > This is a little disappointing, but also predictable: the
| more successful your language, the more people will use your
| language for things it wasn't intended for.
|
| > This post still offends many who have tied Rust to their
| identity, but that's their problem, not mine.
| hyperbrainer wrote:
| Criticising a systems programming language for needing to
| manually manage memory is honestly embarrassing.
| IgorPartola wrote:
| I mean to be fair so is using a systems programming language
| for every use case under the sun. If Rust is a great systems
| programming language that's one thing. If it's a general
| purpose language that's another.
| hyperbrainer wrote:
| The two are not mutually exclusive. Also, I don't think I
| have ever needed to actively think about memory management
| more than .clone() and static for any hobby project I have
| undertaken. All the ML-like features like sum types,
| pattern matching etc. add great value. Cargo too. So, it is
| a great general purpose programming language. But blaming
| it as too low-level or similar despite choosing it is
| obtuse at best.
| keybored wrote:
| A lot of git(1) subcommands were originally written in
| shell or Perl. Now most are written in C.
|
| Through many decades people wrote utilities and
| applications in C. Not hardcore lower-level kernel modules.
| Just utilities and applications. Because that's what they
| wanted to write them in. Over Perl or Java or whatever else
| the alternatives were.
|
| What's more C than that? Writing everything short of
| scripts in it?
|
| Now people write applications in a modern programming
| language with modern affordances. They might be working
| uphill to a degree but they could have chosen much less
| ergonomic options.
|
| The embarrassing part is criticizing people who have put in
| the work, not on the merits of their work, but on... having
| put in too much work.
| tptacek wrote:
| The subtext is that most of the time it won't make a
| difference, and Rust demands that you consider it every of the
| time. That squares with my experience. The powerful argument
| Rust has is that in the hotspots where memory lifecycle and
| layout make a huge difference to programs, it's much easier to
| express the fast and predictable memory arrangement than in
| GC'd languages.
| DiabloD3 wrote:
| I've read this before, it's been passed around the Rust community
| a few times.
|
| The annotated tl;dr is: Chris doesn't want to learn how hardware
| works, they don't want to learn how to write optimal software,
| they don't want to write safe software, they just want to write
| in a language they already know because they're not comfortable
| with learning other languages because their home language is a
| functional language (Haskell). It's a weird, yet short, essay
| that doesn't actually go anywhere.
|
| I suspect Chris wrote the essay against their will, or because
| people asking them about Rust rubbed them the wrong way, because
| they lash out and say "This post still offends many who have tied
| Rust to their identity, but that's their problem, not mine."
|
| Its the Internet, man, if you're not offending someone, nobody is
| reading your shit.
| tedk-42 wrote:
| Surely someone who writes a lot of C code as he mentions has
| written it for hardware, no?
| DiabloD3 wrote:
| Take a gander at the rest of that blog, they're a Haskell
| main.
| Minor49er wrote:
| Chris is a team of people? I thought he was just one developer
| mappu wrote:
| If you re-read the sentence with s/Chris/The Author/ I expect
| you'll find the pronoun cromulent. "They" was exclusively
| plural in Middle English in the 1300s, but, we're not
| speaking Middle English.
| Narishma wrote:
| What makes you think they're a team?
| awesome_dude wrote:
| So, we should be focused on attacking the author, not the
| points raised in the article?
| hyperbrainer wrote:
| Needs (2023)
|
| > I predict that tracing garbage collectors will become popular
| in Rust eventually.
|
| The use of Rc is already very widespread in projects when people
| don't want to deal with the borrow checker and only want to use
| the ML-like features of Rust (Sum types, Option, Error etc.)
|
| > Rust has arrived at the complexity of Haskell and C++, each
| year requiring more knowledge to keep up with the latest and
| greatest.
|
| I wonder when we will see the rise of Haskell like
| LanguageExtensions in Rust. AFAIK, pretty much everybody uses
| things like GADT, PolyKinds, OverloadedStrings etc. The most
| similar thing I can think of Rust right now for is python-like
| decorator application of things like builder macros using Bon.
|
| > Async is highly problematic
|
| Agreed. Tokyo is the only reason, I think, anybody is able to use
| Rust for this stuff.
| tptacek wrote:
| Does Rc really resolve the core problem this post is talking
| about, which is that it's really painful to naturally express
| tree and graph structures in Rust? It feels like I mostly see
| people talking about building application-layer pointer systems
| with integers, which would be surprising if (in a single
| thread, perhaps) you could just Rc your way around the problem.
| cmrdporcupine wrote:
| Sure, Rc/Arc absolutely solves this problem. It's not super
| idiomatic to go crazy with using it like that, but it's
| possible/acceptable.
|
| Using SlotMap and integer ids, etc. doesn't I think offer any
| advantage.
| tptacek wrote:
| I feel pretty comfortable with Rc and Arc, read the "too
| many lists" book, &c. and feel like it is not actually
| simple to model trees with Rc? What am I missing? I'd love
| to be convinced I'm wrong about this (I want to like Rust
| more than I do).
| cmrdporcupine wrote:
| A tree of Rc/Arc<T> is a tree of references, and is
| really no different than a Java or Python reference
| value, except that you'll have to do explicit .clone()s
|
| Is it mutability that's tripping you up? Because that's
| the only gotcha I can think of. Yes, you won't get
| mutability of the content of those references unless you
| stick a RefCell or a Mutex inside them.
| nine_k wrote:
| Doesn't SlotMap save RAM and pointer dereferences?
| cmrdporcupine wrote:
| What is a slotmap lookup... if not a pointer dereference,
| or at least a dereference out of a vector likely on
| heap... so probably a pointer...?
| umanwizard wrote:
| > Does Rc really resolve the core problem this post is
| talking about, which is that it's really painful to naturally
| express tree and graph structures in Rust
|
| No, it doesn't. If you naively express graphs containing
| cycles with `Rc` you will leak memory, just like you would
| with `std::shared_ptr` in C++.
| hyperbrainer wrote:
| Considering that there exists a book about building linked
| lists in Rust[0], I am going to go ahead and say "Unclear"
| That does not matter though. It is easier (though verbose and
| often unidiomatic), and hence Rc has become really popular,
| especially with beginners.
|
| [0] https://rust-unofficial.github.io/too-many-lists/
| ordu wrote:
| _> Does Rc really resolve the core problem this post is
| talking about, which is that it 's really painful to
| naturally express tree and graph structures in Rust?_
|
| No, but Gc will not resolve the core problem either. The core
| problem is that rust forbids two mutable pointers into one
| chunk of memory. If your tree needs backlinks from child
| nodes to parents, then you are out of luck.
| pcwalton wrote:
| Rc does solve the problem, but it often introduces interior
| mutability, which ends up causing usability problems. That's
| why at the end of the day adjacency representations (i.e.
| integers) are often preferred.
| nicce wrote:
| > Agreed. Tokyo is the only reason, I think, anybody is able to
| use Rust for this stuff.
|
| A lot of problems related to Tokyo can be avoided if you think
| your code as structured concurrency and avoid using
| Tokio::spawn. However, too often this is not possible.
| hyperbrainer wrote:
| I don't have too much experience with async, but I have
| noticed a similar pattern. Maybe you are right.
| written-beyond wrote:
| I haven't, yet, run into building rust apps that require
| highly complex async implementations with lifetimes etc.
| however excluding those situations I've found it very
| straightforward and easy to use. I've built some applications
| with a lot of moving parts, mpsc has always been a life
| saver.
| bsder wrote:
| > The use of Rc is already very widespread in projects when
| people don't want to deal with the borrow checker and only want
| to use the ML-like features of Rust (Sum types, Option, Error
| etc.)
|
| And the fact that this hasn't caused alarm is kind of an issue.
|
| The problem with that is Reference Counting is _WAY_ slower
| than good Garbage Collectors on modern CPUs. Reference Counting
| breaks locality, hammers caches and is every bit as non-
| deterministic as a garbage collector.
| IshKebab wrote:
| So much to disagree with....
|
| > In practice, people just want to be able to write a tree-like
| type without having to play Chess against the compiler.
|
| Sure, Rust's strong encouragement of tree-structured ownership
| may be annoying when you try and make a spaghetti ownership soup,
| but it's not like it doesn't have upsides. Many people have
| written about how the ownership & borrowing rules lead to code
| structure that has fewer bugs.
|
| > I think that if you rewrite anything from scratch with
| performance in mind, you'll see a significant performance
| improvement.
|
| Maybe, but I think this is missing the point. The "rewrote it in
| Rust and it's X times faster" stories are generally when people
| rewrite from very slow (Python) or medium fast languages
| (JavaScript or maybe even Go).
|
| In those cases you can rewrite in Rust _without_ considering
| performance and get amazing speedups. I recently did a straight
| 1:1 port of some Python code with zero extra optimisation effort
| and got a 45x speedup.
|
| Sure I maybe could have got the same in C or C++ but there's no
| way I would have rewritten it in C++ because fuck segfaults and
| UB. I don't want to spend any more of my life debugging that.
|
| > Rust has arrived at the complexity of Haskell and C++, each
| year requiring more knowledge to keep up with the latest and
| greatest.
|
| I don't really know about Haskell, but I don't think Rust's
| complexity is anywhere close to as bad as C++'s. Even if it were
| it doesn't matter because in Rust if you forget some complex rule
| the compiler will tell you, whereas in C++ it will randomly crash
| but only in release mode after the program has been running for 2
| hours. Totally different.
|
| > The "Friendly" Community
|
| Gotta agree with this though. The "we're friendly" thing is
| bullshit.
|
| > Async is highly problematic
|
| Also agree here. Async is a huge wart on Rust's otherwise
| relatively unblemished face. Big shame. Oh well. You can _mostly_
| avoid it, and there are some cases where it 's genuinely good
| (e.g. Embassy).
|
| > I feel like Rust is self-defined as a "systems" language, but
| it's being used to write web apps and command-line tools and all
| sorts of things. > > This is a little disappointing, but also
| predictable: the more successful your language, the more people
| will use your language for things it wasn't intended for.
|
| I don't see why he's disappointed about this. Rust is great for
| command line tools and web backends.
|
| > I think that the excellent tooling and dev team for Rust,
| subsidized by Big Tech, pulls the wool over people's eyes and
| convinces them that this is a good language that is simple and
| worth investing in. There's danger in that type of thinking.
|
| Ok this guy is not worth listening to.
| VeejayRampay wrote:
| I'm curious what kind of code gets a 45x speedup by going from
| python to rust
|
| and by that I don't mean the rhetorical or bait-style "i'm
| curious", no, the literal I'm curious, cause I'm trying to find
| use cases such as that these days and I'm often thwarted by the
| fact that for anything requiring remotely decent speeds, python
| most of the time already delegates to C extensions and so any
| rewrite is not as useful
| cyberax wrote:
| > I'm curious what kind of code gets a 45x speedup by going
| from python to rust
|
| Pretty much any code that is not just tying together external
| libraries?
| Aeolos wrote:
| Anecdotal experience: we rewrote an image processing
| algorithm from numpy+scipy to pure rust and got a 50x speedup
| in release builds, without even spending any effort
| optimizing the rust side.
|
| There are further improvements possible around memory
| allocation and cachelines, but 2 days for 50x improvement was
| sufficient to not make it worth investing additional effort.
|
| Edit: this was from a team who had _never_ touched Rust
| before.
| IshKebab wrote:
| It is basically reading a massive JSON file containing a few
| thousand logs and then scanning them with a load of regexes.
|
| I was a bit surprised how much faster it was too. Apart from
| Python being dog slow the only thing I really changed was to
| use RegexSet which isn't available in Python. I didn't
| benchmark how much difference that made though; I just used
| it because it was obviously the right thing to do.
|
| That's kind of the point. If you just do the obvious thing in
| Rust you get very good performance by default.
|
| It's the same in C++ but then you're writing C++.
| tuveson wrote:
| If you heavily rely on the Python standard library, then
| you're using a lot of Python code that doesn't call out to C
| extensions. Peruse the standard library code, if you want to
| get a sense of it:
| https://github.com/python/cpython/tree/main/Lib
|
| So you can expect any code that heavily relies on the
| standard library to be slower than the Rust equivalent.
|
| A purely interpreted language implementation (not JIT'd) like
| CPython is almost always going to have a 10x-100x slowdown
| compared to equivalent code in C/C++/Rust/Go or most other
| compiled/JIT'd languages. So unless your program spends the
| vast majority of time in C extensions, it will be much
| slower.
| danudey wrote:
| This is an old example, but - date/time parsing.
|
| A coworker of mine years ago was trying to parse out some
| large logfiles and it was running incredibly slowly (because
| the log file was huge).
|
| Just for fun he profiled the code and found that 90% of the
| time was spent taking the timestamp ("2019-04-22 15:24:41")
| into a Python datetime. It was a slow morning, so we went
| back and forth trying to come up with new methods of
| optimizing this parsing, including (among other things)
| creating a dict to map date strings to datetime objects
| (since there were a lot of repeats).
|
| After some even more profiling, I found that most of the
| slowdown happened because most of Python's strptime()
| implementation is written in Python so that it can handle
| timezones correctly; this prevented them from just calling
| out to the C library's strptime() implementation.
|
| Since our timestamps didn't have a timezone specified anyway,
| I wrote my first ever C module[0] for Python, which simply
| takes two strings (the format and the timestamp) and runs
| them through strptime and returns a python datetime of the
| result.
|
| I lost the actual benchmark data before I had a chance to
| record it somewhere to reproduce, and the Python 3 version in
| my repo doesn't have as much of a speedup compared to the
| default Python code, but the initial code that I wrote
| provided a 47x performance boost to the parsing compared to
| the built-in Python strptime().
|
| Anyone who had a similar Python script and converted it
| wholesale to Rust (or C or Golang, probably) would have seen
| a similarly massive increase in performance.
|
| [0] https://github.com/danudey/pystrptime/
| jcgrillo wrote:
| One could argue that writing a timestamp as a string which
| then has to be parsed is silly and instead it should be
| delta-of-delta encoded and packed into variable width
| integers, but even then double integrating and constructing
| a datetime for each one would still be expensive in python,
| only less so.
| jerf wrote:
| "I'm often thwarted by the fact that for anything requiring
| remotely decent speeds, python most of the time already
| delegates to C extensions and so any rewrite is not as
| useful"
|
| Be sure you verify this is the case for whatever you think it
| is, though. Pure Python is so much slower than compiled
| languages (not just Rust) that you don't have to do much
| percentage-wise in pure Python before you've badly fallen
| behind in performance versus the pure-compiled alternatives.
|
| I think this is asserted a lot more often then it is
| benchmarked. I am reminded of the way people for a long time
| asserted that the performance of web languages doesn't matter
| because you spend all your time waiting for the database, so
| it never mattered. People would just whip this argument out
| reflexively. It turns out that if you take a non-trivial
| codebase written in such a language and actually benchmark
| it, it is often not true, because as applications grow they
| tend to rapidly outgrow "all my code is just running a SELECT
| and slamming the results with minimal processing out to the
| web stream". I hear this a lot less often than I used to,
| probably through the slow-but-effective process of a lot of
| individuals learning the hard way this isn't true.
|
| I've seen a lot of Python code. Very little of it that was
| not "data science" was just a bit of scripting around lots of
| large C-based objects, such that Python wasn't doing much
| actual work. And even some of that "data science" was falling
| back to pure Python without realizing because NumPy actually
| makes that shockingly easy.
| Etherlord87 wrote:
| Conway's Game of Life perhaps is a good example: it's a
| simple program, with a tight loop and cheap calculation in
| the loop. Python's loops are slow. I wouldn't be surprised if
| the speedup was much greater than 45x.
| tptacek wrote:
| First off, if you edit the "this guy is not worth listening to"
| out of your comment, you'll probably get better responses from
| people.
|
| Second: I don't think this author disagrees with you that there
| are huge speedups to get from porting code out of Python. But
| you'd also get huge speedups porting to Java, and you wouldn't
| be in the business of managing your own memory lifecycles.
| IshKebab wrote:
| I don't think that was too harsh given that he's saying that
| everyone who likes Rust (an _extremely_ popular language) is
| an idiot who has been tricked into thinking it 's good.
|
| How can you take opinions like that seriously? It's like
| saying "nah The Beatles weren't actually that good, everyone
| just thought they were because of their cool sunglasses".
|
| It's patronising and illogical and I don't think it's worth
| listening to nonsense like that.
| tptacek wrote:
| He didn't say that at all.
| VeejayRampay wrote:
| rust is fine, it's a solid mix of performance and expressiveness,
| it has good constructs and it's gaining traction
|
| it's hard to learn so we shall see what kind of niche it can
| carve for itself, but it's fine
| brink wrote:
| > it's hard to learn
|
| And as long as Rust remains popular, this is why we will
| witness endless complaining about it. Most devs are lazy, and
| would rather sweep complexity under the rug and pretend it
| doesn't exist until it becomes a real problem they can't ignore
| anymore. That's fine. But no need to be so vocal about it. At
| this point, people whining about Rust is more of a trope than
| people proselytizing it.
| rastignack wrote:
| > Most devs are lazy, and would rather sweep complexity under
| the rug and pretend it doesn't exist until it becomes a real
| problem they can't ignore anymore
|
| You mean pragmatic. Not all of us are memory absolutists. The
| time ideally invested in memory management really depends on
| the problem space, the deadlines, etc.
| timeon wrote:
| > At this point, people whining about Rust is more of a trope
| than people proselytizing it.
|
| This is common pattern reminds me cross-fit/veganism/i-use-
| arch/etc. Almost like an echo.
| lll-o-lll wrote:
| > People waste time on trivialities that will never make a
| difference.
|
| This is an aha moment as I read it. The complexity of your tools
| must be paid back by the value they give to the business you're
| in.
| Animats wrote:
| My big problem with Rust is too much "unsafe" code. Every time
| I've had to debug a hard problem, it's been in unsafe code in
| someone else's crate. Or in something that was C underneath. I'm
| about 50,000 lines of Rust into a metaverse client, and my own
| code has zero "unsafe". I'm not even calling "mem", or
| transmuting anything. Yet this has both networking and graphics,
| and goes fast. I just do not see why people seem to use "unsafe"
| so much.
|
| Rust does need a better way to do backlinks. You can do it with
| Rc, RefCell, and Weak, but it involves run-time borrow checks
| that should never fail. Those should be checked at compile time.
| Detecting a double borrow is the same problem as detecting a
| double lock of a mutex by one thread, which is being worked on.
| Ygg2 wrote:
| > My big problem with Rust is too much "unsafe" code.
|
| I hear cargo-geiger is useful identifying such crates.
|
| > I just do not see why people seem to use "unsafe" so much.
|
| Because it's:
|
| A) fast (branchless access)
|
| B) fast (calling C libs or assembly)
|
| C) fast (SIMD)
|
| D) people think unsafe Rust is easier
|
| Want to write a JSON parser that will gobble up gigabytes per
| second? Your only way is removing as many branches and use
| assembly as much as possible. Doubly so on stable! I guess the
| same goes for making a "blazingly fast"(tm) graphical stack.
|
| People that think unsafe is easier, shouldn't be writing unsafe
| code. Writing unsafe code correctly is like juggling burning
| chainsaws. Saying that's easier than using chainsaws is moronic
| at best.
|
| EDIT: Consider following, if each of your unsafe {} blocks
| doesn't contain a // SAFETY: //
| Detailed explanation of invariants
|
| One of the chainsaws just cut off your leg.
| pshc wrote:
| _> Rust does need a better way to do backlinks. You can do it
| with Rc, RefCell, and Weak, but it involves run-time borrow
| checks that should never fail. Those should be checked at
| compile time._
|
| It's not clear to me how rustc could detect a dangling backlink
| in a tree structure at compile time. Seems impossible short of
| adding proofs to the type system.
| ritcgab wrote:
| It's ugly but it's inevitable in some sense. The author should
| know what they are doing, and `// SAFETY:` comment is a must.
| fiedzia wrote:
| No. Nobody is going read those (because most people won't
| even know that some unsafe is buried 5 layers of dependencies
| below what they work with). The author should make reasonable
| effort to prove the code is working correctly (and cannot be
| abused) by other means if possible. It might be a domain
| issue, so far all my apps are 100% safe (not counting
| libraries).
| n_plus_1_acc wrote:
| Unsoundness is considered a bug and should be reported and
| fixed.
| hyperbrainer wrote:
| > I just do not see why people seem to use "unsafe" so much.
|
| SIMD seems to be a big one.
| Const-me wrote:
| > I just do not see why people seem to use "unsafe" so much
|
| Because it's impossible to implement any non-trivial data
| structures in safe Rust. Even Vec has unsafe code in the
| implementation to allocate heap memory. When you need efficient
| trees or graphs (I doubt any non-trivial software doesn't need
| at least one of them), unsafe code is the only reasonable
| choice.
|
| C++ does pretty much the same under the hood, but that's OK
| because the entire language is unsafe.
|
| C# has an unsafe subset of the language with more features,
| just like Rust. However, it runs inside a memory-safe garbage
| collected runtime. Even List and Dictionary data structures
| from the standard library are implemented with safe subset of
| the language. Efficient trees and graphs are also trivial to
| implement in safe C#, thanks to the GC.
| bubaumba wrote:
| >> I just do not see why people seem to use "unsafe" so much
|
| >Because it's impossible to implement any non-trivial data
| structures in safe Rust. Even Vec has unsafe code
|
| Hmm.. wasn't memory safety the main selling point for rust?
| If not the only. Now mix of two languages looks even worst
| than one complex. Especially taking into account that it can
| be paired with safe language from long list. Don't know what
| rust fans are thinking, but from outside it doesn't look very
| attractive. Definitely not enough to make a switch. Julia
| looked better at first, but turned out to be just a graveyard
| of abandoned academic projects.
| eddd-ddde wrote:
| You fan wrap unsafe implementations with safe APIs. The
| point is there's an explicit boundary between unsafe an
| safe.
| pcwalton wrote:
| > Now mix of two languages looks even worst than one
| complex.
|
| The point is that the vast majority of code _doesn 't_ have
| to be unsafe. Empirically, Rust code has far fewer memory
| safety problems than non-memory-safe languages.
| epcoa wrote:
| > Hmm.. wasn't memory safety the main selling point for
| rust? If not the only.
|
| No. Like, not at all. Java, Python, C#, Go, Ruby, lisps and
| countless others are "memory safe" in the way that matters.
| That's not Rusts unique value proposition.
| jltsiren wrote:
| Non-trivial data structures are often just a bunch of
| arrays/maps with additional semantics. You may consider
| implementing/using unchecked versions of basic operations for
| a little bit of additional performance. If you implement
| (de)serialization yourself, you may need unsafe code.
| Sometimes the safety of deserialization may be a convenient
| lie, if checking the invariants fully would be too expensive.
| And sometimes you may want to expose internal helper
| functions for various purposes, which may have to be marked
| unsafe if they can break the invariants.
|
| Beyond that, you only need unsafe code for specific kinds of
| data structures. At least in my experience.
| pcwalton wrote:
| > When you need efficient trees or graphs (I doubt any non-
| trivial software doesn't need at least one of them), unsafe
| code is the only reasonable choice.
|
| To name one example, the AnimationGraph in Bevy is
| implemented with petgraph, which is built using adjacency
| lists, and doesn't use any unsafe code in any of the parts
| that we use. It is very high-performance, as animation
| evaluation has to be.
| pcwalton wrote:
| > I'm about 50,000 lines of Rust into a metaverse client, and
| my own code has zero "unsafe". I'm not even calling "mem", or
| transmuting anything. Yet this has both networking and
| graphics, and goes fast. I just do not see why people seem to
| use "unsafe" so much.
|
| I agree. I rarely ever use unsafe, and only as a last resort.
| Unsafe code is really not needed to achieve high performance.
|
| > Rust does need a better way to do backlinks. You can do it
| with Rc, RefCell, and Weak, but it involves run-time borrow
| checks that should never fail.
|
| I think this will basically turn into provably-correct data
| structures. Which is possible to do, and I've long thought
| there should be systems built on top of Rust to allow for
| proving these correct. But we should be clear that something
| like Idris is what we're signing up for. Whatever it is, it is
| assuredly going to be far more complex than the borrow check.
| We should basically only use such systems for the
| implementations of core data structures.
| egnehots wrote:
| Some points resonate with me:
|
| > People don't want "to have to play Chess against the compiler"
|
| Things that are easy to express in other languages become very
| hard in Rust due to the languages constraints on ownership,
| async...
|
| > Rust has arrived at the complexity of Haskell and C++, each
| year requiring more knowledge to keep up with the latest and
| greatest.
|
| It's indeed hard to keep up.
|
| > Async is highly problematic.
|
| Yes, more complexity, more fragmentation and feel like another
| language.
|
| But one point feels unfair:
|
| > the excellent tooling and dev team for Rust [..] pulls the wool
| over people's eyes and convinces them that this is a good
| language that is simple and worth investing in.
|
| What? No. The main appeal was the safety. It's still a
| distinctive feature of Rust. To almost eliminate a whole class of
| safety issues. It has been proven by several lengthy reports such
| as https://security.googleblog.com/2024/09/eliminating-
| memory-s....
|
| They are many projects for which the reliability and efficiency
| are worth the trouble.
| dvektor wrote:
| I agree with a couple points here, specifically I agree that
| choosing a language based on it's community (and not it's
| ecosystem) is just silly. And we all know that async ended up
| being a bit of a thorn in rust's side.
|
| But yeah, rust is very much a systems language: so it will be
| forcing you to think about memory layout one way or the other.
| Idk how valid of a complaint that is when you really consider
| that, and specifically the other alternatives you have.
| tptacek wrote:
| A complication of the "Rust is a systems programming language"
| thing is that people adopt definitions of "systems" of varying
| expansiveness to suit the situation. There are unquestionable
| systems programming domains --- the kernel is a great example,
| and one where it's easy to see why Rust is an exciting
| proposition; same with browsers, the "second OS" everyone runs
| --- and then more questionable domains. Is the framework-layer
| code for a CRUD web application "systems" code? How about a
| container orchestrator?
|
| This isn't a criticism of Rust, but rather of the framing we
| often use to compare Rust and (say) Python or Java.
| DiabloD3 wrote:
| "Systems programming language" has almost turned into a weird
| slur; instead of using it to refer to languages that can
| actually handle that task, they use it to attempt to
| pigeonhole a language into _only_ that.
|
| As in, people don't realize being a "systems programming
| language" is extremely difficult to get right, and many
| languages simply can't handle that (and never will, as per
| internal design requirements unique to those languages); if a
| language gets that right, they're going to get everything
| else right too if people decided to use it for that.
| tptacek wrote:
| See, depending on your definition of "systems programming
| language", that is just wildly false. A language that nails
| all the details and ergonomics of expressing a kernel block
| device driver is almost necessarily going to be suboptimal
| for exploratory scientific computing or line-of-business
| app development.
|
| Again: this is about the term, not about the language. I
| don't think it's controversial to suggest that there is no
| one ur-language that is optimal for every problem domain!
| DiabloD3 wrote:
| I don't think the people that use it as a slur actually
| define it. They use it to mean the language they don't
| like because they think it has some level of enforced
| complexity that takes away from the language instead of
| being an important feature of the language.
| nine_k wrote:
| Rust makes you think about your memory layout, memory
| allocation and avoiding thereof, about the specific time you
| grab and release other resources, about specifics of your
| inter-thread interactions, etc.
|
| If such considerations are natural for your problem domain,
| you likely do "systems programming" and also happen know C,
| have an.opinion on Zig, etc.
|
| If such considerations are the noise which you wish your
| language would abstract away, then you likely do "application
| programming", and you can pick from a wide gamut of
| languages, from Ruby and Python to Typescript to Elixir and
| Pony to C#, Java, and Kotlin to OCaml and Haskell. You can be
| utterly productive with each.
| sophacles wrote:
| What does "think about your memory layout" mean? Can you
| provide an example? I've seen this brought up a few times
| on this thread and have no idea what people are referring
| to when they say it.
|
| As for the rest of your list - I'm not sure why rust is
| special in regards to "the specific time you grab and
| release resources" or "inter-thread interactions".
| Seriously - I have to think about when I acquire and
| release resources like sockets and file handles python, c,
| ocaml, java, c#, and every other language I've used. Its
| not like you can randomly call file.close() or close(fd)
| (in python and c respectively) and expect to be able to
| continue reading or writing the file later. Same for inter-
| thread interactions... all those languages have mutexes
| too. Like none of that is rust-specific, its just the
| consequence of using resources and threads in code.
| timeon wrote:
| Yeah I use often Rust where Python would be enough. But
| unless I really need quick/interactive feedback (for
| exploratory stuff ie.: Jupyter with plots), Rust suits me
| well.
| dang wrote:
| Related:
|
| _My negative views on Rust_ -
| https://news.ycombinator.com/item?id=29659056 - Dec 2021 (89
| comments)
| umanwizard wrote:
| > Distinguishing mutability has its advantages
|
| I think it's misleading to say that Rust distinguishes
| mutability. It distinguishes _exclusivity_. If you hold a
| reference to something, you are guaranteed that nothing else
| holds an exclusive reference to it (which is spelled &mut). You
| are _not_ guaranteed that nothing accessible through that
| reference can change (for example, it might contain a RefCell or
| other interior-mutable type). Shared references (spelled &)
| usually imply immutability, but not always. On the other hand, if
| you hold an exclusive reference to something, you are guaranteed
| that nothing, anywhere, holds any kind of reference to it.
|
| IMO, the fact that exclusive references are spelled "&mut", and
| often colloquially called "mutable references", was a pedagogical
| mistake that we're unfortunately now stuck with.
| jkelleyrtp wrote:
| "There are only two kinds of languages: the ones people complain
| about and the ones nobody uses".
|
| ---
|
| Glad to see fluffy negative articles about Rust shooting up the
| first slot of HN in 20 minutes. It means Rust has made finally
| made it mainstream :)
|
| ---
|
| The points, addressed, I guess?
|
| - Rust has panics, and this is bad: ...okay? Nobody is writing
| panic handling code, it's not a form of error handling
|
| - Rust inserts Copy, Drop, Deref for you: it would be really
| annoying to write Rust if you had to call `.copy()` on every
| bool/int/char. A language like this exists, I'm sure, but this
| hasn't stopped Rust from taking off
|
| - Fetishization of Efficient Memory Representation: ... I don't
| understand what the point is here. Some people care about
| avoiding heap allocations? They're a tool just like anything else
|
| - Rewrite anything and it gets faster: okay sure, but there are
| limits to how fast I can make a Py/JS algorithm vs a compiled
| language, and Rust makes writing compiled code a bit easier.
| People probably aren't rewriting slow Python projects in C these
| days
|
| - Rust is as complex as C++: ...no, it's not. Rust really hasn't
| changed much in the past 6 years. A few limitations being lifted,
| but nothing majorly new.
|
| - Rust isn't as nice of community as people think: subjective
| maybe? People are nice to me at conferences and in discussion
| rooms. There's occasional drama here and there but overall it's
| been pretty quiet for the past year.
|
| - Async is problematic: Async Rust really is fine. There's a huge
| meme about how bad it is, but really, it's fine. As a framework
| author, it's great, actually. I can wrap futures in a custom
| Poll. I can drive executors from a window event loop. Tokio's
| default choice of making `spawn` take Send/Sync futures is an odd
| one - occasionally cryptic compile errors - but you don't need to
| use that default.
|
| I'm unsure why this article is so upvoted given how vapid the
| content is, but it does have a snappy title, I guess.
| s17n wrote:
| > Fetishization of Efficient Memory Representation: ... I don't
| understand what the point is here. Some people care about
| avoiding heap allocations? They're a tool just like anything
| else
|
| The point is that dealing with the Rust borrow checker is a
| huge pain in the ass and for most Rust applications you would
| have been better off just using a garbage collected language.
| jkelleyrtp wrote:
| I mean, maybe?
|
| If you come into Rust thinking you're going to write doubly-
| linked lists all day and want to structure everything like
| that, you're going to have a bad time.
|
| But then in python you run into stuff like:
|
| ```
|
| def func(list = []): list.append(1)
|
| ```
|
| and list is actually a singleton. You want to pull your hair
| out since this is practically impossible to hunt down in a
| big codebase.
|
| Rust is just different, and instead of writing double-pointer
| code, you just use flat structures, `Copy` keys, and `loop
| {}` and move on with your life.
| fiedzia wrote:
| > this is practically impossible to hunt down in a big
| codebase
|
| use linters, they keep getting smarter
| n_plus_1_acc wrote:
| rustc is a good smart linter
| Izkata wrote:
| FYI this site doesn't use ``` for code blocks, it uses
| indentation (two spaces).
|
| https://news.ycombinator.com/formatdoc
| iknowstuff wrote:
| I haven't had to ,,deal with" the borrow checker since like
| 2018. It's quite smart
| CryZe wrote:
| > huge pain in the ass
|
| Maybe if you structure your code weirdly? I haven't
| encountered a major borrow checker issue that I couldn't
| easily resolve in many years.
| Ygg2 wrote:
| > Rust isn't as nice of community as people think
|
| It's a numbers game. As the number of people using Rust grows,
| so does the number of Jerks using Rust. And it's not like the
| Rust community is a stranger to bullying maintainers of crates
| for various things.
|
| > Async is problematic: Async Rust really is fine.
|
| It's... OK. It has a few issues, that hopefully will get fixed,
| like making Pin from a generic struct into a type of reference.
| e.g. instead of `Pin<&str>` you would write `&pin str`.
|
| There is also the coloring problem which is quite a hassle and
| people are looking into possible solutions.
| hyperbrainer wrote:
| > Rust is as complex as C++: ...no, it's not.
|
| Maybe not yet, but it is heading in that direction; and I only
| say this because of the absolutely giant pile of features in
| unstable that seem to be stuck there, but I hope will
| eventually make its way to stable at some point.
|
| > Async Rust really is fine
|
| I dunno. Always thought it was too complicated, but as another
| person pointed out avoiding Tokyo::spawn solves many issues
| (you said this too, I think). So maybe, not Rust's fault :D
| CryZe wrote:
| > Maybe not yet, but it is heading in that direction
|
| About 95% of the unstable features lift limitations that most
| people expect not to be there in the first place. I'm not
| aware of all too many that aren't like that.
| lovethevoid wrote:
| This was an oddly defensive and vapid comment. Mostly just
| handwaving away any views the article brings up, of which at
| least the article expands on their thoughts. This comment is
| just "meh not a bad thing" repeatedly. Why is this comment
| being upvoted?
| pessimizer wrote:
| > This was an oddly defensive and vapid comment.
|
| Even comparatively, next to your own comment? I have no
| specific idea of what you object to or why, but I have
| learned that you are upset.
| jkelleyrtp wrote:
| The title is inflammatory and yet there are few nuanced takes
| in the article. It's weird to see it shoot to the top of HN.
|
| I think the loglog article is a much better, nuanced, full
| critique of Rust.
|
| https://loglog.games/blog/leaving-rust-gamedev/
|
| The internet is just so full of negativity these days. People
| upvote titles but don't read articles. Reading about people's
| views on subjects is useful, but I don't think this one is.
| throwawaymaths wrote:
| I've seen a case where the rust panic handler is used in FFI
| and this creates a memory leak.
| api wrote:
| IMHO the biggest Rust async annoyance is exactly this:
|
| > Tokio's default choice of making `spawn` take Send/Sync
| futures
|
| ... combined with lack of structured concurrency.
|
| This means async tasks look like threads in every respect,
| causing you to end up using Arc<> and other concurrency
| constructs all over the place where they ought not be
| necessary. This harms efficiency and adds verbosity.
| lacker wrote:
| I like Rust but at the same time I agree with the points here.
| These things are indeed problems with Rust.
|
| Nevertheless, C++ has even worse problems. When your alternative
| is using C++, that's the time to consider Rust.
| rich_sasha wrote:
| I think to some extent Rust is a victim of its own unreasonable
| effectiveness. It is great at its narrow niche of memory safe low
| level programming, but frankly pretty good at lots of other
| things. But at these other applications some of its design
| principles get in the way - like the pedantic borrow checker.
| Languages not used outside their niches don't tend to collect
| such criticism.
|
| Python is a bit like that. It is a top choice for a few things,
| and ends up used effectively for other things, simply because it
| is versatile. But then people run into issues with dynamic
| typing, zero static safety, start slapping type annotations
| everywhere... and bemoan Python as a bit of a horror show.
|
| My use case for Rust is complementing Python, where frankly I
| don't care about half the complex features, still it's nicer than
| C or C++ to code in. The complexities of the borrow checker are
| more like a tax to me. I understand people who are frustrated
| with it thought, as otherwise they see it as a bit of a perfect
| language.
| throwawaymaths wrote:
| I think in general python gets used because of laziness and
| vitality. It's just the dumb shit that X person learned first
| because Y person before then was taught it because it was easy
| even though it's maybe not even the right choice for example,
| you can't properly write a _working webserver_ in python
| without {venv, uvicorn, celery etc.} and if youve ever worked
| in another language its like why the hell is this shit here?
| Because it 's viral, someone didn't know better, and it stuck.
|
| Same goes for machine learning. The ML folks at the start
| couldn't be bothered to learn something the least bit
| sophisticated. Some things are getting better. You don't need
| conda anymore, tensorflow wheels are out, and at least instead
| of shippong around .pt, checkpoint, or pickle files at least we
| use safetensors, but there's still python shit around, like
| jinja2 templates for conversations, etc.
|
| Anyways if we want good things we need to get better about
| getting unstuck from these local minima.
| rich_sasha wrote:
| I disagree re Python. It is a brilliant, flexible scripting
| language. It is easy to build expressive libraries such as
| pytest or argparse, with deep introspection. It is easy to
| prototype by subtly changing return types, or even keeping
| them flexible. It is really easy to eg build a custom data
| type and build custom expression trees, such as what ML often
| needs.
|
| It has a number of features (often stemming from the above)
| that make it a PITA for other applications, even when it
| would be fairly well suited to them otherwise. What I would
| give for proper static typing for production Python! Alas,
| that's not coming, and Rust's occasionally mind boggling
| borrow checker is there to stay.
| MuffinFlavored wrote:
| Who uses panic instead of `?` and anyhow / Box<dyn Error> (error
| propagation?)
|
| I think there is even a (gross) way to achieve try/catch around a
| block of code that panics?
| pshc wrote:
| Yeah, panic/assert is only for Things That Really Shouldn't
| Ever Fail, If They Do Our Base Assumptions Have Broken.
|
| whereas Error is for things that are unlikely to fail, like
| network/filesystem requests and recoverable logic bugs.
| jeffreyrogers wrote:
| I learned to program around the peak of object oriented
| fetishization. Shortly after that came functional programming's
| moment, and now it seems we are slightly past Rust and other
| safety focused languages' peak period of hype. All three language
| families have useful things to offer, but were never the panacea
| their proponents claimed them to be. "No Silver Bullet" continues
| to be true.
___________________________________________________________________
(page generated 2024-10-09 23:00 UTC)