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-29 17:20
0

Lubię Rusta, ale nie nazwałbym go "najlepiej zaprojektowanym językiem programowania". Bardzo dużo można by w nim poprawić. Co do narzędzi to ja piszę w Vimie.

Pokaż pozostałe 4 komentarze
Ja właśnie nie lubię składni Javy, C# i są podobni do mnie. - sanny 2019-07-29 17:55
Rust ma problemy, np. ja osobiście uważam, że operator ? jest wygodny, ale w zamian za wygodę poświęcono czytelność. <> do szablonów też nie jest najlepszym wyborem, i Scalowe [] IMHO jest lepsze. @sanny uwierz mi, siedzę w Ruscie zapewne zdecydowanie dłużej niż Ty i "stara gwardia" by się z Tobą zapewne nie zgodziła. Prawdą jest, że Rust ma fajne rzeczy i ciekawe rozwiązania, ale jest trochę rzeczy, które wg mnie mogłyby zostać rozwiązane zdecydowanie lepiej. - hauleth 2019-07-29 18:32
Pamiętaj, że języki programowania dzielą się na imperatywne(proceduralne i obiektowe) i deklaratywne(funkcyjne i logiczne) do tego dochodzi jeszcze inna składnia danego języka. Jeden lubi rybki, a drugi akwarium. Fakt, iż obecnie Rust nie jest jeszcze bardzo popularny, ale za 20 lat kto wie. Być może Google i Microsoft rozwiną nowe systemy właśnie w tym języku programowania. - sanny 2019-07-29 18:44
@sanny: nawet nie wiesz o czym mówisz, bo już rozwijają. Współpracowałem też przy Redox OS, więc trochę na ten temat wiem. - hauleth 2019-07-29 19:46
Chyba każdy słyszał o FuchsiaOS, ale z tego co wiem Microsoft nic jeszcze nie powiedział na temat nowego systemu. A co do RedoxOS to system zabawka, wielu ludzi narzeka, że nie jest tworzony na poważnie i jest źle zaprojektowany. - sanny 2019-07-29 20:03

Pozostało 580 znaków

2019-07-29 17:39
2

Ja wykorzystuję CLion i nie narzekam - na duży plus jest zintegrowany debugger (gdb-multiarch).

jak dla mnie i wielu innych osób jest to obecnie najlepiej zaprojektowany język programowania.

Ostrożnie z tym r/rustjerk ;-) najlepiej zaprojektowany dla każdego znaczy coś innego - spróbuj przykładowo napisać bardziej skomplikowaną apkę Qt w Ruście.

Do tego jest cała masa tematów na reddit w których Rust też wygrywa

Do tego jest również cała masa tematów na Reddicie, w których Rust przegrywa - przykładem jest programowanie asynchroniczne (przynajmniej jeszcze przez najbliższe miesiące).


edytowany 3x, ostatnio: Patryk27, 2019-07-29 17:39
Ale QT nie zostało stworzone dla Rusta, to tak jak byś napisał spróbuj napisać apkę GTK3 w Javie. Jednak coś się ruszyło pod tym względem, możesz już tworzyć aplikacje webowe i desktopowe. https://rocket.rs/ https://azul.rs/ - sanny 2019-07-29 17:40
Btw, Azul jest już martwy niestety - autor się poddał :-P - Patryk27 2019-07-29 17:43
I już naprawdę nie ma innego zamiennika GUI do Rusta? - sanny 2019-07-29 17:45
Takiego, który byłby aktualnie polecany i nadawałby się na produkcję - nie; wszystko póki co w powijakach. Klasycznie: https://areweguiyet.com/ - Patryk27 2019-07-29 17:46
Na pewno jest więcej GUI tylko nie znamy wszystkich nowych projektów. - sanny 2019-07-29 17:50

Pozostało 580 znaków

2019-07-29 20:01
3

