2 ms·

It's also worth distinguishing between "has value types" and "uses value types". C# has them, but they aren't particularly idiomatic--they're regarded as an opt

It's also worth distinguishing between "has value types" and "uses value types". C# has them, but they aren't particularly idiomatic--they're regarded as an optimization.

azth 5y ago
How is that relevant to the point whether a language is "closer to the metal" or not?
- throwaway894345 5y ago
  Because calling a language "close to the metal" is potentially ambiguous--it can imply that a language merely has "close to the metal" features or it can imply that they not only exist but are used in the course of idiomatic code. Specifically, only one of these interpreters conveys the idea: "I can read code in this language and have a pretty good idea about what the generated machine code is like".
  - azth 5y ago
    > I can read code in this language and have a pretty good idea about what the generated machine code is like This is not true even for C. Secondly, it seems that its common in the golang community to parrot things that not only are incorrect, but provably wrong.
    - throwaway894345 5y ago
      First of all, you can look at C code and have a pretty good idea about the generated machine code, or at least a much better idea than with C# and Java. Secondly, it's even easier to predict Go code because Go compilers don't optimize as aggressively as C compilers and because Go has very little UB. > Secondly, it seems that its common in the golang community to parrot things that not only are incorrect, but provably wrong. Whatever your intentions may have been, this is just language war flame bait, and it's against the rules.
int_19h 5y ago
They're reasonably idiomatic. Anyone dealing with the standard library will likely have to deal with KeyValuePair, for example - which is a value type. So are the (language-integrated) tuples.
- codeflo 5y ago
  Tuples are a great example that I might not have thought of -- you practically "define" your own value types all the time. Also, all enum types are value types. And there are lots and lots of very commonly used value types in the base class library: DateTime, TimeSpan, Guid, CancellationToken. Programmers have to be familiar with their semantics.
  - throwaway894345 5y ago
    Yeah, this makes sense. I concede that idiomatic C# uses value types sometimes, although they're more pervasive in idiomatic Go.
- throwaway894345 5y ago
  I take your point--idiomatic C# code uses some value types. It would be more accurate for me to say there's a difference in degree with respect to the extent that C# and Go employ value types: wherever C# uses classes, Go uses structs; where C# uses class instances, Go uses either struct values or pointers to struct values (or interfaces, in the case of runtime polymorphism).

It's also worth distinguishing between "has value types" and "uses value types". C# has them, but they aren't particularly idiomatic--they're regarded as an optimization.

azth 5y ago

How is that relevant to the point whether a language is "closer to the metal" or not?

throwaway894345 5y ago
Because calling a language "close to the metal" is potentially ambiguous--it can imply that a language merely has "close to the metal" features or it can imply that they not only exist but are used in the course of idiomatic code. Specifically, only one of these interpreters conveys the idea: "I can read code in this language and have a pretty good idea about what the generated machine code is like".
- azth 5y ago
  > I can read code in this language and have a pretty good idea about what the generated machine code is like This is not true even for C. Secondly, it seems that its common in the golang community to parrot things that not only are incorrect, but provably wrong.
  - throwaway894345 5y ago
    First of all, you can look at C code and have a pretty good idea about the generated machine code, or at least a much better idea than with C# and Java. Secondly, it's even easier to predict Go code because Go compilers don't optimize as aggressively as C compilers and because Go has very little UB. > Secondly, it seems that its common in the golang community to parrot things that not only are incorrect, but provably wrong. Whatever your intentions may have been, this is just language war flame bait, and it's against the rules.

int_19h 5y ago

They're reasonably idiomatic. Anyone dealing with the standard library will likely have to deal with KeyValuePair, for example - which is a value type. So are the (language-integrated) tuples.

codeflo 5y ago
Tuples are a great example that I might not have thought of -- you practically "define" your own value types all the time. Also, all enum types are value types. And there are lots and lots of very commonly used value types in the base class library: DateTime, TimeSpan, Guid, CancellationToken. Programmers have to be familiar with their semantics.
- throwaway894345 5y ago
  Yeah, this makes sense. I concede that idiomatic C# uses value types sometimes, although they're more pervasive in idiomatic Go.
throwaway894345 5y ago
I take your point--idiomatic C# code uses some value types. It would be more accurate for me to say there's a difference in degree with respect to the extent that C# and Go employ value types: wherever C# uses classes, Go uses structs; where C# uses class instances, Go uses either struct values or pointers to struct values (or interfaces, in the case of runtime polymorphism).