5 ms·
Typescript would require you to check for null before use, which I think makes this a good example of how TS is oftentimes a fairly gentle step up from JS. Or,
by Waterluvian 1y ago
Typescript would require you to check for null before use, which I think makes this a good example of how TS is oftentimes a fairly gentle step up from JS. Or, at least, closer to the correctness of Rust without all the heavy stuff.
- quotemstr 1y agoBut you don't get manual memory management then. No GC, safety, and simplicity: pick any two
- Waterluvian 1y agoThat’s true, two different tools have different pros and cons.
- ori_b 1y agoSure, but GC's not the only upside.
- TylerE 1y agoFor a large number of people including myself, manual memory management is a huge con, not a pro.
- ameliaquining 1y agoYes, but there are use cases where it's a hard requirement.
- kiitos 1y agoyep! but file watcher programs, or http services, or really anything that runs on modern linux servers, are not these use cases!
- koakuma-chan 1y agoDo you manually manage memory in Rust? Because I just write Vec::new or vec![], just like how I would write new ArrayList in Java.
- Aurornis 1y agoYou manually manage memory via ownership rules and lifetimes. You can allocate memory for a Vec with Vec::new. Dropping it deallocates. When and where it's dropped is important. Passing ownership around is important. These are parts of managing the memory. If you need something to be on the heap, you use Box. If you need something to be shared, you use something like Arc or Rc. Rust makes it nice to implicitly handle the common cases so you don't feel like you're doing manual memory management, but you're making decisions about that memory management at every step of the way.
- marcus_cemes 1y agoTo extend upon this, memory generally has a single owner. When it goes out of scope, it gets freed [1]. The drop() function, which appears analogous to free() in C/C++, is actually just an empty function who's sole purpose is to take ownership and make it go out of scope, which immediately frees the memory [2]. > This function is not magic; it is literally defined as: pub fn drop<T>(_x: T) {} This is usually more deterministic than GC languages (no random pauses), but can be less efficient for highly nested data structures. It also makes linked lists impossible without using "unsafe rust", as it doesn't abide by the normal ownership rules. [1]: https://doc.rust-lang.org/rust-by-example/scope/raii.html https://doc.rust-lang.org/rust-by-example/scope/raii.html [2]: https://doc.rust-lang.org/std/mem/fn.drop.html https://doc.rust-lang.org/std/mem/fn.drop.html
- sshine 1y agoLinked lists to arbitrary memory, yes. Linked list from a consecutive chunk of memory managed by a bump allocator: just as easy as any language, no need for unsafe. Admittedly not the easiest language to make a linked list in.
- 1y ago
- pjmlp 1y agoFalse set of options, people just haven't been using the right systems languages with automatic resource management, that also offer escape hatchs to manual memory management. Cedar being one of the very first ones. Whose ideas perculated to Modula-2+, Modula-3, Oberon, Oberon-2, Component Pascal, Active Oberon, D, C# (after Midori learnings finally found their way into the language), Swift, Chapel, and whatever comes next where researchers now try to mix both productivity with modern type systems.