Live data from Hacker News

IT Runs on Java 8

veekaybee.github.io

541–550 of 556 posts

Re: IT Runs on Java 8

#541
post #64

Earlier quoted context omitted.

> The best & brightest in tech are working with the best tools on the biggest problems I don't think that's true—there is a subset of the best and brightest who work on greenfield projects very decoupled from existing customer bases, and they get to blog / present / post a lot about what they're doing. There are quite a few "best and brightest" people who are in large companies or slow-moving industries. They're ofte…

If they're really the best, wouldn't they have their pick of workplaces and optimize for personal enjoyment? Nobody who could chew through research level algorithm problems all day would willingly write Java 8 CRUD apps for Windows Server 2000, because those are the people that have a choice.

People have a strange idea of what "best and brightest" work entails.

I work with Java 8 on a greenfield high-frequency transaction platform for a very large company. It is extremely satisfying to build the "world's largest" of something, and no amount of shiny features in a cute new language would deter me from this work.

Re: IT Runs on Java 8

#542
post #88

All I know is that reading HN and responding to what I've learned has made my salary go up, up, up in the last 5 years. Partially by recognizing there are so many cool things out there that pay well. You can be defeatist and say "I'll never learn all of this,' or you can be clever and figure out the things that are worthwhile to learn. I went from working in a boring insurance shop to one of the fastest growing tech…

Would love to hear more details about your story. What were you doing before exactly? What tech specifically do you feel helped you?

I was at an insurance company upgrading old systems to use less old technology. I had an information science degree and was a pretty lousy programmer.

HackerNews helped to demystify working at a software company. It just seemed more and more in reach as I kept reading and contributing. The most important thing though, is it taught me to get my shit together before making a comment. That extended to being more rigorous in all the work I did, leading to success. I also came across tons of articles about how to level up, and cool resources where I could practice coding challenges. Looking back, it was like having a rich community at tech-oriented company without being able to work at a place like that.

It's really hard to draw a line, but I think I just gained familiarity with the industry and learned to tell when an technology idea is bullshit or legit. All that led to more confidence and that shit is gold when it comes to leveling yourself up.

Re: IT Runs on Java 8

#543
post #98

What's funny about this is that Java 8 is no longer supported by Oracle, so unless you are using openjdk or some other equivalent, IT is running on a potentially insecure platform. Not being cutting edge is one thing, but being insecure...

Large companies have support deals with Oracle (or other providers, like Red Hat, IBM or Azul). My client has one for Java 8 until 2026 I think. One of the larger obstacles in upgrading to Java 11 is that the libraries which replace SOAP clients in JDK are not patched (unlike the JDK), and have a ton of known CVEs to them.

Those are probably all the companies using Java 8 right? ;-)

Re: IT Runs on Java 8

#544

Earlier quoted context omitted.

It takes a lot of power to push something that large. A lot of brain power to grock the ecosystem. Outside of the Java bubble, the view is quite a bit different. All that sophistication looks like a wasted effort. Take something as simple as admining the garbage collector. Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. After working with Go…

> Java has a big selection of GCs, and each has their bunch of knobs for tuning. And you have to pay attention to that stuff. You never have to touch them in the Java world either, unless you like making performance worse that is. I've never ever seen a case where fiddling with garbage collection parameters didn't make things slower. I worked with a guy who worked on a popular java compiler, and he says the same thin…

Are you serious? You have to mess with the maximum memory allocated to the GC all the time with java processes. Also the JVMs default settings basically assume it is the only process running. It will keep hogging a huge amount of memory even if the memory allocated to the GC is 60% empty unless you configure the GC properly. Wasting memory and stealing it from other processes which potentially causes swapping or crashing is far worse than any increased time spent garbage collecting. Unless you're as stupid as the Minecraft developers you will rarely suffer from GC pressure with heaps below 10GB.

Re: IT Runs on Java 8

#545
post #85

The funny thing is that from a purely technological point of view, Java (even the 5-year-old Java 8 and certainly recent versions) is far ahead of most other stuff hyped on HN (as well as less hyped stuff). Virtually no other platform comes close to that combination of state-of-the-art optimizing compilers, state-of-the-art GCs, and low-overhead in-production profiling/monitoring/management. And much of the cutting-e…

Isn't Minecraft written in Java. Many Fortune XX have their entire product lines written in it. Frankly, I don't understand the hate it gets on HN.

