LINUX.ORG.RU

Про статическую типизацию и безопасный доступ к памяти

 , , ,


3

2
★★★★★

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

«надо было пейсать на расте!»

Вот в редокc-осе нету багов памяти, потому что для того, чтоб просто запуститься ей нужно 2 гига. И то как повезет.

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

Проверять типы заместо компилятора?

Тесты на JS видел?

Ну и тесты не дают memory safety.

И тут в тред врывается fuzz testing.

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

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

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

Тесты на JS видел?

Ну?

И тут в тред врывается fuzz testing.

Вы-то сами пробовали его использовать, или только слышали звон?

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

Самые убежденные сторонники строгой статической типизации - это жаваскриптеры. Где вы видели сейчас проект без статического анализатора и тайпскрипта?

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

почему гугловское что-то написано на хламе из 80-90х?

Да потому что в гугле деды сидят на всех менеджерских позициях, вот и выбирают то, что было тогда, когда они сами ещё программировали.

Nexmean
()

70% CVE в винде из-за неправильной работы с памятью

В расте эти 70% один в один превратились бы 50% логических ошибок и 20% неправильная работа с памятью. Хотя, неправильная работа - это и есть логическая ошибка. Вот бы кто придумал кнопку «сделать правильно».

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

И какой предположительный процент ошибок Винды, если представить что она в один момент переписалась на Раст, отловил бы компилятор из этих 70-ти?

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

Читат умеешь? 70-50-20=0. 0 %.
А сколько новых ошибок чудных привнес бы хруст, как следствие борьбы с типизацией. Думаю ошыбок было бы все 146%

anonymous
()

За все хорошее против всего плохого! Только вот в typescript фигня, а не статическая типизация. Проблем добавляет больше, чем решает. Язык либо сразу проектируется как статический, либо идет мучительное натягивание совы на глобус ради неосиляторов динамики, которые одновременно и неосиляторы развитых систем типов. Т.е. нужна на самом деле жабка, но по какой-то причине приходится сажать индусов за динамические драндулеты.

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

На самом деле там куча Rust. На С++ скорее всего части где в Rust пришлось бы городить unsafe на unsafe. Это правда что его меньше знают, значит неясно зачем платить большую когнитивную нагрузку если все равно unsafe. Это ж не research проект что кому-то что-то доказать. А так заходите кто угодно в реп, найдете подсистемы на Rust

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

динамической типизации

Напомните, почему у неё ещё есть сторонники? Ну кроме тех, кто ничего серьёзнее скриптов на сотню строк ничего не писал.

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

Потому что динамическая типизация - это всего лишь немного меньше типов по сравнению со статической: TObject и парочка служебных типов для null, undefined и тп. И да, больше не значит лучше. Твоя нединамическая типизация не в состоянии это различать?

anonymous
()
  1. Количество CVE не значит абсолютно ничего. Нужно считать количество эксплуатируемых.

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

Даже если надеть маску адепта Rust — не вижу причин для радости.

38% багов в Airbnb из-за динамической типизации

Динамическая типизация в контексте безопасности — безусловное зло.

Другое дело, что в контексте бизнеса на безопасность даже банки в основном кладут (дешевле возмещать потери клиентам) — обычно скорость разработки более важна.

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

обычно скорость разработки более важна.

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

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

Другое дело, что в контексте бизнеса на безопасность даже банки в основном кладут (дешевле возмещать потери клиентам) — обычно скорость разработки более важна.

Тут вопрос: а не замедляет ли динамика скорость разработки больших сервисов?

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

Вот и я о чем. Заманаешься чинить описки васянов с другой стороны земного шара.

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

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

Наоборот же, отладка в динамике проще и быстрее. Жалуйся лучше про рефакторинг.

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

Ну дак ее больше. Потому что каждая сраная очепятка требует еще один раз прогнать весь комплекс. Ну юнит тесты тут конечно спасают, но кто же станет ломать полёт своей гениальной мысли сраным TDD.

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

в контексте бизнеса на безопасность даже банки в основном кладут (дешевле возмещать потери клиентам)

maxcom, у вас модератор сломался: он должен был бороться с 4.2, а не примкнуть к нему

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

варнингов в rust нет, как бы.

Ну вообще-то есть, только называется он unsafe! и грепается по сорцам отдельно от компиляции.

q0tw4 ★★★★
()

38% багов в Airbnb из-за динамической типизации

Так этот твой руст не единственный язык со фиксацией типов на этапе компиляции. Java, С#, да много чего еще

70% CVE в винде из-за неправильной работы с памятью

Та же Java тоже управляет памятью, причем тут rust-то?

account1986
()

70% CVE в винде из-за неправильной работы с памятью

Это всё потому, что у вендузятников valgrind-а нет. В моём линуксе мои программы на C после valgrind-а работают с памятью правильно, а волосы гладкие и шелковистые

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

Java тоже управляет памятью

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

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

Покажи хоть один пригодный для ежедневного использования ДТ язык. Cayenne хрен где скачаешь, Edwin Brady опять что-то наколенное мутит, на остальных только теоремы про сложение с умножением доказуюццо.

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

Ты охренел? Скрипты на 100 строк рулят! Если уж что-то и писать, то только скрипты на 100 строк. 1000 скриптов на 100 строк лучше, чем один на 100к строк.

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

Ну так DT - крайняя степень статики. Впрочем по выразительности оно почти догоняет динамику.

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

В свежий c# 8 вроде ввели [non-]nullable type, я полагаю поломав обратную совместимость со старым кодом, где все включения string a = null нужно будет менять на string? a = null, это так? Но дотнетчикам ломать не привыкать. Жабе это не грозит, но такая типизация заложена в kotlin. Так что, чтоб было меньше NPE пользуйтесь новыми языками.

Aber ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.