LINUX.ORG.RU
Форум — Development  

Посмотрел я этот ваш Rust

 ,


6

8

Вобщем, дошли руки потыкать палочкой.

Я вот что не пойму - зачем и кому он нужен, ну правда?

Это же новый C++. То есть, чрезмерно переусложненный язык, в котором, как говорил Луговский, разобраться может разве что хорошая зубрилка, а не хороший программист, но при этом не дающий никаких бонусов к продуктивности, и никакими киллер-фичами не обладающий.

Close to metal? Нет, извините, мне когда надо будет close to metal - я пойду сишку возьму. Которая реально, и Close To Metal, и со стабильным ABI, так важным для низкоуровневого программирования, и так далее. А если просто производительности не будет хватать, в том числе там из-за GC, так ведь - что в Java, что в Common Lisp, есть огромное количество возможностей затюнить производительность до нужного уровня, при этом не стреляя себе в ногу.

Продуктивность разработчика? Я сильно в этом сомневаюсь. Потому что вот есть языки программирования, предлагающие наибольшую продуктивность, не ограничивающие пользователя практически никак, и, конечно, вместе с тем, довольно сильно нагружающие межушной нервный узел, довольно нетривиальные для изучения. Как пример, лиспы всевозможные. Но Rust в их число не входит. Там на каждом углу костыли, подпорки, железные двери с замками, и чуть что так обухом по голове можно получить.

Наконец, ну безопасность чтоли, хваленая? Ну, опять нет. Взять тот же unsafe. Если вам нужна прямо таки безопасность-безопасность - берите что-нибудь вроде хаскеля(или какого-нибудь Coq, или что-нибудь подобное, с зависимыми типами, если совсем упоролись), ну или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами.

Вобщем, не вижу зачем этот язык нужен, нам и C++ хватает, если надо не ехать, а шашечки(т.е. тупо позадротствовать, да).

★★
← Давно вы писали десктопные приложения(и на чем)?
Модный, молодежный язык →

 ← 1 2 3 4 5 6 7 8 9

Да, действительно, зойчем когда есть бомженственственный php

tz4678 ★★
()
Последнее исправление: tz4678 (всего исправлений: 1)

Сложилось аналогичное впечатление. Интересно еще то, что я написал одну поделку на Rust, потом переписал ее на Go и у меня получилось примерно то же количество строк (~600). Я ожидал что Go будет сильно многословней.

urxvt ★★★★★
()

аватарки первых двух отписавшихся символизируют

Harald ★★★★★
()
Ответ на: комментарий от bhfq

Go лучше всего характеризует умственно-отсталый суслик, являющийся его маскотом. Но этот тред - про Rust.

lovesan ★★
() автор топика

Вобщем, не вижу зачем этот язык нужен

Неужели еще один все понял?

Deleted
()
Ответ на: комментарий от Deleted

Ох уж эти форумные детективы. Нет-нет да и найдут что-то, что никто и не скрывал.

mersinvald ★★★★★
()

Макросы-то процедурные посмотрел, лиспер?

Kuzy ★★★
()

нам и C++ хватает

Особенно учитывая тот факт, что плюсы активно развиваются и дорабатываются.

anonymous
()

Это же новый C++. То есть, чрезмерно переусложненный язык, в котором, как говорил Луговский, разобраться может разве что хорошая зубрилка, а не хороший программист, но при этом не дающий никаких бонусов к продуктивности, и никакими киллер-фичами не обладающий

Я давно пишу, что суть владения крестами сводится к тому, чтобы изучить фичи языка, которые нужно избегать. По этой причине так много людей не знают досконально особенностей крестов — эти особенности им не нужны, они пользуются только узким спектром приемов.

И да, я склоняюсь к тому, что Rust стал мертвым языком. Именно стал, потому что к нему приложили ручки эффективные менеджеры. К сожалению, он был изначально создан сырым, поэтому возникла необходимость доработки.

