Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How Netflix really uses Java

infoq.com

Post reply on HN
Print view View original

41–50 of 100 posts

Re: How Netflix really uses Java

#41

Post by jakewins »

John23832 wrote: post #35
doctorpangloss wrote: post #26

Earlier quoted context omitted.

Adopting RxJava means fixing all the bugs in everything up front. That is why it feels complex. In my opinion and in the opinion of other adopters, it is a more expressive way to define correct behavior. This is essentially the same tension between static and dynamic typing. No matter what, all bug free code is complex. Correct code can be written in any paradigm. But productful code ships with bugs. Does test user c…

> Adopting RxJava means fixing all the bugs in everything up front. That is why it feels complex. I disagree with this. It mentally changes the thought processes when debugging, which was the biggest issue that was brought up. > Does test user creation need to be bug free? I don’t know. It feels like something where productful test user creation can ship with bugs, even if in reality your test code harnesses should n…

This was part of some “testing in production” type scheme?

Are there any talks or blog posts on how y’all wired this up, lessons learned etc?

Re: How Netflix really uses Java

#42

Post by bcrosby95 »

shp0ngle wrote: post #36
iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

I don't think the experience is that much different between the different services, honestly. I vaguely have some recollection of Max being a bit bad, but don't remember the details. They are all fine. Except for YouTube, that's just leagues ahead of everything else.

YouTube is the only thing I've ever interacted with where I can hear the audio of videos that I shouldn't be able to hear. And I've had times where two were playing at once overlapping eachother.

It only happens a few times per year for me, but I've never had it happen on another service.

Re: How Netflix really uses Java

#45

Post by taeric »

iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

Would hit a whole lot better if the Netflix app wasn't equally as bad as the Disney+ one....

Re: How Netflix really uses Java

#46

Post by burnished »

iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

Based on my own experience its just frank observation

Re: How Netflix really uses Java

#47

Post by jakewins »

CharlieDigital wrote: post #33
Nican wrote: post #27

I have been out of the loop with Java. Is Virtual Threads the answer to asynchronous I/O? (Much like Go/C# async/node.js?) That looks like an interesting solution to support asynchronous I/O without breaking all the APIs, and having the async/await mess that C# created.

> ...the async/await mess that C# created What do you find messy about it? Seems fairly straight forward, IME.

Not sure what the poster above was thinking of, but it seems kinda the same as every other language that’s adopted it - powerful, but footguns abound. I ran some async C# in a debugger - in Rider - the other month, and the debugger just goes off the deep end.

Does C# have the same issue Python does with accidentally calling blocking code? In async Python - which I mostly quite like actually - it’s terrifying to bring in a library because if you’re unlucky it does some blocking network call deep inside that stalls your whole app..

Re: How Netflix really uses Java

#48

Post by John23832 »

jakewins wrote: post #41
John23832 wrote: post #35

Earlier quoted context omitted.

> Adopting RxJava means fixing all the bugs in everything up front. That is why it feels complex. I disagree with this. It mentally changes the thought processes when debugging, which was the biggest issue that was brought up. > Does test user creation need to be bug free? I don’t know. It feels like something where productful test user creation can ship with bugs, even if in reality your test code harnesses should n…

This was part of some “testing in production” type scheme? Are there any talks or blog posts on how y’all wired this up, lessons learned etc?

No this all happened in preprod. Every team in the growth space ran their own tests across the various permutations of users (country, payment type, plan, ... at the time free trial, feature flags) to determine if their code was valid and worked to go to production. Each team continuously deployed independently. Given that we also were continuously integrating as well... you get a lot of customers created.

Sorry no talks.

Re: How Netflix really uses Java

#49

Post by rightbyte »

rco8786 wrote: post #31
kagakuninja wrote: post #12

Earlier quoted context omitted.

I'm interviewing at Disney Streaming, lol

There is a bug in the Roku app where if you close it and then re-open quickly it will hang on the profile login screen every, single time. Have to go back to Home again and re-open the app. Seems dumb, but I have 2 little kids and they both like to "pause" whatever show when it's time to turn the tv off. So after the first one does it, I have to do this dumb little dance to get the app to load again so the second one…

> they both like to "pause"

My son also want to do this. Pause. Then turn the TV off. Maybe they believe the show will keep running with the TV off unless paused?

Re: How Netflix really uses Java

#50

Post by karmakaze »

iammiles wrote: post #4

…let's say, your TV, or your iOS device will just do 10 network calls to these different microservices. It will just not scale at all. You would have a very bad customer experience. It would feel like using the Disney app. It's just not ideal. That’s some shade.

I don't consider making many network calls necessarily bad for experience. My https://hackerer.news page load makes more requests than I care to count and it runs for 70 seconds (looking at the 'date:'s in the network tab). But the page renders very quickly. It might be bad if you're in AU/NZ idk, but all the requests are cached via CloudFlare and being individual units is highly cacheable which probably offsets a lot of other downsides.
Post reply on HN