Cześć. Zastanawiam się czy platforma .NET to taki jack of trades, master of none. W backendzie rządzi Java, na froncie Javascript, w mobilnych Kotlin, w grach i rzeczach niskopoziomowych C++ a .NET i C# próbuje ogarnąć wszystkie te dzedziny a jak wiemy jeśli coś jest do wszystkiego to często jest do niczego. Może to trochę przesada, ale czy ta "zachłanność" MS ma sens i przyszłość? Tak jak napisałem, jeśli ktoś chce zrobić zaawansowaną aplikację webową to wybierze Jave, C# też może być, ale jednak Java góruje. Dalej, Czy Blazor ma jakiekolwiek szanse zastąpić JS? Czy ktoś na serio wybierze Xamarina zamiast Kotlina do pisania apki mobilnej?
0
0
Jsa jakby miało coś zastąpić to byłoby to WebAssembly*, a Blazor to tylko wsparcie dla WebAssembly oraz "framework".
* - moim zdaniem jako kod wynikowy z innych języków np.
(module
(type (;0;) (func (result i32)))
(func $test (type 0) (result i32)
i32.const 42)
(table (;0;) 1 1 funcref)
(memory (;0;) 2)
(global (;0;) (mut i32) (i32.const 66560))
(export "memory" (memory 0))
(export "test" (func $test)))
Tak jak napisałem, jeśli ktoś chce zrobić zaawansowaną aplikację webową to wybierze Jave
skąd taka pewność?
2
Każdy język wysokopoziomowy to taki szwajcarski scyzoryk.
Blazor to przede wszystkim framework do pisania SPA (bardzo fajny swoją drogą). Jest więc bardziej konkurencją dla innych frameworków (React, Vue itp.) i w takich kategoriach bym go przede wszystkim postrzegał. Fakt że ogranicza konieczność użycia JS do minimum jest oczywiście ważnym atutem. Ale nie oszukujmy się, pisząc jakąkolwiek większą aplikację prędzej czy później pojawi się konieczność jakiegoś zastosowania JS (chociaż i tak w większości przypadków znajdzie się ktoś kto już to zrobił i napisał do tego bibliotekę)- od tego jest JS interop.
2
Trochę tak jest. Dotnet przez ostatnie lata dostał rzeczy, które na papierze brzmią fajnie, ale w praktyce niewiele dają. Jeżeli jestem dotnetowcem od lat, to wieloplatformowość pewnie nie jest mi potrzebna, bo i tak jestem zżyty z Windowsem. Podobnie z szybkością — fajnie, że w benchmarkach dotnet wymiata, ale zazwyczaj chodzi o to, żeby było wystarczająco szybko, niekoniecznie najszybciej. A co innego dał mi dotnet przez ostatnie lata, co naprawdę przydałoby mi się jako programiście? EF Core, z którym na początku był cyrk, bo nawet group by nie robił na bazie, tylko w pamięci? Razor Pages, które dzielą 80% kodu z MVC i w dużej mierze inaczej rozkładają pliki? Wbudowany DI zamiast używania NInjecta albo wbudowane biblioteki do Jsona zamiast Newtonsoft.Json?
Do tego C# skupia się na rzeczach, które w moim odczuciu są zbędne i tylko zaciemniają sprawę. Nie potrzebuję kolejnego sposobu na napisanie hello worlda albo kolejnej składni do funkcji, albo kolejnego pattern matchingu dla ifa. Wolałbym rzeczy, które pozwoliłyby mi zrobić coś, co wcześniej było niemożliwe albo bardzo trudne, na przykład HKT, możliwość wpięcia się w kompilator jak w lomboku, nowy GC (żebym mógł odpalać joby na sparku z sensowną wydajnością), fibery zamiast korutyn.
Co programista dotneta mógł zrobić w 2015, czego nie mógł w 2010? DLR i async. Co programista dotneta może w 2020, czego nie mógł w 2015? Spany i ref structy. Z mojej perspektywy ostatnie pięć lat jest w dużej mierze stracone, bo argumenty o odpalaniu dotneta na Linuksie kompletnie mnie nie ruszają. Oby przepisanie wszystkiego od zera pozwoliło im znowu się rozpędzić w najbliższych latach, ale pamiętam, że dwa lata temu mówiłem to samo i niewiele się zmieniło.
3
Jeżeli jestem dotnetowcem od lat, to wieloplatformowość pewnie nie jest mi potrzebna, bo i tak jestem zżyty z Windowsem.
Tobie może faktycznie nie jest potrzebne, niemniej jednak całości - ekosystemowi już tak i moim zdaniem naiwnym byłoby sugerowanie że cross-platformowy dotnet nie był znaczącym krokiem na przód całości.
Nie potrzebuję kolejnego sposobu na napisanie hello worlda
A to nie jest po prostu krok w kierunku uczynienia C# bardziej REPL?
0
WeiXiao napisał(a):
A to nie jest po prostu krok w kierunku uczynienia C# bardziej REPL?
Może i tak, tylko tak naprawdę na co to komu? Jak ktoś chciał mieć REPL-a, to już dawno miał, chociażby przez CsScript czy PowerShell (sam tak używam od jakichś siedmiu lat), a są ciekawsze rzeczy do zrobienia. To nie jest tak, że ja mówię, że te rzeczy są niepotrzebne i powinni je wywalić. Ja mówię, że mogli ten czas spędzić na implementowaniu bardziej przydatnych elementów.
0
Jak duża część dotneta działa na nie-Windowsach?
Nie znam rzetelnego sposobu na zebranie takich statystyk - no bo jak? appki stoją za reverse proxy i już nie ma jakichś dziwnych pomysłów na HTTP Headery typu POWERED-BY: ASP.NET
Mógłbym się jedynie wypowiadać nt. mnie i ludzi z mojego bubble.
0
To istotne, bo jeżeli okazałoby się, że wieloplatformowość nie dała wielu nowych klientów, to jest to para w gwizdek.
To może nie strzelajmy - @krwq ty pewnie będziesz się orientował, jak wygląda sprawa korzystania przez "prawdziwych klientów" z .NET na non-Windows? jak się to zmienia z czasem.
Chociaż trzeba pamiętać że jest to bardziej inwestycja w przyszłość - co Ci z silnego środowiska jeżeli nie działa na tym, na czym siedzą devowie? Linux/MacOS, a przynajmniej taka jest moda
1
@Edelner:
Edelner napisał(a):
Tak jak napisałem, jeśli ktoś chce zrobić zaawansowaną aplikację webową to wybierze Jave, C# też może być, ale jednak Java góruje. Dalej, Czy Blazor ma jakiekolwiek szanse zastąpić JS? Czy ktoś na serio wybierze Xamarina zamiast Kotlina do pisania apki mobilnej?
Tak. Dziesiątki ludzi dziennie tak robią. Z różnych przyczyn. Java nie ma nigdzie 100% rynku. Kotlin nie ma 100% rynku. JS nie ma 100 rynku. Obnihdy zadna technologiq nie bedzi2 miala 100% rynki w swojej niszy.
W swiecie doroalych ludzi nie ma Pani przedszkolanki, która mówi wszystkim w czym mają pisać.
Poważne aplikacja pisze się nawet w php choć to przecież... php. (mam uraz z wersji 3).
.net jest wystarczająco dobry do wielu rzeczy.
4
Edelner napisał(a):
jeśli ktoś chce zrobić zaawansowaną aplikację webową to wybierze Jave
No pewnie ktoś tak zrobi. A ktoś inny wybierze .NET, a jeszcze ktoś inny PHP.
Ja rozumiem, że w jakimś HFT, systemach giełdowych czy streamingowych Java wygrywa ze zrozumiałych względów, ale nie w zaawansowanych aplikacjach webowych, które z powodzeniem od 20 lat powstają w .NET.
Czy ktoś na serio wybierze Xamarina zamiast Kotlina do pisania apki mobilnej?
W Kotlinie można na iOS?
W branży growej też nie siedzę, ale powered by Unity widzę dość często.
Afish napisał(a):
Trochę tak jest. Dotnet przez ostatnie lata dostał rzeczy, które na papierze brzmią fajnie, ale w praktyce niewiele dają. Jeżeli jestem dotnetowcem od lat, to wieloplatformowość pewnie nie jest mi potrzebna, bo i tak jestem zżyty z Windowsem.
Słyszałeś może o takiej firmie jak Amazon? :P
Oni tam maja taką chmurę i sprzedają dostęp do wirtualnych serwerów. Tak się składa, że te z Windowsem są 2-2,5 raza droższe od tych z Linuksem. Więc jak ktoś ma tysiąc takich maszyn i kosztuje go to jakieś ćwierć miliona € miesięcznie, to jak uda mu się zatrudnić programistów niezżytych z Windowsem, to po roku będzie miał 3 mln € na nowy jacht, dwa koenigseegi albo dużo prostytutek nadziewanych kokainą.
Wbudowany DI zamiast używania NInjecta albo wbudowane biblioteki do Jsona zamiast Newtonsoft.Json?
Kopiują pomysły z Javy, nie ma co narzekać, po prostu trzeba nie używać. ;)
Co programista dotneta mógł zrobić w 2015, czego nie mógł w 2010? DLR i async. Co programista dotneta może w 2020, czego nie mógł w 2015? Spany i ref structy. Z mojej perspektywy ostatnie pięć lat jest w dużej mierze stracone, bo argumenty o odpalaniu dotneta na Linuksie kompletnie mnie nie ruszają. Oby przepisanie wszystkiego od zera pozwoliło im znowu się rozpędzić w najbliższych latach, ale pamiętam, że dwa lata temu mówiłem to samo i niewiele się zmieniło.
Ja tam lubię pattern matching i throw expression. Czasem nawet tuple i funkcje lokalne. Tylko tutaj już kładziesz nacisk na C#, a nie .NET, a to temat na inną dyskusję.
0
to jak uda mu się zatrudnić programistów niezżytych z Windowsem
No właśnie rzecz w tym, że to czy ktoś programuje na Windowsie, a deployuje na Linuxa czy to bezpośrednio czy przez kontener nie powinno mieć wpływu.
I jeszcze się nie spotkałem z tym, aby miało, no może poza wersjami .NET Cora typu 0.x czy 1
0
somekind napisał(a):
Słyszałeś może o takiej firmie jak Amazon? :P
Oni tam maja taką chmurę i sprzedają dostęp do wirtualnych serwerów. Tak się składa, że te z Windowsem są 2-2,5 raza droższe od tych z Linuksem. Więc jak ktoś ma tysiąc takich maszyn i kosztuje go to jakieś ćwierć miliona € miesięcznie, to jak uda mu się zatrudnić programistów niezżytych z Windowsem, to po roku będzie miał 3 mln € na nowy jacht, dwa koenigseegi albo dużo prostytutek nadziewanych kokainą.
Kolejny argument fajny na papierze, ale niekoniecznie potwierdzony w rzeczywistości (a przynajmniej nie ma statystyk, które by go potwierdzały).
Po pierwsze, jeżeli aplikacja była w ekosystemie Windowsa, to nie da się jej ot tak przenieść na Linuksa. Jeżeli zaś nie polegała na ekosystemie dawniej, to wobec tych argumentów wybór dotneta był błędem.
Po drugie, to 2-2,5 da się zbić do 1,6. W Azurze w ogóle nie ma to znaczenia, obie maszynki są w tej samej cenie.
Po trzecie, trudniej jest znaleźć programistów dotneta niezżytych z Windowsem. Ten argument pewnie zniknie za 5 lat, ale teraz nie powinno się go pomijać.
Czy wiele firm zaoszczędzi na przenosinach na Linuksa? Jak najbardziej. Czy dla wielu firm będzie to nieopłacalne czy niewykonalne? Pewnie tak. Ale to nawet nie jest meritum problemu. Wieloplatformowość jest super, ale czy trzeba było na kilka lat niemal hamować rozwój dotneta i zaczynać od nowa? Nie można było go stopniowo dostosować do innych platform, przy zachowaniu ciągłości i kompatybilności? Łapię, że autorzy chcieli pozbyć się wielu rzeczy, które uznają za skopane, ale naprawdę nie przemawia do mnie, że przez kilka lat nie mogłem wziąć class library z dotnet frameworka i po prostu użyć na Linuksie.
Ja tam lubię pattern matching i throw expression. Czasem nawet tuple i funkcje lokalne. Tylko tutaj już kładziesz nacisk na C#, a nie .NET, a to temat na inną dyskusję.
To nie chodzi o to, co lubisz, tylko co możesz zrobić, a czego nie mogłeś. Może zaoszczędzę kilka linijek, może kod będzie dla niektórych czytelniejszy, ale HKT dalej nie zrobię, a async dalej polega na kontekście synchronizacji i w blazorze używa jednego wątku, więc trzeba będzie naprawiać deadlocki.
Dla mnie dotnet naprawdę zrobiłby krok naprzód, gdyby pozwolił uruchamiać JVM na CLR. IKVM radzi sobie z wieloma bibliotekami, gdyby otrzymał pełnoprawne wsparcie i ogarnął cglib czy inne haki, to wtedy byłby to naprawdę pokaz możliwości.
1
Po pierwsze, jeżeli aplikacja była w ekosystemie Windowsa, to nie da się jej ot tak przenieść na Linuksa. Jeżeli zaś nie polegała na ekosystemie dawniej, to wobec tych argumentów wybór dotneta był błędem.
Załóżmy że masz typowy dotnet shop - winformy, wpfy, COMy - dlaczego nagle mieliby pisać aplikacje webowe w czym innym?
nie powinno mieć wpływu Nie ma wpływu, o ile programiści piszą kod, który nie polega na jakiejś różnicy między systemami. Nawet głupie nazwy plików, które w Windowsie domyślnie nie biorą pod uwagę wielkości liter, a w Linuksie już tak. O znaczkach nowej linii, ukośnikach w ścieżkach czy kodowaniu plików nawet nie wspomnę, a to zaledwie mikroskopijny początek. Weź gita — na Linuksie działa szybko, na Windowsie bardzo wolno, bo wykorzystuje operację plikową, która w Linuksie jest optymalizowana, a w Windowsie niemal z definicji wolna. Wszyscy znają takie niuanse?
Nawet jeżeli nie znają, to co z tego?
w końcu naprawią to i tyle, nie są to raczej kosztowne bugi.
0
WeiXiao napisał(a):
Załóżmy że masz typowy dotnet shop - winformy, wpfy, COMy - dlaczego nagle mieliby pisać aplikacje webowe w czym innym?
No ale jeżeli używają tych technologii, to nie przejdą na Linuksa, więc co im po wieloplatformowości?
Nawet jeżeli nie znają, to co z tego?
w końcu naprawią to i tyle, nie są to raczej kosztowne bugi.
Wręcz przeciwnie, to są bardzo kosztowne sprawy, bo dotyczą architektury rozwiązania. Na przykład z tego powodu masz WSL2, bo pierwsza wersja próbowała emulować API Linuksa przez API Windowsa i wiele operacji było za wolnych.
0
No ale jeżeli używają tych technologii, to nie przejdą na Linuksa, więc co im po wieloplatformowości?
Skąd te pewniaki? przejdą/nie przejdą.
Widziałem przypadki gdzie przechodzą m.in w celu większej elastyczności dla ich klientów jeżeli chodzi o środowiska.
Na przykład z tego powodu masz WSL2, bo pierwsza wersja próbowała emulować API Linuksa przez API Windowsa i wiele operacji było za wolnych.
Myślę że nie ma co porównywać tego, co chciało zrobić WSL1 z problemami końca linii czy nazwy pliku z którymi walczyliby devowie.
I raczej jestem skłonny twierdzić, że developowanie na Windowsie i deployment na Linuxa jest o wiele częstszym przypadkiem niż develop na Linuxie i deploy na Windowsie - w kontekście tej słabej wydajności fs na Windowsie.
0
WeiXiao napisał(a):
W celu zmniejszenia kosztów oraz większej elastyczności dla ich klientów jeżeli chodzi o środowiska.
Jeżeli aplikacja używa COM-ów, to jak przeniesiesz ją na Linuksa? Nawet pomijając takie szczegóły, to przepisanie aplikacji też jest kosztem i to niemałym. No ale powtarzam ten sam argument w kółko, więc już mi się nie chce tego dalej ciągnąć.
WeiXiao napisał(a):
Myślę że nie ma co porównywać tego, co chciało zrobić WSL1 z problemami końca linii czy nazwy pliku z którymi walczyliby devowie.
Oczywiście, jak pomijasz resztę mojej wypowiedzi, to rzeczywiście wyrwany z kontekstu argument o końcu linii brzmi zabawnie.
WeiXiao napisał(a):
I raczej jestem skłonny twierdzić, że developowanie na Windowsie i deployment na Linuxa jest o wiele częstszym przypadkiem niż develop na Linuxie i deploy na Windowsie - w kontekście tej słabej wydajności fs na Windowsie.
Ale sugerujesz, że problemy są tylko przy przechodzeniu z Linuksa na Windows (bo w Linuksie działa, w Windowsie nie), a w drugą stronę nie ma nic? To chociażby poczytaj, jakie haki robi dotnet na Linuksie w obszarze rezerwowania pamięci. To są problemy, o których mówię, gdy okazuje się, że inna platforma albo wspiera coś bardzo słabo (i w efekcie jest nieużywalne), albo cały koncept tam nie ma zastosowania i trzeba zmieniać architekturę.
1
Jeżeli aplikacja używa COM-ów, to jak przeniesiesz ją na Linuksa? Nawet pomijając takie szczegóły, to przepisanie aplikacji też jest kosztem i to niemałym. No ale powtarzam ten sam argument w kółko, więc już mi się nie chce tego dalej ciągnąć.
oraz w kontekście
Jeżeli zaś nie polegała na ekosystemie dawniej, to wobec tych argumentów wybór dotneta był błędem.
Aplikacje webowe nie polegają na ekosystemie, niemniej jednak mogłeś chcieć je pisać w .NET z tego względu że inne twoje softy (wpfy/winformy/comy) pisałeś oczywiście w .NET i w tej technologii twój zespół jest biegły. No dziwnym byłoby wybranie np. PHP/Javy do aplikacji webowych jeżeli masz zespół programujący w .NET. Oczywiście pomijam skrajne przypadki.
To zapytam tak:
Jeżeli chodzi o web appki, to z jakimi problemami się spotkałeś przy zdeployowaniu aplikacji napisanej pod Windowsem na Linuxa?
Bo mi osobiście użycie API które były OS aware typu Environment.NewLine i bodajże Path.Combine oraz doinstalowanie fontów w Linuxie rozwiązało prawie wszystkie problemy przy takim przejściu.
0
WeiXiao napisał(a):
Aplikacje webowe nie polegają na ekosystemie, niemniej jednak mogłeś chcieć je pisać w .NET z tego względu że inne twoje softy (wpfy/winformy/comy) pisałeś oczywiście w .NET i w tej technologii twój zespół jest biegły. No dziwnym byłoby wybranie np. PHP/Javy do aplikacji webowych jeżeli masz zespół programujący w .NET. Oczywiście pomijam skrajne przypadki.
Sam wymieniłeś COM-y.
WeiXiao napisał(a):
Jeżeli chodzi o web appki, to z jakimi problemami się spotkałeś przy zdeployowaniu aplikacji napisanej pod Windowsem na Linuxa?
Ale to nie o to chodzi, to kompletnie nie jest mój argument. Ja mówię wprost, że wieloplatformowość jest fajna, jednocześnie zadając pytania:
- Dlaczego przez kilka lat nie mogłem odpalać frameworkowych class library na Linuksie? Dlaczego wszystko trzeba było zacząć od zera?
- Jeżeli nie przenoszę się na inną platformę, to co nowego dał mi dotnet przez ostatnie 5 lat?
- Czy jest sens tyle inwestować w poprawę szybkości przy jednoczesnym zachowaniu starego GC (co zdecydowanie utrudnia wejście w big data), starych ograniczeń stabilności (na przykład niezłapany wyjątek ubijający platformę), niespecjalnym rozwijaniu maszyny wirtualnej (kiedy HKT albo sensowne wsparcie fiberów)? Być może „lepsze” byłoby zrobienie czegoś innego
2
Sam wymieniłeś COM-y.
Tak, napisałem
Załóżmy że masz typowy dotnet shop - winformy, wpfy, COMy - dlaczego nagle mieliby pisać aplikacje webowe w czym innym?
i czy jest coś w tym dziwnego?
przecież nie piszesz tylko jednego typu aplikacji,
przecież to że piszesz Winformy/COMy dla klienta X, wcale nie oznacza że klient Y nie chciałby hostować u siebie SuperWebApp na CentOSie, bo nie chce się mu stawiać jednej instancji WinServer dla jednej appki.
Jeżeli nie przenoszę się na inną platformę, to co nowego dał mi dotnet przez ostatnie 5 lat?
Twojemu usecase chyba niewiele.
może OpenSource, ale taki prawdziwy, gdzie możesz ot tak "pogadać" z core devami, a nie - coś tam gdzieś tam na codeplex.
Czy jest sens tyle inwestować w poprawę szybkości przy jednoczesnym zachowaniu starego GC (co zdecydowanie utrudnia wejście w big data), starych ograniczeń stabilności (na przykład niezłapany wyjątek ubijający platformę), niespecjalnym rozwijaniu maszyny wirtualnej (kiedy HKT albo sensowne wsparcie fiberów)? Być może „lepsze” byłoby zrobienie czegoś innego
Chciałbym zasugerować, że jeżeli Maoni majstruje przy GC, to raczej nie wpływa to na pracę Stephena Touba przy Spanowaniu BCL/Runtime
oraz prace tych obu w większości przypadków również nie wpływają na pracę przy Roslyn.
Więc co to znaczy te "tyle inwestować"? te rzeczy mają różna złożoność, różne priorytety, więc mogą być po prostu "soon™" ze względu na złożoność
Spójrz ile poszło na same Nullable Ref Types.
We've put in at least 25 dev-years of effort in the compiler layer alone. This does not include annotating core libraries, IDE experience coding, or anything else that builds on top of the compiler. And there's still more to do.
Jeżeli chodzi o twoje Haskellowe bajery (chociaż nie jestem pewien czy o to akurat chodzi :P), to
Do you wish the .NET IL design supported the Type Classes functionality like Haskell? I wish F# has Type Classes.
What is the possibility of adding F#'s Result<TOk, TError> type as part of the .NET framework, and not tucked beneath under FSharp namespace in the future?
As a member of the C# compiler and language design team, I might be able to offer a bit more insight into questions
I think after we get discriminated union support, new types of types is the next big thing on the radar. We're looking at a number of things, including typeclasses.
I can't speak to whether the BCL will actually add Option or Result types, but we'll hopefully be adding discriminated unions in C# 10, and then you'd be able to declare your own and have them actually work as you expect in C#.
Więc wracając do pytania "co nowego dał mi dotnet przez ostatnie 5 lat?"
może punkt na roadmapie? :) może kroki popełnione w kierunku tych celów?
0
WeiXiao napisał(a):
i czy jest coś w tym dziwnego?
Nie jest. Jedynie kwestia w tym, że może ja chcę zostać na Windowsie (bo coś tam), wtedy cały argument o wieloplatformowości jest dla mnie nieistotny.
WeiXiao napisał(a):
Chciałbym zasugerować, że jeżeli Maoni majstruje przy GC, to raczej nie wpływa to na pracę Stephena Touba przy Spanowaniu BCL/Runtime
oraz prace tych obu w większości przypadków również nie wpływają na pracę przy Roslyn.
Tu raczej jest kwestia, że tylko Maoni majstruje przy GC (no dobra, nie tylko, bo tam jest jeszcze druga osoba w zespole, ale nie znam więcej szczegółów). Dlaczego nie ma sensownego API do podmiany GC (i nie przytaczaj tu tego interfejsu wyciągniętego przez praktykanta parę lat temu)? Przecież gdyby takie było, to można byłoby chociażby kombinować z jakimś otwartym pod Sparka.
WeiXiao napisał(a):
We've put in at least 25 dev-years of effort in the compiler layer alone. This does not include annotating core libraries, IDE experience coding, or anything else that builds on top of the compiler. And there's still more to do.
Hah, to jest akurat świetny argument, bo osobiście uważam, że jest to bardzo mało przydatny element.
WeiXiao napisał(a):
Jeżeli chodzi o twoje Haskellowe bajery (chociaż nie jestem pewien czy o to akurat chodzi :P), to
Nie, akurat nie o to chodziło. Zauważ, że ten element już jest w F#, więc nie jest to ograniczenie dotneta, tylko jakaś tam decyzja priorytetów w języku. Ja mówię o czymś, co jest blokowane przez implementację generyków na poziomie CLR.
WeiXiao napisał(a):
może punkt na roadmapie? :) może kroki popełnione w kierunku tych celów?
No i właśnie o to chodzi, że to tylko punkty. Tak jak mówię, mam nadzieję, że rozpędzą się w najbliższych latach, ale tak samo mówiłem dwa lata temu i niespecjalnie poszło to do przodu.
0
"general purpose" to jest dla mnie tylko na wikipedii
Dla mnie większość technologii ma swoje specyficzne zastosowanie, a reszta niby można ale po co.
A tutaj to jeszcze zrozumiałbym gdy byłaby mowa o C# a nie o samym .Net a to przecież głównie webowka tylko
3
Ej, zaraz to w końcu jak to jest z tą multiplatformowością? Najpierw @somekind i inni pisza "ale przecież C# i .NOT są wieloplatformowe teraz i możesz kodzić na Linuxie!!!1111!!!!" a później C#-powcy sami przyznają że de facto to fikcja, bo jak będziesz C#-powcem to na 99% procent będziesz kodził na windowsie? xD
6
@Aleksander32:
muszę przyznać, że nie wiem z którego postu wywnioskowałeś takie cuda
naprawdę, jestem wręcz pod wrażeniem, że ktoś mógł tak zakrzywić wszystko to, co było tutaj napisane :D
1
@WeiXiao:
Np.
Po trzecie, trudniej jest znaleźć programistów dotneta niezżytych z Windowsem. Ten argument pewnie zniknie za 5 lat, ale teraz nie powinno się go pomijać.
Czyli teoria jest taka że C# działa na Linuxie, w praktyce jakieś 99% firm używa windowsa jako środowiska do developmentu w .NOT
4
@Aleksander32:
To raczej taki skrót myślowy @Afish - chodzi o to, że jeżeli .NET przez np. 15 lat był Windows-only, no to większość devów C# ma doświadczenie z Windowsem, a jako że ta cross-platformowośc jest relatywnie nowa 5? 4? 3? lata, no to jeszcze nie wszyscy na pewno przeszli, ale jaki to jest % trudno ocenić - w moim bubble .NET + non-Windows jest czymś normalnym.
Czyli teoria jest taka że C# działa na Linuxie, w praktyce jakieś 99% firm używa windowsa jako środowiska do developmentu w .NOT
Dlaczego tutaj zaznaczyłeś "do developmentu"? przecież to że developuje na Windowsie, a wdrażam na Linuxa wcale nie ujmuje cross-platformowości, czyż nie? a wręcz na plus.
0
Dlaczego tutaj zaznaczyłeś "do developmentu"? przecież to że developuje na Windowsie, a wdrażam na Linuxa wcale nie ujmuje cross-platformowości, czyż nie?
Masz rację, ale mi chodziło o że programista może preferować korzystanie z Linuxa jako systemu operacyjnego ;) Chociaż tu przyznam się do błędu, sprawdziłem na nofluffjobs i jednak są jakieś oferty dla .netowców z możliwością kodzenia na Linuxie/Macu
2
@Aleksander32:
To bardziej zależy od tego czym zajmuje się dana firma.
Jeżeli chcesz robić GUI na Windowsa - winformy/wpf czy rozszerzenia do innych systemów (jakieś COMy) to raczej nie zrobisz tego z Linuxa/MACa tak prosto/dobrze jak na Windowsie (jeśli w ogóle, nie wiem, nie próbowałem). Na pewno nie pomaga fakt, że zazwyczaj takie aplikacje istnieją już wiele lat i stoją na .NET Framework, a nie np. zostały utworzone na .NET (Core) 5.
Chociaż coś w tym kierunku idzie (GUI) Introducing .NET Multi-platform App UI oraz są już jakieś rozwiązania typu AvaloniaUI, ale nie wiem czy jest to prod ready.
Jeżeli są to aplikacje webowe czy consolki, to nie ma problemu.
1
To może nie strzelajmy - @krwq ty pewnie będziesz się orientował, jak wygląda sprawa korzystania przez "prawdziwych klientów" z .NET na non-Windows? jak się to zmienia z czasem.
Tutaj chyba najlepiej dodać linki z blogu firmy Criteo ("18k containers over 260k CPU cores” a repozytorium “250 repos and 3000 projects"):
https://medium.com/criteo-labs/moving-net-to-linux-at-scale-d8ff49b42661
https://medium.com/criteo-labs/the-net-core-journey-at-criteo-1e47ed87adce
0
Imponujące jak głęboko kopią aby im to śmigało, chociaż ten fragment nie jest za bardzo zachęcający :P
If your workloads are pushing .NET to its limits, you will probably have to build and manage your own Core fork and make it available to your deployments.
szkoda że nie działa to tak out of the box, no ale cóż - skala zobowiązuje ;)
Microsoft did not “just” move to Open Source, the teams are working deeply integrated with the issue/pull request model of GitHub. So don’t be shy and if you find a problem, create an issue with a detailed reproduction and even better, provide a pull request with the fix. Everyone in the community will benefit!
bardzo się cieszę, że to co napisałem w tym temacie odzwierciedla rzeczywistość xD
może OpenSource, ale taki prawdziwy, gdzie możesz ot tak "pogadać" z core devami, a nie - coś tam gdzieś tam na codeplex.
1
Afish napisał(a):
Kolejny argument fajny na papierze, ale niekoniecznie potwierdzony w rzeczywistości (a przynajmniej nie ma statystyk, które by go potwierdzały).
@Afish: owszem, nie mam statystyk. Ale pewnie możesz sobie policzyć prawdopodobieństwo, z jakim taki randomowy programista jak ja, który nie robi kariery w wielkim świecie, ani nie szuka "najnowszych technologii" trafia do firm, które przechodzą takie procesy.
Po pierwsze, jeżeli aplikacja była w ekosystemie Windowsa, to nie da się jej ot tak przenieść na Linuksa. Jeżeli zaś nie polegała na ekosystemie dawniej, to wobec tych argumentów wybór dotneta był błędem.
Błędem z jakiego konkretnie powodu?
Po trzecie, trudniej jest znaleźć programistów dotneta niezżytych z Windowsem. Ten argument pewnie zniknie za 5 lat, ale teraz nie powinno się go pomijać.
Nie bardzo wiem, dlaczego czyjeś prywatne dewiacje miałyby mieć znaczenie w tej dyskusji. Programista nie musi być administratorem, prawdopodobnie nawet lepiej, żeby nie był.
Wieloplatformowość jest super, ale czy trzeba było na kilka lat niemal hamować rozwój dotneta i zaczynać od nowa? Nie można było go stopniowo dostosować do innych platform, przy zachowaniu ciągłości i kompatybilności? Łapię, że autorzy chcieli pozbyć się wielu rzeczy, które uznają za skopane, ale naprawdę nie przemawia do mnie, że przez kilka lat nie mogłem wziąć class library z dotnet frameworka i po prostu użyć na Linuksie.
Pewnie nie trzeba, ale strzelam, że równoczesny bujny rozwój i tworzenie nowej platformy, która ma wspierać wszystkie stare funkcje oraz te nowo dodawane byłoby znacznie bardziej kosztowne. Dla mnie normalne jest to, że soft w pewnym momencie przechodzi w etap supportu, a na nowe, wspaniałe ficzery trzeba poczekać do nowej wersji.
To nie chodzi o to, co lubisz, tylko co możesz zrobić, a czego nie mogłeś. Może zaoszczędzę kilka linijek, może kod będzie dla niektórych czytelniejszy, ale HKT dalej nie zrobię
A co daje HKT?
Dla mnie dotnet naprawdę zrobiłby krok naprzód, gdyby pozwolił uruchamiać JVM na CLR.
Trochę nie rozumiem celu tej incepcji. Co by to komu dało?
Afish napisał(a):
Nie jest. Jedynie kwestia w tym, że może ja chcę zostać na Windowsie (bo coś tam), wtedy cały argument o wieloplatformowości jest dla mnie nieistotny.
Odbijając piłeczkę - tu nie chodzi o to, co jest dla Ciebie nieistotne. :)
Możliwość cięcia kosztów w biznesie jest istotnym czynnikiem, biznes to robi, a biznes to też źródło naszych zarobków.
Aleksander32 napisał(a):
Np.
Po trzecie, trudniej jest znaleźć programistów dotneta niezżytych z Windowsem. Ten argument pewnie zniknie za 5 lat, ale teraz nie powinno się go pomijać.
Czyli teoria jest taka że C# działa na Linuxie, w praktyce jakieś 99% firm używa windowsa jako środowiska do developmentu w .NOT
@Aleksander32: Najpierw napisałeś, że siszarpowcy twierdzą, że coś jest fikcją, a potem cytujesz kogoś, kto nim nie jest. Ponadto, nawet jeśli nikt nie programuje w .NET na Linuksie, to nie zmienia faktu, że można to robić, więc generalnie coś nie wyszła ta argumentacja.
Znacząca część programistów Javy też siedzi na Windowsach, bo taka polityka korpo, i co z tego?