5 ms·

You can know your class alignments in Java using tools like http://openjdk.java.net/projects/code-tools/jol/ http://openjdk.java.net/projects/code-tools/jol/ H

by azth 5y ago

You can know your class alignments in Java using tools like http://openjdk.java.net/projects/code-tools/jol/ http://openjdk.java.net/projects/code-tools/jol/ Having access to pointers is a superficiality. Java is getting value types, and C# already has them.

dwohnitmok 5y ago
Right but those tools are VM-specific (e.g. the one you've posted is Hotspot-specific) and VM-specific optimizations are usually considered advanced optimizations in Java. Valhalla's value types aren't the same thing as pointer access (or lack thererof). The first thing is that this is baked into the definition site rather than being something that can be decided at a call site. The second thing is that value types entail way more than just pointer access (as befits a higher-level approach). In particular it gets rid of the built-in ability of Java objects to act as locks, gets rid of mutation, etc. It's a much larger change than just referencing and dereferencing. More to the point, the notion of pointers referencing and dereferencing is a lower level concept than reference vs value types. The former is usually used to implement the latter.
- azth 5y ago
  > More to the point, the notion of pointers referencing and dereferencing is a lower level concept than reference vs value types. The former is usually used to implement the latter. If the end result is the same, then the claim is really meaningless. I'm just pointing out the parroting that goes on in the golang community.
  - dwohnitmok 5y ago
    > If the end result is the same, then the claim is really meaningless. One being used to implement the other doesn't mean the end result is the same (you cannot use value types and reference types to implement pointers because of the call-site vs definition-site distinction). As I mentioned, value types are far more than pointer dereferencing.
    - azth 5y ago
      The point is, pointer dereferencing in golang is limited to mimicing value types/reference types, something that C# already offers. It is not like C and C++ where you have pointer arithmetic. So it's just an illusion that it is "closer to the metal".
      - dwohnitmok 5y ago
        No it's not. Value types and reference types are definition-site concepts whereas pointer referencing and dereferencing are call-site things. This allows both for different ways of programming as well as different language semantics.
      - thegeekpirate 5y ago
        > It is not like C and C++ where you have pointer arithmetic. You absolutely _can_ do pointer arithmetic—it just requires using the "unsafe" package for obvious reasons (https://go.dev/play/p/Batmgb1KJcg https://go.dev/play/p/Batmgb1KJcg). Hell, there's even a helper function (https://pkg.go.dev/unsafe#Add https://pkg.go.dev/unsafe#Add) for addition!
        azth 5y ago
        Calling unsafe is not the point here. You can do similar things in Java if you really need to.
throwaway894345 5y ago
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.
- 5y ago
geodel 5y ago
> Java is getting value types, And it is good thing to have. But if one desperately comment same thing multiple times, I feel reasonable to ask why the hell they weren't added in all these years?
- azth 5y ago
  The philosophy behind Java is that a feature needs to be demonstrated in production very well before it is added to the language, in order no to go overboard with features and end up with C++ :) Value types have proven their worth, especially with the gap between CPUs and memory bandwidth, so they're being added.

by azth 5y ago

dwohnitmok 5y ago

Right but those tools are VM-specific (e.g. the one you've posted is Hotspot-specific) and VM-specific optimizations are usually considered advanced optimizations in Java. Valhalla's value types aren't the same thing as pointer access (or lack thererof). The first thing is that this is baked into the definition site rather than being something that can be decided at a call site. The second thing is that value types entail way more than just pointer access (as befits a higher-level approach). In particular it gets rid of the built-in ability of Java objects to act as locks, gets rid of mutation, etc. It's a much larger change than just referencing and dereferencing. More to the point, the notion of pointers referencing and dereferencing is a lower level concept than reference vs value types. The former is usually used to implement the latter.

azth 5y ago
> More to the point, the notion of pointers referencing and dereferencing is a lower level concept than reference vs value types. The former is usually used to implement the latter. If the end result is the same, then the claim is really meaningless. I'm just pointing out the parroting that goes on in the golang community.
- dwohnitmok 5y ago
  > If the end result is the same, then the claim is really meaningless. One being used to implement the other doesn't mean the end result is the same (you cannot use value types and reference types to implement pointers because of the call-site vs definition-site distinction). As I mentioned, value types are far more than pointer dereferencing.
  - azth 5y ago
    The point is, pointer dereferencing in golang is limited to mimicing value types/reference types, something that C# already offers. It is not like C and C++ where you have pointer arithmetic. So it's just an illusion that it is "closer to the metal".
    - dwohnitmok 5y ago
      No it's not. Value types and reference types are definition-site concepts whereas pointer referencing and dereferencing are call-site things. This allows both for different ways of programming as well as different language semantics.
    - thegeekpirate 5y ago
      > It is not like C and C++ where you have pointer arithmetic. You absolutely _can_ do pointer arithmetic—it just requires using the "unsafe" package for obvious reasons (https://go.dev/play/p/Batmgb1KJcg https://go.dev/play/p/Batmgb1KJcg). Hell, there's even a helper function (https://pkg.go.dev/unsafe#Add https://pkg.go.dev/unsafe#Add) for addition!
      - azth 5y ago
        Calling unsafe is not the point here. You can do similar things in Java if you really need to.

throwaway894345 5y ago

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.
5y ago

geodel 5y ago

> Java is getting value types, And it is good thing to have. But if one desperately comment same thing multiple times, I feel reasonable to ask why the hell they weren't added in all these years?

azth 5y ago
The philosophy behind Java is that a feature needs to be demonstrated in production very well before it is added to the language, in order no to go overboard with features and end up with C++ :) Value types have proven their worth, especially with the gap between CPUs and memory bandwidth, so they're being added.