My assumption is the poster wants to imply Oracle destroyed the good will and interest for people to start new Java projects after the licensing changes and subsequent shakedown. Java clearly still runs all over the place and will for a while (although plenty of people trying to keep java but get away from oracle).
The Java goodwill is mostly gone and I see zero new orgs trying it so while Java is still alive and well the mindshare has definitely been squandered given the capability that Java has.
Java is one of the giants and there are tons of existing and new projects that use it. Hotspot is the choice for high performance programs. Approaching its performance even with C++ requires a dedicated team of experts. Look at QuestDB, or Netflix, as current examples of projects choosing Java.
The languages that get a lot of airtime on HN like Rust, Go, and OCaml are way down in a tier of languages that get a lot of blog posts but enjoy relatively little traction in reality.
> Hotspot is the choice for high performance programs. Approaching its performance even with C++ requires a dedicated team of experts.
It's very surprising to hear you say this, as it's so contrary to my experience.
From the smallest programs (Computer Language Benchmarks Game) to pretty big programs (web browsers), from low-level programs (OS kernels) to high-level programs (GUI Applications), from short-lived programs (command-line utilities) to long-lived programs (database servers), it's hard to think of a single segment where even average Java programs will out-perform average C, C++, or Rust programs.
I hadn't heard of QuestDB before, but it sounds like it's written in zero-GC Java using manual memory management. That's pretty unusual for Java, and would require a team of experts to pull off, I'd think. It also sounds like it drops to C++ and Rust for performance-critical tasks.
It's a statement of my experience in the performance achieved in practice by real developers who lack dedicated language support teams. And even the ones who enjoy dedicated language support teams. I could point to gRPC. gRPC-Java is slapping gRPC-C++ sideways. Why is that? Because when a codebase is increasingly complex, the C-style lifetime management becomes too difficult for developers to ponder, and they revert to relying on the slower features of the language platform, like reference counting smart pointers.
I think hybrid implementations, where a project enjoys the beneficial aspects of the language runtime at large, but delegates small, critical functions to other languages, makes sense. That keeps the C, C++, or Rust stuff contained to boundaries that are ponderable and doesn't let those language platforms dictate the overall architecture of the program.
If gRPC overhead is critical to your system, you've probably already lost the plot on performance in your overall architecture.
You make a fair point about smart pointers, and median "modern C++" practices with STL data structures are unimpressive performance-wise compared to tuned custom data structures, but I can't imagine that idiomatic Java with GC overhead on top is any better.
The fact of the matter is that you read through a lot of these start up blogs on how they scaled X technology to some amazing number like 1000 users a day or whatever. But your average Java Spring app on Postgres is doing some far heavier workloads.
The languages that get a lot of airtime on HN are the ones the young people will just use by default.
Hotspot is the current choice for high performance programs, but is Rust lower performance in some way or are the only downsides related to its younger age?
It’s perhaps useful look at what languages brand new projects are being started with rather than just looking at what languages large established companies like Netflix are choosing.
Depends where you are, in startup world definitely yes. Elsewhere, not so much.
Companies couldn't care less about the underlying platform or language, they want reliability, stability and tons of easy to find people who can work with it from Day1. Java delivers all that, and will keep delivering for upcoming decades. Big businesses and big money love this (or hate the least out of IT stacks).
Rust is not inherently slower but then again neither are C and C++, but in practice all of those tend to be less efficient than realistic Java systems. Rust is displacing C in contexts where Rust's less than amazing performance are not noticeable in contrast to C's also-not-amazing level of performance. And I also think there is a cognitive bias under which a developer will reach for Rust to supplant a legacy C program, because that developer reflexively dislikes managed language runtimes.
only after the move is complete and assuming it's as successful as you think it would be. What usually happens is the migration takes on a life of its own and is a multi-year if not multi-decade project. It sucks up so much money and effort that a business could be using to actually build their business vs migration to a different database. Meanwhile, the account execs of the old system know you're moving off of it so say good bye to any kind of contract discounts or special treatment during emergencies.
There's entire graveyards of failed enterprise system migrations. The most likely outcome is eventually a compromise has to be made and now you have two systems to maintain and license, the legacy one, and the new one. With the promise of eventually getting off the old one but it never happens.
I'm on a project with a client that has 24 ERPs across their enterprise around the globe from acquisitions. Half of them are ERPs that were meant to replace another one but the transition was never completed. A big part of this project is integrating all of their sales pipelines, analytics, and history into, yet another, enterprise system.
It’s rarely that clean. Sure, there is the immediate sticker price, but you have to factor in the migration costs as well. Depending on how deep the integration goes, it could take years of effort. All of which is going to take political capital to get people to migrate perfectly working systems without any operational gain. Plus you have the old guard who actively fight you-maybe they have spent their career in Oracle and that is all they know.
Even if you do move mountains and make it happen, suddenly any outages after the transition become your fault. “This never happened on the old system.”
How is that realistic? If you offer me insane money, I will of course bluster that I can do the impossible. When I inevitably fail, I still have a pocket full of cash.
It's not realistic, money doesn't make hard things easy. Paying someone more doesn't make them more capable, at best it an incentive to work longer/harder. That doesn't make them more capable either, it just makes them work more. If someone asked me to swim the English Channel I'd say no because i can't do it. If someone offered me $2M to do it i would still say no. Let's say i said "yes, i'll figure something out.", well i would still drown or need to be rescued even after being paid $2m.
You are right, that's exactly my point. I was in such situation multiple times. People will say "it's impossible" but they actually mean "it's impossible given my motivation connected to money, time I could be given, freedom to experiment without boss looking at the calendar, and probably a bunch of other things". When the same people are given sudden motivation kick (even as a hypothetical) they start to actually think. Maybe they'll figure out that it's impossible anyway and won't do it for a $100M. Myself, I'd immediately start to think how to do it.
That's about how much it cost my company to move the flagship off of z/OS. That kept the language (Cobol) and DB2 intact (moved to DB2LUW); just a new build target basically.
It took like 5 or 6 years and that $10M represents the cost of only 10 months of operations on Z.
It's not really going to benefit ME anything. It will benefit my employer this amount. I might get an extra bonus for successful migration, but it's peanuts compared to the savings.
So in such situation, I'd be tempted to actively oppose this initiative.
Now imagine the switch is going to cost you $100M in downtime and change consultants, if it succeeds at all, and your new provider will up the price in a few years time anyway.
Big enterprise businesses want support contracts for someone to blame. Yes, you can find Postgres support, but switching to a different devil is the far more common option.
Just not that straightforward in practice. You have all of these product lines that people are building that you're hoping will grow the business. They all depend on your backend stuff that's just an implementation detail. You have to somehow convince everyone across the org to stall their product development to perform a "migrate to Postgres" thing? It's not going to be easy.
There was a recent big company that posted on Twitter about "shutting down our last Oracle server" and that was the last thing in a multi-year process or something like that.
Coordination is sometimes harder than the technology itself.
The assertion was that switching vendors would save $10M. I asked why the new vendor would forego $10M that the old vendor was able to collect. Are you saying that the new vendor has to offer this discount otherwise there’s no incentive to migrate? (I agree that migrating is very difficult politically.)
So you did, I did not pick up that you meant peer vendors which is pretty obvious on re-reading. I believed you were saying that Enterprise Vendors (who are often Oracle customers) would jump to save $10m. But that wasn't what your question was.
I recall the "magic" of the aca actually being focused on junk insurance so bad they look like scams, a marketplace to facilitate apples-to-apples competition, and most importantly, making it illegal to deny coverage to people because of genetic tests or public/stolen information like that (a great thing to see the 23&me breach coming).
My impression was it would be painful in a lot of ways but we need better competition and better protection in order to have the private insurance industry actually work for people instead of abuse them and health insurance is too important (and complicated, and too much history of dishonesty) for laissez faire.
Nobody in this comment chain was saying it was good for the customers. The GP was saying that they clear out room for new businesses, and if brick-and-mortar-fabric-superstore were still a viable model someone would be doing it.
I am looking for fabric right now and am terribly frustrated not to have anywhere but limited quilting shops available. Online is not an answer, because you can't handle the fabric for weight, exact color, and stretchiness.
JoAnn drove all the medium-sized fabric stores out and left us with nothing.
The lack of customer density over time drove out all the fabric stores - medium sized or not.
At-home sewing has been declining since I've been alive, and it was just barely hanging on when I was a kid. The demographics simply cannot support these stores in most locations outside of hyper-dense cities.
Not to mention the folks who shop for fabric tend to be some of the most cost-conscious consumers around. They are more or less the prototype of a customer who will go to a B&M store and then price match on-line,.
I'm honestly surprised even Jo-anne survived as long as it did.
The "clear out room for new business" argument is as absurd as it gets. If you think the landscape is packed to capacity with brick-&-mortar stores to the point that it needs "room for new business," you don't live in the USA.
Consolidation frees up real estate, allowing new businesses to open. Where I live, old supermarkets are now farmers’ markets, trampoline parks, and health clubs, and an old car dealership is a church.
> "as soon as possible after the software launches"
This isn't true, just desired, and is one of the main roots of the conflict here. OF COURSE you would like to start selling in advance and then have billing start with customers the instant the "last" pr is merged. That isn't a realistic view of the software world though and pretending it is while everyone knows otherwise starts to feel like bad faith. Making software that works, then having time to deploy it, make changes from early feedback, and fix bugs is important. THEN all the other business functions should start the cant-take-back parts of their work that need to coordinate with the rest of the world. Trying to squeeze some extra days from the schedule is a business bet you can make but it would be nice if the people taking this risk were the ones who had to crunch or stay up all night or answer the page.
Trying to force complicated and creative work into a fake box just so you can make a gantt chart slightly narrower only works on people a couple times before they start to resent it. 10x that if management punishes someone when that fantasy gantt chart isn't accurate and 100x that if the one punished is the person who said "it's impossible to know" and then was forced into pretending to know instead of the person doing the forcing.
I, and others, don't agree with the blanket statement that "no estimates" is not a legitimate argument in any scenario. Can you expand on why you think there isn't a single case where estimates don't add value? Similarly, is there anything specifically in that post's claims that you think was incorrect, leading to their false conclusion?
Okay, a scenario where you're building a hobby project alone and you don't care if or when it gets finished would be one where estimates aren't needed.
There is no scenario where it's appropriate or necessary when developing software professionally or even as a side project where others are expecting you to complete work at some point.
One of the many misconceptions in the original comment in this thread is that "worthwhile software is usually novel", which is not the case without a very specific and novel definition of worthwhile that I don't believe was intended.
If software isn't novel, that means some other, existing software does the same thing just as well in the same way on the same platform. So, unless it's a hobby project you're building alone, why don't you just use the existing software?
I think that writing software that isn't novel fails to be worthwhile by a perfectly ordinary, mainstream definition of "worthwhile".
So you would consider a CRUD app with some basic business rules to be novel? Basically meaning that any software that requires any development effort is novel?
That's a completely valid definition of worthwhile software, but to claim it's impossible to create an estimate to complete said development is absurd.
You just keep saying things are absurd or obvious but not putting anything behind it.
I hope this isn't a semantics game where things like "1 - 6 months" counts as an estimate in this context.
The point way back up this thread was accurate timelines for complicated, novel work have large error bars but those error bars aren't as bad as the equivalent error bars on estimating whatever "return" it is being pitted against.
I wouldn't consider something like "1-6 months" as a valid estimate, as that would indicate there is too much uncertainty and it needs to be broken down into subtasks that can be estimated with much less variance.
I've written what is probably several pages now in response to two individuals who are redefining terms in order to play the exact semantic games you mentioned, but in order to claim no estimation of any sort needs to be done. We seem to be done talking past each other now that I explicitly pointed out their usage of non-standard terms and my suspicions of why (having also unfortunately lived through software development managed by Gantt chart and other unpleasant experiences where someone who had no idea what they were managing was in control of a project), which is fine with me.
Feel free to describe your experience in practice when working in an organization where software developers answer to no one but themselves and are never asked for any justification for their progress or any projections of when they will be finished (both of which would require estimation to provide).
If you are able to tell stakeholders something like you'll be done in 1-6 months or provide no insight at all into when your tasking will be done, do no tracking of progress internally, and perform no collaboration around the completion of synchronous tasks within your team, I'll acknowledge no estimation is taking place during that process.
This is a really important perspective to remember in all our daily lives but also when motivated politicians say things like "autism epidemic". I guess there might be an equivalent decline in people labeled as difficult?
If anyone is going to support policy for our fellow humans spend an extra moment making sure to both have empathy and make sure we're comparing apples to apples.
Would be more effective to simply ask for a point to be clearly made rather than grandstanding about what stupid people vs people with even slight intelligence believe as a way to try to indirectly insult other posts.
reply