Dziedziny gdzie Rust ma sens:

  • FFI
  • Crypto
  • IoT/Embedded (w przyszłości, bo na razie wsparcie architektur jest nie za bogate)
  • Przetwarzanie wielowątkowe
  • "Tight loops"
  • OS-dev
  • Niskopoziomowe network-stuff
  • Game Dev

Dziedziny gdzie Rust może mieć jakieś szanse, ale są lepsze alternatywy:

  • CLI - Go/Python/JS/Ruby/Bash jednak mają tutaj przewagę w zdecydowanie łatwiejszym pakowaniu na różne platformy (cross-compiling w Ruscie jeszcze nie jest idealny)
  • GUI - na razie Rust nie ma żadnej biblioteki z prawdziwego zdarzenia do GUI, ale kto wie jak będzie w przyszłości, jak na razie to Python/C++/C#/Java

Dziedziny gdzie Rust IMHO nie ma sensu, chyba, że jesteśmy ograniczeni jakimiś zasobami (jak np. IoT):

  • Backend - zwyczajnie IMHO nie ma sensu wydatek czasowy, skoro to samo można uzyskać Erlangiem/Elixirem zdecydowanie łatwiej i nie tracić tak dużo na wydajności, a jak coś to zawsze mamy Rustler (patrz FFI wyżej) i można "tight loop" (patrz wyżej) napisać w Ruscie.
  • Obliczenia naukowe - tutaj Python/Julia/R będą jednak wiodły prym, Rust może jako FFI (patrz wyżej), ale większość "zasadniczej pracy" będzie we wcześniej wymienionych językach.
  • Przetwarzanie rozproszone (aka wiele maszyn) - tutaj dalej Java/Scala, Erlang/Elixir, Pony i im podobne będą miały zdecydowanie więcej zalet.
Pokaż pozostałe 2 komentarze
Nie zauważyłem, żeby Rust był przesadnie trudny, język jak język. Raczej C++ jest gorszy pod tym względem. - sanny 2019-07-29 20:34
Nie jest trudny, jest inny, więc wymaga przyswojenia dużej ilości konceptów na raz w porównaniu do Pythona, a to może być przytłaczające. - hauleth 2019-07-29 20:37
@hauleth co przejścia python -> rust twórca Flaska tak zrobił. Teraz chyba w obu. - Cr0w 2019-07-29 20:48
@Cr0w: nie nazwałbym go "początkującym". Jak ktoś już pisze dużo, to nie jest dla niego problem by przejść z jednego do drugiego, dla nowych osób w programowaniu może to być jednak trochę problemem. - hauleth 2019-07-29 20:56
Znaczniej łatwiej z Pythona przejść na https://nim-lang.org/ Tym bardziej, że już wyszedł RC2 i niedługo wyjdzie 1.0. - siloam 2019-08-04 21:44

Pozostało 580 znaków

2019-07-29 21:08
1
hauleth napisał(a):

Dziedziny gdzie Rust ma sens:

  • Przetwarzanie wielowątkowe

Moim zdaniem nie. Tracing GC zdecydowanie ułatwia pisanie wydajnego kodu wielowątkowego. Przeciętny programista prędzej napisze wielowątkowe przetwarzanie w języku z tracing GC jak Java, C# czy Go gdzie można sobie przesyłać jakiekolwiek referencje między wątkami ot tak bez martwienia się o dealokację niż w języku typu C, C++ czy Rust, gdzie zarządzanie zasobami, referencjami atomowymi, etc zjada czas programisty i/ lub procesora. Języków skryptowych nie wziąłem pod uwagę, gdyż są z reguły jednowątkowe (np JavaScript ze swoim event loopem czy Python z GILem) - przynajmniej te które kojarzę.


"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 4x, ostatnio: Wibowit, 2019-07-29 21:13
w pythonie jest jakis ruch z obejsciem GIL'a, wiec moze niedlugo... ale skladnia okropna :( - Cr0w 2019-07-30 06:35

