undefined | Better HN

0 pointskuhsaft6d ago0 comments

I hate to say it. But thats user error. The struct paradigm is different from classes. Structs are meant to be plain-old data types; simply a typed span of memory.

Structs are values, classes are entities with encapsulation.

The shape of the state would be structural. Whether or not the data in that shape is valid is behavioral.

Structs are useful when working with spans of memory.

Another example of a good usage of struct is Guid, which is 128 bits of data packed together.

The C# equivalent to Java ‘value class’ would be a class with a struct encapsulated for data. The data is flattened and allocated on the heap like Java. Similarly, escape analysis could stack allocate the class at runtime.

0 comments

2 comments · 1 top-level

DarkNova66d ago· 1 in thread

This is what makes the nuances of Valhalla's Value types so compelling. The idea are granular structs with "Integrity by default", where you can selectively give up constraints on class design to get performance characteristics.

Structs in most languages simply bunch a couple constraints together to get another set of performance benefits, but there's no law stating that they couldn't be singled out. In the design of Valhalla, it states that types can come in 4 buckets:

1: Fully identity classes (total control, mutable)

2: Value Based classes (no mutability, but full integrity and dense memory layout)

3: Implicitly constructed values (forced empty default constructor for swift bulk array initialization)

4: Tearable Values (No cross-field integrity during runtime for parallel access)

And I bet that for a vast majority of developers, #4 will come to a shocking surprise, thinking "values are threat safe" because they are told to use immutables.

This way of splitting up structs is the real interesting part of Valhalla, but this shitty AI-generated article buries everything interesting.

kuhsaftOP6d ago

Imo #4 is why it’s not that useful. If the data is larger than an atomic read/write op the data isn’t flattened and it’s a regular object with value equality and immutability.

You have to opt into force flattening, and then it’s the same as a struct, except it’s still heap allocated without escape analysis. You still have to implement synchronization to prevent tearing.

Static code analysis can give you a warning for potential tearing of structs.

DotNext.Threading provides Atomic<T> to enable high-performance atomic operations on structs without heap allocation.

https://dotnet.github.io/dotNext/features/core/atomic.html

The design of value classes just seems counteractive to its purpose: memory management. If I want to manage contiguous blocks of memory, let me manage contiguous blocks of memory. If I want to allocate something on the stack, let me allocate something on the stack.

The paradigms of struct vs object are too different and they’re trying to combine them into one.

j / k navigate · click thread line to collapse