Rust wybór IDE między Intellij lub PyCharm

Odpowiedz Nowy wątek
2019-07-29 16:01
0

W czym na co dzień programujecie pod Rust? Zakochałem się w tym języku programowania, jak dla mnie i wielu innych osób jest to obecnie najlepiej zaprojektowany język programowania.

A co to za różnica, przecież obydwa są od JetBrains. - lion137 2019-07-29 17:52
Chyba tylko w lekkości, Intellij ma więcej dodatków których nie da się odinstalować. - sanny 2019-07-29 17:54
Zarówno IntelliJ jak i PyCharm bazują na IntelliJ Platform, tzn to jest to samo IDE tylko inaczej skonfigurowane i z innym zestawem domyślnie zainstalowanych wtyczek. - Wibowit 2019-07-29 18:47

Pozostało 580 znaków

2019-07-30 19:53
0

Memory corruption w czystej Javie (bez sun.misc.Unsafe) nie dostaniesz

Możesz mieć np. dwa wątki próbujące uzyskać niesynchronizowany dostęp do zasobu (np. próbujące zmodyfikować to samo pole) - jeśli podpada to pod definicję memory corruption.

Porównujmy jednak jeżyny do jeżyn - Rust celuje w nisze C++-o-podobne, gdzie 70% wszystkich bugów związanych jest z dostępem do pamięci; większości z tych błędów (jeśli nie wszystkich) nie da się odtworzyć w tzw. safe Rust.

Rustowy borrow checker nie zapobiega np niepoprawnemu kodowi typu:

Nie zapobiega i nie może zapobiegać - mimo XXI wieku kompilatorom ciężko idzie czytanie w myślach, a przytoczony przez Ciebie kod równie dobrze może mieć jak najbardziej oczekiwane zachowanie.

Nie zmienia to faktu, że borrow checker zapobiega pewnej znaczącej klasie błędów (patrz wyżej: 70%), czyli jest good enough.

W Javce wszystkie kolekcje są w 100% oparte na bezpiecznym kodzie

Przytoczony przez Ciebie kod jest całkowicie bezpieczny - ułomność borrow checkera tego nie zmienia.

Należy mieć na uwadze, że celem Rusta nie jest bycie 100%-unsafe-free, a kompromisy - w porównaniu do C++, gdzie wszystko jest legalne, w Ruście podejrzany kod owijasz w blok unsafe i wtedy wiesz, którym fragmentom należy zwrócić szczególną uwagę w trakcie PR oraz ich wykorzystywania, jakie inwarianty muszą zostać spełnione itd.

Co jeśli chcę by 5 wątków miało referencję do tego samego obiektu? Wszystkie 5 muszą mieć Arce. Słabe rozwiązanie.

Dla mnie jest to dobry kompromis - spróbuj zrobić podobną akcję ze structural sharing w C++ :-)

chyba, że jednak pokażesz mi że można mieć wydajne wielowątkowe structural sharing w Ruście bez bloków unsafe i jakiegoś ręcznego zarządzania pamięcią.

Istnieje biblioteka im-rs, która zawiera raptem kilka bloków unsafe - dla porównania do C++ znalazłem immer, które zawiera potencjalnie unsafe w każdej linijce kodu.

Ogólnie rzecz biorąc porównywanie Rust ze Scalą uważam za tani chwyt marketingowy - gdyby Rust działał na maszynie wirtualnej, cały ten "niebezpieczny" kod można by przenieść do środka VMki i chwalić się patrzcie, nasz Rust 2.0 nie ma ani jednego unsafe!. Nie ma, bo cały jest wewnątrz VMki - dokładnie tak, jak ma to miejsce z Javą.


edytowany 2x, ostatnio: Patryk27, 2019-07-30 19:55

Pozostało 580 znaków

2019-07-30 20:26
0

Możesz mieć np. dwa wątki próbujące uzyskać niesynchronizowany dostęp do zasobu (np. próbujące zmodyfikować to samo pole) - jeśli podpada to pod definicję memory corruption.

Wydaje mi się, że nie podpada.

Porównujmy jednak jeżyny do jeżyn - Rust celuje w nisze C++-o-podobne, gdzie 70% wszystkich bugów związanych jest z dostępem do pamięci; większości z tych błędów (jeśli nie wszystkich) nie da się odtworzyć w tzw. safe Rust.
Należy mieć na uwadze, że celem Rusta nie jest bycie 100%-unsafe-free, a kompromisy - w porównaniu do C++, gdzie wszystko jest legalne, w Ruście podejrzany kod owijasz w blok unsafe i wtedy wiesz, którym fragmentom należy zwrócić szczególną uwagę w trakcie PR oraz ich wykorzystywania, jakie inwarianty muszą zostać spełnione itd.

No w porównaniu do C/ C++ Rust wygląda OK, ale dalej cudów nie ma, bo języków programowania jest dużo więcej.

Istnieje biblioteka im-rs, która zawiera raptem kilka bloków unsafe - dla porównania do C++ znalazłem immer, które zawiera potencjalnie unsafe w każdej linijce kodu.

