bloomthrowaway

It's the default because in any garbage collected language you can delay taking out the trash as long as you want... as long as you have memory. The most efficient thing to do is never run the collector at all.

JS does frequent GC cycles because its unacceptable to let a webpage eat all the ram. Not sure why Go collects so frequently. Java's default IMO is the most reasonable of the three. If you have a server with 4gb the best choice is to let the garbage collector use all of it

It should be able to... Hopefully Go and Java will be some of the first GC languages to target WASM, and we'll find out :) . Personally I'm more worried about the size of the GC getting added to the binaries than how fast it is.

I'm really excited for WASM, it should be nearly as fast as native code. Java and native code aren't far apart though, so I would say 1.5-2x faster generally

>Slowness isn't a property of the language it's a property of the runtime

This is true to an extent, but look at the time and money poured into PHP and how slow it still is after all these years.

Language design choices have a huge effect on how fast the runtime can be. In Javascript, objects are stored as a map of key->value pairs, and aren't strongly typed. This design requires more overhead for type checking and many optimizations used by strongly typed languages won't work. Even in toy benchmarks its clear that Java has a performance lead https://benchmarksgame-team.pages.debian.net/benchmarksgame/... . It's slower than java on every test.

You don't see the memory difference because these toy benchmarks don't allocate much. Node/JS will always use more memory for storing objects, sometimes far more because it isn't strongly typed. In Java, an array of ints will use 32 bits * size plus some fixed bytes. In Javascript, each item in the array can use 2-3x the max "size" of the number, because the runtime can't figure out what type it should be.

Nice! I think it may be slightly out of date though. For example, you don't need Tuples library if you use Apache commons because it has Tuple support. Also, Javaslang has been renamed Vavr. Still a solid article though

VS Code support for Java ain't bad

> Concern 5: Java is too slow/consumes too much memory

It's sad that this is still a thing. Compared to more trendy languages like Python and Javascript, Java is very light on memory. JS is known for being fairly fast and "light", but its actually 5-10x slower than Java and uses 5-10X more memory. And the whole "lightness" of it is a lie. Javascript's run-time is probably bigger and more complex than the JVM.

Java used to be painful, but there's a ton of tools that make it easy to use if you know where to find them. Some, like Lombok, get rid of a majority of the "cruft" by enhancing the language itself. Awesome Java is a treasure trove of useful stuff. https://github.com/akullpp/awesome-java

The combination of speed, flexibility, and robustness can't be found anywhere else, Although Go is slowly catching up.

maybe, but its cleaner in other ways. It burns hotter and more efficiently, creating less CO2 and some other byproducts by a decent margin. It produces more SO due to fuel sulfur content, and more NOX which is produced because of high temperatures. So its a trade-off.

But at this point the limits are just politicians pulling levers. There's not enough science involved to debate which pollutants we care about and what the lowest realistic limits are.

In the auto industry its generally understood that the emissions limits are so low, especially for diesel, that its physically impossible to meet them in some situations like cold engine + cold weather and when driving up grade.

Emissions regulations have made great progress in cleaning up auto emissions, but now politicians keep squeezing the numbers without realizing some of the limits are becoming impossible. So everyone starts cheating, because otherwise we would have no combustion powered cars.

Insane irony is that ships and even some buildings burn horrifically impure "bunker fuel" or wood, and with car emission limits so low these sources are the vast majority of harmful emissions. Its like cities in Cali forcing citizens to make drastic changes to conserve water, when over 90% is used by farmers.

I wouldn't do it. You should split your services out of necessity, not as a design pattern. Service meshes are also quite immature at the moment and basically guaranteed to give you lots of pain. Inter-service communication adds a ton of complexity and isn't a totally solved problem. The biggest issue is distributed transactions.

Say you have a service that updates two others within the same call. A write "fan out". What happens if one of the writes succeeds and the other fails? Since they don't share the same transaction boundary you need to implement rollbacks yourself. One for every single call you fan-out to. For writes to two services you need to write two rollback mechanisms to handle cases where either call fails.

But it gets even worse. What if the service doing the fan-out dies when its only made one of the two calls, and that first call succeeds? Well now you have no way to rollback, so the next step is to persist "fanout status" to durable storage as each call succeeds.

But it gets worse still... What if you get a service loop? So you write to one service which writes to another and that third service asks your service something all within the same call. WTF is the global view of data consistency when this happens? There isn't one, its undefined behavior.

If you go down this rabbit hole far enough you end up writing your own global database to synchronize everything. The proper way to do "microservices" is to share a datastore so it can handle the transactions and rollback for you. But once you share a datastore, why not just build a monolith that can horizontally scale easily?

I get that some companies are writing services with their own datastores, I've worked on several of these projects myself. They have all been a data consistency nightmare. Write your services like Google does, "monoliths" running hundreds or thousands of instances all connected to the same database that scales in the same way.

I don't mind threads when they're done right. Every Java app server is multi-threaded and I don't remember the last time I ran into deadlocks. It's best for performance and readability to have both threads and async support. This is achievable with some work in Java by using Comsat/Quasar

I don't like Javascript at all, even with all the linters I could find its too easy to make mistakes. Too many old broken language constructs they can't fix. Java's strongest sell has always been an extremely reliable platform, strong typing, and solid standard libraries, things I also can't say about JS.

Typescript on the other hand is glorious. My favorite language now. Fixes all the issues with using JS for large applications besides flaky libraries. I still don't think its ready for server-side development, not until they add threads (WTF is taking so long). When you're running on a 32 core system node doesn't make any sense.

Yes, I know there's various workarounds like launching multiple copies of your app, but that still limits parallelism on the app level and its pretty lame.

> - Python: as a first language of choice replacing Visual Basic or Java.

I don't see this happening in practice. Python has taken over the niche of Perl/PHP/Ruby/Bash almost completely but traditional uses for Java are hardly touched.

VB is dead, the only thing out there right now that seems like it may replace Java is C#.

Scala gets a bad rap from most JVM devs, but Kotlin may be a contender for Java replacement on both mobile and desktop.

Top earners? Likely to stay Java and C/C++ because they're not going anywhere and they're harder to learn than most languages. Maybe Swift for a while too because less people know it (because its Apple specific)

multiple hash functions only exist because they don't use secure hashes (for speed reasons) so there's collisions.

Normally for passwords you would use a secure hash, negating this

you're right, although I don't think compression would save a ton of space since the hashes are random. Might save a bit or maybe 2 per entry

Bloom filters don't do anything special to change FP rates, a compact list of random hashes is always more efficient than using a Bloom filter until the filter is 100% full

its the same structure as a Bloom filter but more efficient because it has no empty slots

you can compress it by just truncating the hashes as short as you want

If you use a secure hash on the banned passwords they will be random (as good as arbitrary), then just truncate them to 7-8 bits and sort by prefix, searching them using binary search. It will be more efficient than a Bloom filter because there can be zero empty space between entries. It creates a structure similar to a Bloom filter but with no wasted space (no empty entries)

A Bloom filter is great when you need a probabilistic hash table that is fairly efficient and can have records added efficiently.

With a fixed list as I described above, the insertion cost is enormous (avg cost of moving 1/2 of the array elements), but the space/speed efficiency reaches the theoretical limit

Sorry to say this, but this is actually worse than just truncating the hash.

Why? Bloom filters are designed to maintain a reasonable false positive rate while still allowing you to add items extremely quickly (high insertion rate).

Since the bad password list is presumably fixed (or almost so) you can do checks faster and with a lower FP rate by just truncating the hashes and prefix sorting the list ahead of time.