It is also one of the poorest performing games in the history of video games.

Re: IT Runs on Java 8

#546
post #281

Earlier quoted context omitted.

> the actual language & core libraries are incredibly slow to react to anything. async/await being the obvious example. Still no sign of it in the Java language, nor any expectation of it, unless I missed something.

https://wiki.openjdk.java.net/display/loom/ which is superior to async/await, if I may say so myself (I'm the project lead)

That's very nice, but saying it's strictly superior to async/await is a stretch. Fibers/stackful coroutines are a different approach with its own tradeoffs.

On the plus side, fibers offer almost painless integration of synchronous code, while async/await suffer from the "colored functions" problem[1].

The price you pay for that, is the higher overhead of having to allocate stacks. If you don't support dynamic stacks which can be resized, you basically don't have a much better overhead than native threads. There are two solutions I'm aware of, both of them have been done by Go at different times: segmented stacks and re-aligning and copying the stack on resize. Both carry some memory overhead (unused stacks) and computational overhead (stack resizing).

[1] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

Re: IT Runs on Java 8

#547
post #446

In the majority of companies it's simply not possible to operate on the bleeding edge the way HN articles would have you believe you should. Besides the obvious issues around the value of rewriting stable legacy systems on new platforms, there are also man power issues. You need tier 1 developers to live on the bleeding edge because any problem that comes up (and they will come up) largely requires you to solve it yo…

Are we reading same HN? It seams majority of people advocate fairly sane proven choices for majority of projects e.g. start with the monolith default to PostgreSQL for dbms etc.

You've never seen disdain for Java on HN?

Re: IT Runs on Java 8

#548
post #425

Earlier quoted context omitted.

The initial version of F-35 was lifted wholesale from Yakovlev Yak-141. Basically during the wild late 80's early 90's in Russia Lockheed Martin entered into an agreement with the Yakovlev bureau to do who knows what with Yak-141 (which sounds impossible and wild in itself nowadays). The agreement lasted just long enough for them to rip everything off and was then dissolved. http://aviationintel.com/yak-141-freestyle…

That's a massive exaggeration at best. The F-35B variant borrows the lift fan design from the Yak-141. That's a single feature of a single variant of an aircraft that has a half-dozen other completely unrelated features. The Yak-141 didn't have helmet-mounted displays, it wasn't stealthy, it didn't have the new combat information management systems, it wasn't built out of modern composite materials, and so forth.

Would be quite a feat to have all those things in late 80s, don't you think? :-) It's not an "exaggeration" The planes even look similar, and Lockheed got $1.5T in government money for a few million they spent bribing government officials in Moscow.

Re: IT Runs on Java 8

#549
post #281

Earlier quoted context omitted.

https://wiki.openjdk.java.net/display/loom/ which is superior to async/await, if I may say so myself (I'm the project lead)

That's very nice, but saying it's strictly superior to async/await is a stretch. Fibers/stackful coroutines are a different approach with its own tradeoffs. On the plus side, fibers offer almost painless integration of synchronous code, while async/await suffer from the "colored functions" problem[1]. The price you pay for that, is the higher overhead of having to allocate stacks. If you don't support dynamic stacks…

> Fibers/stackful coroutines are a different approach with its own tradeoffs.

The only tradeoffs involved, as far as I'm aware, are effort of implementation. There are no runtime tradeoffs.

> The price you pay for that, is the higher overhead of having to allocate stacks.

You have to allocate memory to store the state of the continuation either way. Some languages can choose not to call the memory required for stackless continuations "stacks" but it's the same amount of memory.

> Both carry some memory overhead (unused stacks) and computational overhead (stack resizing). Their "advantage" is that, because they're inconvenient, people try to keep those stacks shallow.

Stackless continuations have the same issue. They use what amounts to segmented stacks. "Stackless" means that they're organized as separate frames.

Re: IT Runs on Java 8

#550
post #491

Earlier quoted context omitted.

If the native routine blocks the kernel thread, it blocks, and if not, it doesn't. While something could hypothetically be done about blocking native routines, we don't see it as an important use case. Calling blocking native code from Java is quite uncommon. We've so far identified only one common case, DNS lookup, and will address it specifically.

Nice. So going 100% async is a real possibility?

I'm not sure what that means.
Post reply on HN