Programming thread

LMAO THEY'RE LITERALLY JUST COPY PASTING FEATURES FROM .NET NOW
View attachment 2151119
.Net has had value types for ages, and C# added pattern matching ala JEP 405 a couple of years back! One thing I have to wonder about java primitives is whether they'll be remotely compatible with generics, I suspect not, in which case enjoy rewriting every algorithm for specific primitive types!
TFW you are in the shadow of your Microshaft clone, desperately trying to keep up
TFW java :story:
Hold your horses. The influence of value types into the JVM is a consolidation of conclusions from Java, Scala, Clojure and Kotlin. Java's development is very conservative, to the degree Goetz said something to the effect of "the last language to adopt a feature".
If you've read the JEPs in a more than cursory fashion you'd know primitive types are designed to work with generics
 
I found out the other day that the Raspberry Pi people released a microcontroller board called the Pico. I've been wanting to get into that sort of stuff for a while, but needed something with an easy on-ramp for a newbie, and I think the Pico fills that niche quite easily. I got a kit from Amazon which included the board plus a breadboard and all of the LEDs, resistors, and other components needed to complete the projects in their official intro-level guidebook and I've had a lot of fun playing with it so far. The book has you use MicroPython (which from what I gather is just Python with a compiler optimized for minimal hardware), but they've put other books out there walk you through how to hack for it with C instead; unfortunately the computer I'm playing with this on is a newer Apple Silicon machine and there isn't an AS port of one of the libraries I need, so I've been sticking with the Python so far despite my distaste for it, but I'm hoping to be able to switch over to C soon. I'd really recommend giving this a look if you want to get into microcontroller stuff - they've done a good job of smoothing over the speed bumps both in cost and technical knowledge.
 
Hold your horses. The influence of value types into the JVM is a consolidation of conclusions from Java, Scala, Clojure and Kotlin. Java's development is very conservative, to the degree Goetz said something to the effect of "the last language to adopt a feature".
If you've read the JEPs in a more than cursory fashion you'd know primitive types are designed to work with generics
>Reading

It's something at least, requiring reimplementation of containers for every primitive has always been incredibly retarded. I wonder how much this'll level the playing field between Java and .Net, adoption will probably be a speed bump
 
>Reading

It's something at least, requiring reimplementation of containers for every primitive has always been incredibly retarded. I wonder how much this'll level the playing field between Java and .Net, adoption will probably be a speed bump
Perhaps adoption would be an issue, but maintaining their existing base would not be. If I were a business with java legacy code, I would absolutely prefer migrating to a new version of java rather than porting to .NET. The difference between those two could be "couple weeks setback" vs "out of business".
 
>Reading

It's something at least, requiring reimplementation of containers for every primitive has always been incredibly retarded. I wonder how much this'll level the playing field between Java and .Net, adoption will probably be a speed bump
With the least amount of powerleveling possible, I can say I haven't seen anyone considering .NET for backend. It's either JVM languages, Python or Go.
So I think we'd see effects in the other direction, Java making inroads into areas where .NET has some market share. Combined with work on SKIJA I have a dream of Java on desktop.
From what I gather from Java's core team, they take immense pains to make all the new features forward and backwards compatible.
Perhaps adoption would be an issue, but maintaining their existing base would not be. If I were a business with java legacy code, I would absolutely prefer migrating to a new version of java rather than porting to .NET. The difference between those two could be "couple weeks setback" vs "out of business".
Adding record / primitive keywords to your POJOs - easy.
Migration to another platform - lol no, never gonna happen
Also, if you have performance issues with Java there are a ton of things which can be worked on / fixed before the only thing left becomes primitive classes. Performance is a painful subject, plenty of people don't consider it then write abhorrent messes.
 
So I think we'd see effects in the other direction, Java making inroads into areas where .NET has some market share. Combined with work on SKIJA I have a dream of Java on desktop.
From what I gather from Java's core team, they take immense pains to make all the new features forward and backwards compatible.
Perhaps adoption would be an issue, but maintaining their existing base would not be. If I were a business with java legacy code, I would absolutely prefer migrating to a new version of java rather than porting to .NET. The difference between those two could be "couple weeks setback" vs "out of business".
I'm not talking about people moving from .NET to Java or visa versa, I'm just talking about relative speed up of programs post-primitives.
With the least amount of powerleveling possible, I can say I haven't seen anyone considering .NET for backend. It's either JVM languages, Python or Go.
This is probably just a question of field ¯\_(ツ)_/¯ You do web stuff right?

