pkolaczk

41 ms·

511.
by pkolaczk 5y ago
> Not in the case of a mark-compact collector, which works entirely in place, or a mark-region collector such as Immix [0], which only copies a small fraction of the heap. The mutator always allocates from a contiguous memory region. It
512.
by pkolaczk 5y ago
JMH is a standard tool we use for performance comparisons. For context, see Scala's battle with specialization to get reasonable performance of collection transformations. Once you start using lambdas to define e.g. a filter condition,
513.
by pkolaczk 5y ago
> Java is capable of all of these optimizations though In theory - yes. In my experience it just repeatedly does worse job than a C / C++ / Rust compiler, unless I'm very careful in Java coding (yes, I can often make it cl
514.
by pkolaczk 5y ago
> Most of them will get collected the next GC run as a young generation going out of function / block scope. Depends on the use case. Not if you're storing them in a long living collection. Also heap allocation is costly, even
515.
by pkolaczk 5y ago
Optional is only a part of the picture here. It also missed: * branch elimination with cmov * loop unrolling * SIMD vectorization * turning heap allocation into stack allocation All those things could be done without breaking any semantic g
516.
by pkolaczk 5y ago
The freedom to reference anything easily from any place is a double edge sword. I agree it makes 5% of hard issues go away, but on the flip side it makes the other 95% more complex. Tracing GC is a "goto" of memory management. You
517.
by pkolaczk 5y ago
> No, with RAII you still need to design your program around who owns each object, and thus who should clean it up With or without RAII you should design your program around who owns each object, unless you want to end up with unmaintain
518.
by pkolaczk 5y ago
Don't know how .Net, but many times I found that Java HotSpot compiler is weaker in optimisation strength than C, C++ and Rust compilers. For instance see this: https://pkolaczk.github.io/overhead-of-optional/ As
519.
by pkolaczk 5y ago
Most (all?) LSP implementations are open source. If the same effort they put into reimplementing the compilers went into making better LSP-based solutions, LSP would run circles around custom plugins, because LSP has accurate data from the
520.
by pkolaczk 5y ago
> Compiling and working code" does not mean it's valid or acceptable code. In safe Rust and Scala it means it is valid, modulo bugs in the compiler, which are rare. Also I'm really talking about code that is obviously ok -
521.
by pkolaczk 5y ago
It doesn't support LSP - that reads: it is not polished, or sometimes hardly even works for a bunch of languages that other IDEs and editors work fine with. BTW: I'm not saying it is bad or doesn't get the job done for a sele
522.
by pkolaczk 5y ago
> Doesn't this just means that IntelliJ, being an independent implementation, flags problems that a compiler frontend doesn't, and vice-versa? No, it often flags perfectly correct (compiling and working) code. Search for "
523.
by pkolaczk 5y ago
Why did you write Go would be a better alternative then? You say "no GC" as an advantage, but Go relies on GC.
524.
by pkolaczk 5y ago
They decided to code their own analyzers for some languages like Scala and Rust instead of relying on the support provided by the compiler frontend through the language server protocol. Result: Intellij idea has endless "good code red&
525.
by pkolaczk 5y ago
This idea does not work when you need a different comment on each line. You're obviously not going to commit each line of code separately. Also, not all code is being read in an IDE, and not all code is stored in git. The code may outl
526.
by pkolaczk 5y ago
Why do you think so?
527.
by pkolaczk 5y ago
The best way is to keep scripting out of build files. Build recipes must be simple, boring, reliable, and same everywhere. Gradle and SBT allow unlimited scripting and builds often end up as an unreliable mess. The more cleverness they put
528.
by pkolaczk 5y ago
A web browser is a huge and complex app. The argument it struggled with memory issues is moot if you can't show a comparably featured app written in Java to compare memory use. Anyways, I've got plenty of anecdotal evidence where
529.
by pkolaczk 5y ago
The total memory overhead of manual memory management can be virtually zero if you're careful enough to avoid fragmentation (and you can because it is manual, so you control a lot of details). There is for example no constant header fo
530.
by pkolaczk 5y ago
Wait, fragmentation is not included in that 6%. It is that a GC with no fragmentation will already suffer a 6% overhead. A region-based GC will suffer from additional temporary fragmentation on top of those 6% as well, because some segments
531.
by pkolaczk 5y ago
I don't know the exact reason here, but from my experience JVMs don't seem to perform optimisations as deep as static compilers. You can see the compiler not only missed scalar replacement here, but also didn't use a conditio
532.
by pkolaczk 5y ago
Right, using too dependencies don't make things simpler . They make them easier as long as the dependencies can do exactly what you need. However sometimes you come to a point where the dependency can't do something that's
533.
by pkolaczk 5y ago
Scalar replacement does not work even in very trivial cases: https://pkolaczk.github.io/overhead-of-optional/ In all those cases, Optionals were inlined, didn't escape, yet they haven't been properly optimize
534.
by pkolaczk 5y ago
That blog post is based on a silent assumption that software development cost is somehow lower for Python than for other "faster" languages. This is not what I observe in practice. I was not more productive in Python than I was in
535.
by pkolaczk 5y ago
Rune is pretty close, although it is dynamic ( https://github.com/rune-rs/rune ), Mun seems to be getting in that direction as well (and has a static type system!) but has fewer features ( https://github.com&#x
536.
by pkolaczk 5y ago
I feared macros initially, but when I tried I was actually surprised by how easy they were. Way easier than Scala 2.x macros.
537.
by pkolaczk 5y ago
C++ next version with lots of crap cut down is called Rust. ;)
538.
by pkolaczk 5y ago
> But you can write Java and C# in a more performant way while not sacrificing time to market, speed of refactors and maintainability. Writing Java in a more performant way often means ditching OOP and using primitive types, primitive ar
539.
by pkolaczk 5y ago
It is very easy to mess up signed with unsigned then - because they are the same static type. You have to put comments in the code to clarify the interpretation of bits.
540.
by pkolaczk 5y ago
Code that has too many indirection levels for no business purpose is bad, not good. Encapsulation is only good if it hides the things that the user of the code doesn't need to know. Loose coupling is not quality by itself - it can be e

More ›