[Oo-oO]

Ktoś może być ciekawy, czy może być coś gorszego, widywanego niekiedy np w #programowanie #embedded niż pisanie w C++ w taki sposób jak pisało się w C.
Otóż może!

Abominacja glib, gdzie pisze się w C które wygląda jak C++. g_autoptr(GError) error = NULL; masakra jakaś.

Szkoda mi że w #rustlang jest tylu oszołomów i fanboyów - język jest spoko, można go polubić, ale ta "kultura" z nim związana jest imho nieprzyjemna.

[Krolik]

Przecież fanboizm w Rust to niewielki ułamek tego co jest w Go. I na dodatek jest uzasadniony, bo język faktycznie rozwiązuje pewne problemy, których na razie nie rozwiązuje żaden inny język.

Jak na r/rust na Reddicie spytasz, czy Rust jest dobry do pisania webappek na szybko to ci ludzie napiszą uczciwie że ujdzie, ale język jest dość trudny i takie coś dużo lepiej napisać w czymś co znasz. I np. polecą ci

[Oo-oO]

@Krolik: a tego co jest w Go to w ogóle ani nie wiem, ani nie śledzę - miałem jedno podejście do Go i nie przypadło mi to do gustu. Znaczy, dobrze rozumiem, że twierdzisz że fanboizm jest uzasadniony? :D

Czekam na Ziga - póki co mnie jeszcze nie przekonuje, choć podzielam ich motywacje.

Wiesz, stosując analogię do tego co piszesz wyżej, jak na konwencie Linuxowym była spina o bindingi Rust-C,

[Rosly]

@Oo-oO: zerkij sobie jak wygląda kod w kernelu Linuxa

[Oo-oO]

@Rosly: wiem jak wygląda kod w kernelu, nawet coś tam sam napisałem. Zerknij sobie jak wygląda dowolny kod embedded w Ruście.
Możemy się przerzucać podobnymi bezsensownymi uwagami, ale niewiele to wnosi do tematu.

[Krolik]

@Oo-oO: No ale w aferze kernelowej Rust vs C to przecież chodzi o to że to właśnie ludzie którzy piszą w C nie mają ochoty uczyć się Rusta i wyrazili obawy, że jak zmienią coś po stronie C to część w Rust przestanie działać. Developerzy Rust powiedzieli, że spoko, nie ma sprawy, oni to biorą na siebie i poprawią, pod warunkiem że część w C będzie przyzwoicie udokumentowana. Bo w

[sorek]

widywanego niekiedy np w #programowanie #embedded niż pisanie w C++ w taki sposób jak pisało się w C.

@Oo-oO: przecież C++ pisane jak C to właśnie najlepsza rzecz. C++ to miało być C z klasami i QOL rzeczami a obecnie ten język jest zasrany.

Jak piszesz jak w C to kod jest dużo bezpieczniejszy (zwykle) i

[Krolik]

@sorek: przecież Zig nie rozwiązuje tych samych problemów co Rust, więc jak to w ogóle porównywać? Zig nie jest nawet memory safe. No i niech wreszcie osiągnie stabilność, bo na razie to zabawka dla entuzjastów niezdatna na produkcję.

[zarowka12]

bo w C nie da się praktycznie nie robić dziur

@Krolik: i dlatego właśnie kernel jest pełen dziur! Sorry, ale nie mogłem się powstrzymać. C pozwala popełniać pewne błędy, których gdzie indziej nie dałoby się zrobić. Ale to nie znaczy, że nie da się w nim pisać bezpiecznego kodu, ani że wymaga to jakiejś eksperckiej wiedzy. Nie jest też tak, że błędy związane z zarządzaniem pamięcią są jakąś plagą i

[Rosly]

@Oo-oO: nie zrozumiałem co jest bezsensownego w moim argumencie?

[Krolik]

@zarowka12:

Nie jest też tak, że błędy związane z zarządzaniem pamięcią są jakąś plagą i zmiana języka wprowadzi rewolucję.

