fzeindl

Maybe they found AGI and it is now controlling the board #andsoitbegins.

Have you ever read up on communicating sequential processes? In that model you have one or multiple threads executing work while new messages arrive on a queue. In such an architecture handling signals is trivial.

This is not exactly what you are asking for but a very nice explanation and it tries to work without math as long as possible https://www.bzarg.com/p/how-a-kalman-filter-works-in-picture...

Well I shipped fat jars using capsule more than 15 years ago without any issues. Nobody ships file-trees.

Also the Startup depends on how much memory you allocate, but much of it is due to verifying class security, a feature that other runtimes don't even have. Or badly used reflection, another feature others don't have.

In any case I really never found it an issue if a server takes 3 seconds to start and I never understood why people complained about Java startup. My guess is they complain about clunky desktop application with a million classes written in it.

Regarding the bytecode: the interpretation and just in time recompilation gives Java sometimes better than native performance.

It also allows you to hook into the code on the fly and transform it with agents. Can native do that?

This is correct but not because of Java. The android SDK is terrible because of many reasons.

Which is also the reason why kotlin is so popular there. Using extensions function and concise syntax you can build clutches around this terrible abomination of an SDK.

The JVM uses as much RAM as you allocate in your program. If you get along with 4 megabytes then you can set the maximum memory of the JVM to 4 megabytes and it will never use more than that.

Which Java baggage do you mean?

The JVM is one of the most optimized, most performant, most monitorable, most secure and most predictable software-runtimes there is.

How exactly do you consider it a big disadvantage?

Kotlin is a much more likely candidate. Excellent IDE support, deep integration with Java, already the go-to language for Android, many years of production and less "different" than Rust.

I find XML tool in general feature complete and great.

Especially editor integration works great as opposed to YAML which is so ambiguous that it IntelliJ IDEA constantly breaks indentation during copy and paste.

Just dropping the tip here:

xmlstarlet is a great tool if you want to query xml on the commandline using xpath or do some xslt transformations.

Similar to jq's utility for processing json.

Is there anything, maybe a legal agreement, that can stop google from breaking this promise in three years?

They are not famous for longterm project management.

> Don't scale for millions of concurrent tasks when you're only looking at a couple dozen max, no matter what language or environment you're in. Very common problem for programmers this decade.

And also with fibers/virtual threads (project loom) you can actually have a million threads using blocking hand-off on one machine. So the performance argument is kind of gone.

> As fun as it is to hate on JavaScript, it's really interesting to go back and watch Ryan Dahl's talk introducing Node.js to the world

Agreed. JavaScript was actually my first language after TurboPascal in 1996.

I was also there listening to the first podcasts when node came out.

JavaScript is a very interesting language, especially with it's prototype memory model. And the eventloop apart from the language is interesting as well. And it's no coincidence Apple went as far as baking optimizations for JavaScript primitive operations into the M1 microcode.

But I still think multithreading is best done by using blocking operations.

NIO can be implemented on top of blocking IO as far as I know but not the other way round.

Also, sidenote, I think JavaScript's only real failure is the lack of a canonical module/import system. That error lead to countless re-implementations of buildsystems and tens of thousands of hours wasted debugging.

Async Everything is a bad language.

Async/await was a terrible idea for fixing JavaScript's lack of proper blocked threading that is currently being bolted onto every language. It splits every language and every library-ecosystem in half and will cause pains for many years to come.

Everyone who worked with multi-threading outside of JavaScript knows that using actors/communicating sequential processes is the best way to do multi-threading.

I recently found an explanation for that in Joe Armstrong's thesis. He argues that the only way to understand multi-threaded programs is writing strictly sequential code for every thread and not muddling all the code for all the threads in one place:

"The structure of the program should exactly follow the structure of the problem. Each real world concurrent activity should be mapped onto exactly one concurrent process in our programming language. If there is a 1:1 mapping of the problem onto the program we say that the program is isomorphic to the problem.

