Mnie jakoś całko omineło. Ale wchodzę na Tiobe Index, a tam
the new Google language Carbon enters the TIOBE index at position 192
słyszał ktoś? Na co to komu? Po co to komu? I dlaczego nie Rust?
0
4
C++ ze wszystkimi nowościami ze wszystkich nowych wersji to skomplikowany potwór pełen starych niedopatrzeń, które teraz trzeba trzymać ze względu na kompatybilność wsteczną, w rodzaju tego, że zgodność ABI uniemożliwia modyfikowanie implementacji biblioteki standardowej. Tym niemniej istnieje potężny ekosystem, multum bibliotek i gotowego kodu i trochę tego szkoda. Stąd idea Carbona - ma być nie tyle zastępstwem dla C++ (bo tu faktycznie jest Rust), a nowoczesnym językiem, który pozwalałby na bezpośrednie uruchamianie starego kodu C++ i łączenie obu języków. Czyli to coś w rodzaju Kotlina dla Javy.
Patrz również sekcja Why build Carbon w Readme, oraz sekcję What alternatives did you consider? Why did they not work? w FAQ.
0
Hm, zastanawiam się jak trudna do stworzenia jest ta "interoperacyjności z C++" że nie można jej dodać do już istniejących języków jak Rust, Go czy Dart tylko trzeba tworzyć kolejny jezyk programowania. Czy jakiś język potrafił wywoływać kod w C++ czy zawsze idzie to przez protezę zgodności z C?
UPDATE Ciekawe, czytam że ciężko, hm
1
D umie wywoływać C++, ale i tak tylko częściowo. Problem jest taki, że jeśli chcesz mieć zgodność z C++ to potrzebujesz mieć pełen kompilator C++ wbudowany w kompilator twojego języka, trochę się to mija z celem, zwłaszcza, że C++ jest bardzo skomplikowanym językiem.
0
hauleth napisał(a):
Problem jest taki, że jeśli chcesz mieć zgodność z C++ to potrzebujesz mieć pełen kompilator C++ wbudowany w kompilator twojego języka
No ale jakby jako podstawę wziąć Clanga z LLVM i swój kompilator też oprzeć na LLVM to już chyba jakiś punkt styku jest?
Swoją drogą cielawe czy teraz w googlo też wszystko piszą od początku jak dla go czy jednak się ugieli i uzyją istniejącego kompilatora, np wyżej wspomnianego Clang + LLVM
UPDATE patrząc po repo chyba się ugieli i uzyli LLVM. No to teraz rozumiem czemu nie mogą tego połączyć z Go
1
KamilAdam napisał(a):
Hm, zastanawiam się jak trudna do stworzenia jest ta "interoperacyjności z C++" że nie można jej dodać do już istniejących języków jak Rust, Go czy Dart tylko trzeba tworzyć kolejny jezyk programowania. Czy jakiś język potrafił wywoływać kod w C++ czy zawsze idzie to przez protezę zgodności z C?
UPDATE Ciekawe, czytam że ciężko, hm
Fajne pytanie.
C++ ma wiele rzeczy tak ogromnie specyficzne dla siebie (np obok dyskutowane bardzo rozwinięte templejtki), że ciężko uwierzyć w przenośność, zwłaszcza że np templejtkowanie nie ma prawie nic do binarnej kompatybilności, to w 99.5% operacje na sursach (biblioteka boost niemal nie ma modułów CPP, wyłącznie HPP)
EDIT: klasyczny maszynowy call, tablica funkcji wirtualnych, new, jakaś forma sprzątania, to pewnie jakimś wysiłkiem by się dało uzyskać kompatybilność, tyle że to szkolne C++ sprzed lat 20, a nie współczesność w profesjonalnych rękach.
Np w stajni Borland / Embecadero nigdy nie było nawet próby integracji templejtek z innym jezykiem (Delphi) (na marginesie: a cała integracja bardziej przez nagięcie C++ aby było komaptybilne)
3
No ale jakby jako podstawę wziąć Clanga z LLVM i swój kompilator też oprzeć na LLVM to już chyba jakiś punkt styku jest?
I kończysz jak C++ z kompatybilnością z C, gdzie ogranicza Ciebie istniejący kod oraz to, że musisz współpracować z C++. Na tym polega cały problem, albo będziesz miał współczesny język z nowymi rozwiązaniami, albo będziesz ograniczony starszą technologią. Nie ma specjalnie innego rozwiązania, zwłaszcza w przypadku języków tak rozbudowanych i skomplikowanych jak C++.
2
Cel to posiadanie nowoczesnego języka, który jest maksymalnie kompatybilny z C++ w obie strony. Czyli coś jak kotlin dla javy a nie jak scala dla javy. I w sumie to tyle, autorzy piszą, że gdy nie potrzebujemy kompatybilności z C++ to lepiej użyć coś innego