LINUX.ORG.RU

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

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

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

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

Спасибо, писал на делфи семь лет, не готов согласиться с тобой.

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

Манипуляция каждый раз в том что они просто кодят на своем решете каждый день, но Раст пробуют на прочность по всей строгости доставая из жопы самые мудренные сценарии чтобы доказать что какой-то сферический баг в вакууме может случиться. Когда найдут такой баг, очень радуются и делают логический скачек до «в Rust возможны баги, значит его разработчики лгут, когда утверждают что на Rust код безупречен и баги абсолютно невозможны никогда» и «Rust не нужен, что и требовалось доказать».

У них в голове требовалось. Требовалось очень, очень сильно

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

Манипуляция каждый раз в том что они просто кодят на своем решете каждый день, но Раст пробуют на прочность по всей строгости доставая из жопы самые мудренные сценарии чтобы доказать что какой-то сферический баг в вакууме может случиться. Когда найдут такой баг, очень радуются и делают логический скачек «Rust не нужен, что и требовалось доказать»

Я таким же макаром могу говорить, что C++ безопасен в 99% случаев. А чо ты достаешь из жопы самые мудренные сценарии? Пиши на крестах нормально, и код будет нормальным, безо всяких там UB.

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

А у меня есть вопрос: почему страница должна грузиться дольше 100 мс? 1 секунда — это очень, очень много.

Текущий тред на лоре грузится у меня за 550мс, главная 250мс. И это с разогретым кешем и нулевым функционалом фронтенда.

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

99% разрабов не пишут этого софта. А 1% может и на сишке пописать.

На чем писать этот 1% и сам решит) Только там не 1 процент. Суть в том что иногда время рантайма может стоить космических денег, значительно дороже времени программииста. И чем крупнее проект тем серьезнее последствия и крупнее суммы, так что…

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

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

на расте можно объявлять все функции как «unsafe fn», и спокойно себе писать на Box-ах без лишних заморочек, с удобными struct и union

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

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

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

Это как с некоторыми мужиками бывает: когда они уже после сорока видят, что возраст даёт о себе знать и мужское здоровье уже не то, что в 18, они начинают строить из себя богатырей, фоткаются с молоденькими девушками, ходят в майке «Секс-инструктор» и постят в Одноклассниках снимки из отпуска, где они на пляже мускулами играют, пытаясь убедить всех (и себя в том числе), что они ещё огого.

Вот тут на ЛОР-е есть дюжина таких, только из мира программирования. Они где-то глубоко внутри понимают, что знание наизусть стандарта С++ о многих тысячах страниц и сотнях нюансов, когда ждать УБ, а когда просто сегфолт, скоро просто никому будет не нужно. Всё переедет в Вёб, классический десктопный софт больше не будет писаться, гуй будет весь на Электроне и аналогах. Ну и Раст захватит ту нишу, которую ещё обороняет ППЦ ЦПП.

Отсюда все эти манёвры и попытки подогнать ситуацию под шаткие аргументы.

Смиритесь и встретьте почтенные годы с гордо поднятой головой, а не юля, как уж на сковороде.

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

Текущий тред на лоре грузится у меня за 550мс, главная 250мс. И это с разогретым кешем и нулевым функционалом фронтенда

160 мс у меня грузится сам тред, еще какое-то время (1+ секунда) запрашиваются кэшированные ресурсы аватарок и JS. Фронт не нулевой, потому что есть jQuery для обновления треда и отправки сообщений без перезагрузки. У Facebook тоже как бы «нулевой» фронт, потому что он только загружает статичные странички, но почему-то все-таки не нулевой и все на него смотрят как на эталон SPA.

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

160 мс у меня грузится сам тред, еще какое-то время (1+ секунда) запрашиваются кэшированные ресурсы аватарок и JS.

я все вместе считал.

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

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

У Facebook тоже как бы «нулевой» фронт, потому что он только загружает статичные странички, но почему-то все-таки не нулевой и все на него смотрят как на эталон SPA.

На счет эталона не уверен но там действительно SPA и это уже огромная разница.

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

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

Где этот проект? Youtube пишется на питоне, инстаграм пишется на питоне, whatsapp пишется на эрланге, Гугл пишет на жаве, питоне, и C++, Facebook пишет на PHP. Ты бы хоть сказал компаниям из FAAMG, что, оказывается, время рантайма у них может стоить космических денег, а то они не в курсе.

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

Мне кажется, что они перепиливают свои сервера по результатам голосований на stackoverflow. Потому что там уже накидано в кучу всех самых модных технологий — и я сомневаюсь, что там хотя бы один человек сел и взвесил за и против применения той или иной технологии. Меня умиляются вот такие новости:

