91–100 of 100 posts
Earlier quoted context omitted.
> ...the async/await mess that C# created What do you find messy about it? Seems fairly straight forward, IME.
Agreed. The task system in C# is pretty clean imo. Same with Rust (sans the type system implementation of Futures) and Go's goroutines. Especially compared to CompletableFuture in Java.
Earlier quoted context omitted.
Lol the Disney+ app UX is honestly terrible. Not to mention the regular app crashes on apple devices. Disney has _how_ much money to spend on their streaming services technology stack and they just... don't? Just feels like they'll piss on the customerwhen given the chance because people will still pay for that sweet Disney juice regardless.
What I find funny is that with that kind of money you could staff 10 app teams, develop the app 10 times in different ways and just pick the best one in the end.
Earlier quoted context omitted.
Agreed. The task system in C# is pretty clean imo. Same with Rust (sans the type system implementation of Futures) and Go's goroutines. Especially compared to CompletableFuture in Java.
Specifically, function coloring (C# and Rust in your examples) is not the same as coroutines in Go or virtual threads in Java.
Function coloring can be handled by just blocking on an async function. Though the reverse takes some planning.
Earlier quoted context omitted.
Even at Netflix RxJava is not fully accepted. When I was there I wrote a service which called many downstreams. It orchestrated test user creation. I used RxJava because it was being pushed by the platform team, and coupled well with our internal GRPC api handlers. I shared with the team and people complained about the complexity… so I ended up ripping it out. What people wanted was a test user creation service that…
Is there any reason they don't adopt kotlin? It seems a lot simpeler with suspended functions and coroutines?Instead of RXJava.
Earlier quoted context omitted.
I had a close look at RxJava and decided I wasn't smart enough to understand it. I intentionally didn't tell my colleagues about it, they would have loved it and I would have been in big trouble.
Yeah, I'm in the same boat. I'm coming fresh to the team and I haven't written any Java in anger for 8 years, and there's Rx in here. I'm sure I could sit here and study it over and over until I get it, but why? My service is running at Promises are all over the place too. I understand why someone thought this was a good idea ("I'm doing the scalable thing!"), but in the end it appears completely unnecessary (e.g. do…
I've been coding in C recently and really enjoy the limitations. Usually there's only one way to do something.
I never worked with micro services, but I have this question. Do micro services require more and better management? I can imagine that you need to keep track of all these services, along with information about dependencies, code version, API version and others. Of course, monolithic services also require these this sort of management, but it should be less complex.
At Netflix scale, there most certainly is a service discovery registry where each service registers itself. The registry can be used for other services to find out how to reach each service, what regions those services are deployed in, how many instances of each service there are, what operations that service supports, etc. https://devopscube.com/service-discovery-explained/
In theory... would Go be (1) as performant for Netflix's scale/speed needs, and (2) be practical in 2024 from a platform/ecosystem perspective?
Meanwhile, if you're building something smaller than Netflix, I'm writing a book just about that ( https://opinionatedlaunch.com/ ). It's about mobile apps, but I talk about backend at great length, especially since my background is Java. The book is called "opinionated" because I cover Quarkus ( https://quarkus.io/ ), monolith, Fly.io, and no K8s. No fancy stuff to pad your CV, just to get things done the simplest w…
Why Fly.io if you want to build a monolith? Compared to Heroku or Render, to me Fly.io seems to be more aimed at edge computing.
But when I evaluated them, Render didn't support loading my own docker image, so it's incompatible with my build process and CI/CD.
The book is a living document, and I always try to find easier/cheaper/faster/better ways of doing things, so I'll definitely check Render again!
Earlier quoted context omitted.
Why Fly.io if you want to build a monolith? Compared to Heroku or Render, to me Fly.io seems to be more aimed at edge computing.
I want Heroku experience without paying Heroku price, so Render and Fly.io were an option. But when I evaluated them, Render didn't support loading my own docker image, so it's incompatible with my build process and CI/CD. The book is a living document, and I always try to find easier/cheaper/faster/better ways of doing things, so I'll definitely check Render again!