4 ms·

C++ has had these things for years. Seriously though, the JVM is killing it. Can't wait until I can compile my .jar to verilog and run it on my FPGA, or send

C++ has had these things for years. Seriously though, the JVM is killing it. Can't wait until I can compile my .jar to verilog and run it on my FPGA, or send the verilog to TSMC and get some ASICs printed out.

eeperson 9y ago
Why wait: https://chisel.eecs.berkeley.edu/ https://chisel.eecs.berkeley.edu/
- Cieplak 9y ago
  Chisel is very sweet, definitely the tool I would use to implement the JVM instruction set in silicon.
repsilat 9y ago
> C++ has had these things for years. C++ is built on these things. The "value type" thing informs everything about the language. I love it, and it's my go-to language when something just has to be fast, but it comes along with some hefty baggage. Java gets a lot of mileage out of its reference-first philosophy that C++ would be wise to try out -- the "everything must be possible with no overhead" philosophy of the language bleeds into the programming community in unhealthy ways, and the amount of language machinery to make the value stuff work "as well as possible" (https://stackoverflow.com/questions/3601602/what-are-rvalues-lvalues-xvalues-glvalues-and-prvalues https://stackoverflow.com/questions/3601602/what-are-rvalues...) is absurd. > Seriously though, the JVM is killing it As for the JVM and Java, this seems like a guilty admission that the CLR and C# ate their lunch a decade ago (perhaps not wrt performance, but for language features....) I've never worked in the Microsoft stack, but the stories have been the same since the dawn of the age -- "C# is Java with real generics, value types and lambda functions." First they laughed...
- _old_dude_ 9y ago
  Value types doesn't seem to be like struct in C++ or C#. They are immutable so you have no way to know if they are stack allocated, split over several registers or on heap. This is important because it means that JITs will not have to be changed, they will not have to manage stack aliases like in C#/C++.
- Matthias247 9y ago
  As great as structs in C# for performance reasons are: They also provide several new ways to shoot yourself in the foot if you don't understand their behavior to 100%. One example that I run many years ago was having a struct Foo { int x; } which was nested inside a List<Foo> myList. Trying to mutate one list element with syntax like myList[0].x = 27 silently failed, because the indexer of the list returns a copy of Foo and you mutate that inside of writing it back. Nowadays its a compiler error, but back then it wasn't. The workaround is something like "Foo f = myList[0]; f.x = 27; myList[0] = f;". Which is quite weird if you are coming from C++. From a C# point of view it's actually obvious, since you can't pass around references and pointers to structs inside of other things - and if you also add this functionality, you get lots of the complexity from C++ back (references to structs, functions/properties that return references, questions around reference lifetimes, etc.). Without having also reference semantics for structs, structs also can't achieve the kind of performance which "value types" in C++ have, since they sometimes need to be copied fully. Another nice gotcha is the surprising behavior of readonly structs, which e.g. is documented here: https://bytes.com/topic/c-sharp/answers/261922-readonly-behavior-structs https://bytes.com/topic/c-sharp/answers/261922-readonly-beha... For those reasons I think it's quite fair that Java and other languages did not immediately jump onto the value types train. I think introducing them carefully, and trading off the performance gains against the amount of new complexity in the language is fine.
  - pjmlp 9y ago
    When Java was introduced we already had plenty of GC enabled languages with value types. Eiffel, Oberon, Modula-2+, Modula-3, VB, are just a few examples. Hence why I always saw as lost opportunity not to provide them in first place.
- bitmapbrother 9y ago
  >As for the JVM and Java, this seems like a guilty admission that the CLR and C# ate their lunch a decade ago I disagree. The JVM continues to eat the lunch of the CLR in performance, developer mindshare, pervasiveness and ecosystem. And with each new Java version those language feature differences continue to decline. And if you do need that syntactic sugar then there's always Kotlin.
- Cieplak 9y ago
  I was hoping the Seriously though conveyed the sarcasm of the previous sentence, given that Java is written in C++. I agree with you that C# is a much nicer programming language than Java. The HotSpot JVM, otoh, is a masterpiece of engineering in terms of its JIT and GC optimizations.
  - repsilat 9y ago
    > I was hoping the Seriously though Ah, my fault. You expected more than the audience deserved.
- rsj_hn 9y ago
  > As for the JVM and Java, this seems like a guilty admission that the CLR and C# ate their lunch a decade ago The reason why this never happened was that Java was good enough. A quick look at TIOBE shows C# stuck at around 3% while java continues to reign supreme. I do think C# is a better language in many ways, but not, it seems, in any ways that really matter for purposes of language adoption. Which is a shame, since I enjoy writing code in C# more than in java, but I don't have much opportunity to do it, and I've never been in a situation in which C# was the language and it wasn't an MS-only solution.

