Jaki język programowania bez null/nil w 2024?

Zdaniem niektórych C#, tylko wystarczy w nim wyłączyć null i po sprawie.

Scala, a jeśli jednak aspekty funkcyjne okażą się zbyt hardkorowe, to Kotlin - https://kotlinlang.org/docs/null-safety.html#0

Zależy co rozumiesz przez null, bo różne języki rozumieją to inaczej.

Niektóre rozumieją to jako "reprezentacja braku obiektu". Inne jako super typ wszystkich typów. Jeszcze inne jako odrębny byt, prymityw z jedną wartością (taki upośledzony bool). Musiałbyś powiedzieć na jakich cechach "null"a Ci zależy, a na jakich nie.

Kotlin

A co chcesz robić? Od tego chyba należy zacząć. Do niskopoziomowych chyba Rust nie ma konkurencji (zważywszy na twoje wymaganie). Z wysokopoziomowych Haskell.

do rusta, ale składnia mi się nie podoba.

Dość słaby argument. Z doświadczenia, to może być wręcz argument za tym, żeby spróbować. Jeśli składnia Ci się nie podoba to znaczy prawdopodobnie, że to coś nowego. Tak więc pewnie zmieni to twoje myślenie o programowaniu. :) Natomiast warto zwrócić uwagę na założenia projektu: brak GC, focus na wydajność i poprawność kodu. Jeśli się z tym nie zgadzasz to Rust nie jest dla Ciebie.

Ogólnie to dziwne, że ludzie rezygnują z języka dlatego, że składnia się różni o kilka procent od tego, co znają. Rust to dalej składnia mainstreamowa (co innego np. Haskell). Pewne rzeczy nie zawsze są intuicyjne i czasem jest przegadanie albo koncepcje typu lifetime’y, które trzeba uwzględnić w deklaracjach, ale… gdyby ludzie nie uczyli się języka, bo w składni jest coś, co im się nie podoba, to każdy programista znałby tylko 1 język i nigdy by się nie nauczył innego, nawet HTMLa. Bo każdy kolejny język będzie wnosił pewną odmienność.

elwis napisał(a):

do rusta, ale składnia mi się nie podoba.

Dość słaby argument. Z doświadczenia, to może być wręcz argument za tym, żeby spróbować. Jeśli składnia Ci się nie podoba to znaczy prawdopodobnie, że to coś nowego. Tak więc pewnie zmieni to twoje myślenie o programowaniu. :) Natomiast warto zwrócić uwagę na założenia projektu: brak GC, focus na wydajność i poprawność kodu. Jeśli się z tym nie zgadzasz to Rust nie jest dla Ciebie.

Tzn. sam przymierzam się do nauki rusta i przykładowo jeszcze nie widziałem języka który tak by skomplikował pracę z czymś tak podstawowym jak enumy że trzeba o porównanie wartości enuma pytać na stackoverflow ;)
https://stackoverflow.com/questions/51429501/how-do-i-conditionally-check-if-an-enum-is-one-variant-or-another

Ale zgadzam się że przede wszystkim język wybiera się ze względu na zastosowanie, dostępność frameworków i społeczności w tym kierunku. Choć kotlina da się użyć do pisania apki desktopowej, rusta do webdevu, c# do machine learningu a scalę do apek mobilnych to nie polecałbym żadnej z tych opcji.

LukeJL napisał(a):

Rust to dalej składnia mainstreamowa (co innego np. Haskell).

Myślę, że to jest dość dyskusyjna sprawa. Może jest sporo nawiązań do innych języków, są klamerki, ale wiele rzeczy jest innych, a wiele rzeczy, które wydają się być znajome znaczą właściwie coś zupełnie innego. Na przykład model objektowy jest zupełnie inny niż w językach takich jak Java czy C++. Tak naprawdę dobry kod w Ruscie, dla kogoś kto nie kodował w Scali ani Haskellu prawdopowobnie nie będzie zbyt czytelny na początku.

obscurity napisał(a):