https://developers.slashdot.org/story/21/02/24/2110258/why-discord-is-switchi...

Типа «написали сервер на Go. Быстро заработало. Написали на Rust — заработало еще быстрее». Производительность Rust не возникает из астрала магическими пассами, она имеет вполне конкретные причины и механизмы, которые можно оценить заранее или, в крайнем случае, написать примитивный прототип для бенча. Но у разрабов из дискорд такие удивленные глазки, вроде «ух ты, а, оказывается, есть ЯП, которые выдают более быстрые программы, чем Go». Конечно есть. Они просто про язык Си не слышали еще — вот подожди чутка, сейчас до них дойдет слух, и они начнут отдельные сервисы на Си писать, а потом рассказывать, что есть такой язык программирования.

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

Ну в 2021 начинать новый проект на Сишке - это совсем надо поехать

Фух, слава богу, что я в 2019 начал — значит, у меня с головой всё в порядке.

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

Да, меня полностью устраивает эргономичность Раста, кроме некоторых вещей - обработка ошибок например

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

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

Но у нас нет такого языка — есть только C++ и Rust.

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

Отсюда все эти манёвры и попытки подогнать ситуацию под шаткие аргументы.

Я вижу по другому. Самые ярые хейтеры Раста, типа Царя или Siborgium-а на самом деле латентные растоманы. Остальные же просто потрындеть на тему программирования пришли.

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

160 мс у меня грузится сам тред, еще какое-то время (1+ секунда) запрашиваются кэшированные ресурсы аватарок и JS.

я все вместе считал

А смысл? Через 160 мс сайт полностью работоспособен и на нем есть весь контент, включая стили отображения. Дам еще через полминуты у меня какой-то JS загрузился — его тоже считать во время загрузки?

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

Можешь предложить вариант лучше? С кнопкой пользователь хотя бы знает, что есть новые сообщения. В принципе, можно было бы загружать новые сообщения и подсвечивать до тех пор, пока пользователь не проведет мышкой. Правда, как это штуку натянуть на пагинацию — понятия не имею.

Худшее же, что придумали в UI за последнее время — это бесконечная прокрутка, когда пользователь понятия не имеет, где он находится и сколько контента еще есть.

На счет эталона не уверен но там действительно SPA и это уже огромная разница

В какой момент для тебя «нулевой фронт» превращается в «SPA»? Когда грузится по десять секунд, вкладка выжирает 200+ Мб оперативы, не индексируется поисковиком и на страницы нельзя дать ссылку? Facebook сам уходит от такого принципа, и больше склоняется к подгрузке через JS содержимого следующей страницы, четко отделенной от предыдущей в ссылке. По сути почти то же самое можно сделать на фреймах. А если бы лор был на фреймах — это для тебя был бы «ненулевой» фронт?

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

Не понял в чем твой point

В том, что я завидую успешным крестовикам, в то время, как сам упорно избегаю любой возможности сделать карьеру программиста, хотя кресты — это идеальная ниша для меня, я спокойно осваиваюсь в проектах-многомиллионниках, при этом могу вылавливать самые замороченные баги, с которыми не справится 99% программистов. Вот и интересуюсь, что же я потерял, проигнорировав предложение уехать работать в штаты.

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

Где этот проект? Youtube пишется на питоне, инстаграм пишется на питоне, whatsapp пишется на эрланге, Гугл пишет на жаве, питоне, и C++, Facebook пишет на PHP. Ты бы хоть сказал компаниям из FAAMG, что, оказывается, время рантайма у них может стоить космических денег, а то они не в курсе.

А дискорд пишется на расте и драйвера в линуксе теперь пишутся на расте.

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

А я не сомневаюсь https://habr.com/ru/post/487116/ Ни кто не стал бы переписывать проект просто по приколу.

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

Результат превзошел ожидания.

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

Влажные фантази.

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

Можешь. Разница где проводить границу. Мне граница Rust нравится больше чем плюсов

Может и больше нравится, да только кому нужен язык, которые немного лучше крестов? Всем нужен язык, который намного лучше крестов. При том, что кресты настолько ужасны, что, казалось бы, любой язык должен быть лучше крестов. Даже Си, в некоторых вещах.

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

Всем нужен язык, который намного лучше крестов.

Это какой? Чтобы не стеснял программиста в попытках сделать что угодно и при этом строго контролировал корректность программ, предоставлял примитивы для любых концепций программирования и при этом имел sound type system, позволял писать программы без рантайма и при этом предоставлял GC, если понадобилось работать с графами?

