Wpis z mikrobloga

Co myślicie o .NET MAUI? Ma szanse to wypalić choćby na skale fluttera? Jak przeglądałem opinie to raczej jeszcze się nie zbyt nadaje na komercyjne projekty, ale Microsoft dość mocno w to inwestuje.
Ogólnie to Microsoft mocno inwestuje (Blazor, MAUI), tak jakby trochę chcieli wszystko moc zrobić w jednym środowisku (.NET) i za pomocą jednego języka (C#). Jakby nie patrzeć to rozwiązania backendowe i chmurowe, które się komercyjnie sprawdzają już maja.

#programowanie #dotnet #csharp
  • 11
@Vane1905 z rok temu doszło do tego żeby wpakowali Blazora w web view który był w MAUI. Zawsze mam tak że takie rzeczy świetnie wyglądają na pierwszy rzut oka a potem im dalej w las tym więcej drzew i wychodzą różne problemy jak słaby iser experience przy dużym latency w blazor serwer czy problem z SEO w flutter web
@Vane1905: w listopadzie wychodzi .net 8 I mają tam trochę usprawnić blazora żeby nie trzeba było decydować czy server czy wasm.
Maui z tego co kojarzę nie ma wsparcia na Linuxie albo był tam jakiś problem przy próbie dockerowania związany z tym.
Fajnie się w tym pisze jak ktoś nienawidzi JavaScript (i jej miliona frameworkow)
języki z tracing GC nie nadają się na GUI. Patrz Java na Androidzie vs Swift na iOS. Ten drugi tak nie laguje.


@Krolik: myślę, że większy problemem jest design języka Java/C# niż sam fakt istnienia tracing gc. Jakby powstał język taki jak Go do UI, gdzie nie wszystko jest obiektem to śmigałoby dużo lepiej. Z drugiej strony mobliki teoretycznie też nie powinny mieć dużego problemu z długimi pauzami, bo living heap
Co myślicie o .NET MAUI? Ma szanse to wypalić choćby na skale fluttera?


@Vane1905: microsoft po prostu próbuje zadziałać w tym temacie, bo ugryzienie kawałka tortu w postaci aplikacji mobilnych jest bardzo kuszące. Wątpię, że coś z tego wyjdzie, bo konkurencja w postaci Fluttera jest duża i za bardzo nie wiem czym microsoft chciałby przekonać developerów, którzy chcą iść w rozwiązania multiplatformowe. Zwłaszcza, że za Flutterem stoi firma, która siedzi mocno
@Saly: mobilki działają na słabych prockach a do tego muszą oszczędzać baterię. Nawet jeśli ogarniesz pauzy sprzątając w tle to nadal marnujesz energię na to sprzątanie. Allocation rate w C# jest podobny jak w Javie. Mobilki mają też mniej ramu niż serwery. GC powoduje 3x-5x większe zużycie RAMu niż RC. Dlatego iPhone może mieć o połowę mniej RAMu i nadal działać lepiej.
Jakby powstał język taki jak Go do UI, gdzie nie wszystko jest obiektem to śmigałoby dużo lepiej


@Saly: no raczej nie. U nas jeden team napisał proxy CQL w Go i ono pożera 2,7 GB przy 10k połączeń. Z tych 2,7 GB, niemal 2 GB to narzut GC, kolejne 250 MB to narzut stosów gorutyn. Go ma bardzo podobną charakterystykę wydajnościową co Java/C# - marnuje masę pamięci na GC. Do tego
GC powoduje 3x-5x większe zużycie RAMu niż RC. Dlatego iPhone może mieć o połowę mniej RAMu i nadal działać lepiej.


@Krolik: bez przesady. Takie go by default pozwala na 2x większe zużycie (można zmniejszyć). Co do większego zużycia RAMu to zgaduje, że obiekty są tu problemem a nie samo GC. Z drugeij strony RC też swoje kosztuje: taki std::shared_ptr tez swoje kosztuje, choć z drugiej strony nie używa się go na
Takie go by default pozwala na 2x większe zużycie (można zmniejszyć).


@Saly - bo jest ustawione domyślnie bardzo agresywnie, tzn włącza się często. Kosztem jest palenie dużej liczby cykli na samo GC. Niestey w tracing GC masz tradeoff - odśmiecasz często i palisz dużo CPU, ale masz znośne użycie pamięci, albo oszczędzasz CPU odśmiecając rzadko, ale wtedy zużycie pamięci eksploduje. W aplikacjach mobilnych nie możesz palić sobie tak dowolnie dużo cykli CPU,