81–90 of 143 posts
The fact that re-using a slot for a different object of the same type is considered a memory safety technique is ridiculous.
The fact that re-using a slot for a different object of the same type is considered a memory safety technique is ridiculous.
- Type safety > Memory management and type safety: https://en.wikipedia.org/wiki/Type_safety#Memory_management_...
- Memory safety > Classification of memory safety errors: https://en.wikipedia.org/wiki/Memory_safety#Classification_o...
- Template:Memory management https://en.wikipedia.org/wiki/Template:Memory_management
- Category:Memory_management https://en.wikipedia.org/wiki/Category:Memory_management
I’d love to see a language that kept everything as familiar as possible and implement memory safety as “the hard bit”, instead of the Rust approach of cooking in multiple different new sub languages and concepts.
Safety is not an extra feature a'la carte. These concepts are all inter-connected: Safety requires unions to be safe, so unions have to become tagged enums. To have tagged enums usable, you have to have pattern matching, otherwise you'd get something awkward like C++ std::variant. Borrow checking works only on borrowed values (as the name suggests), so you will need something else for long-lived/non-lexical storage.…
Earlier quoted context omitted.
I stand corrected on C++. Can you think of any other languages? Of the ones I listed, I use all of, and am continuously frustrated by this limitation.
>Can you think of any other languages? Yes. E.g. every language where you can pass pointers can do this. Reference are a construct around pointers. >Of the ones I listed, I use all of, and am continuously frustrated by this limitation. Why? This is only a limitation for a few basic types. All the language you mention allow you to modify objects passed to a function. If it ever were any issue though you can always ret…
Hint: Python and Javascript will use the type passed to determine mutability. Kotlin will let you pass a mutableStateFlow etc that can be used for, e.g., top-level data structure, but not an arbitrary variable. (e.g. a data structure field, or free variable).
The most popular languages, outside of C and C++, cannot pass pointers. And, raw pointers are not ideal; they lose type safety, memory safety etc.
There are always canonical patterns for a given language to write a function like I did. I find them to be universally more complicated and less explicit/versatile than what I posted; they require code to permeate beyond the function signature.
Earlier quoted context omitted.
Yet another PoV: for some things with critical timing or so, GC might be a problem. But most of the time, it isn’t. The performance/predictability topic could also be reviewed… I was talking with a colleague about that, he said “in C I know exactly where things are when” And I replied that under any OS with virtual memory, you have basically no clue where are things at any time, in the N levels of cache, and you cann…
Even with critical timing, real time GCs exist for decades now, PTC and Aicas are two surviving companies selling software tooling for embedded markets, including their own JVM implementations, with AOT compilers, bare metal deployments and real time GC. Many of their customers are factory processes and military deployments with weapons control, two scenarios where any kind of stall might produce deadly results.
Earlier quoted context omitted.
>Can you think of any other languages? Yes. E.g. every language where you can pass pointers can do this. Reference are a construct around pointers. >Of the ones I listed, I use all of, and am continuously frustrated by this limitation. Why? This is only a limitation for a few basic types. All the language you mention allow you to modify objects passed to a function. If it ever were any issue though you can always ret…
I challenge you to write the function signature I posted in Python, Javascript, or Kotlin; I'm confident you will not be able to, and the alternatives will be more provincial and unergonomic. Hint: Python and Javascript will use the type passed to determine mutability. Kotlin will let you pass a mutableStateFlow etc that can be used for, e.g., top-level data structure, but not an arbitrary variable. (e.g. a data stru…
class A:
a = 0
v.a = 2
a1.a = 1
print(a1.a)
modify(a1)
print(a1.a)
Earlier quoted context omitted.
I stand corrected on C++. Can you think of any other languages? Of the ones I listed, I use all of, and am continuously frustrated by this limitation.
>Can you think of any other languages? Yes. E.g. every language where you can pass pointers can do this. Reference are a construct around pointers. >Of the ones I listed, I use all of, and am continuously frustrated by this limitation. Why? This is only a limitation for a few basic types. All the language you mention allow you to modify objects passed to a function. If it ever were any issue though you can always ret…
Earlier quoted context omitted.
Even with critical timing, real time GCs exist for decades now, PTC and Aicas are two surviving companies selling software tooling for embedded markets, including their own JVM implementations, with AOT compilers, bare metal deployments and real time GC. Many of their customers are factory processes and military deployments with weapons control, two scenarios where any kind of stall might produce deadly results.
Thank you so much! Now I have a more powerful argument, when at work somebody says a motor ECU cannot use GC, because of time constraints! Of course I assume there might be a catch from the cost PoV, where Mil may be ok, automotive consumer goods may be a problem (today)
More people need to read up on C#'s ref's: https://em-tg.github.io/csborrow/ These kinda-sorta fall under borrow checking or regions, just without any annotations. Then again, Ada/Spark's strategy also technically falls under Tofte-Talpin regions: https://www.cs.cornell.edu/people/fluet/research/substruct-r...
https://github.com/prasannavl/WinApi
The performance of this interop layer is so close to native it's difficult to argue for doing things the much more painful way.