jatone

x11 has problems this is known. not moving to wayland isn't a regression its just maintenance of the status quo.

> I think the basic intellij config is set at max 2 gigs of RAM

yes, that is the conservative JDK defaults iirc; its likely unrelated to intellij specifically. I only mentioned the system specs because the other commenter was like 'i buy nice machines and give the editor tons of RAM'. but thats the cost of them using java. I don't want to tune my editor to ensure its responsive and can get its job done.

> Windows issue, and has nothing to do with intellij

except I exclusively run linux. ;)

> what language was that project written in?

early days for a flutter app. most of the issues most certainly due to the plugins themselves.

it was primarily gradle tasks running without prompting and fucking up my build.

I didn't configure anything. the experience was so bad I just bailed out, switched to my standard stack vscode and the command line stuff and never looked back.

it was android studio stuff at the time. I just tapped out of using it jetbrains related tooling after that experience.

the point I was making is that it wasn't an under powered machine that causing issues as implied by the responder.

sadly the issues I was having at the time were not just me all of them were documented / reported in the github issue tracker for flutter/android studio.

perfectly happy how I've phrased my criticisms. if jetbrains wants glowing reviews, then they can make a glowing product. I've been upfront where my issues reside, how they impacted me and they are well known issues with the tool. I'm not the first to make these comments nor will I be the last.

however, your tone in this thread implies you're not a neutral player in this. do you have any relation with intellij/jetbrains?

while I appreciate the offer; there is nothing to dig into here. jetbrains just doesn't bring anything to the table compared to other options. and it lost my trust on reliability in a massive way due to android studio and never really performing well at its core function, writing software, compared to things like sublime, vscode, even vim/emacs; once configured.

and if I'm going to pay for something like an IDE it needs to be rock solid when the free competition is competent.

see this might be the difference I don't distinguish between intellij and its various spin offs. Most of my interactions with its ecosystem have been through Android Studio.

and it was so horrible I won't touch the others for any length of time. I also havent developed in java for over a decade until recently (for work, only touch java if you pay me).

no I want my IDE to be functional without destroying my system performance or fucking up my codebase. jet brains is a massive offender here. it doesn't need to be. I have a giant machine ~128GB of RAM and 24 cores. the fact I have to tune my IDE is insane.

the not helpful issues with jetbrains are when it crashes, slows down my system, prevents me from modifying files because reasons, modifies my build configurations in unsafe ways because it thinks it knows best, interferes with CLI run commands because it doesn't safely check that it can modify files owned by other applications.

I'll grant you these are generally issues with the individual plugins within jetbrains. why deal with all that when I don't have to? Why deal with the performance issues the JVM has when I don't have to?

vscode I get autocomplete, debuggers, decent linting, decent performance. that's an IDE in a nutshell. not a text editor.

I'm happy you enjoy JB, great. it doesn't change any of the above and havent seen any indicators that the above has changed or will change in the future for it. hence I don't use it.

fleet may be promising in this regard. but don't feel the need to jump ship when I already have remote code editing in vscode. which is the only real first class feature fleet has to distinguish itself from other IDEs.

it was primarily android and gradle issues honestly within its jetbrains IDE.

jetbrains itself has performance issues, and you need to muck around too much to get them working properly.

the JVM also causes issues resulting it having to tune the environment params to get decent performance. JB makes tons of assumptions and attempts to be helpful in ways that just are not; precompiling automatically, running massive indexing jobs causing the machine to bog down, assuming it has the right to modify your environment.

these are all things I just do not want to think about when in essence I'm navigating directories and editing files with fancy hover tooltips.

the standalone versions are okay usually depends on the language. I just want an editor with code linting regardless of the language.

vscode in that respect has been a god send. install language server and you're done. performance is generally good and the background tasks seem thus far havent completely bogged down my machine.

there also isn't a reason for them to use it xwayland works fine for the usecase.

I hope they support wayland natively but its just not necessary atm.

thats funny I've always found jetbrains IDE to be error ridden annoyances where I end up spending more time dealing with problems the IDE has caused than developing software.

> Granted, that's how easy it is to properly check JS code for whether it does something sensible

> especially because issue categorization and accuracy was so random

Stockholm syndrome is strong with this one. =)

the reason you didn't find the IDE suggestions helpful is exactly because of how difficult it is to reason about dynamic language code. the tooling is basically just guessing and expecting you to deal with the noise on the off chance it found something.

because the lack of a type annotation via introspection makes tools automatically generating code for your less than useful.

> Have you followed this very thread?

indeed i am, people seem to having issues dealing with the reality of the two languages. One (golang) the problems you encounter with its GC are easily remedied using memory pools or adding compute. The other? you don't really have a choice without fighting against the language itself. or relying on improvements to the GC itself. which is precisely why java has had to spend so much effort on their GC to reduce latency while golang has been able to achieve extremely similar results with a fairly straight forward concurrent mark and sweep.

> Hardly a good thing for throughput-oriented applications.

add more compute. problem solved. its extremely rare to have situations where you can't add more compute to the problem. that's the point. you can easily solve throughput issues with compute. you can't solve latency issues as easily. if your STW GC pause ends up being 30s+ you're fucked. period.