Pozostało 580 znaków

2019-07-29 21:12
0

Przeciętny programista prędzej napisze wielowątkowe przetwarzanie (...)

Pytanie tylko jak długo taki program podziała i czy będzie zwracał prawidłowe wyniki :-)


Pozostało 580 znaków

2019-07-29 21:15
0

W sensie sugerujesz, że poleganie na GC sprawi, że program będzie miał więcej błędów niż przy ręcznym zarządzaniu pamięcią? Jest raczej odwrotnie.

Atomowe referencje (pomijając już to, że są kosztowne obliczeniowo) też wymagają dyscypliny, bo nie dealokują automatycznie cyklów. Musisz sam zadbać o ich dealokowanie, a jak nie to zostaniesz z wyciekiem pamięci.


"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 1x, ostatnio: Wibowit, 2019-07-29 21:18

Pozostało 580 znaków

2019-07-29 21:18
0

sensie sugerujesz, że poleganie na GC sprawi, że program będzie miał więcej błędów niż przy ręcznym zarządzaniu pamięcią?

Wielowątkowy - jak najbardziej.
Zwłaszcza biorąc pod uwagę, że Rust zwyczajnie nie pozwala np. na. niesynchronizowany dostęp do pamięci (w porównaniu do Javy, C# oraz Go).

Atomowe referencje (...) nie dealokują automatycznie cyklów

Są biblioteki do Rusta, które obchodzą ten problem, choć - jak przypuszczam - pewnym kosztem obliczeniowym.


edytowany 7x, ostatnio: Patryk27, 2019-07-29 21:21

Pozostało 580 znaków

2019-07-29 21:31
0

Niby Rust na wiele rzeczy nie pozwala, ale od czego jest unsafe? Mnóstwo kodu jest usiane słówkiem unsafe. Np:

$ git clone https://github.com/servo/webrender.git
Cloning into 'webrender'...
$ cd webrender/
$ find . -name *.rs | wc -l
121
$ grep --include=\*.rs -rnw '.' -e 'unsafe' | wc -l
244

Średnio ponad dwa słówka unsafe na plik. Tutaj niby unsafe jest wykorzystywane do różnych rzeczy, ale już się spotkałem z podejściem typu - kod w Ruście działa za wolno - użyję unsafe i arytmetyki wskaźników. Obstawiam, że w momentach gdy zabawa w referencje i borrow checking stawałaby się upierdliwa to unsafe ścieliłoby się gęsto.

W komercyjnym kodzie Scalowym w firmie mamy mnóstwo aktorów, future'ów, asynchronicznych strumieni, etc a problemów z data races prawie żadnych (oprócz pewnych kulawych testów opartych o globalny mutowalny stan, ale to inna historia, bo ktoś wymyślił genialny inaczej framework do testów, a synchronizacja nic by tu nie pomogła). To dlatego, że korzystamy w dużej części z niemutowalnych struktur danych do przesyłania danych między wątkami. Wygodnie i bezpiecznie. Nie trzeba ekstra bibliotek żeby coś obchodzić. Nie trzeba się zastanawiać, czy przesyłanie referencji między wątkami jest kosztowne (bo nie jest).


"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 8x, ostatnio: Wibowit, 2019-07-29 21:42

Pozostało 580 znaków

2019-07-30 08:09
0

Niby Rust na wiele rzeczy nie pozwala, ale od czego jest unsafe?

unsafe służy do budowania abstrakcji, których nie da się wyrazić w systemie typów Rusta (https://matklad.github.io/201[...]/unsafe-as-a-type-system.html) oraz do komunikacji z zewnętrznymi API (które z założenia mogą robić wszystko, stąd ich niebezpieczeństwo).

Mnóstwo kodu jest usiane słówkiem unsafe

Zależy jak na to spojrzysz: technicznie każdy program napisany w C#, Go czy Javie składa się wyłącznie z bloków unsafe - przy czymś takim średnio dwa na plik to miód na oczy :-)

Obstawiam, że w momentach gdy zabawa w referencje i borrow checking stawałaby się upierdliwa to unsafe ścieliłoby się gęsto.

Ano zdarza się (np. w projekcie actix będącym implementacją aktorów oraz serwera HTTP w Ruście) - przy czym nie jest to w żaden sposób wina języka.

Język oraz społeczność starają się wręcz wyjść na przeciw wykorzystywaniu unsafe, stąd m.in. powstała dyrektywa #![forbid(unsafe_code)] oraz projekty typu cargo-geiger.

korzystamy w dużej części z niemutowalnych struktur danych do przesyłania danych między wątkami (...) Nie trzeba się zastanawiać, czy przesyłanie referencji między wątkami jest kosztowne (bo nie jest).

Jeśli masz niemutowalną strukturę, w Ruście owijasz ją w Arc i bez problemu wysyłasz do wszystkich wątków, jakie potrzebujesz - w cenie wtedy masz wtedy zarówno zliczanie referencji, jak i brak problemów z borrow checkerem.

Fakt, wysłanie takiej referencji nie jest darmowe (trzeba wszak odpalić calutkie fetch_add()! /s), lecz w dalszym ciągu jest to lżejsze od garbage collectora z C# czy Javy.

Edit: z ciekawości sprawdziłem te przypadki unsafe w WebRender i zdaje się, że ok. połowa z nich związana jest z odwoływaniem się do zewnętrznego API (OpenGL oraz FreeType). FFI całkiem słusznie jest unsafe-by-default, można się rozejść :-P


edytowany 9x, ostatnio: Patryk27, 2019-07-30 08:23

Pozostało 580 znaków

2019-07-30 19:21
1

Zależy jak na to spojrzysz: technicznie każdy program napisany w C#, Go czy Javie składa się wyłącznie z bloków unsafe - przy czymś takim średnio dwa na plik to miód na oczy :-)

Natomiast kod typu x = x + 1 jest impure i unsafe w Haskellu, więc z punktu widzenia Haskella cały kod w Ruście jest unsafe. Idąc dalej - kod w Haskellu jest unsafe dla programistów Coq czy Idrisa, bo nie ma dowodów poprawności.

Trzeba się zastanowić co te obostrzenia w Ruście dają. Memory corruption w czystej Javie (bez sun.misc.Unsafe) nie dostaniesz, dereferencja nulla zawsze skutkuje NPE, a nie jest UB jak w C++ czy Ruście z unsafe. To co Rust wymusza to widoczność zmian w zmiennych współdzielonych między wątkami. W Javie można zapomnieć volatile i wtedy nie wiadomo kiedy zmiany się rozpropagują. Rustowy borrow checker nie zapobiega np niepoprawnemu kodowi typu:

while (arc.get() != 5) {}
// tutaj osobny wątek może ustawić arc na wartość != 5
arc.set(8);

podczas, gdy poprawny kod wygląda mniej więcej tak:

while (!arc.compareAndSet(5, 8)) {} // zmiana jeśli zajdzie to zawsze z 5 na 8

Ogólnie to Rustowe safety jest niewiele wyższe niż Javowe, ale borrow checker w Ruście jest upierdliwy.

Ano zdarza się (np. w projekcie actix będącym implementacją aktorów oraz serwera HTTP w Ruście) - przy czym nie jest to w żaden sposób wina języka.

Jak nie jest? Borrow checker jest głupi. Przykład - Vec::split_off

    #[inline]
    #[stable(feature = "split_off", since = "1.4.0")]
    pub fn split_off(&mut self, at: usize) -> Self {
        assert!(at <= self.len(), "`at` out of bounds");

        let other_len = self.len - at;
        let mut other = Vec::with_capacity(other_len);

        // Unsafely `set_len` and copy items to `other`.
        unsafe {
            self.set_len(at);
            other.set_len(other_len);

            ptr::copy_nonoverlapping(self.as_ptr().add(at),
                                     other.as_mut_ptr(),
                                     other.len());
        }
        other
    }

unsafe trzeba tutaj wrzucić gdyż borrow checker nie jest w stanie zorientować się, że podzielenie mutowalnego wektora na dwa jest bezpieczne.

W Javce wszystkie kolekcje są w 100% oparte na bezpiecznym kodzie (no chyba, że jest tam jakiś natywny w ramach optymalizacji, ale jeśli już to bardzo mało).

Fakt, wysłanie takiej referencji nie jest darmowe (trzeba wszak odpalić calutkie fetch_add()! /s), lecz w dalszym ciągu jest to lżejsze od garbage collectora z C# czy Javy.

malloc + free jest bardziej kosztowne obliczeniowo niż tracing GC, ale za to mniej kosztowne pamięciowo. Dowód jest tutaj:
https://benchmarksgame-team.p[...]/performance/binarytrees.html
Najszybsze rozwiązanie w C#, F#, Erlangu i Javie korzystają ze standardowego tracing GC (zwykły new oraz automatyczne odśmiecanie). Rozwiązania oparte o malloc/ free bądź new/ delete są wolniejsze od tych z tracing GC. Dopiero użycie pul (szukaj nazw pool lub arena w importowanych modułach) w C++, Ruście, C, etc sprawia, że takie coś jest szybsze niż tracing GC, ale pule to rozwiązanie o bardzo wąskim spektrum zastosowań.

Jeśli masz niemutowalną strukturę, w Ruście owijasz ją w Arc i bez problemu wysyłasz do wszystkich wątków, jakie potrzebujesz - w cenie wtedy masz wtedy zarówno zliczanie referencji, jak i brak problemów z borrow checkerem.

Jak dostanę Arca to już jestem z nim uwięziony albo muszę skopiować obiekt na który wskazuje. 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.

W programowaniu funkcyjnym używa się standardowo niemutowalnych kolekcji z structural sharing. Weźmy dla przykładu drzewa: https://en.wikipedia.org/wiki/Persistent_data_structure#Trees Stworzenie nowego drzewa na podstawie poprzedniego z jedną nową zmianą wymaga tylko O(lg n) dodatkowej pamięci, a nie O(n) jak w przypadku kopiowania całego drzewa. Dlaczego tylko O(lg n)? Dlatego, że nowe drzewo zawiera referencje do starych poddrzew. Wyobraź sobie teraz że wyprodukowałem trzy drzewa:

val drzewo1 = (0 to 1000 * 1000).map(i => i -> i * i) // drzewo z milionem elementów
val drzewo2 = drzewo1 + (8 -> 3) // drzewo z milionem elementów
val drzewo3 = drzewo2 + (-1 -> 8) // drzewo z milonem i jednym elementem

Sumarycznie te 3 drzewa zajmują praktycznie tylko tyle co samo pierwsze dzięki structural sharing. Co jeśli chcę teraz przesłać te drzewa do 3 różnych wątków w np Scali? Po prostu je przesyłam bez żadnego opakowywania. Co musiałbym zrobić w Ruście? Skopiować dane tak by drzewa były niezależne? To marnotrawstwo pamięci. Użyć Arc do wszystkich referencji wewnątrz drzewa? To nie tylko narzut pamięciowy, ale przede wszystkim obliczeniowy. Zamiast miliona zwykłych referencji byłoby milion Arców.

Wszystkie języki funkcyjne są oparte o tracing GC głównie dlatego, że umożliwia to tanie współdzielenie skomplikowanych struktur danych między równocześnie wykonującymi się wątkami. No 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ą.


"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 1x, ostatnio: Wibowit, 2019-07-30 19:22

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