Одна из острых проблем крестов «метакода примерно столько же, сколько самого выполняющегося кода». Эта проблема стала еще более острой в расте, где метакода уже больше, чем выполняющегося кода. Отказ от объектов, акцент на статический полиформизм - это круто. Но что делать с ситуацией, когда «за деревьями не видать леса»?

Теперь приготовьтесь к лютой отсебятине: ящитаю, что C++ не создавал проблемы безопасности кода, которую так яростно пытаются решить растовцы. Более того, ящитаю, что до конца эту проблему у них все равно не получится победить, потому что есть сложные динамические структуры и есть многопотоки, в которых инструменты раста бессильны или почти бессильны. Ящитаю, что изначально проблемой был сам Си, с которого перенял многие подходы к организации кода C++. А именно, проблемы buffer/stack overflow, out of range access, use after free, double free, удобная обработка ошибок, и также отсутствие локальных функций - последняя была исправлена недавно введение лямбд. Кратко по проблемам: стэк - зло; проверка индексов в релизе позволяет ловить многие ошибки; использование данных с ограниченной видимостью устраняет необходимость регулярного ручного жонглирования указателями; по ошибкам Go пока наиболее близок к тому, что я хотел бы видеть в языке будущего. К сожалению, подсчет ссылок и сборка мусора не являются в данном случае универсальными решениями, потому что ресурсоемки и отдаляют от железа, а также плохо заходят во многозадачность.

Close to metal?
А если просто производительности не будет хватать, в том числе там из-за GC, так ведь - что в Java, что в Common Lisp, есть огромное количество возможностей затюнить производительность
Продуктивность разработчика?
Наконец, ну безопасность чтоли, хваленая?

Rust предлагался именно для замены крестов с чуть большей безопасность. Вся индустрия C/C++ выросла из соображений «производительность, производительность, еще больше производительности. Всё ради производительности». В жертву приносилась и скорость разработки, и безопасность. Код на расте бегает в разы быстрее Java/CL, и потому именно там, где это важно, пишут на крестах/расте. А это низкоуровневые либы, сервера, ну и те же браузеры. Пока при этом продуктивность разработчика ниже, чем на Java, но не намного — никогда не волнует плюс-минус 10% в сроках сдачи проекта. Однако, очень соблазнительно выглядит перспектива писать такой же быстрый код, как на C/C++, но при этом все-таки получить какую-то долю безопасности бесплатно, не жертвуя ничем при этом.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

Код на расте бегает в разы быстрее Java/CL

CL можно оптимизировать до уровня встроенного ассемблера, так что никаких в разы там не будет

lovesan ★★
() автор топика
Ответ на: комментарий от cherry_boy

Т.е. раст это как «альтернативный рок»? Когда играть собственно музыку не умеют, зато все обмазаны татуировками итд. Ок.

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

Лучше, чем всей страной слушать хор пионеров.
Иметь альтернативу лучше, чем не иметь, а дальше каждый сам себе злой Буратино.

cherry_boy
()

Разработчик раста кто? Мозилла? Правильно пишут - они делают всё что угодно, лишь бы браузер не писать. Достаточно просто посмотреть по новостям, какие изменения вносятся в браузер, чтоб понять всю суть.

А что касается языка - обычной сишечки(которая C, а не C++) достаточно, чтоб ехать с шашечками в подавляющем большинстве случаев.

anonymous
()

Another one bites the dust!

grim ★★☆☆
()

Руст на то и педеруст, что ненужно. У дишечки ещё какие-то шансы были, и то по ощущениям в тупик с ней зашли.

Hertz ★★★★★
()

ну или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами

джава даже близко не дает тех гарантий что дает safe-код в rust

maloi ★★★★★
()
Ответ на: комментарий от Hertz

Вот кстати дишечка вчера приятно удивила. В ней подкрутили CTFE, и, теперь он не валится на большой генерации кода, и памяти жрет не так много как раньше