No i jak przeczuwałem są osobne wersje oparte o Rc i Arc. Ciekawe byłyby wyniki benchmarków przy przetwarzaniu wielowątkowym.

Ogólnie rzecz biorąc porównywanie Rust ze Scalą uważam za tani chwyt marketingowy - gdyby Rust działał na maszynie wirtualnej, cały ten "niebezpieczny" kod można by przenieść do środka VMki i chwalić się patrzcie, nasz Rust 2.0 nie ma ani jednego unsafe!. Nie ma, bo cały jest wewnątrz VMki - dokładnie tak, jak ma to miejsce z Javą.

No niespecjalnie. Taki Vec::split_off to typowa funkcja biblioteczna, a nie jakaś niskopoziomowa operacja, która nadaje się do wbudowania w VMkę. Zauważ, że całe kolekcje w Javie są napisane w Javie, a nie np w C jak w CPythonie. W Javie unsafe kod jest w zasadzie potrzebny tylko do FFI albo optymalizacji wydajnościowej. Memory safety w Javie jest osiągnięte bez upierdliwego borrow checkera, więc skoro borrow checker w Javie nie istnieje to nie trzeba używać unsafe by go obejść. Oczywiście da się kombinować w Ruście jak koń pod górę by unikać unsafe, tylko czy efekt jest warty zachodu? Może w pewnych przypadkach warto zmienić język?


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2019-07-30 20:41
0

No i jak przeczuwałem są osobne wersje oparte o Rc i Arc.

I całkiem słusznie, ponieważ są to dwa odmienne typy o różnych zastosowaniach.

Zauważ, że całe kolekcje w Javie są napisane w Javie

Vec::split_off() można by bez problemu napisać w Safe Rust z wykorzystaniem najklasyczniejszej pętli - kod wygląda jak wygląda w ramach optymalizacji; copy_nonoverlapping jest unsafe, ponieważ stanowi ono odpowiednik C-owego memcpy, gdzie pewne inwarianty należy zapewnić z zewnątrz (m.in. bloki pamięci muszą być odpowiednio duże oraz nie mogą na siebie nachodzić - kompilator potrafiący rozumieć tak niskopoziomowe abstrakcje byłby krok od rozwiązania problemu stopu).

W Javie unsafe kod jest w zasadzie potrzebny tylko do FFI albo optymalizacji wydajnościowej

Ponieważ reszta niebezpiecznego kodu znajduje się w VMce, która gwarantuje zachowanie pewnych inwariantów w runtime'ie - stąd nie ma w Javie potrzeby wykorzystywania unsafe poza FFI.

skoro borrow checker w Javie nie istnieje to nie trzeba używać unsafe by go obejść

Raz jeszcze: jeżyny z jeżynami; Rust nie powstał jako alternatywa dla Javy czy innych języków z zarządzaną pamięcią, których charakterystyka i wykorzystanie znacznie odbiegają od takiego C++.

Patrząc z drugiej strony mógłbym wysunąć argument, że Java jest gupia, bo nie nadaje się do oprogramowania ATtiny.

A, no i najważniejsze: unsafe nie powstało wyłącznie jako narzędzie do "unikania" borrow checkera - dowolną własną funkcję mogę również oznaczyć jako unsafe i dorzucić komentarz z informacją co np. musi zajść, aby funkcja działała prawidłowo, a na co należy uważać.

Oczywiście da się kombinować w Ruście jak koń pod górę by unikać unsafe, tylko czy efekt jest warty zachodu?

Trochę aplikacji w Ruście już napisałem i nie zdarzyło się, abym - rozumiejąc zasadę działania borrow checkera - musiał kombinować jak koń pod górę; to raczej bolączka początkujących programistów.

Może w pewnych przypadkach warto zmienić język?

Język to tylko narzędzie - ja przykładowo profesjonalnie piszę w PHPie, czyli jeszcze inna bajka ;-)

Rust nie jest żadnym świętym Graalem, podobnie jak nie jest nim Java czy Go - każde ma / stara się znaleźć swoją niszę i uważam, że przede wszystkim należy dostosowywać narzędzia do zadań. Nie od tego jednak wywiązała się dyskusja :-)


edytowany 3x, ostatnio: Patryk27, 2019-07-30 20:43

Pozostało 580 znaków

2019-07-30 21:39
0

Nie od tego jednak wywiązała się dyskusja :-)

Wywiązała się od wielowątkowości w Ruście. No cóż, pożyjemy i zobaczymy jak ta wielowątkowość w Ruście będzie się sprawować. Błędów związanych z brakiem volatile'a (czyli widocznością zmian między wątkami) mam śladowe ilości, więc ich redukcja nie zrekompensowałaby mi utraty wygody znanej chociażby z Javy.

Rust (a konkretnie actix) ostatnio zaszalał konkretnie w benchmarkach TechEmpower: https://www.techempower.com/b[...]ramework-benchmarks-round-18/
Przepis na suckes to jednak unikanie komunikacji między wątkami (bye bye Arc) oraz zastąpienie zwykłej alokacji przez pule obiektów: https://github.com/TechEmpowe[...]s/4834#issuecomment-499429995


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
edytowany 2x, ostatnio: Wibowit, 2019-07-30 22:02

