9 ms·

> This is why Objective-C looks so bizarre Interesting point, hadn't thought about this before. > TS doesn't have syntax for value vs reference types or memor

> This is why Objective-C looks so bizarre Interesting point, hadn't thought about this before. > TS doesn't have syntax for value vs reference types or memory ownership/lifetimes...if you kept the syntax similar to TS, then new features may end up looking bolted on and forced I would argue that the vast majority of code in a low-level language doesn't care about manual memory access or pass by val/ref. It's all abstracted away into libraries. It just comes down to a different syntax, but they are all doing the same thing. As seen here: https://rosetta.fiatjaf.com/compare/TypeScript/Rust/ https://rosetta.fiatjaf.com/compare/TypeScript/Rust/. Most of the time we are just passing around references anyway. So why no make this the default implicit case, and then when you need something exotic, add syntax then.

nyberg 4y ago
> I would argue that the vast majority of code in a low-level language doesn't care about manual memory access or pass by val/ref. > Most of the time we are just passing around references anyway. So why no make this the default implicit case, and then when you need something exotic, add syntax then. This depends on what the language is being used for. If it's to write high level glue code then passing references/pointers around is likely the norm. However the majority of cases you will care about how things are passed, how they're allocated, where they're allocated, and so on. If you don't care you're often using the wrong tool for the job or you're writing inefficient messy code. Writing allocators (arena/bump, heap, gc, rc, memory pools, etc) requires control more often than not and applications which desire performance often need to write their own tailored to their usage patterns (e.g you don't want it to free things at the wrong time). Data layout and alignment of said data play a key role in keeping the application performant along with the ability to reinterpret memory without copying values which is something TS lacks. Access to inline assembly for the cases where the compiler generates undesirable code or where what you want to do can't be expressed in the language itself. The above applies to quite a few domains and especially to embedded where you often have limited resources (time, memory, code size, etc). It may seem like a rare case but if you look around your at your everyday appliances around your home, sensors in your car, your headphones, and so on, you'll see that it's a rather common case. It would be good for you to try such languages for a while so you can see why the features presented to you exist and try to develop something which touches the different areas where it's used. Embedded is a nice start with especially dealing with MMIO.

nyberg 4y ago

> I would argue that the vast majority of code in a low-level language doesn't care about manual memory access or pass by val/ref. > Most of the time we are just passing around references anyway. So why no make this the default implicit case, and then when you need something exotic, add syntax then. This depends on what the language is being used for. If it's to write high level glue code then passing references/pointers around is likely the norm. However the majority of cases you will care about how things are passed, how they're allocated, where they're allocated, and so on. If you don't care you're often using the wrong tool for the job or you're writing inefficient messy code. Writing allocators (arena/bump, heap, gc, rc, memory pools, etc) requires control more often than not and applications which desire performance often need to write their own tailored to their usage patterns (e.g you don't want it to free things at the wrong time). Data layout and alignment of said data play a key role in keeping the application performant along with the ability to reinterpret memory without copying values which is something TS lacks. Access to inline assembly for the cases where the compiler generates undesirable code or where what you want to do can't be expressed in the language itself. The above applies to quite a few domains and especially to embedded where you often have limited resources (time, memory, code size, etc). It may seem like a rare case but if you look around your at your everyday appliances around your home, sensors in your car, your headphones, and so on, you'll see that it's a rather common case. It would be good for you to try such languages for a while so you can see why the features presented to you exist and try to develop something which touches the different areas where it's used. Embedded is a nice start with especially dealing with MMIO.