Wpis z mikrobloga

  • 0
@mirasKo-Kalwario: btw: wybór Javy do napisania Cassandry też był błędem ale to przez Facebooka a teraz nikt nie przepisze miliona linii kodu. Jest wiele takich projektów które musiały się bujać z kiepską technologia niedostosowaną do problemu tylko dlatego że twórca nie umiał nic innego i nie odrobił pracy domowej na etapie projektowania. Kolejnym sztandarowym przykładem jest Minecraft. Ile to godzin pochłonęło na tuning a i tak zawsze lagowało.
  • Odpowiedz
@Krolik: skoro był takim błędem to pewnie nikt teraz nie używa cassandry, oh wait

Dalej nie podales githuba i dalej przepisujesz tezy z artykułu który wysłałeś, myślałem że masz jakąś wiedzę o tym GO ale chyba tylko tyle co wyczytałeś na jakimś blogu zakładając ze o ruscie i C masz taką samą wiedzę to nie dziwię się że nikt cie nie posłuchał w firmie i zrobili po swojemu
  • Odpowiedz
  • 0
dalej przepisujesz tezy z artykułu który wysłałeś


Połowy rzeczy, które wymieniłem nie ma w tym artykule. Nie napisałeś, że są nieprawdziwe, więc wychodzi na to że się z nimi zgadzasz. No trudno by inaczej, bo to są fakty, a nie opinie.

myślałem że masz jakąś wiedzę o tym GO


Mam
  • Odpowiedz
albo bardzo dużym rachunkiem z AWS.


jeszcze to, to już chyba trochę przesadza :D zarabiacie coś na swoich klientach prawda ? niech te 10 tyś połączeń na 3gb wypadało jak napisałeś, piszesz 1 klient 100koła, 10 t3.medium (ma 4gb) on-demand kosztuje $0.0416, 10*24*30*$0.0416=300$ (a przecież taki ruch pewnie w nocy nie występuje, to skalujesz w dół) - to, to jest dużo ? czy sam fakt rachunku na karcie kredytowej jest najważniejszy ?
  • Odpowiedz
  • 0
@bkowalczyyk: krytykujesz czytelność kodu, którego w Go w ogóle nie dałoby się napisać, bo Go nie umie w funkcje generyczne. Argument w stylu "Fiat 126p lepszy od mercedesa, bo od klimatyzacji w mercedesie można się przeziębić (jak się źle ustawi), a fiacik klimatyzacji nie ma". Zresztą w tym kodzie nie ma nic nieczytelnego - ot rozbudowana specyfikacja typu. Znacznie to lepsze niż jakieś ogólne interface{} i potem ifologia i downcasty,
  • Odpowiedz
  • 0
@bkowalczyyk: 10k połączeń to nawet nie jest jeden nasz klient. 10k połączeń to jeden nasz klient ma do jednego naszego serwera. Druga sprawa że nigdy instancji nie dobiera się na styk. Bo to że zjada 3GB w teście nie oznacza że po dłuższym czasie nagle nie przekroczy 4 GB i się nie wypieprzy na ryj. GC w Go niczego nie gwarantuje, maksymalnego zużycia pamięci również. Nie gwarantuje nawet braku fragmentacji
  • Odpowiedz
10k połączeń to nawet nie jest jeden nasz klient.

I to też napisałem przecież xd

Ogarniętego javowca trudniej znaleźć, bo na jedno ogłoszenie przychodzi 1000 CV z czego 999 osób nic nie umie, a jedna może się nadaje na juniora. Ludzi od Rusta znaleźć bardzo łatwo - dajesz komentarz na Hacker News i w ciągu godziny masz kilka bardzo mocnych kandydatur.


@Krolik: chcesz żebym tu nie porównywał malucha z mercedesem
  • Odpowiedz
  • 0
@bkowalczyyk:

, a fakt że czasem latency skoczy do 5ms bo GC się odpalił nie jest problemem.


Gdyby to było tylko 5 ms raz na jakiś czas to pewnie nikt kopii by o to nie kruszył. Realnie mieliśmy czasy na poziomie kilku sekund. A to wystarczy żeby zrobić timeout i żeby klient zobaczył.
  • Odpowiedz
  • 0
@Boska_Klaudia: jest const, które jest tak biedne że nie działa praktycznie z niczym interesującym. Czyli tak jakby go nie było. Znikoma użyteczność w praktyce. Nawet w javie 1.0 można było mieć stałe pola w obiektach i parametry final.
  • Odpowiedz
Realnie mieliśmy czasy na poziomie kilku sekund. A to wystarczy żeby zrobić timeout i żeby klient zobaczył.


@Krolik: to mogliście poszukać dobrych Javovców, np tak że: dajesz komentarz na Hacker News i w ciągu godziny masz kilka bardzo mocnych kandydatur - i problem solved i elo i pora na csa.
  • Odpowiedz
  • 0
@bkowalczyyk: jest tylko jeden sposób aby mieć całkowitą gwarancję że GC się nie włączy - pisać kod tak aby nie alokować obiektów na stercie. No to teraz wyobraź sobie programowanie w języku obiektowym bez używania obiektów. Czyste C jest bardziej ergonomiczne i mniej błędogenne niż taka Java. Jeżeli tak nie zrobisz, to nie masz absolutnie żadnej gwarancji ile czasu potrwa GC i kiedy się włączy. I dotyczy to również tych
  • Odpowiedz
  • 1
@bkowalczyyk: Tu masz artykuł o tym jakie są prawdziwe koszty GC: https://arxiv.org/abs/2112.07880.

In addition, we find that newer low-pause GCs are significantly more expensive than older GCs, and, surprisingly, sometimes deliver worse application latency than stop-the-world GCs.


Problem z popularnością GC polega na tym, że ludzie testują najpierw malutkie prototypy aplikacji z malutkimi ilościami danych i wtedy wszystko działa ładnie, zwłaszcza że komputery są obecnie naprawdę cholernie szybkie i tego dodatkowego narzutu GC nie widać. I konkludują, że GC jest już "solved problem", co nie jest oczywiście prawdą. Ale potem idą z tym na produkcję, danych jest więcej, obciążenie jest większe i nagle okazuje się że GC robi brrrrr, pojawiają się jakieś przypadkowe pauzy czy okresy niskiej wydajności, apka zużya jakieś potworne ilości RAMu i jest killowana przez OOMkiller itp. I potem jest trwająca miesiącami walka pt. "tuning GC". Której nigdy nie udaje się do końca wygrać i która pochłania więcej roboczogodzin niż gdyby cała apka była napisana nawet w archaicznym
  • Odpowiedz