; => CaffeineOverdoseError

ROTTERDAM!!!!

That sounds awful

That is what turned me off academia. People scrambling to get recognized for work they might not have done themselves, but they are at the top of the food chain.

It is even topical in Denmark the moment: https://da.wikipedia.org/wiki/Please_don%27t_steal_my_work

Are you researching as well @U4P4NREBY?

well, I did the work, but I am not technically a researcher. And to be honest, it doesn’t matter much to me since I don’t need to game citations to have a career like the tenure track people.

I think the proof is in the pudding. I open source everything I do here and that paper trail leads directly to me in 100% of the cases.

That’s at least a positive way of seeing it. But yes, the citation game is what makes some parts of academia seem toxic (in my opinion, and I can only see it from the outside as I’m no researcher myself).

The way I see it, having a plethora of open source contributions is the software developer’s equivalent to having lots of citations. And I consider myself a software developer, not a researcher even if my output is often research-adjacent.

True, the difference is, as you put it before, with software contributions the paper trail leads to the developer who made it.

To me that means open source contributions are worth more.

precisely

Dammnnnnn I didn’t know it was that bad in Denmark 😮 I’ve heard about it being an issue in the states before.

I think it’s common almost everywhere in academia. It has some serious perverse incentives. Career advancement is basically a pyramid scheme linked to the citation scores and the funding that is attached to your name. Employment for researchers is extremely precarious until they finally become a professor, which means those lower in the hierarchy accept long work hours with poor financial compensation + having to attribute a great deal of their work to those higher up in the hierarchy, since they bring the name recognition and/or funding. A as a consequence of this, you will find that a lot of PhDs and postdocs have this extremely meek and subservient attitude since this is furthers their career advancement. I am not a part of that system (thankfully) so I also don’t have to work interest hours, but I do get to observe it first-hand almost every day.

😞

That's what academia runs on Can you imagine what would happen if it lost its prestige? No more research grants, donations or conventions. Instant demotion from researcher to unemployed bum

If some esoteric vc investor is reading this, lend me your power and I'll break the prestige monopoly 😁

Immediately added it to our company Slack space, thanks! 😅

All credit goes to @U4P4NREBY in the message right above (very topical crediting 🙂)

what is a java 1.0 green thread?

https://noss.github.io/2009/03/23/only-green-threads-are-green.html

are these the regular Thread ?

the very first release of java had non-native "green" threads ... scheduling was entirely in-JVM

I see, I didn't know that

then one of the early subsequent major releases introduced native threads

and it took them 25 years to re-introduce virtual threads? ;)

>> Isnt this just "green threads"? >> > Java developers may recall that in the Java 1.0 days, some JVMs implemented threads using user-mode, or "green", threads. Virtual threads bear a superficial similarity to green threads in that they are both managed by the JVM rather than the OS, but this is where the similarity ends. The green threads of the 90s still had large, monolithic stacks. They were very much a product of their time, when systems were single-core and OSes didnt have thread support at all. Virtual threads have more in common with the user-mode threads found in other languages, such as goroutines in Go or processes in Erlang -- but have the advantage of being semantically identical to the threads we already have.

Taken from here: https://www.infoq.com/articles/java-virtual-threads/ by Brian Goetz

yeah, googling found me that @U0N9SJHCH... but it's not very satisfying - e.g. what do jdk19 vthreads do differently ?

and what's a monolithic stack as opposed to any other stack ?

You are right, it‘s not really a deep explanation

AFAIK green threads were multiplexed on one real thread, while virtual threads do MxN multiplexing

Would the JEP be of help? https://openjdk.org/jeps/425

Lots of details there

searching for "green" in that doc @U11EL3P9U gives roughly what @UK0810AQ2 said

🙂

There is always the mailing list

that may have more answers

i asked chatGPT as well, and along with some vague stuff which might be hinting at MxN multiplexing, it also gave me:

Stack Size: Java 1.0 green threads had a fixed stack size, which limited their scalability. Java 19 virtual threads use a flexible stack allocation mechanism that allows the JVM to dynamically adjust the stack size based on the application's needs, improving scalability.

ah, from the JEP:

The stacks of virtual threads are stored in Java's garbage-collected heap as stack chunk objects. The stacks grow and shrink as the application runs, both to be memory-efficient and to accommodate stacks of arbitrary depth (up to the JVM's configured platform thread stack size). This efficiency is what enables a large number of virtual threads, and thus the continued viability of the thread-per-request style in server applications.

old grean threads Mx1 new virtual threads MxN, but that from the JEP is the best I think

Would have really liked first class continuations with that But alas

Old ones green, new ones super green

grean? lern2spel Buce

> monolithic Monoliths* are bad mkay ... *except for when they're repos ... or backends written in Clojure.

@UK0810AQ2 jdk.internal.vm.Continuation is there (though you need to toggle it on when you start the JVM), and they say they'll ultimately support continuations via some future stable public API, but for now... 😞

Yeah, I already played with it but it feels half baked, and it can't be forked

Their comments about how lightweight threads should meet most use cases for continuations makes me worry that they'll never support them properly, but I do hope they manage something in the end. Combined with other recent improvements and the upcoming TCO support, I'd be excited about all the implementation improvements we could make for languages like Clojure, Kawa, &c.

This would really depend on Oracle paying Ron Pressler to finish the implementation or move him to the next project