ergo: w .necie jest wybór między microsoftem, a microsoftem, nawet jeśli @somekind twierdzi inaczej :)

@Wibowit: to dobrze czy źle? bo imo na plus ;)

@somekind twierdził, że jest wręcz odwrotnie, tzn. w .necie jest wybór, a w javie jest tylko spring. w zasadzie to tylko się droczę :) jakoś specjalnie mi się nie chce zastanawiać co jest lepsze, ale wydaje mi się (z naciskiem na 'wydaje'), że jeżeli mamy rozwiązania od różnych dostawców to jest mniejsza szansa, że zostaniesz na lodzie, gdy wejdzie coś nowego.

@Wibowit: no ale druga skrajnosc ze przechodzac przez 5 projektow napotykasz 5 roznych libek do http/orma/blabla tez jest słaba :D

Nikt, kto komercyjnie zajmuje się .net nie interesuje się tym. To jak debatowanie o aborcji - nic nie warte i nie zmieniające mielenie językiem.

W .NET jest spory wybór bibliotek do wszystkiego, a jeśli Microsoft zrobi kolejną, to wybór jeszcze zwiększy. Sugeruję odstawić butapren - w tym wieku działa ze zdwojoną siłą.

Natomiast porównywanie MassTransit z MediatR brzmi intrygująco - według jakich kategorii niby?

@somekind: podeślesz bibliotekę do mqtt ze wsparciem dla v5 i QUIC :) ?

Jak dla mnie to nic nie zmieni, nowe projekty może tego użyją a może nie. Dużo osób jest przyzwyczajona do masstransita albo mediatR i nie będzie im się chciało nad tym pochylać.

Walczcie z jakimkolwiek microsoftowym produktem. W C++ swego czasu królowało WINApi i jest to najgorsza biblioteka jaką wyszła z ramienia tej firmy, która była rakiem tego języka przez spory okres dopóki QT nie nabrało popularności.

Przecież QT wrappuje WinApi. QT można porównać co najwyżej do WinForms, WPF, MFC, VCL, LCL etc. Używając QT i tak jest wołane WinApi. WinApi to coś jak X11.

No tak i dzięki temu mamy prostsze życie.

@Schadoow: nie wiem co to v5 i QUIC ani jak to się ma do tematu.

@somekind: W .NET jest spory wybór bibliotek do wszystkiego no właśnie jest biedny. V5 to wersja protokołu mqtt a QUIC to sobie wpisz HTTP/3 + QUIC

@Schadoow: To jednak jakaś nisza. Na jakich platformach znajdziesz bibliotekę do MQTT v5 ze wsparciem QUIC? W Go nie widzę, w Rust nie widzę. Na JVM też na szybko nie znalazłem.

@some_ONE: tak tak wszystko czego nie ma w .net to nisza :p. Dla c i eralnga masz natywnie dla pythona i javy masz bibilioteki które są bindinigem na tą bibliotekę w C ale są gotowe. Z innych bibliotek które ostatnio kopnął mnie brak dla .net to np https://ngrok.com/docs/agent-sdks/ . Jakoś mam takiego pecha, że jak mam zrealizować(solution +HLD bo nie pisze w .NET) jakiś projekt w .net to jest zawsze jebanie się z brakiem sdk :p. W sensie jezeli mam przetestowane rozwiązania dla javy,js czy go to najczęściej w przypadku .NET pojechanie schematem mi sie nie uda :p.

@Schadoow: tak tak wszystko czego nie ma w .net to nisza ja tego nie powiedziałem. A czy MQTT over QUIC to nisza czy nie można zweryfikować sprawdzając ile brokerów MQTT w ogóle to wspiera. Strzelam, że jakiś 1 na 10 (albo i nie). Oczywiście nie sprawdzałem.

@Schadoow: mianem "wszystkiego" określiłem typowe potrzebne do pracy rzeczy, nie wszystkie możliwe protokoły świata. Ok, powinienem był może inaczej się wyrazić, ale po prostu czepiasz się słówek w tym momencie - bo nie o tym wszakże jest ten wpis.