No właśnie dokładnie tak jest.
Są badania z Google i Microsoft, wskazujące że około 60% podatności w systemach to błędy zarządzania pamięcią. Co więcej, Google również opublikował niedawno raport [1] że odkąd systematycznie zwiększają udział bezpiecznych języków w systemie Android, liczba podatności spada. Android posiada obecnie już pokaźną ilość kodu Rust (znacznie

[Krolik]

@sorek:

https://news.ycombinator.com/item?id=25623634

Przy czym chodzi mi o dyskusję w komentarzach, nie same benchmarki, bo one się zwykle nie przekładają na idiomatyczny kod. Idiomatyczny kod w safe Rust jest szybszy niż idiomatyczny kod w C. Unsafe nie daje praktycznie nic w kwestii wydajności.

[Oo-oO]

@Rosly: rzuciłeś jakieś stwierdzenie "zajrzyj sobie do źródeł kernela" i nie wiadomo o co ci chodzi, czy miało to być nawiązanie do C/C++, czy może do kultury w Ruście, nie wiem. Zinterpretowałem to "kod w kernelu jest ujowy" - bo nie wyraziłeś innego zdania, ale dalej nie bardzo wiem co to ma do rzeczy.

@sorek pisanie w C++ jak w C moim zdaniem jest pomyłką. Ani programiści C nie

[sorek]

pisanie w C++ jak w C moim zdaniem jest pomyłką. Ani programiści C nie są zadowoleni ani ci od C++. Kastrujesz w taki sposób język z możliwości które tam zostały dodane.

@Oo-oO: ale niektóre możliwości są dość głupie i to co się dzieje po C11 jest wręcz dziwne.

Główny problem C to to, że musisz dużo boilerplate produkować, C++ to ukróca przez QOL (nawet samo function overloading z default wartościami). Według mnie

[Oo-oO]

@sorek: trochę mnie zgubiłeś - a co się wielkiego dzieje w C po C11, nie śledziłem za bardzo? C++ się mocno zmieniło, C moim zdaniem niewiele. Zdaje się wprowadzili możliwość inicjalizowania struktur tą składnią z kropką, albo mi się coś pomyliło :) Tzn pamiętam że kiedyś to sprawdzałem, ale potem mi jakoś wyleciało z głowy. Zdaje się coś z dynamicznymi tablicami było jeszcze.

Ano, boilerplate w C istnieje. W ogóle

[sorek]

a co się wielkiego dzieje w C po C11

@Oo-oO: chodziło mi o C++11 sorki.

Jedynym moim problemem z C/C++ to właśnie system zarządzania bibliotek oraz fakt że wszędzie masz te archaiczne rozróżnienie na .h/hpp i .c/cpp pliki. Pod tym względem nowoczesne języki mają zdecydowanie przewagę.

Ale dlatego preferuje C++ od czystego C bo on daje niemalże nieskończoną abstrakcje tworzenia i zastępowanie starych modułów/structów często staje się mega łatwe dzięki

[Oo-oO]

@Krolik:

Gdzie, kiedy i kto tak twierdził, szczególnie w kontekście dyskusji dotyczącej użycia Rust w kernelu?

nie zapisuję takich stwierdzeń, a i część padła na konferencjach - pewnie da się wyszukać je w necie bo często są nagrywane; z drugiej strony często są też przycinane więc nie wszystko da się wychwycić. Nie mówiłem też że tylko w tym kontekście, a ogólnie.
Mogę się mylić - ale ja to jakoś odebrałem że

[Krolik]

@Oo-oO: No bo generalnie jeśli ktoś coś zmieni i złamie kompatybilność wsteczną to zasada jest że poprawia wszystkie zależności w dół. Zawsze tak było. Różnica jest taka, że w przypadku Rust dużo bardziej prawdopodobne jest że dostaniesz w takiej sytuacji błąd kompilacji niż że wprowadzisz błąd, który wywali kernel lub otworzy dziurę.

twierdzenie że wszystko jest źle i trzeba robić po naszemu.

Nie, nikt nie twierdzi że wszystko jest źle. Ale