It is extremely important that the mapping is exactly 1:1. The reason for this is that it minimizes the conceptual gap between the problem and the solution. If this mapping is not 1:1 the program will quickly degenerate, and become difficult to understand. This degeneration is often observed when non-CO languages ["non concurrency-oriented", looking at you JavaScript!] are used to solve concurrent problems. Often the only way to get the program to work is to force several independent activities to be controlled by the same language thread or process. This leads to a inevitable loss of clarity, and makes the programs subject to complex and irreproducible interference errors." [0]

[0] https://erlang.org/download/armstrong_thesis_2003.pdf

There is also a good rant against async/await by Ron Pressler who implemented project loom in java: https://www.youtube.com/watch?v=oNnITaBseYQ

That is your opinion. We will see what the courts say to Meta and Amazon.

It is enforced internationally just like copyright law. It is a law for EU users no matter where their data resides. Meta was fined 1.3 billion dollars in spring for GDPR violation.

Kotlin all the time, for these reasons:

* Nullsafe typing.

* Nullsafe typing!

* Inline extension functions for existing APIs. These are supremely useful. You can write features like locking and unlocking around a block, or try-with-resources in a one-liner, without compromising performance.

* (Nested) When statements, if-else as expression etc.

* Reified generics. You can actually write: "if (xy is T)" or use T::class

* Nullsafe typing

* Data classes

* Getter/Setter syntax as property and indexing syntax.

* Only unchecked exceptions

Kotlin really is Java 2.0.

I am glad to hear that you use 3-week sprints. 2 week sprints are too short, yet everyone uses them without questioning.

There's a good article by the author of tachyons.css which is similar to tailwind, but never got that much attention: https://mrmrs.cc/writing/scalable-css/

It seems that the main and only problem "solved" by SCRUM is the awkward situation where a freelance-team or solo developer happily present the result of their (web-, ux-, app-)implementation that took them half a year, the customer realizes they wanted something else and both are angry at each other.

So now SCRUM has a feedback cycle that prevents that from happening.

It makes sense for UX and interaction-heavy parts, but not at all for systems and backend programming, which are much harder to divide into a workable backlog.

> There is an element of practicality for very long-term maintenance if you run i.e. VMs off a different storage layer.

That is very good advice. I know about a datacenter outage/degradation in a very large company, which all of you know.

A couple of network switches got overloaded. The switches connected the SAN to the VMs, so it caused all kinds of weird problems in different applications.

> start owing 24.99%+ APY

Why that specific number in your example. That looks like a supermarket price tag. Is that common in the US?

> “Our memory is slow, so let’s redraw only things that changed” is kind of a given nowadays.

Tangentially related: Android still doesn't get this. Turn on the screen refresh flashes in the developer menu and then look a your static screen and be amazed who often android draws even though nothing changed.

This issue of having the answer in the comments definitely wasn't there 5-10 years ago and makes the site much more difficult to skim and read hence provoking more hapless questions.

Maybe they should expire comments or remove them alltogether.

I looked it up now.

"In the libet Experiment, Libet asked subjects when they felt the intention to move, he asked them to watch the second hand of a clock and report its position when they felt that they had felt the conscious will to move.

Libet found that the unconscious brain activity leading up to the conscious decision by the subject to flick their wrist began approximately half a second before the subject consciously felt that they had decided to move."

<--- the bug could be chronostasis. They subjects perception of time is warped when looking at the clock.

I have heard about that experiment too and I am now pretty sure it can be explained by chronostasis https://en.m.wikipedia.org/wiki/Chronostasis

I have written quite a bit about this in my blogpost https://www.fabianzeindl.com/posts/the-codequality-pyramid

Also check out this study which links software quality to deviations in estimation: https://dl.acm.org/doi/10.1145/3524843.3528091

The LMax architecture: https://martinfowler.com/articles/lmax.html

Also read up on branchless programming, lock-free data structures and avoiding heap-allocations.

> It’s crazy to me to think someone actually thought using step functions and lambdas in this way was a good idea.

Maybe Amazon used this to test step functions and lambdas.