SR_team ★★★★★
()
Ответ на: комментарий от cherry_boy 
(defpackage vop-example
  (:use #:cl #:sb-ext #:sb-c)
  (:export #:fact))

(in-package #:vop-example)

(defknown fact (fixnum) fixnum
    (movable flushable foldable always-translatable)
  :overwrite-fndb-silently t)

(in-package :sb-vm)

(define-vop (vop-example:fact)
  (:translate vop-example:fact)
  (:args (n :scs (signed-reg)))
  (:arg-types fixnum)
  (:results (r :scs (signed-reg)))
  (:result-types fixnum)
  (:policy :fast-safe)
  (:generator 0
              (inst mov r 1)
              LOOP
              (inst test n n)
              (inst jmp :z DONE)
              (inst imul r n)
              (inst dec n)
              (inst jmp LOOP)
              DONE))

(in-package #:vop-example)

(defun fact (n)
  (declare (type fixnum n))
  (fact n))



CL-USER> (vop-example:fact 5)
120
CL-USER> (disassemble 'vop-example:fact)
; disassembly for VOP-EXAMPLE:FACT
; Size: 45 bytes. Origin: #x1002496174                        ; VOP-EXAMPLE:FACT
; 74:       498B4510         MOV RAX, [R13+16]                ; thread.binding-stack-pointer
; 78:       488945F8         MOV [RBP-8], RAX
; 7C:       840425F8FF1020   TEST AL, [#x2010FFF8]            ; safepoint
; 83:       BA01000000       MOV EDX, 1
; 88: L0:   4885DB           TEST RBX, RBX
; 8B:       7409             JEQ L1
; 8D:       480FAFD3         IMUL RDX, RBX
; 91:       48FFCB           DEC RBX
; 94:       EBF2             JMP L0
; 96: L1:   48D1E2           SHL RDX, 1
; 99:       488BE5           MOV RSP, RBP
; 9C:       F8               CLC
; 9D:       5D               POP RBP
; 9E:       C3               RET
; 9F:       CC10             INT3 16                          ; Invalid argument count trap
lovesan ★★
() автор топика
Ответ на: комментарий от byko3y

См. выше.

Там многие программы для лиспа не оптимизированы и написаны довольно тупо, это давно известно, но лисперам лень править

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

Мрак.

Руст конечно сомнительной нужности изобретение, но по сравнению с таким кодом что угодно лучше.

Deleted
()
Ответ на: комментарий от Deleted

Дело в том что в других языках вообще нельзя расширять компилятор, в отличие от CL. Так что «страшно выглядит»(для не-лиспера) это все же на порядок лучше чем «тупо нету».

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

Дело не в «не-лиспере», а в:

  1. соотношении объема строк кода к фактической работе в этом примере;
  2. том, что ручное перекладывание байт конечно занимательно в качестве хобби, но вообще такого уровня оптимизации давно умеет выполнять машина.

в других языках вообще нельзя расширять компилятор

Значит нужно пробовать создавать «более другие» языки, и если технология будет иметь практическую применимость, она взлетит.

Deleted
()
Последнее исправление: Deleted (всего исправлений: 2)

ну или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами

И словить NPE.
Что конечно не sigseg, но тоже неприятно.

WatchCat ★★★★★
()
Ответ на: комментарий от Deleted

соотношении объема строк кода к фактической работе в этом примере;

Естественно это просто пример. В реальной жизни скорее встретится использование каких-нибудь SSE/AVX.

том, что ручное перекладывание байт конечно занимательно в качестве хобби, но вообще такого уровня оптимизации давно умеет выполнять машина.

SBCL тоже умеет.

(defun fact (n)
  (declare (optimize (speed 3) (safety 0) (debug 0)))
  (loop :for i fixnum :to n
        :for fact fixnum = 1 :then (* i fact)
        :finally (return fact)))

; disassembly for FACT
; Size: 60 bytes. Origin: #x1003469F80                        ; FACT
; 80:       840425F8FF1020   TEST AL, [#x2010FFF8]            ; safepoint
; 87:       31C0             XOR EAX, EAX
; 89:       31C9             XOR ECX, ECX
; 8B:       4885DB           TEST RBX, RBX
; 8E:       7D09             JNL L1
; 90: L0:   488BD1           MOV RDX, RCX
; 93:       488BE5           MOV RSP, RBP
; 96:       F8               CLC
; 97:       5D               POP RBP
; 98:       C3               RET
; 99: L1:   B902000000       MOV ECX, 2
; 9E:       EB07             JMP L3
; A0: L2:   48D1F9           SAR RCX, 1
; A3:       480FAFC8         IMUL RCX, RAX
; A7: L3:   840425F8FF1020   TEST AL, [#x2010FFF8]            ; safepoint
; AE:       4883C002         ADD RAX, 2
; B2:       488BD3           MOV RDX, RBX
; B5:       4839D0           CMP RAX, RDX
; B8:       7FD6             JNLE L0
; BA:       EBE4             JMP L2

Вообще говоря, система VOP это не просто «инлайн ассемблер», это низкоуровневое представление компилятора, в которое сам SBCL компилирует flow graph / ast. Оно сама по себе довольно хитрая, VOP-ы можно комбинировать, указывать их стоимость и другие опции(и потом компилятор выбирает наиболее подходящий в данном конкретном месте).

Значит нужно пробовать создавать «более другие» языки, и если технология будет иметь практическую применимость, она взлетит.

Такие языки автоматически становятся диалектами лиспа, или вылетают на помойку истории как абсолютно неюзабельные. Проходили.

lovesan ★★
() автор топика
Ответ на: комментарий от lovesan

Дело в том что в других языках вообще нельзя расширять компилятор

В clang и gcc можно.

anonymous
()
Ответ на: комментарий от crutch_master

Царь ушел в оффлайн, но дело его живёт!

Царь

Какой-то местный поехавший со своей собственной сектой, мнение которых никого не интересует. Leave Rust Alone!

Разорванный Флакон

anonymous
()
Ответ на: комментарий от lovesan

Вообще говоря, система VOP это не просто «инлайн ассемблер», это низкоуровневое представление компилятора, в которое сам SBCL компилирует flow graph / ast. Оно сама по себе довольно хитрая, VOP-ы можно комбинировать, указывать их стоимость и другие опции(и потом компилятор выбирает наиболее подходящий в данном конкретном месте).

А вот это хорошо придумано

Deleted
()

Считай, что у тебя статический анализатор впихнули в сам компилятор раста. Отсюда разные правила.

И к тому же, в расте еще столько правил, потому что задача такая сложная. Написание системного софта сложно само по себе. И здесь возникает больше уверенности, меньше переживаний, что все будет работать, как было задумано. Буквально, валгринд и отладчик нужны гораздо-гораздо реже, чем при использовании C++.

Но меня больше всего привлекает в расте другое. Там довольно хорошая реализация связки генерики+трейты, что по сути является слизанной версией полиморфизма+классов типов из хаскеля. Когда привыкаешь к ним, то все остальные языки, не умеющие такого, становятся в твоих глазах языками второго сорта.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)

ну или на худой конец, что-нибудь вроде Java, где все безопасно прямо как в дурдоме с мягкими стенами.

Java безопасный? насмешил

Int64 ★★★
()
Ответ на: комментарий от lovesan

Писать проще на том языке, который знаешь. Ваш КО.

По вашей логике на Питоне/JS проще писать, чем на C++. А на деле, жизнь без типов - боль. И приходится пердолиться с анализаторами типа mypy. Шило на мыло.

Сравни насколько проще писать на той же Java чем на Си.

Смотря что. Писать на java под микроконтроллеры будет довольно проблематично.

Ну и сравнивать с Си - это прошлый век, ибо хуже Си сейчас ничего нет.

RazrFalcon ★★★★★
()
Ответ на: комментарий от anonymous

Это же новый C++

Ну вообще-то нет

Т. к. новый (правильный) C++ — D. А Rust — очередное монстрозное в худших традициях C++.

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
 ← 1 2 3 4 5 6 7 8 9
← Давно вы писали десктопные приложения(и на чем)?
Development
Модный, молодежный язык →