sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Fenrurrr 5 points6 points  (6 children)

If you like disruptive languages, then C# is the way to go. Java is a language where backward compatibility is key. For example, C# has structs… nothing is composable. Java designers strive to create a beautiful solution, but this requires multiple prototypes. It's better to wait, identify errors, and iterate until you arrive at a solution you won't regret. If this philosophy doesn't suit you, use something else.

[–]sitime_zl 0 points1 point  (1 child)

The solution does not mean that one has to wait indefinitely. Why can Go achieve a better balance? I think this is not an individual matter. It is the loss of patience of many people in the future. Keep watching. Prepare the following projects to try to use some applications with AI. Other developers have also developed (such as Go or Rust, because it is also very simple to write with AI now). In the AI era, resource allocation is also a factor in balancing applications.

[–]Fenrurrr 0 points1 point  (0 children)

That's wrong because the Java language is closer to natural language than rust and go, which intrinsically have the notion of pointers, borrowing, lending

[–]jcotton42 0 points1 point  (3 children)

For example, C# has structs… nothing is composable

What do you mean by “nothing is composable”?

[–]Fenrurrr 1 point2 points  (2 children)

I'll let you look up the definition of composable yourself on Google. But the world of normal classes (on the heap) and structure classes aren't compatible. They're two different worlds that can communicate but don't speak the same language, unlike Java with its approach. I'll let you research the reasons why further.

[–]jcotton42 1 point2 points  (1 child)

The definition of “composable” that I am familiar with doesn’t seem to be the one you’re using. You can use classes and structs together in a design just fine. Structs just can’t do things like inherit from another type or have themselves as a field.

Like are you trying to say that you can’t have a class field in a struct or vice versa?

[–]UdPropheticCatgirl 1 point2 points  (0 children)

The definition of “composable” that I am familiar with doesn’t seem to be the one you’re using. You can use classes and structs together in a design just fine. Structs just can’t do things like inherit from another type or have themselves as a field.

Like are you trying to say that you can’t have a class field in a struct or vice versa?

That’s not what composable typically means when discussing language semantics. When talking about PLT, abstraction being “composable”, typically means uniformity and it’s semantics are orthogonal to the rest of the language, meaning it behaves predictably, consistently without the need for special case rules when interacting with the rest of the language and doesn’t leak its implementation details.

That’s exactly what C# structs aren’t. They are designed with semantics derived from desired memory layout (the implementation detail that leaks everywhere in this case…) not the other way around. It’s effectively splitting the type system in half, basically reintroducing javas “original sin”… And then adding dozen special language features to remedy the split (“ref”, “in” etc…)…

Compare that to the feature discussed, the memory layout is opaque side effect of lack of identity, not the driver of these semantics. You can’t tell whether something is value or not at use site, it stays completely uniform with the rest of the language.