eeperson 9y ago

Why wait: https://chisel.eecs.berkeley.edu/ https://chisel.eecs.berkeley.edu/

Cieplak 9y ago
Chisel is very sweet, definitely the tool I would use to implement the JVM instruction set in silicon.

repsilat 9y ago

> C++ has had these things for years. C++ is built on these things. The "value type" thing informs everything about the language. I love it, and it's my go-to language when something just has to be fast, but it comes along with some hefty baggage. Java gets a lot of mileage out of its reference-first philosophy that C++ would be wise to try out -- the "everything must be possible with no overhead" philosophy of the language bleeds into the programming community in unhealthy ways, and the amount of language machinery to make the value stuff work "as well as possible" (https://stackoverflow.com/questions/3601602/what-are-rvalues-lvalues-xvalues-glvalues-and-prvalues https://stackoverflow.com/questions/3601602/what-are-rvalues...) is absurd. > Seriously though, the JVM is killing it As for the JVM and Java, this seems like a guilty admission that the CLR and C# ate their lunch a decade ago (perhaps not wrt performance, but for language features....) I've never worked in the Microsoft stack, but the stories have been the same since the dawn of the age -- "C# is Java with real generics, value types and lambda functions." First they laughed...

_old_dude_ 9y ago
Value types doesn't seem to be like struct in C++ or C#. They are immutable so you have no way to know if they are stack allocated, split over several registers or on heap. This is important because it means that JITs will not have to be changed, they will not have to manage stack aliases like in C#/C++.
Matthias247 9y ago
As great as structs in C# for performance reasons are: They also provide several new ways to shoot yourself in the foot if you don't understand their behavior to 100%. One example that I run many years ago was having a struct Foo { int x; } which was nested inside a List<Foo> myList. Trying to mutate one list element with syntax like myList[0].x = 27 silently failed, because the indexer of the list returns a copy of Foo and you mutate that inside of writing it back. Nowadays its a compiler error, but back then it wasn't. The workaround is something like "Foo f = myList[0]; f.x = 27; myList[0] = f;". Which is quite weird if you are coming from C++. From a C# point of view it's actually obvious, since you can't pass around references and pointers to structs inside of other things - and if you also add this functionality, you get lots of the complexity from C++ back (references to structs, functions/properties that return references, questions around reference lifetimes, etc.). Without having also reference semantics for structs, structs also can't achieve the kind of performance which "value types" in C++ have, since they sometimes need to be copied fully. Another nice gotcha is the surprising behavior of readonly structs, which e.g. is documented here: https://bytes.com/topic/c-sharp/answers/261922-readonly-behavior-structs https://bytes.com/topic/c-sharp/answers/261922-readonly-beha... For those reasons I think it's quite fair that Java and other languages did not immediately jump onto the value types train. I think introducing them carefully, and trading off the performance gains against the amount of new complexity in the language is fine.
- pjmlp 9y ago
  When Java was introduced we already had plenty of GC enabled languages with value types. Eiffel, Oberon, Modula-2+, Modula-3, VB, are just a few examples. Hence why I always saw as lost opportunity not to provide them in first place.
bitmapbrother 9y ago
>As for the JVM and Java, this seems like a guilty admission that the CLR and C# ate their lunch a decade ago I disagree. The JVM continues to eat the lunch of the CLR in performance, developer mindshare, pervasiveness and ecosystem. And with each new Java version those language feature differences continue to decline. And if you do need that syntactic sugar then there's always Kotlin.
Cieplak 9y ago
I was hoping the Seriously though conveyed the sarcasm of the previous sentence, given that Java is written in C++. I agree with you that C# is a much nicer programming language than Java. The HotSpot JVM, otoh, is a masterpiece of engineering in terms of its JIT and GC optimizations.
- repsilat 9y ago
  > I was hoping the Seriously though Ah, my fault. You expected more than the audience deserved.
rsj_hn 9y ago
> As for the JVM and Java, this seems like a guilty admission that the CLR and C# ate their lunch a decade ago The reason why this never happened was that Java was good enough. A quick look at TIOBE shows C# stuck at around 3% while java continues to reign supreme. I do think C# is a better language in many ways, but not, it seems, in any ways that really matter for purposes of language adoption. Which is a shame, since I enjoy writing code in C# more than in java, but I don't have much opportunity to do it, and I've never been in a situation in which C# was the language and it wasn't an MS-only solution.