Tzn. sam przymierzam się do nauki rusta i przykładowo jeszcze nie widziałem języka który tak by skomplikował pracę z czymś tak podstawowym jak enumy że trzeba o porównanie wartości enuma pytać na stackoverflow ;)

Komplikacje w składni Rusta wynikają głównie z trzech powodów:

• poprawność kodu wymaga pisania rzeczy, których często z lenistwa nie piszemy. Więc np. zalecaną formą sprawdzania enuma jest match, który wymaga podania wyniku dla każdej możliwej wartości. Chociaż rzeczywiście można po prostu zrobić #[derive(PartialEq)], przynajmniej jeśli enum nie korzysta typów, które tego nie implementują. Pewnie dlatego nie jest to domyślne (tym bardziej, że stosunkowo rzadko enumów używa się bez pól, wtedy PartialEq ma najwięcej sensu).
• jasność i kontrola nad wydajnością wymaga, żeby wszystko co powoduje narzut wydajnościowy wymaga takiego lub innego oznaczenia w kodzie. Np. alokacja na stercie będzie zaznaczona przez Box<>, a użycie vtable słowem kluczowym dyn.
• Brak GC ani manualnej alokacji pamięci wymaga tych wszystkich cyrków z lifetimami. Gwarancje memory safety z kolei wymagają reżimów referencji (borrow checker).

Z mainstreamowych poza Rustem to został Ci tylko Haskell (z godnych uwagi).
Z tym, że jeżeli składnia Rusta Ci przeszkadza, to i Haskell może Ci nie podejść, bo strzelam, że problem jest raczej w "jak coś nie wygląda jak C/C++" to jest nieczytelne. (Java, C#, JS - też się wilicza)

obscurity napisał(a):

No rozumiem to wszystko, niemniej w podstawowym użyciu powinny zachować moim zdaniem zachowanie z innych języków. Czemu nie mogą mieć domyślnie tego #[derive(PartialEq)]?

Bo domyślny equals (i hashCode) to zło znane np. z javy (i nie tylko).

Jeśli wszystkie obiekty mają equals to nic nie powstrzymuje programisty przed wpakowaniem czegoś głupiego do Set czy HashMapy, a potem mamy w najlepszym wypadku słabą wydajnośc, wycieki pamięci, a najgorszym subtelne / trudne do znalezienia bugi w logice. Szczególnie, że domyślność tego equals powoduje, że programiści nawet nie zdają sobie sprawy z istnienia jakiegoś problemu.

Tym niemniej jakaś ergonomia - w stylu, jesli moje obiekty są trywialne, to można domyślnie wygenerować PartialEq (on demand) i dodać tylko ostrzeżenie byłaby w porządku.

Od 2 lat moim głównym językiem jest kotlin i bardzo sobie cenię. Przyjemnie się pisze, przyjemnie się czyta. Jest relatywnie prosty i jak się zna javę to grzechem jest nie spróbować.

Grzyboo napisał(a):

Od 2 lat moim głównym językiem jest kotlin i bardzo sobie cenię. Przyjemnie się pisze, przyjemnie się czyta. Jest relatywnie prosty i jak się zna javę to grzechem jest nie spróbować.

Jestem w sumie troche fanboyem kotlina, ale nie uważam, że jest bardzo godny uczenia się.
To taka trochę Scala--, a Scala to taki Haskell po roku na Podlasiu.
Oba Scala i Kotlin są dość praktyczne, (ze względu na biblioteki + jvm), ale nie są po prostu ciekawe (nie są wystarczająco innowacyjne ani eleganckie).
Kotlin ma do tego trochę pecha być za blisko javy, więc łatwo utkwić w jakieś patologii - typu kotlin ze springiem, gdzie niby masz nowoczesny dość funkcyjny język, a kod jest i tak na poziomie visual basica.

Jakkolwiek, jeśli w perspektywie jest java vs kotlin, to nie ma nad czym się zastanawiać.

C, ale zamiast NULL to wpisuj 0.

Assembly.