4 ms·

Rust memory management is... profoundly not manual? Case in point: I use Rust/WASM in all of my web apps to great effect, and memory is never a consideration.

by tekacs 1y ago

Rust memory management is... profoundly not manual? Case in point: I use Rust/WASM in all of my web apps to great effect, and memory is never a consideration. In Rust you pretty much never think about freeing or memory. On top of that, when objects are moved across to be owned by JS, FinalizationRegistry is able to clean up them up pretty much perfectly, so they're GC-ed as normal.

teaearlgraycold 1y ago
Wrangling the borrow checker seems pretty manual at times. And I don’t know why you’d bother with a persnickety compile time GC when JS’s GC isn’t a top issue for front end development.
- zdragnar 1y ago
  The borrow checker just verifies that you're handling the concept of ownership of memory correctly. The actual management of memory- allocating, reclaiming, etc - are all handled automagically for you.
  - auggierose 1y ago
    There is no need for the concept of ownership of memory in JavaScript. So you are wasting time on a concept that doesn't matter in languages with a real GC. Dealing with ownership = manual memory management.
    - zdragnar 1y ago
      This used to not be true- once upon a time, Internet Explorer kept memory separate for DOM nodes and JavaScript objects, so it was very easy to leak memory by keeping reference cycles between the two. Now, with all the desire for WASM to have DOM access I wonder if we'll end up finding ourselves back in that position again.
    - zarzavat 1y ago
      You can still have ownership issues and leaks even with a GC, if an object is reachable from a root. e.g. object A is in a cache and it references object B which references objects C D E F G ... which will now never get collected. If A owns B then that is as expected but if A merely references B then it should hold a WeakRef
- tekacs 1y ago
  I use Rust for all the other reasons, real types being a major one of them: https://hn.algolia.com/?type=comment&query=typescript%20sound%20author%3Atekacs https://hn.algolia.com/?type=comment&query=typescript%20soun... It's kinda exhausting to use TypeScript and run into situations where the type system is more of a suggestion than a rule. Passing around values [1] that have a type annotation but aren't the type they're annotated as is... in many ways worse than not typing them in the first place. [1]: not even deserialized ones - ones that only moved within the language!
- apatheticonion 1y ago
  You stop noticing the borrow checker after a while and being able to write insanely parallel/performant code is quite rewarding. Again, not all websites need to be usable on low end hardware/have a 1mb memory footprint - but there are a lot of use cases that would benefit. Think, browser extensions that load on every tab and consume 150mb+ * number of tabs open and shares the main thread with the website. ServiceWorkers that sit as background processes in your OS even when the browser is closed, that sort of thing.

by tekacs 1y ago

teaearlgraycold 1y ago

Wrangling the borrow checker seems pretty manual at times. And I don’t know why you’d bother with a persnickety compile time GC when JS’s GC isn’t a top issue for front end development.

zdragnar 1y ago
The borrow checker just verifies that you're handling the concept of ownership of memory correctly. The actual management of memory- allocating, reclaiming, etc - are all handled automagically for you.
- auggierose 1y ago
  There is no need for the concept of ownership of memory in JavaScript. So you are wasting time on a concept that doesn't matter in languages with a real GC. Dealing with ownership = manual memory management.
  - zdragnar 1y ago
    This used to not be true- once upon a time, Internet Explorer kept memory separate for DOM nodes and JavaScript objects, so it was very easy to leak memory by keeping reference cycles between the two. Now, with all the desire for WASM to have DOM access I wonder if we'll end up finding ourselves back in that position again.
  - zarzavat 1y ago
    You can still have ownership issues and leaks even with a GC, if an object is reachable from a root. e.g. object A is in a cache and it references object B which references objects C D E F G ... which will now never get collected. If A owns B then that is as expected but if A merely references B then it should hold a WeakRef
tekacs 1y ago
I use Rust for all the other reasons, real types being a major one of them: https://hn.algolia.com/?type=comment&query=typescript%20sound%20author%3Atekacs https://hn.algolia.com/?type=comment&query=typescript%20soun... It's kinda exhausting to use TypeScript and run into situations where the type system is more of a suggestion than a rule. Passing around values [1] that have a type annotation but aren't the type they're annotated as is... in many ways worse than not typing them in the first place. [1]: not even deserialized ones - ones that only moved within the language!
apatheticonion 1y ago
You stop noticing the borrow checker after a while and being able to write insanely parallel/performant code is quite rewarding. Again, not all websites need to be usable on low end hardware/have a 1mb memory footprint - but there are a lot of use cases that would benefit. Think, browser extensions that load on every tab and consume 150mb+ * number of tabs open and shares the main thread with the website. ServiceWorkers that sit as background processes in your OS even when the browser is closed, that sort of thing.