Adding record / primitive keywords to your POJOs - easy.
Also, if you have performance issues with Java there are a ton of things which can be worked on / fixed before the only thing left becomes primitive classes. Performance is a painful subject, plenty of people don't consider it then write abhorrent messes.
Wait a second though I've read a little bit more (f3'd it really), how would primitives even work with java generics? As far as I can tell none of the JEPs actually propose a solution, and having generics continue work by type erasure is impossible unless the proposal is to just automatically box them which undoes the benefit of using primitives anyway.
Are you talking about this old JEP from 2014? It only raises questions
On performance though, if we are talking about something like mathematics then no, primitives are essential for achieving any amount of performance. You simply can't have a decent math library if every vector has to be heap allocated. If we are talking something like text manipulations or web communication though then yes, lack of primitives probably won't be a serious bottleneck.
 
This is probably just a question of field ¯\_(ツ)_/¯ You do web stuff right?
Depends on how you define it. I shuffle data from one end to another. Don't think I ever exposed an API to a frontend, though.
Wait a second though I've read a little bit more (f3'd it really), how would primitives even work with java generics? As far as I can tell none of the JEPs actually propose a solution, and having generics continue work by type erasure is impossible unless the proposal is to just automatically box them which undoes the benefit of using primitives anyway.
  • Allowing operations on both primitive value types and primitive reference types, with seamless conversions between the two. Primitive value types enable storing and passing primitive objects without indirection. Primitive reference types enable polymorphism and null references when working with primitive objects.
The API of primitive classes exposes a reference to it for polymorphism
The primitive reference type of a primitive class is spelled with the class name followed by .ref. The values of a primitive reference type are references to instances of the named class, or null. A primitive reference type is a subtype of all of the named class's declared supertypes.

Point pi; // stores a Point object
Point.ref pr; // stores a reference to a Point
Shape s; // stores a reference to a Shape, which may be a Point
  • A separate JEP will update Java's generics so that primitive value types can be used as type arguments.

An important followup effort, not covered by these JEPs, will enhance the JVM to specialize generic classes and bytecode for different primitive value type layouts.
From how I read this, closer to C++ templates
taken from https://openjdk.java.net/jeps/401
On performance though, if we are talking about something like mathematics then no, primitives are essential for achieving any amount of performance. You simply can't have a decent math library if every vector has to be heap allocated. If we are talking something like text manipulations or web communication though then yes, lack of primitives probably won't be a serious bottleneck.
If you're doing math heavy stuff in Java you should be using accelerator libraries anyway.
 
The API of primitive classes exposes a reference to it for polymorphism


From how I read this, closer to C++ templates
taken from https://openjdk.java.net/jeps/401
References to primitive objects are created by primitive reference conversions from primitive values. Like boxing conversions, primitive reference conversions are implicit in the Java language. But primitive reference conversions can be much lighter-weight, because they do not introduce a new identity.
...
A primitive value conversion, like an unboxing conversion, converts from a reference to a primitive value, throwing an exception if the reference is null.
...
A method invocation may perform an implicit primitive reference or value conversion to ensure the type of the receiver matches the expected type of this in the method declaration.
...
Java's generics are designed to work only with reference types, but a future JEP will enhance generics to interoperate with primitive value types.
So in other words value types don't work with generics, rather they have an automatic boxing conversion.
I mean that future goal is as similar to templates as .Net generics are to templates, but their proposal here is just to add automatic boxing for all value types, which is pretty much what I predicted.

Interesting to be able to talk about value types that are on the heap though, C# lacks that capability and it makes certain things awkward. Pretty silly really, .Net absolutely has the capability, but for some reason imposes the restriction that all boxed types are taken as readonly except through mutating interface methods which is kind of arbitrary and retarded
:stress:
That said, this .ref thing isn't true reference capability, this only allows you to lift things onto the heap, which does come with a cost.

If you're doing math heavy stuff in Java you should be using accelerator libraries anyway.
I mean I wrote my own vector math library that operates on arrays when I was making a game in java, but the point is that you can't write fluent code like that, you have to frame everything in the context of object pooling and imperative operations. It's the difference between Vec3 Add(in Vec3 a, in Vec3 b) and void Add(float[] ar, int firstIdx, int secondIdx, int outputIdx, int span)
Which would you rather deal with :story:
My basic thesis here is that you shouldn't have to convert all of your math to unintuitive array operations in order to achieve a basic level of performance, it drastically hurts your ability to generalize and write algorithms.
 
So in other words value types don't work with generics, rather they have an automatic boxing conversion.
I mean that future goal is as similar to templates as .Net generics are to templates, but their proposal here is just to add automatic boxing for all value types, which is pretty much what I predicted.