Pozostało 580 znaków

2019-08-05 16:02
0

A ja nadal nie wiem które IDE lepiej podpowiada składnie Rust, PyCharm czy Intellij? Widziałem, że powstało kilka webowych frameworków do Rusta. Więc śmiało można w nim pisać szybki backend? Obecnie poszukuję najlepszych i najpopularniejszych bibliotek do pisania programów graficznych(GUI) i silników gier w tym języku. Oby jak najszybciej wybili się jacyś liderzy, konkretne frameworki.

Pozostało 580 znaków

2019-08-05 23:55
1

A ja nadal nie wiem które IDE lepiej podpowiada składnie Rust, PyCharm czy Intellij?

Przecież to to samo IDE i ta sama wtyczka, więc co za różnica?


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
No raczej nie jest to samo, skoro tu w intellij muszę pobrać około 600MB, a w przypadku PyCharm tylko 350MB. Jeżeli to samo, to ja wybieram to drugie. - sanny 2019-08-06 18:21
No straszne. 300 MB to mi się w niecałą minutę ściąga jak leci z pełną prędkością. Różnica w funkcjonalności byłaby jakbyś wybrał CLiona - ten ma chyba dodatkowo debuggera dla Rusta i może też inne dodatki. CLion nie ma jednak wersji community. - Wibowit 2019-08-07 00:20

Pozostało 580 znaków

2019-08-07 14:06
1

PyCham i IntelliJ to jest to samo IDE z różnym zestawem wtyczek. Dlatego IntelliJ jest „trochę” cięższe. Nie ma znaczenia, które wybierzesz, bo i tak musisz dociągnąć wtyczkę do Rusta. Kluczem do odpowiedzi na twoje pytanie jest to, jakich innych języków używasz? Wiedząc, co jeszcze będziesz potrzebować można podjąć decyzję.

Pozostało 580 znaków

2019-08-07 14:14
0

Swoja droga jezeli mam pelna wersje IntelliJ to samymi wtyczkami moge go zrownac mozliwosciami z np PyCharmem albo CLionem? Czy to bedzie tylko imitacja?


01010100 01110101 01110100 01100001 01101010 00100000 01101110 01101001 01100101 00100000 01101101 01100001 00100000 01101110 01101001 01100011 00100000 01100011 01101001 01100101 01101011 01100001 01110111 01100101 01100111 01101111 00101110 00100000 01001001 01100011 00100000 01110011 01110100 01101111 01101110 01110100 00101110
edytowany 1x, ostatnio: stivens, 2019-08-07 14:14

Pozostało 580 znaków

2019-08-07 14:17
3

Tak, możesz spokojnie go zrównać. Rozróżnienie na wiele produktów jest trochę zaszłością, ale przede wszystkim wynika z chęci „odchudzenia” IDE i przygotowania wersji pod konkretne grupy użytkowników. Obecnie używam IntelliJ z pluginami webowymi jak w WebStormie plus python z PyChama i nie ma najmniejszego problemu. Co prawda taki kombajn czasami potrafi zjeść ramu, ale to akurat nie jest problem.

Co prawda taki kombajn czasami potrafi zjeść ramu Fajnie by bylo jakby wtyczki sie aktywowaly na podstawie projektu/glownego jezyka/ - stivens 2019-08-07 14:19
Jak masz w projekcie Javę na Springu, Pythona, Reacta, SASS, Dockera i dwie różne bazy danych, to może trochę wtyczek potrzebować. - Koziołek 2019-08-07 14:20
No to klikam na 20k... - lamerski 2019-08-07 18:09

Pozostało 580 znaków

2019-08-07 15:12
0
Koziołek napisał(a):

Tak, możesz spokojnie go zrównać. Rozróżnienie na wiele produktów jest trochę zaszłością, ale przede wszystkim wynika z chęci „odchudzenia” IDE i przygotowania wersji pod konkretne grupy użytkowników. Obecnie używam IntelliJ z pluginami webowymi jak w WebStormie plus python z PyChama i nie ma najmniejszego problemu. Co prawda taki kombajn czasami potrafi zjeść ramu, ale to akurat nie jest problem.

To chyba nie jest do końca prawda, obecnie CLion nie jest osiągalny na IntelliJ.
Pytanie z wątku miałoby sens gdyby porównywać IntelliJ vs CLion a tak to nie ma znaczenia.

A tu mnie zaskoczyłeś. Co z CLion jest nie tak, że nie można go osiągnąć na IntelliJ? - Koziołek 2019-08-07 15:28
CLion ma zaimplementowaną natywnie obsługę GDB, której - zdaje się - nie można przemycić we wtyczkach. - Patryk27 2019-08-07 15:33
@Patryk27: w sensie w IntellliJ trzeba go dociągnąć. Przy czym doczytałem i wychodzi mi, że CLion jest w części zamkniętym softem, ale są pluginy od innych dostawców. - Koziołek 2019-08-07 15:34

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0