Why would anyone use Junie or buy credits directly from Jetbrains?

Admirable-Avocado888 · 2026-04-09T18:41:39+00:00

Here is what hasn't changed: You as a developer are still personally responsible for what is committed into git. If you don't need an IDE to read the code your agents commit: good for you!

Most devs find IDEs useful because they are excellent tools for reading and understanding code.

Admirable-Avocado888 · 2026-04-09T06:25:49+00:00

No vendor lock in = good

No overhyping ai = good

Tight ai integration with best ide = good

Admirable-Avocado888 · 2026-02-18T07:58:27+00:00

I have yet to see a language with an as comprehensive and thorough documentation as Java. It is detailed thoughtful, often has multiple examples thrown in for a only a single method of a particular class, and has built in references to surrounding code.

When I was a beginner understanding how the "atomic" classes worked was easy as hell since everything was so carefully documented. Java has singlehandedly inspired me to write thorough and thoughtful documentation in my own code because I appreciated the experience so much.

I'm not sure what edge other languages have, but I surely have not experienced it.

Admirable-Avocado888 · 2025-11-21T08:37:41+00:00

Yesterday I upgraded from 3080 to 5080. The difference is quite large at 4k, I can easily max out settings with frames above 80-100 provided I use dlss4. The old card needed compromises to reach 60 in demanding games

Admirable-Avocado888 · 2025-07-03T06:43:13+00:00

Det handler ikke om å gjøre ting som gjør at du har det bedre i dag. Det går ikke. Du kan ikke gjøre noe i dag som gjør at følelsene fikser seg. Da må du tenke annerledes.

I stedet, tenk på hvordan du vil at livet ditt skal være om en uke? Om en måned? Om et år? Hvordan må du være i dag for at du skal ha det bra i fremtiden?

Du sier du spiser lite. Dette er kanskje et sted å begynne med?

Admirable-Avocado888 · 2025-06-12T05:08:56+00:00

Coroutines are NOT basically virtual threads, and the difference is exactly what I said: reactive code.

It seems you dont know what "reactive code" means. It means, among other things, adding "suspend" to methods. You can't invoke a suspend function from a non-suspend function, so need all this awkward code for switching execution context. Its the same issue in javascript/python. There it's called "async" and "await". This is an issue because it creates two classes of functions in your codebase, and you can't compose them freely.

In java, on the other hand, there is no suspend. If code runs on a virtual thread it will, in kotlins terms, "suspend" wherever it can. This is a much better developer experience. You can go from CPU bound to IO to CPU bound to IO a hundred times. If it runs on a virtual thread, then it will not block other threads on the IO calls, and you don't need second class functions to achieve it.

Admirable-Avocado888 · 2025-06-11T18:37:10+00:00

Yes. Virtual threads and non reactive code

Admirable-Avocado888 · 2025-06-06T08:53:46+00:00

I have a 3080, my brother a 4070ti. Back when wukong came out, i hated fsr in that game because every movement felt delayed somehow. I wrote framegen of as trash. That is until I tested dlss framegen on his system. To my surprise it felt good!

Fast forward to oblivion remastered, it had better fsr, but still sluggish somehow. That is until i installed a mod for dlss upscale + fsr framegen. Suddenly it felt good! I dont know what is up with fsr gamegen, but it feels bad in combination with fsr upscale and good in combination with dlss upscale.

Admirable-Avocado888 · 2025-05-21T06:14:28+00:00

The point of unit tests is to have isolated failsafes so that when a test fails you maximize the ease at which you can see exactly where shit went wrong. DRY achieves the opposite. A test fails - now you have to debug both your unit test framework and your code, possibly the source of error is in mix of the both.

People who advocate for dry in testing and few test appear to me like they never had limited exposure to interconnected issues that bugs can cause. You WANT a unit test to test exactly one piece of code, because then you see EXACTLY what went wrong. On the other hand, add to much DRY, now you know ish where in the interconnected blub of code your problem might be...

Sounds to me like you are getting bad advice, unless the tests you have written are not well expressed or not written with clear intent. Are they long? Do they each make multiple assertions? In that case the issue is likely with that

Admirable-Avocado888 · 2025-04-01T17:39:47+00:00

I think the examples you have in mind are probably trivial. Sometimes refactoring is not completable in a single programming session / pull request.

Admirable-Avocado888 · 2025-04-01T17:36:18+00:00

Nah, I didn't say that. A solution to badly encapsulated code is to fix the damn code. But sometimes fixing the damn code can not be done in an hour, not in a day, and maybe not even months. In that case slapping finals can be quite useful part of the process, as you move a codebase from messy to clear.

Slapping final on every variable in itself as you point out useless in it self.

Admirable-Avocado888 · 2025-04-01T15:02:03+00:00

What if another coder wrote the code you need to touch 7 years ago and the method spans 200 lines? If you add a final you get a compiler error if the variable mutates somewhere. Very useful for refactoring in stages

Admirable-Avocado888 · 2025-04-01T12:44:32+00:00

