Szybkie porównanie wybranych cech obu języków.
Dużo podobieństw
Załóżmy, że ktoś nagle zostaje wrzucony do projektu prowadzonego w Ruby on Rails a większość jego dotychczasowych programistycznych doświadczeń dotyczy Pythona (albo odwrotnie). To z pewnością rodzi masę porównań i spostrzeżeń. Python i Ruby są bardzo podobne. Oba są interpretowanymi, dynamicznie typowanymi językami ogólnego przeznaczenia. Istnieją pewne podobieństwa w składni a co więcej, oba języki są dość podobne w implementacji:
- Możesz pisać rozszerzenia w C.
- Oba zostały skompilowane do kodu bajtowego; interpretery tak Pythona jak i Rubiego są w zasadzie gigantyczną i przez to wręcz fascynującą instrukcją switch w C.
- Oba interpretery są nękane przez Global Interpreter Lock (GIL, GVL), który uniemożliwia współbieżne wykonywanie kodu.
Ale Python i Ruby zajmują dziś różne przestrzenie: twierdzą Pythona jest data science, podczas gdy Ruby jest nierozerwalnie związany ze strukturą Rails. Ale czy takie zaszeregowanie nie jest czasem w sumie przypadkowe? Przecież równie dobrze mogłoby być na odwrót; projekty tych języków są tak podobne, że równie dobrze możemy wyobrazić sobie świat, w którym Python jest lingua franca do tworzenia stron internetowych, a Ruby ma wszystkie biblioteki do machine learningu.
Składnia lepsza w Ruby?
Składnia Rubiego jest zwięzła. Programowanie obiektowo jest wprowadzone konsekwentnie: w Rubim po prostu tworzysz strukturę swojego kodu za pomocą klas i metod. W Pythonie OOP jest opcjonalne i bo projektanci nie byli jego fanami. Musisz się więc obejść bez słowa private i reszty obiektowego slangu.
Ruby ma opinię języka, który zezwala na zrobienie tego samego na wiele sposobów. Ale też trzeba zauważyć, że bloki w Rubim zajmują tak uprzywilejowaną pozycję w składni języka, że jesteście po prostu zachęcani do użycia ich w projekcie interfejsu.
Sprawdź oferty pracy na TeamQuest
Nie macie wrażenia, że Rubi wymaga od Was podejmowania mniejszej ilości decyzji, nazwijmy to - technicznych? Z drugiej strony, Ruby idzie chyba trochę w za dużą zwięzłość. Prawie zawsze istnieją różne sposoby wyrażania podstawowych pojęć składniowych. A programiści Ruby mają wręcz talent czy tendencję do przeładowanych jednoliniowców, niczym w Perlu.
Generatory punktem dla Pythona?
Mówi się, że warto się nauczyć języka programowania, jeśli zmienia on sposób myślenia. Jeśli chodzi o Pythona, to to co się przydaje i zmienia mentalność programisty to generatory. Szczególnie w przypadku przetwarzania danych użycie generatorów jest naturalne (i wydajne pod względem pamięci). Generatory stopniowo ewoluowały, aby stać się podstawą asynchronicznych korutyn (coroutines) we współczesnych wersjach Pythona. Ale Ruby 3.0 zawiera też Fibers, stanowiący wyraz bardzo podobnej koncepcji, co oznacza, że Pythonowiec wdrażający się w Ruby’ego nie będzie musiał długo tęsknić za generatorami.
Ekosystem
Język open source żyje i umiera wraz ze swoją społecznością i ekosystemem. A Ruby wydaje się być tutaj w niekorzystnej sytuacji, ponieważ jest to dobrze znany język, ale raczej niszowy w miejscu pracy i często nieobecny w 10 najlepszych rankingach.
Z drugiej strony, narzędzia i biblioteki w tym języku są bardzo dojrzałe. Wydaje się, że Ruby skupia się zaledwie na kilku kluczowych projektach, ale są one naprawdę solidne. Jeśli z kolei chcesz w Pythonie napisać aplikację internetową albo napisać zestaw testów BDD to prawie zawsze będziesz miał do wyboru wiele możliwości realizacji takiego zadania.
Jest pewna korzyść w tym skupieniu się na kilku kluczowych bibliotekach open source: podczas gdy deweloperów Ruby jest wciąż niewielu, kiedy masz możliwość porozmawiania z jednym z nich, zwykle mają oni doświadczenie w co najmniej 80% technologii, z których korzystasz w tym języku.
