First request latency also can really suck in Java before hotpathed code gets through the C2 compiler. You can warm up hotpaths by running that code during startup, but it's really annoying having to do that. Using C++, Go, or Rust gets you around that problem without having to jump through the hoops of code path warmup.
You can create a native executable with GraalVM. Alternatively, if you want to keep the JVM: With the ongoing project Leyden, you can already "pre-train" some parts of the JVM warm-up, with full AoT code compilation coming some time in the future.
And going the other direction, if you want your C++ binaries to benefit from statistics about how to optimize the steady-state behavior of a long-running process, the analogous technique is profile-guided optimization (PGO).
GraalVM is terrible. Eats gigabytes of memory to compile super simple application. Spends minutes doing that. If you need compiled native app, just use Golang.
I used to be really excited about GraalVM but this, together with limitations in what Java code can run (reflection must be whitelisted - i.e. pain) made me run away from it. I do use Go, but my favourite substitute for Java is actually Dart. It can run as a script, compile to a binary or to a multiplatform "fast" format (a bit like a jar), and performance wise it's par on par with Java! It's faster on some things, a bit slower on other... but in general, compiling to exe makes it extremely fast to start, like Go. I think it even shares some Go binary creation tooling since both are made by Google and I remember when they were implementing the native compiler, they mentioned something about that.
I worked on JVMs long ago (almost twenty years now). At that time most Java usage was for long-running servers. The runtime team staunchly refused to implement AOT caching for as long as possible. This was a huge missed opportunity for Java, as client startup time has always, always, always sucked. Only in the past 3-5 years does it seem like things have started to shift, in part due to the push for Graal native image.
I long ago concluded that Java was not a client or systems programming language because of the implementation priorities of the JVM maintainers. Note that I say priorities--they are extremely bright and capable engineers that focus on different use cases, and there isn't much money to be made from a client ecosystem.
AOT is nice for startup time, but there are tradeoffs in the other direction for long tail performance issues in production.
There are JITs that use dynamic profile guided optimization which can adjust the emitted binary at runtime to adapt to the real world workload. You do not need to have a profile ahead of time like with ordinary PGO. Java doesn't have this yet (afaik), but .NET does and it's a huge deal for things like large scale web applications.
Java definitely does have that, although maybe not in the most commonly used JDK distributions. E.g. companies needing ultra-low latency even before the first request, would use Azul JDKs like Prime (paid), pre-train the profile in non-production environments, and then use it in production on new version deployment.
Gaming the JIT just to get startup times in line is a decent sign that Java's "fast" comes with invisible asterisks all over prod graphs. At some point you're managing the runtime, not the app.
AOT options like GraalVM Native Image can help cold starts a lot, but then half your favorite frameworks breaks and you trade one set of hoops for another. Pick which pain you want.
I challenge the idea that first request latency is bottle necked by language choice. I can see how that is plausible, mind. Is it a concern for the vast majority of developers?
This is why I use java for long running processes, if i care about a small binary that launches fast, i just use something slower at runtime but faster at startup like python.
They do, to add to another comment of mine elsewhere, JIT caches go all the way back to products like JRockit, and IBM JVM has and it for years in Maestro, now available as OpenJ9.
Too many folks have this mindset there is only one JVM, when that has never been the case since the 2000's, after Java for various reasons started poping everywhere.
My architecture builds a command registry in Clojure/JVM which runs as a daemon, the registry is shared by a dynamically generated babashka (GraalVM) shell that only includes whitelisted commands for that user. So for the user, unauthorized commands don’t even exist, and I get my JVM app with no startup overhead.
the best way is via CRaC (https://docs.azul.com/crac/) but only a few vendors support it and there’s a bit of process to get it setup.
in practice, for web applications exposing some sort of `WarmupTask` abstraction in your service chassis that devs can implement will get you quite far. just delay serving traffic on new deployments until all tasks complete. that way users will never hit a cold node
start time generally isn't a huge concern for web applications (outside of serverless) since you've got the existing deployment serving traffic until its ready. if you're utilizing kubernetes, the time to create the new pods, do your typical blue-green promotion w/analysis tests etc. is already a decent chunk of time regardless of the underlying application. if you get through it in 90 seconds instead of 60, does that really matter?
I really hate how completely clueless people on hn are about java. This is not, and has not been an issue for many many years in Java and even the most junior of developers know how to avoid it. But oh no, go and rust is alwaayssss the solution sure.
Crac / aot cache / ready now all can address this. Not even considering native aot. Multiple low latency trading systems across market markers, hedge funds and ibs prove this. But people just want to compare it to building a cli tool in go or rust.
But like can you provide an actual example of an application?
> But people just want to compare it to building a cli tool in go or rust.
This seems like the key. HN is definitely biased towards simpler, smaller tools. (And that's not a bad thing!). The most compelling JVM stories I hear are all from much larger scale enterprise settings.
Kafka being a good example. It's very good at what it does, but painful to manage and usually not worth the pain for anyone who's not in a mega enterprise.
Because in real life, real world applications software is large, long running and needs to be bulletproof. Clis are not powering the world's infrastructure via piped bash scripts. It really baffles me what people actually do as software engineers on here with some of the nonsense that gets thrown around.
Not the GP, but for really large code bases, Go is missing a few features that I've noticed:
1) No immutable types. My work team is a huge user of immutable data stuctures in Java to make sure data passed around to other teams isn't changed. Go doesn't really have a good way to do this.
2) Refactoring can be really annoying (or at least really noisy) because of public/private being defined by capitalization of method/field names.
3) Error handling isn't great. I love Go's errors being just normal values, but the `error` interface is awkward when trying to figure out what kind of errors can be thrown without having in-depth knowledge of the kinds of errors that can be returned. We regularly need to make different decisions depending on the kind of error returned. Knowing which errors can be returned in Go is not defined by the method being called (only in comments).
This is not a dig at Go and this will be controversial but I so struggle to see what problem or area Go is solving outside of CSP. It's a nice language it just feels far too simple and I am really convinced of it as a systems language over Modern C++ and if you want that alternative then we have our rather oxidized friend that seems to more substantial. That's just my take.
I code Go at work. I've been using it for just over 3 years. I really like it. I prefer Java, but Go is a much more ergonomic C and its a very pragmatic language. Except for the *%!@ error system, that can burn in hell.
> However complex error recovery is an anti pattern for Go.
Bit of snark from my side, but that's exactly what makes it less good of a fit for "industry purposes".
Go's error handling is possibly the worst out of any "modern" language, it basically copied C's errno which is not something you should have ever done.
This was exactly my experience when I first read about Go. I was so excited until I found they were repeating the c experience of check every bloody return value separately. That was the worst feature of c - why copy it
Because almost my definition you can't handle errors in the component, otherwise you would have a conditional and not an error.
E.g. if I do some IO like "make a copy of these files" and get an error/exception, it's only the caller or maybe even that caller's caller that can properly deal with this condition (e.g. to decide that we will skip the erroneous files or retry).
Hey it's better in Go. In Java it's getFoo(). In Go it's just Foo(). Saves three bytes, and three keystrokes if you program by hand and don't autocomplete!
That's the policy being followed here. If you remember back a few weeks, Iran killed likely 30,000 of its own citizens. On top of that, they will not negotiate about medium and short-range missiles or stopping of nuclear production.
A power like that that happily goes after it's neighbors, directly or indirectly is a threat to everyone.
Applying those particular criticisms to Iran and not Israel is a special kind of irony given the past ~75 years (but especially the last 2-3), and when the latter is presently attacking the former unprovoked.
Islamic Republic sees itself as a vehicle to spread Islamic revolution around the world.
Just listen to their internal rhetoric, watch who they find and why, and it is clear. However, since it’s Trump who is bombing IR, people will defend the IR regardless of what the IR stands for.
> Smart features: Turn on smart features in Gmail, Chat, and Meet - When you turn this setting on, you agree to let Gmail, Chat, and Meet use your content and activity in these products to provide smart features and personalize your experience.
My wife turned this off because she didn't want typing suggestions or even grammar correction. After disabling the feature, she was much happier.
Wow, so US judges are just making it up as they go along, huh? It's like every case is a different judgement with no consistent criterion.
>Doe vs. U.S. That case centered around whether the feds could force a suspect to sign consent forms permitting foreign banks to produce any account records that he may have. In Doe, the justices ruled that the government did have that power, since the forms did not require the defendant to confirm or deny the presence of the records.
Well, what if the defendant was innocent of that charge but guilty of or involved in an unrelated matter for which there was evidence in the account records?
> With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
Prepaid credit cards tend to be a very common fraud vector (very similar to gift card scams).
For chargebacks, the merchant has to pay at least a $15 fee on every chargeback, regardless of the outcome of the result. It's why many merchants prefer for you to contact them and ask for a refund rather than going through the chargeback process. For small purchases, merchants tend to just refund rather than dealing with an angry customer that's going to charge back.
On the other hand, prepaid credit cards seem to be one of the only ways to prevent merchants from "running up" the charges on a customers account. Sure, a customer can go through the dispute process but it's quite a hassle. Just "limiting the amount of money you place on the table" is quite effective. Giving a merchant your credit card with say a $5,000 or more available balance seems like insanity, like laying out 50 of $100 bills on the table: "here, go ahead, can I trust you to take only what you should" ? I would pay extra to have a VISA or MC credit card that only offers say a $200 limit, just for dubious situations, but again, providers have a "conflict of interest" in that they only make their "cut" when the charges go through, so the more and the larger the charges - - the more "cut" they obtain.
A prepaid card doesn't prevent you from being liable for a bill. This is like how leaving your wallet at home when you visit a resteraunt doesn't entitle you to free food because they don't charge you up front.
No but it significantly raises the effort for collecting said money. The company would need to have a strong case (that they need to be able to defend in court if necessary) to do it.
No scummy company relying on dark patterns/etc to charge the customer without their consent will dare potentially airing this dirty laundry in front of a judge.
I consider it immoral to dodge paying bills just because you can get away with it. This is like saying it's okay to shoplift because a store may not think it's worth it to go through the legal process to come after you.
I adjust my morals to match those of the entity I'm dealing with. I have no problems "stealing" from a company who is trying to steal money from me by sneaking in unexpected charges.
Nextgrid hit the nail on the head. If you are being an honest customer, but a company is attempting to "blackmail" you into paying bogus or "run up" charges like Google Adwords, which multiple reports indicate they are more than 70% bot generated hits, you can sue them in your local jurisdiction, here we have justice of the peace, small claims, force the big corp to hire local counsel.
Do they want to take it higher ? Taunt them with "dumping discovery on them", otherwise known as a far reaching motion for discovery, they'll be forced to deliver a tractor trailer load of paper . . .
With all due respect, historically, the guy with the greenbacks holds the upper hand in any deal. Many abide by the rule: “The customer is always right”.
Internet merchants often with unrealistic low pricing to “bait you” are attempting to sway the balance in their favor by cutting corners, eliminating posting a telephone number answered promptly by a live human being, too often sending out “one way” do-not-reply emails, which is shameful. Recently I encountered a tactic whereby a large corporate health care company would ONLY discuss matters over a phone call, so unless you were recording the conversation (and provide proper legal notice of such at beginning of call) there was no record of the conversation (now internet providers like Spectrum are doing the same). In fact, they were attempting to force me to sign a 30+ page contract full of legalese and “boilerplate” in their doscusign pdf format which coincidentally disallows one from modifying or typing in any disclaimers within the signature line. They refused over multiple communications to respond to several of my questions regarding costs and any future billing. I finally just stonewalled them by saying I would only communicate via email so there would be a written record.
I can regularly obtain a live human on the phone with Amazon and have always received a favorable response - - - obviously Amazon values their reputation. I personally will not do business with any company that fails to provide a telephone number answered promptly by a live human.
Often I buy locally from brick and mortar shops with return policies in the event the product doesn't hold up to expectations. The somewhat higher prices I pay at brick and mortar are just “added insurance” that doesn't even compare to the serious disappointment or anger one experiences from some internet purchases where the seller sent a fake or missing GPU card, or the item coming from China has no reasonable cost of shipping it back “hoping” for a refund, or even a US merchant who refuses to honor a valid return. Now that memory prices have exploded, I expect to see even more of these fake or missing GPU shipments from online sellers.
Having been a former cc merchant, I know that any merchant that receives a chargeback will suffer at least a $35 hit, plus more on the time and effort to respond and fight the chargeback, indeed I encourage all buyers to challenge any that we discover dishonest. Merchants getting enough chargebacks will suffer the company providing the merchant account cancelling their business merchant account, often the merchants are are then “blacklisted” in the cc industry.
Chargebacks or disputes will lock your account, so definitely stay away from that path.
But just closing the bank account will stop auto billing (it's considered a decline). So if you closed the account, it would just stop paying for whatever it is, and then cloud may lock the gcp account until it's paid. (I'm not 100% sure what cloud does with unpaid invoices).
You've never tried to free-range raise your kids then. Some friends in our neighborhood had the police called on them for riding their bikes around the block, and the cops followed the kids back to their front door and then talked with the parents.
I wish Java had a proper compiler.
reply