Первое не позволено теоремой Райса, второе - теорией типов, ну третье может быть можно сделать.

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

В таких компаниях нету никаких «крестовиков» или «джавистов», там это даже звучит странно, как «лопатник» или «молоточник». Есть просто инженеры разных уровней. Ну разве что за исключением специализированной команды работающей над базовым инструментарием конкретного языка или разрабатывающей стиль кодирования.

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

А дискорд пишется на расте и драйвера в линуксе теперь пишутся на расте

А СУБД не пишутся на расте. И СУБД являются ключевыми звеньями в производительности многих веб-серверов. Ну и да, еще одним ключевым звеном являются ОС, которые написаны на Си, а на расте там только драйвера, которые с таким же успехом можно писать еще и на паскале:

https://wiki.freepascal.org/linux/kernel/module_development

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

Результат превзошел ожидания

Там нет никаких «ожиданий». Там вполне конкретно написано «программа на Rust работает быстрее аналогичной программы на Go». Внезапно. Кто бы мог подумать. Возьмем на заметку.

А я не сомневаюсь https://habr.com/ru/post/487116/ Ни кто не стал бы переписывать проект просто по приколу

Минимум аргументации — максимум пафоса. У них среднее время ответа растет до 20 мс — и это вроде как является причиной перейти с Go на Rust? Прям лёг сервис, все пользователи на протяжении этих 20 мс гневно строчили жалобы в поддержку на тупящий сервис, и все 20 мс поддержка жаловалась разработчикам на то, что «это невыносимо».

А вот что сделали для решения подобной задачи людишки из dgraph:

https://github.com/dgraph-io/ristretto

60 млн запросов в секунду. Оно, к слову, базируется на стандартных map языка Go. Map, который выделяет свои данные вне кучи и они не обрабатываются сборщиком мусора, то есть, у самого map околонулевая стоимость сборки мусора. А значит, дискордовцы с очень большой вероятностью накосячили в реализации и там даже близко нет никаких «мы написали очень эффективный код Go с минимальным количеством выделений памяти» — потому что если вы написали очень эффективный код, то какого хера у вас сборщику мусора вообще есть что собирать?

Потому этот рассказ больше похоже на «мы набирали индусов на Go — теперь решили набрать индусов на Rust. А поскольку нам нужен какой-то красивый повод для того, чтобы об этом объявить — вот вам наша история про замену одного кривого сервиса другим». Ну не осилили они Go или надоел он им — хорошо, пишите на другом языке, но зачем придумывать этому оправдания?

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

Чтобы не стеснял программиста в попытках сделать что угодно и при этом строго контролировал корректность программ, предоставлял примитивы для любых концепций программирования и при этом имел sound type system, позволял писать программы без рантайма и при этом предоставлял GC, если понадобилось работать с графами?

Rust в ранних своих версиях был очень близок к годной замене C++. Система типов у него замечательная и современная. А GC, например, есть в ядре линукса, но применяется оно только к очень ограниченному числу сущностей — я склоняюсь к позиции, что неограниченное использование GC является злом. Это понимали разрабы Go, потому у них контейнеры не подвержены сборке мусора, как это происходит в том же V8. В отличие от JVM, которая стала живым подтверждением того, как плохо всё становится, когда на каждый чих создается мусор.

По поводу безопасности всё просто: либо ты тратишься на персистентные/неизменяемые структуры данных, а также на всякие счетчики ссылок и мутексы, передаешь данные между акторами сообщениями, и получаешь надежный, но медленный код; либо ты делаешь lock-free алгоритмы, где можно с очень высокой производительностью выстрелить себе в ногу.

Всё, попытка создания универсального и эффективного алгоритмы работы с разделяемыми данными пока что ни у кого не увенчалось успехом. У меня есть определенные задумки по этому поводу, но пока что это скорее гайдлайны для писания подобных алгоритмов, нежели формально выверенные правила, по которым можно програмно проверить любой алгоритм на корректность. Грубо говоря, это некий контейнер, который выполняет конечное число действий по достижению целевого состояния, единого для всех потоков, и любой поток может толкать контейнер по пути достижения единого целевого состояния, либо генерировать ошибку при недостижимости этого состояния. Естественно, задача проверки конечности действий, достижимости и единственности цели — это весьма тяжелая штука в плане формальной проверки (если возможная).

Те же контейнеры, которые есть в стандартной либе раста, крайне ограничены и покрывают лишь малую долю всех задач работы с разделяемой памятью. Нужно понимать, что простая блокировка и RW блокировка — это самые примитивные инструменты, которые очень далеки от достижения оптимальной производительности. И тем более у них нет механизмов для избегания дедлоков, которые неизбежно понадобятся в любой мало-мальски сложной системе.

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