Interesting to be able to talk about value types that are on the heap though, C# lacks that capability and it makes certain things awkward. Pretty silly really, .Net absolutely has the capability, but for some reason imposes the restriction that all boxed types are taken as readonly except through mutating interface methods which is kind of arbitrary and retarded
:stress:
That said, this .ref thing isn't true reference capability, this only allows you to lift things onto the heap, which does come with a cost.


I mean I wrote my own vector math library that operates on arrays when I was making a game in java, but the point is that you can't write fluent code like that, you have to frame everything in the context of object pooling and imperative operations. It's the difference between Vec3 Add(in Vec3 a, in Vec3 b) and void Add(float[] ar, int firstIdx, int secondIdx, int outputIdx, int span)
Which would you rather deal with :story:
My basic thesis here is that you shouldn't have to convert all of your math to unintuitive array operations in order to achieve a basic level of performance, it drastically hurts your ability to generalize and write algorithms.
I'm not sure if it's strictly boxing as exists now for numbers, because it still doesn't have the overhead of an object with an identity, headers, etc. I think it's just a pointer to the primitive instead of the variable itself behind the scenes, which isn't terrible all things considered.
It's all in development now. Those JEPs are very new. The generics support will come and will work well.
Your vector woes would have been solved if Java had true vector types which supported SIMD instructions (they're working on it, too), then you could "project" actions, which would be pretty cool.
My only exposure to an accelerated vector library is https://github.com/uncomplicate/neanderthal/ which deals more in vectors and matrices, and has allegedly crazy performance.
 
I'm not sure if it's strictly boxing as exists now for numbers, because it still doesn't have the overhead of an object with an identity, headers, etc. I think it's just a pointer to the primitive instead of the variable itself behind the scenes, which isn't terrible all things considered.
From the context, they are absolutely saying boxing conversion, the only caveat being that they don't include all the usual overhead with the boxed value, which is progress sure, but it's still heap garbage.
It's all in development now. Those JEPs are very new. The generics support will come and will work well.
I dunno man, I really cannot imagine how they'll do that without either a breaking change or a new distinct form of generic. The current form literally depends on type erasure to work, and I really don't think that can be rationalized with value types. My guess would be some kind of constraint that allows a generic to optin to value type parameters, but I don't know how you'd grandfather existing generics into that.
For example, ArrayList literally uses an Object[] parameter to store it's elements, that is a guaranteed breaking change if you try to make it store a value type. Furthermore, all generic types are currently assumed to have the same internal layout, and thus are mutually convertible, but that is simply impossible to maintain if you substitute in a value type. For instance, Function<float, float> would have to be completely interchangeable with Function<String, String> —as they both just decorated Function<Object, Object>— to maintain complete backwards compatibility, and I just don't see how that's possible.
If by some miracle they do figure this problem out though, they have a nice opportunity to add some good interfaces to the basic math types so that basic generic math functions can be written.
Your vector woes would have been solved if Java had true vector types which supported SIMD instructions (they're working on it, too), then you could "project" actions, which would be pretty cool.
My only exposure to an accelerated vector library is https://github.com/uncomplicate/neanderthal/ which deals more in vectors and matrices, and has allegedly crazy performance.
Well even these proposed changes will basically solve that issue, though a related issue that they'll run into is copying costs, which .Net (sort of) fixed with ref and in.

One thing they should consider is allowing single inheritance of value types, I know it doesn't fit with the general view of value types, but it's honestly a great feature that .Net is sorely lacking.
 
Last edited:
Regarding everything else it's mostly a wait-and-see situation, although you can probably pester Brian Goetz on twitter and actually get a response. There's probably more info on the jdk mailing list, too. I think I should start reading it.
One thing they should consider is allowing single inheritance of value types, I know it doesn't fit with the general view of value types, but it's honestly a great feature that .Net is sorely lacking.
May have missed it, are primitive classes and record types final?
 
May have missed it, are primitive classes and record types final?
I'm just guessing based on what .Net did, but if they haven't said so explicitly maybe they won't. All the better, no reason to have such a restriction anyway.


One problem I'm currently sussing out is how to handle passing of values. Currently my best option appears to be pass by r-value reference, and return by value (where value may be an l-value reference). Returning by r-value —which I would like to do were it possible— creates a seemingly inescapable issue of scope, as for instance how then do you return a value from this;
Ruby:
(Let [[a (...)]              # Declare a value a
 (Add (TEval [a (...)]))    # Add something to a, the result will have the scope of Let
])                           # Value escapes it's scope, error
You will have to somehow copy the value to the escaping scope, either explicitly, or implicitly. One option is to simply determine whether the object escapes, and copy it in that case, but this will likely have many cases where the value can't be copied —e.g. struct with references that would also escape— and would therefore lead to confusing errors. Another option is to mark the value for copying somehow —(ByVal (...)), but this is effectively a more verbose form of simply returning by value.
In light of this, it seems that simply passing by r-value and returning by value is most appropriate and consistent. The issue then is that the r-value reference becomes a second class concept, that only really only exists in the mind of the interpreter, and I'm not super keen on that kind of inconsistency.
 
I'm looking at developing some software using distributed computing and although I've got some textbooks and I'm doing a subject on this next semester, I was just wondering if anyone here had anything particularly useful. I understand most things about it, but it doesn't hurt to ask.
 
I'm looking at developing some software using distributed computing and although I've got some textbooks and I'm doing a subject on this next semester, I was just wondering if anyone here had anything particularly useful. I understand most things about it, but it doesn't hurt to ask.
Generally, don't do it unless you have a valid use case.

Really, that goes for any paradigm, technology, or platform.

Cloud providers like AWS and Azure have spent a lot of time an expense abstracting away some of the more arcane or troublesome concepts so that they have a specific offering for things like distributed messaging, job queues, short-lived on-demand processes, and horizontal and vertical scaling.

Most college classes aren't there for you to be developing in the most efficient manner possible, they want you to learn the primitive concepts and implement it at a very basic level to solidify your understanding. For example, I basically never have to stop and think about network partitioning issues on DynamoDB global tables because it's handled so well by Amazon but it's a common topic for college courses in distributed computing.
 
Generally, don't do it unless you have a valid use case.

Really, that goes for any paradigm, technology, or platform.

Cloud providers like AWS and Azure have spent a lot of time an expense abstracting away some of the more arcane or troublesome concepts so that they have a specific offering for things like distributed messaging, job queues, short-lived on-demand processes, and horizontal and vertical scaling.

Most college classes aren't there for you to be developing in the most efficient manner possible, they want you to learn the primitive concepts and implement it at a very basic level to solidify your understanding. For example, I basically never have to stop and think about network partitioning issues on DynamoDB global tables because it's handled so well by Amazon but it's a common topic for college courses in distributed computing.
I refuse to use AWS because they're an enormous company, and I'd get more satisfaction building my own distributed computing platform for my own personal use. I have a number of old computers that I want to use as slaves for abstracting into one interface, and running software and rendering tasks on it.

I have no real use for it beyond that it's cool and I want to use my skills while I'm bored. Also considering that my university does cover this content in depth, and my university has resources available for me to test and deploy this stuff
 
I refuse to use AWS because they're an enormous company, and I'd get more satisfaction building my own distributed computing platform for my own personal use. I have a number of old computers that I want to use as slaves for abstracting into one interface, and running software and rendering tasks on it.

I have no real use for it beyond that it's cool and I want to use my skills while I'm bored. Also considering that my university does cover this content in depth, and my university has resources available for me to test and deploy this stuff
Very well.

Well pretty much any modern distributed system is going to include application layer A performing some kind of processing then sending the result on to layer B via a message queue in a pub-sub arrangement. Usually this is to free layer A to respond to incoming requests while some beefier or more scalable technology in layer B handles the heavy lifting.

Get yourself a message queue of your choice -- RabbitMQ or whatever else the kids are using these days.
Put together a package of shared models that will act as the content of the message.

Layer A will consist of [1..X] instances and layer B will consist of [1..Y] instances.
Layer B instances subscribe to the queue+topic.
Layer A instances publish to queue+topic.

Layer B instances dequeue messages and perform their long-running work. As they free up, they take another message in a non-deterministic fashion.

For extra credit, implement an additional queue topic for messages that fail to process through layer B along with any error output.
 
Very well.

Well pretty much any modern distributed system is going to include application layer A performing some kind of processing then sending the result on to layer B via a message queue in a pub-sub arrangement. Usually this is to free layer A to respond to incoming requests while some beefier or more scalable technology in layer B handles the heavy lifting.

Get yourself a message queue of your choice -- RabbitMQ or whatever else the kids are using these days.
Put together a package of shared models that will act as the content of the message.

Layer A will consist of [1..X] instances and layer B will consist of [1..Y] instances.
Layer B instances subscribe to the queue+topic.
Layer A instances publish to queue+topic.

Layer B instances dequeue messages and perform their long-running work. As they free up, they take another message in a non-deterministic fashion.

For extra credit, implement an additional queue topic for messages that fail to process through layer B along with any error output.
Ok awesome. I've already established multi-CPU consensus and my software is capable of queueing up tasks so I guess I'm halfway there. I just need to implement the single interface that's capable of easily distributing tasks.
I plan on writing an interface that can execute Python, Java, C, C++ and an hMail interface. I've noted that down so thank you for the tips.
 
  • Like
Reactions: GreeneCoDeputy
Back