At this level they can just go bare metal or colo. Use Hetzner's pricing as reference. Logs don't need the same level of durability as user data, some level of failure is perfectly fine. I would estimate 100k per month or less, maximum 200K.
Google was moving to vector rendering instead of static images for Google Maps, which uses a lot less data, so Apple wanted that. Google in turn wanted a lot more data from Apple about the user making the map requests. Apple didn't want to give Google more user data, and Google would't give Apple the better map product without it.
So Apple pushed ahead with their own maps instead, hoping that they'd be good enough to keep people from wanting Google Maps, which ... didn't pan out. Instead, Apple was forced to allow Google Maps in the app store, since their own maps weren't good enough, and people were complaining. So in the end, Google got the data, since lots of people use Google Maps instead of Apple's maps.
And in the long run it worked out fine. Apple Maps is a totally adequate product today despite being inferior to Google Maps for many years. Now we at least have some choice!
I mean, forcing Apple to allow a choice absolutely worked out for people. Apple Maps is decent, but I still generally prefer Google Maps. But iirc they both added my #1 desired feature, which is showing where traffic lights are.
Unfortunately these pushers were not strong enough to get Java to add null-safety. "Everything can be null" is the by far biggest daily headache of working in Java codebases.
JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.
If you properly handle not returning/using nulls in your checkstyle rules and don’t allow nulls to be deserialized anywhere (forcing the use of Optional), then you can pretty much eliminate NPE.
I can’t remember the last time I encountered one by using the proper compile time checks. It does need to be enforced organization-wide, and not partially with annotations, but if you can make that change then you can code in Java without the mental overhead of null.
Does no good when interacting with the standard library, where things like collection methods return null for "not found". All that discipline and organization you're talking about? That's a compiler's job, and if it won't do so, I'll find a language that does. I don't spend much time griping about Java these days though, because I've had many such languages in my arsenal for some time now. Ironically in most of them I use null quite freely because it's now a distinct type and no longer a landmine.
Usually you’re using a lot of Optional and Streams, so the collection method returns null inside a .map() and you don’t need to think about it.
To be clear, it is handled by the checkstyle rules at compile time, so you won’t accidentally forget.
Inputs to standard libraries will obviously never NPE if you pass in a non-null value.
For outputs, a lot of standard collection .get() calls are unnecessary when you’re working with small collections or Optionals, where you simply use stream, filter, ifPresent.
Or simply wrap the return with Optional.ofNullable, checkstyle will not accept it if you don’t.
Yeah, if you have perfect dilligence, you can work around many language's weaknesses. But we're in an imperfect world. It's not easy to influence my coworker's code style and impossible to do with other teams or people who worked on my projects in the past and left since, yet I still have to work with their code.
> then you can pretty much eliminate NPE.
NPEs is only one kind of cost incurred by the lack of null safety. The other is all the unnecessary "if (x == null) {" boilerplate code caused by the uncertainty and defensive programming, which increases complexity and worsens readability.
Java's stated design philosophy since way back is to let other languages experiment and then incorporate what appears to work out, thus being able to maintain an append-only change philosophy where everything is always backwards compatible. Kotlin is undeniably a source of inspiration, as is many other languages.
(This doesn't always work out, some bad API decisions[1] will likely haunt Java forever, some features are arguably a bit undercooked (e.g. exception handling in Stream:s), but given the constraints it's kind of remarkable how well it does work)
Checked exceptions themselves to me looks like an experiment which had no place in Java. I don't know language landscape in 1990, may be it looked like a good idea back then. But today: C++, JavaScript, Python, C# are few of the most popular languages which use unchecked exceptions.
May be one day Java will just retire this concept and make all exceptions unchecked. It'll be backwards-compatible change. Make `throws` clause cause deprecation warnings and that's about it.
Checked exceptions are an unfortunate case of a feature being rolled out in a language that wasn't ready to support it ergonomically and then becoming a pariah because of how bad the experience was in that language. There's nothing wrong with the concept—checked exceptions are conceptually the same as every function returning a Result type—but without type inference and without some ergonomics like Rust's ? operator they're really hard to work with and so people grew to hate them.
I personally believe that it is now within reach for Java to fix checked exceptions to be ergonomic and useful. If they do it, Java could have one of the best error handling paradigms out of any modern language, but I suspect it won't happen because the community has come to land so firmly against checked exceptions.
Making big feature and possibly breaking changes such as making checked exceptions ergonomic would only be possible if the original language designer - James Gosling decided to dust his sleeves, un-retire himself and lead the job. Now, its a distant pipe dream.
That’s true. But why would Java take inspiration from Kotlin, which adds very little new to the picture (scala has done basically everything before, let alone ML, from where most of the new features java (or any other modern language) copies originate from)