и драйвера в линуксе теперь пишутся на расте.

Срочно неси все драйверы в линуксе, написанные (или хотя бы пишущиеся в данный момент) на расте.

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

В таких компаниях нету никаких «крестовиков» или «джавистов», там это даже звучит странно, как «лопатник» или «молоточник». Есть просто инженеры разных уровней

Ну ёлы, я недавно писал на делфях, сейчас пишу на JS. Кто я после этого — молоточник или лопатник? Конечно же на изучение либ нужно намного больше времени, чем просто на изучение базового языка. По моим ощущениям, более менее вошел в курсе дела я только месяца через два, а продвинутые навыки получил после года. И я сомневаюсь, что человек, который знаком с сорцами хрома вдоль и поперек, внезапно пойдет писать на Java какой-то БД-сервис — просто потому что ему понадобится потратить уйму времени на изучение целевых инструментов.

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

Ваши слова только подтверждают опасения.

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

А СУБД не пишутся на расте.

Пишутся https://tensorbase.io/2021/03/16/announce_base_fe.html

Там нет никаких «ожиданий». Там вполне конкретно написано «программа на Rust работает быстрее аналогичной программы на Go». Внезапно. Кто бы мог подумать. Возьмем на заметку.

Что ты пытаешься доказать?

Нагрузочное тестирование сразу показало отличный результат. Быстродействие службы на Rust оказалось таким же высоким, как у версии Go, но без этих всплесков повышения задержки!
Что характерно, мы практически не оптимизировали версию Rust. Но даже с самой простой оптимизацией Rust смог превзойти тщательно настроенную версию Go. Это красноречивое доказательство, насколько легко писать эффективные программы на Rust по сравнению с глубоким погружением в Go.
Но наc не удовлетворил простой статус-кво по производительности. После небольшого профилирования и оптимизации мы превзошли Go по всем показателям. Задержка, CPU и память — всё стало лучше в версии Rust.

Понимаешь что тут написано? Они не ожидали что раст покажет хорошие результаты «из коробки».

А вот что сделали для решения подобной задачи людишки из dgraph

Сравнил теплое с мягким, может быть у них эти 60 лямов запросов в секунду каждые 2 минуты виснут на время работы GC. Понимаешь что такое реалтайм системы и что для них важнее стабильность и предсказуемость, а не абстрактное количество запросов?

Потому этот рассказ больше похоже на «мы набирали индусов на Go — теперь решили набрать индусов на Rust. А поскольку нам нужен какой-то красивый повод для того, чтобы об этом объявить — вот вам наша история про замену одного кривого сервиса другим». Ну не осилили они Go или надоел он им — хорошо, пишите на другом языке, но зачем придумывать этому оправдания?

Фантазер.

TDrive ★★★★★
()
Последнее исправление: TDrive (всего исправлений: 2)
Ответ на: комментарий от Siborgium

Срочно неси все драйверы в линуксе, написанные (или хотя бы пишущиеся в данный момент) на расте.

С разморозкой, вот какая ситуация https://habr.com/ru/company/selectel/blog/552142/ была месяц назад.

Удивительно что раста-хейтеры еще не нашли эту статью и не водят хоровод вокруг нее.

TDrive ★★★★★
()
Последнее исправление: TDrive (всего исправлений: 1)
Ответ на: комментарий от TDrive

Сравнил теплое с мягким, может быть у них эти 60 лямов запросов в секунду каждые 2 минуты виснут на время работы GC

фантазер

Может раст каждые 2 минуты виснет на время освобождения дерева Rc?

Это обоюдоострый аргумент, и фантазируешь здесь ты.

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

А мессенджер это теперь реалтайм система?

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

Может раст каждые 2 минуты виснет на время освобождения дерева Rc?

Опыт дискорда говорит об обратном.

Это обоюдоострый аргумент, и фантазируешь здесь ты.

Я аргументирую свои слова, какие фантазии?

А мессенджер это теперь реалтайм система?

Там голосом общаются если ты не в курсе.

TDrive ★★★★★
()
Последнее исправление: TDrive (всего исправлений: 1)
Ответ на: комментарий от TDrive

А СУБД не пишутся на расте.

Пишутся https://tensorbase.io/2021/03/16/announce_base_fe.html

Я не имел в виду, что это невозможно. И сишный код один в один переписывается на хаскеле — но это бессмысленно, потому что язык не дает никаких инструментов для упрощения решения задачи. Вся СУБД — про изменяемое общее состояние и корректную логику работы с ним.