if you're GC is the source of the problem because of garbage generation, generate less garbage. in go that's generally very easy. in java its very much not.

>beat Go by a huge margin, due to its more advanced GC, see:

you mean the advantage that entirely disappears with a memory pool added in like 4 lines of code? doesn't sound like a huge margin win to me.

I've never once asserted java's GC isn't amazing for the problem its solving. I'm asserting its completely unnecessary in golang because golang allows avoiding the garbage to begin with.

you: 'JAVA GC IS AMAZING COMPARED TO GOLANGS!' me: 'who gives a shit in practice golang memory allocation problems are trivial to resolve'

its the in practice of dealing with reality of the two languages I care about not the self inflicted problems java forces on developers.

rolls eyes I've tuned java's GC for highly available and massive throughput systems.

pretty familiar with the trade offs. java's problem isn't GC (in general) its problem is memory layout and the fact it can't avoid generating a metric shit ton of garbage.

G1GC was a good improvement and I stopped paying attention at that point because I no longer had to deal with its problems (left the ecosystem).

I'm not asserting java hasn't improved or that its GC implementations aren't modern marvels. fundamentally they're just a self inflicted wound.

golang wouldn't benefit anywhere near as much as java has from these implementations because guess what... they've attempted GC that operate under similar assumptions, young allocations, compacting patterns, etc. and they failed to make an improvement that just increasing the heap size knob wouldn't fix using the current GC.

depends on the compiler and language. golang seems to counter point your position quite handedly. having one of the fastest compile times and being highly concurrent.

if your application is so simple it doesn't use concurrency then 99% of the time you can completely remove the need for GC by preallocating slabs.

this is entirely BS. if by complex you mean overly abstracted and useless boilerplate then yes. java is larger and more complex.

and your assertion about the runtime only being able to do so much is just wrong here. golang will slow down your application in order to meet GC deadlines.

however its incredibly rare to see GC STW pauses for longer than 10s of ms. not even sure its possible given how the GC is written. this is true for heaps in the 100s of GBs.

this is why you don't hear about issues with golangs GC since like ~1.7. it just doesn't show up in 99% of use cases.

your basic assertion that java's GC is more advanced and therefor better is completely without merit. GC doesn't operate in isolation. java has more complicated GC systems because the language mandates them. golang entirely sidesteps the issues java has requiring said systems with better memory layouts and utilizing the stack.

its incredibly rare to hear stories about golangs GC because its simply not a problem.

java still has a bunch of issues and requires different GC tradeoffs as a result. meaning java will likely be in a constant state of 'which GC model do I use'

i've literally experienced worse pauses from java (sometimes surpassing 30s) GC due to allocation. granted it was pre the latest G1 GC. but they absolutely exist and many companies run on older versions of java.

and I doubt you see pauses in golang longer than 30ms. proof please.

that was never an issue? maybe your thinking of the slowness golang had in returning memory to the OS? that was resolved.

yes. golang is actually less restrictive than java. and avoids a ton of the bullshit abstractions you see in every java code base.

you can fix throughput problems by adding compute resources, you can't fix latency issues. I'll always pick a GC that optimizes latency over throughput. its easier to maintain the software.

throughput can be fixed by adding compute. latency cannot. always optimize for latency with gc.

and no the heap will not keep growing in golang. it'll force threads to help with GC if its falling behind. thereby reducing the rate of allocations and speeding up the collection.

you know what other group of humans are ineffective at their jobs?

every... single... one... corporations/government doesn't fucking matter. group of humans working together? inherently inefficient.

the role of ISPs are not to act as your firewall. that's your routers job. NAT does nothing to increase that security realistically since most routers are closed by default to inbound connections.

NAT as security is purely in the corporation realm of usefulness and afaik IP6 supports NAT just fine. it just wouldn't be a fundamental requirement for the internet to even exist.

doesnt really work. people don't necessarily park near their apartment. thats the point.

facepalm the assumption being made in my statement is that the individual cell can support the same charging rate.

my understanding was it was the chemistry of the cells that impacts the charging rate, not the physical size. happy to be wrong on that though.

scaling has mean dimensions. whats best for energy density may not necessarily be best for charging rates.

hardly disinformation. vaccinated individual are less contagious, tend to clear their system of the virus faster, etc.

are they still potentially vectors? yes. could the virus still potentially mutate? yes.

is the chance of either of those happening greatly reduced? absolutely. so relatively speaking the vaccinated are walking bioweapons in comparison.

those are implementation details around the particular batteries. which is fine. nothing I said is absolving us of physical requirements. my point was entirely the system itself as a whole.

there are a number of ways to pluck the chicken. smaller more numerous cells -> same power, faster charging due to concurrency.

point was if your cable can't supply the power the entire point is irrelevant.

go is incredible for distribution. you're distributing binaries not a bunch of source files.

now the build tooling still needs some work around versions but its only a minor problem generally as much as it annoys me personally.

the fact that people think tires matter in a comparison between EV and combustion engines is hilarious. 'these things both have tires, clearly EV is worse as a result.' facepalm

there's a huge amount of power being transferred into your home too. it really isn't a problem to do safely.