Есть замеры tantivy vs lucene и tantivy быстрее. Поэтому разумно ожидать что поиск построенный поверх tantivy можно сделать более быстрый чем поверх lucene. Так что здесь логичное предположение, что можно на Rust быстрее сделать в теории.
В статье Сергея написано детально о причинах, но всё таки на C++ надежный проект поддерживать сложно, а растоманов у нас тогда почти не было. Плюс можно было переиспользовать куски кода эластика скажем касательно мультиматч запросов, что бы переход для клиентов сделать плавнее. Сегодня, наверное, если начинать новый проект действительно может быть лучше взять tantivy и делать вокруг него на Rust.
Каждый раз когда вижу такие статьи на хабре понимаю, что надо всё таки дописать мою статью "Почему ваш кросс-языковой бенчмарк вам врёт". У меня там отличный пример есть, где можно на двух "совершенно одинаковых алгоритмах" получить Java сколь угодно быстрее чем Rust :)
Фантастично то, что люди получив измерения вообще не пытаются даже понять почему они такие числа получили. Вот у человека получается что Rust в 10 раз медленнее, чем Java. И ничего в голове не щелкает, человек публикует статью. Насколько странным должен получиться результат, что бы человек начал искать проблему в своем тесте? В 100 раз должен Rust проиграть Java, в 1000? :) А если бы Java на числодробилки бы оказалась медленнее, там наверное пока в миллион раз её не обгонят никто даже и не почешется, что делает что-то не так :)
Есть хороший доклад одноклассников почему они запили свой поисковой движок: https://youtu.be/7UAR1Vl_5Iw . Там в частности Solr разбирают. Solr рассчитан на маленькие нагрузки и удобный деплой в облаках. Скажем Solr запросы обрабатывает в один поток. Это обеспечивает высокую эффективность при маленьких нагрузках и большинству проектов этого достаточно.
он в СТ 80% времени тратит на рефакторинг и только 20% на написание нового кода
Очень забавно, но иногда мне кажется, что я 100% времени трачу на рефакторинг: мне часто дают задачи взять кусок кода написанный ранее левой пяткой и сделать его быструю и надежную версию к тому же добавив новый функционал.
Но свой код я рефачу достаточно редко:)
Берёте и добавляете, Python или хорошый JS читается как книга
Допустим, но я бы предпочел читать книгу не с начала. Все таки типы дают мне возможность не заглядывать в некоторые места т.к. очевидно там ничего нет. Хотя конечно это не замена документации.
Берёте и меняете… если вы меняете поведение функции то вы либо создаёте новую функцию с новым именем либо (что геморойно и зачем такое вообще?) бегаете поиском по проекту и меняете поведени, но вообще это моветон такое делать не соглосовав с коллегами.
Ну вот допустим стал ты перформенс инженером, сидишь профилируешь код: видишь какие-то умники наслушались лекций про ФП и везде возвращают значения обернутые в Optional и один такой метод горячий прям реально нагружает GC, т.к. где ФП, а где джава. Идешь и меняешь метод, он, скажем, теперь возвращает не Optional, а String но может и null теперь вернуть. Коллега, который этот метод написал давно уволился, а те кто им пользовались половина либо уволились либо стали менеджерами и забыли как программировать. Другие же трогали его год назад и уже забыли где и почему. А тимлид хочет ступеньку на графике таймингов уже завтра. Вот в такой ситуации без типов будет очень больно.
Обратите внимание на аккуратность формулировки «здесь я фактически руками реализую алгебраический тип данных» целых две оговорки в предложении.
Понятно что в Java нет АТД и нет синтаксических возможностей его выразить (но кстати в новых версиях там есть sealed классы, что бы нельзя было объявлять новых наследников, но я решил писать для статьи на Java 11). Здесь происходит такого же рода симуляция, как например люди делали в свое время ООП на чистом С, тоже корявое и рукописное.
Действительно классы и АТД удобно расширяются в разные стороны, но здесь мы ничего не расширяем и отличие как бы не заметно. Я думал об этом написать, но тогда пришлось бы объяснять double dispatch и всякие tagless final. Но не стал, т.к. во-первых статья уже огромная, во-вторых её тема это не «пишем ФП на Java». Ну и цель примера показать как можно убрать логику в декларации, а то что оно похоже на АТД в некотором роди приятный бонус.
Достаточно взять конкретные ветки этого графа, чтобы знать, откуда пришли данные, что с ними происходило, и в какой форме они могут быть в конкретном месте в программе
А как ты понимаешь глядя в локальную точку графа откуда пришли данные и какова их природа без типов? Вот если ты пришел в проект новый и тебе дали задачу на шаге X сделать ещё одно действие Y. Или все таки держать в голове весь путь от инпута до текущего шага исполнения обязательно? Тогда кажется я все корректно описал про «держать всю программу в голове»:-)
Ну вот вы написали пайплайн, а потом уволились и мне надо добавить изменений в середину? Или скажем изменить какую-то функцию, которой пользуетесь вы и ещё в нескольких разных местах разные люди? И начинается Дженга, где одно неловкое движение и башня упадет. Или вы просто выбрасываете весь ранее написанный код и переписываете его заново?:-) Я честно не понимаю.
По идее должно хорошо и просто работать в ФП языках так как там нет мутаций. Если разрешать мутации, то сразу много выплывает тонких кейсов, так что всё равно придется какие-то корректные вещи запрещать.
Ну вот например удалять из коллекции можно всегда — это не приведёт к проблемам типизации. Это на самом деле чудовищная тема если начать её копать, особенно если отойти от абстрактных вещей к конкретным. Я советую для разминки потратить где-то пол часа жизни что бы разобраться почему метод HashMap.get в Rust принимает не тип ключа K, а новый тип Q, который такой что
Вот кстати интересный пример про книгу. Скажем Преступление и наказание около 600 страниц. И в начале, если помните, там главный герой убивает старушку, а ещё свидетельницу: молодую девушку. Однако, в конце книге про свидетельницу нет уже ни слова. А была бы у Достоевского статическая типизация, книга бы до печати не дошла пока бы он не поправил несоответствия. Ну и подобных историй в литературе предостаточно.
Что касается концепций, признаться не могу понять в чем аргумент. У меня например постоянно такое, что концепции одинаковые (по крайней мере в моей голове), а код всё таки приходится подправлять.
Я бы почитал вашу статью так что обязательно пишите.
Сам я не писал серьезно на ДТ языках поэтому в целом я готов принять какие-то убедительные доводы. Однако ваши вызываю у меня вопросы.
вы концентрируетесь над потоком исполнения, контекст движется вместе с этим потоком и вам очевидно что происходит вокруг
Звучит так, как будто программа пишется так же, как исполняется её исходный код, в виде некоторого пайплайна. Однако, на практике написание программы скорее напоминает переусложнённую версию игры в Дженга, где вам приходится расширять программу изнутри периодически выделяя общие паттерны в мини-фреймворки, попутно удаляя неиспользуемое легаси. Более того сам характер взаимосвязей между компонентами не похож на поток: низкоуровневые компоненты переиспользуются многократно причем на разных абстрактных уровнях.
Сам я сталкивался с таким, что разработчик, не осилив написать типобезопасную версию апи, оставлял торчать Object-ы в декларациях или явные касты в коде и в результате тривиальный рефакторинг ломал всю программу, но понятно это было только при запуске тестов, а хочется же во время компиляции.
в этих языках важно писать как можно проще (явно как завещал Гвидо), компактнее и выбирать максимально читабельные и полные названия для всего
Писать так программы хорошо на любом языке, но тут мне кажется есть некоторая подмена понятий: хорошо писать код, который выглядит просто и понятно, но писать такой код совсем не просто: от того и идет «когнитивная нагрузка». Более того, если вы пишете библиотечный код, то самое главное, что бы им было просто и удобно пользоваться, а это зачастую значит писать очень сложный код внутри самой библиотеки.
Говорю же тут немного плавую. Знаю что изоморфизм есть, но не знал даже как он называется:) Про термы не понял, что такое терм в данном случае? Какое-то объявление типа или выражение?
И кстати как тебе статья в целом? Твое мнение было бы мне важно т.к. я на несколько твоих статей опираюсь здесь и даю на них ссылки:)
Есть замеры tantivy vs lucene и tantivy быстрее. Поэтому разумно ожидать что поиск построенный поверх tantivy можно сделать более быстрый чем поверх lucene. Так что здесь логичное предположение, что можно на Rust быстрее сделать в теории.
Фаллические символы были всегда популярнее во все времена.
Все претензии к обществу.
В статье Сергея написано детально о причинах, но всё таки на C++ надежный проект поддерживать сложно, а растоманов у нас тогда почти не было. Плюс можно было переиспользовать куски кода эластика скажем касательно мультиматч запросов, что бы переход для клиентов сделать плавнее. Сегодня, наверное, если начинать новый проект действительно может быть лучше взять tantivy и делать вокруг него на Rust.
А там так же через Unsafe всё делается. У нас по сути так же.
Пожалуйста :)
Каждый раз когда вижу такие статьи на хабре понимаю, что надо всё таки дописать мою статью "Почему ваш кросс-языковой бенчмарк вам врёт". У меня там отличный пример есть, где можно на двух "совершенно одинаковых алгоритмах" получить Java сколь угодно быстрее чем Rust :)
Фантастично то, что люди получив измерения вообще не пытаются даже понять почему они такие числа получили. Вот у человека получается что Rust в 10 раз медленнее, чем Java. И ничего в голове не щелкает, человек публикует статью. Насколько странным должен получиться результат, что бы человек начал искать проблему в своем тесте? В 100 раз должен Rust проиграть Java, в 1000? :) А если бы Java на числодробилки бы оказалась медленнее, там наверное пока в миллион раз её не обгонят никто даже и не почешется, что делает что-то не так :)
Хах! Приятно что к моим статьям возвращаются :-)
На самом деле я с тех пор перевел свою статью на английский и там код уже по чище.
Но про
MaybeUninitя не знал конечно.На самом деле в итоге я забил на изучение Раста.
Есть хороший доклад одноклассников почему они запили свой поисковой движок: https://youtu.be/7UAR1Vl_5Iw . Там в частности Solr разбирают. Solr рассчитан на маленькие нагрузки и удобный деплой в облаках. Скажем Solr запросы обрабатывает в один поток. Это обеспечивает высокую эффективность при маленьких нагрузках и большинству проектов этого достаточно.
Вообще конечно выглядит как подтверждение гипотезы, что корпорации мстят Столлману за свободный софт.
Очень забавно, но иногда мне кажется, что я 100% времени трачу на рефакторинг: мне часто дают задачи взять кусок кода написанный ранее левой пяткой и сделать его быструю и надежную версию к тому же добавив новый функционал.
Но свой код я рефачу достаточно редко:)
Допустим, но я бы предпочел читать книгу не с начала. Все таки типы дают мне возможность не заглядывать в некоторые места т.к. очевидно там ничего нет. Хотя конечно это не замена документации.
Ну вот допустим стал ты перформенс инженером, сидишь профилируешь код: видишь какие-то умники наслушались лекций про ФП и везде возвращают значения обернутые в Optional и один такой метод горячий прям реально нагружает GC, т.к. где ФП, а где джава. Идешь и меняешь метод, он, скажем, теперь возвращает не Optional, а String но может и null теперь вернуть. Коллега, который этот метод написал давно уволился, а те кто им пользовались половина либо уволились либо стали менеджерами и забыли как программировать. Другие же трогали его год назад и уже забыли где и почему. А тимлид хочет ступеньку на графике таймингов уже завтра. Вот в такой ситуации без типов будет очень больно.
Понятно что в Java нет АТД и нет синтаксических возможностей его выразить (но кстати в новых версиях там есть sealed классы, что бы нельзя было объявлять новых наследников, но я решил писать для статьи на Java 11). Здесь происходит такого же рода симуляция, как например люди делали в свое время ООП на чистом С, тоже корявое и рукописное.
Действительно классы и АТД удобно расширяются в разные стороны, но здесь мы ничего не расширяем и отличие как бы не заметно. Я думал об этом написать, но тогда пришлось бы объяснять double dispatch и всякие tagless final. Но не стал, т.к. во-первых статья уже огромная, во-вторых её тема это не «пишем ФП на Java». Ну и цель примера показать как можно убрать логику в декларации, а то что оно похоже на АТД в некотором роди приятный бонус.
А как ты понимаешь глядя в локальную точку графа откуда пришли данные и какова их природа без типов? Вот если ты пришел в проект новый и тебе дали задачу на шаге X сделать ещё одно действие Y. Или все таки держать в голове весь путь от инпута до текущего шага исполнения обязательно? Тогда кажется я все корректно описал про «держать всю программу в голове»:-)
Ну вот например удалять из коллекции можно всегда — это не приведёт к проблемам типизации. Это на самом деле чудовищная тема если начать её копать, особенно если отойти от абстрактных вещей к конкретным. Я советую для разминки потратить где-то пол часа жизни что бы разобраться почему метод HashMap.get в Rust принимает не тип ключа K, а новый тип Q, который такой что и
doc.rust-lang.org/std/collections/struct.HashMap.html#method.get
Что касается концепций, признаться не могу понять в чем аргумент. У меня например постоянно такое, что концепции одинаковые (по крайней мере в моей голове), а код всё таки приходится подправлять.
Сам я не писал серьезно на ДТ языках поэтому в целом я готов принять какие-то убедительные доводы. Однако ваши вызываю у меня вопросы.
Звучит так, как будто программа пишется так же, как исполняется её исходный код, в виде некоторого пайплайна. Однако, на практике написание программы скорее напоминает переусложнённую версию игры в Дженга, где вам приходится расширять программу изнутри периодически выделяя общие паттерны в мини-фреймворки, попутно удаляя неиспользуемое легаси. Более того сам характер взаимосвязей между компонентами не похож на поток: низкоуровневые компоненты переиспользуются многократно причем на разных абстрактных уровнях.
Сам я сталкивался с таким, что разработчик, не осилив написать типобезопасную версию апи, оставлял торчать Object-ы в декларациях или явные касты в коде и в результате тривиальный рефакторинг ломал всю программу, но понятно это было только при запуске тестов, а хочется же во время компиляции.
Писать так программы хорошо на любом языке, но тут мне кажется есть некоторая подмена понятий: хорошо писать код, который выглядит просто и понятно, но писать такой код совсем не просто: от того и идет «когнитивная нагрузка». Более того, если вы пишете библиотечный код, то самое главное, что бы им было просто и удобно пользоваться, а это зачастую значит писать очень сложный код внутри самой библиотеки.
И кстати как тебе статья в целом? Твое мнение было бы мне важно т.к. я на несколько твоих статей опираюсь здесь и даю на них ссылки:)