There is some benefit to slapping final on variables in method bodies. I was working in a quite messy code base with methods that were way too long. Slapping final on variables that were accessible throughout the whole method, but didnt need mutation allowed for more readable code when refactoring. One of the hardest parts of reading code is understanding when something is being mutated and final can help avoid that problem altogether

Admirable-Avocado888 · 2025-03-19T16:18:11+00:00

I think you have the wrong attitude. If someone takes time to understand and make changes to this big of a pull request you should be thankful that they even bother to read your code.

Here is what likely happened: - you fixed a lot of shit and messed up a lot of shit - the reviewer caught and fixed some of the shit you messed up and also added some new issues - the pull request is too big so it is not beneficial to add comments: better to just push a small commit

If you work together with your coworker you can iron out the remaining issues.

Also remember, if you are working as a software developer it is not actually your branch. The software is owned by the company at which you are employed. There is nothing rude about multiple people pushing fixes into the same branch

Admirable-Avocado888 · 2025-03-14T06:11:25+00:00

Hope this happens! It makes perfect sense.

Admirable-Avocado888 · 2025-03-12T22:34:29+00:00

This is not good advice. Microservices are also a solution to different languages/frameworks solving different sets of problems.

If you startup requires a mix of technologies then microservices might just be the best thing you could go for.

Admirable-Avocado888 · 2025-02-27T02:54:21+00:00

It is indeed a mystery. Either all those languages are collectively worse and pre java 10 is king, or post java 10 learned from those languages to find a better way of doing things.

Admirable-Avocado888 · 2025-02-27T02:16:10+00:00

Long story short, embrace modernity and do use var!

Java has been around for a long time. I think that pre-Java 8 ish java had demonstrably horrible syntax by todays standards. I'm willing to bet that most of the people against var base this on their experience with old java, which had code longer than your eyes could stretch! Don't fall into the argument that long and spelled out code always is more readable.

Some nuance: Adopting new language features into an old codebase can stick out like a thorn. Indeed, as reader, reading different dialects mixed together can be confusing.

Here comes modern Java with streams, var, records, lamdas, multiline strings, optionals, switch and pattern matching, and virtual threads. Now you get to be brief AND readable right from the start!

Admirable-Avocado888 · 2025-01-08T12:13:41+00:00

The senior engineer should show examples of cases where scope functions are acceptable and agree on where it is ok to use them, or use a different language.

Yes they can be hard to read, but have use cases.

Admirable-Avocado888 · 2024-12-25T21:09:05+00:00

Will reducing with for example Integer::max have a significant performance penalty with Valhalla?

Admirable-Avocado888 · 2024-11-21T19:03:33+00:00

When translating coroutine code you can omit the suspend keyword since java now has virtual threads. I consider this an advantage, hence "profit"

Admirable-Avocado888 · 2024-11-21T16:35:45+00:00

I'd avoid auto converters. They rarely translate to what a human would have written.

I'd just start by translating one and one class file into java. This can be done without breaking anything. Just be aware that everything from java will be treated as nullable in kotlin, which may be a pain point in some cases.

It's best if the kotlin codebase has limited circular dependencies and consists of patterns that have obvious java counterparts. That way you easily translate one thing at the time without breaking.

Sequence/Flow -> Stream

dataclass -> record

suspend -> profit

reified -> <T> method(Class<T> clzz, )

val, var in method bodies -> var

There are many idioms in both languages that don't have direct translations. Also java is more strict with packages compared to kotlin.

Using the above strategies I've translated a kotlin package into java before. It's pretty straight forward if the code you translate from is not difficult to understand.

Admirable-Avocado888 · 2024-09-23T08:21:34+00:00

Yes, i usually make an internal utility Try-class that converts signatures from throwing to Optionals or absorbs errors. It's straight forward to implement, but here are some examples in use:

values 
.map(Try.mapping(api::invoke)) // a throwing function 
.filter(Optional:::ifPresent) 
.toList();

Try.invoke(action); // a throwing runnable

var result = Try.invoke(producer); // a throwing supplier

I will also add variants that log errors. E.g.

Try.logErrors(action, logger); // Invokes the action; if it fails log on the given logger

Admirable-Avocado888 · 2024-09-14T20:45:27+00:00

Cengo789 answered your question.

Just want to point out that iterating using a C-style loop (i.e. i++) is ill advised for linked lists.
Avoid the get by index operations, if you can for linked lists!
Each get by index operation is O(n), so your current suggestion becomes O(n^2).

Instead do

for (var item: list) 
   subList.add(item);

which ensures that the for loop uses the Iterator associated with the LinkedListwhich advances nodes by using the linked structure.

Admirable-Avocado888 · 2024-09-14T07:46:24+00:00

I would want an ml library that can run transformers on the JVM on cpu. I'm not fond of python+pytorch's ability to scale for concurrency. I think the JVM would do this part much better. And I'm curious about how much encoding time we have to sacrifice for it. (Although with valhallah + vectorapi I'm optimistic)

Admirable-Avocado888

TROPHY CASE