Там нет никаких «ожиданий». Там вполне конкретно написано «программа на Rust работает быстрее аналогичной программы на Go». Внезапно. Кто бы мог подумать. Возьмем на заметку.

Что ты пытаешься доказать?

Чтобы иметь разумные ожидания, нужно эти построить на основе какого-то анализа. Какой может быть анализ, если челы лепят что попало, и это что попало как попало работает? Результаты могут быть любыми. Скорее они должны быть удивлены, что оно у них вообще как-то заработало — вот в это я поверю.

Понимаешь что тут написано? Они не ожидали что раст покажет хорошие результаты «из коробки»

А с чего ты взял, что он показал хорошие результаты? Ты графики загрузки ЦПУ видишь? Они, между прочим, у раста выше аналогичных для Go. Наговнокодили на Go, потом наговнокодили на расте — раст в чем-то там обогнал «тщательно настроенный» говнокод на Go. И что это показывает? Что шурупы забивать молотком удобнее, чем закручивать гвозди отверткой?

Сравнил теплое с мягким, может быть у них эти 60 лямов запросов в секунду каждые 2 минуты виснут на время работы GC

Графики читай, и текст — там всё написано, а ты выдумываешь.

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

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

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

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

Там голосом общаются если ты не в курсе

Да, вот только на раст переписали не эту часть. О качестве дискордового войса и его «реалтаймовости» лучше вообще умолчать.

Siborgium ★★★★★
()
Последнее исправление: Siborgium (всего исправлений: 1)
Ответ на: комментарий от TDrive

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

Там написано про какой-то абстрактный тестовый драйвер, в ответ на который Торвальдс попросил пример настоящего драйвера. Которого до сих пор нету.

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

Предоставляю тебе необходимую инфу: https://google.com

Вперед, почитаешь – возвращайся, пока что с тобой не о чем разговаривать.


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

Siborgium ★★★★★
()
Последнее исправление: Siborgium (всего исправлений: 1)
Ответ на: комментарий от byko3y

Я не имел в виду, что это невозможно. И сишный код один в один переписывается на хаскеле — но это бессмысленно, потому что язык не дает никаких инструментов для упрощения решения задачи. Вся СУБД — про изменяемое общее состояние и корректную логику работы с ним.

Не очень понял о чем ты, в случае с TensorBase автор утверждает что смысл есть, там сравнения по перформансу с кликхаусом.

Чтобы иметь разумные ожидания, нужно эти построить на основе какого-то анализа. Какой может быть анализ, если челы лепят что попало, и это что попало как попало работает? Результаты могут быть любыми. Скорее они должны быть удивлены, что оно у них вообще как-то заработало — вот в это я поверю.

Они же написали на чем основано их решение, привели графики.

А с чего ты взял, что он показал хорошие результаты? Ты графики загрузки ЦПУ видишь? Они, между прочим, у раста выше аналогичных для Go.

Нет не выше если учесть пики, но у раста распределение нагрузки равномерное, именно это им и нужно.

Наговнокодили на Go, потом наговнокодили на расте — раст в чем-то там обогнал «тщательно настроенный» говнокод на Go. И что это показывает?

У тебя прям какая то инсайдерская инфа, ты работаешь в дискорде? Или просто фантазируешь?

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

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

лол, какие мы агрессивные, иди читай и не е***и мозги.

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

Отправил в игнор.

Какой ужас, пойду плакать.

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

Не очень понял о чем ты, в случае с TensorBase автор утверждает что смысл есть, там сравнения по перформансу с кликхаусом

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

Чтобы иметь разумные ожидания, нужно эти построить на основе какого-то анализа. Какой может быть анализ, если челы лепят что попало, и это что попало как попало работает? Результаты могут быть любыми. Скорее они должны быть удивлены, что оно у них вообще как-то заработало — вот в это я поверю.

Они же написали на чем основано их решение, привели графики

А я объяснил, почему их сервис на Go — низкокачественный говнокод. А тот факт, что программа на Rust еле обогнала говнокод на Go позволяет предположить, что на расте там написан аналогичный говнокод. Потому «графики» позволяют делать вывод, что удивлены он должны быть только тем, что сервис у них вообще как-то работает, а не вываливается в панику каждые 2 минуты. Хотя этого мы не знаем, может у них там паника перехватывается и продолжается работа.

Наговнокодили на Go, потом наговнокодили на расте — раст в чем-то там обогнал «тщательно настроенный» говнокод на Go. И что это показывает?

У тебя прям какая то инсайдерская инфа, ты работаешь в дискорде? Или просто фантазируешь?

Я не работаю в дискорде, но я за версту чую мудаков и налюб.

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