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

возьмем например объект у которого 20 int64 полей то для 3тб получится 20млд объектов и если сильно оптимистически посчитать что процессор успевает просканивовать один объект за один такт то для 2ггц процессора получится 10 секунд, в реальности в разы больше (плюс кроме прохода по объектам надо еще выяснить те которые остались чтобы удалить), даже если и можно компенсировать это многоядерностью все равно получается порядок на десятки секунд что точно не вариант если gc не умеет делать сборку мусора инкрементально и будет приостанавливать обработку запросов на 10 секунд

Добрый день. А с тупыми вопросами сюда или есть отдельный чат? Например интересует такое: функция fun1 возвращает несколько результатов, я могу их запихнуть в одну переменную? а потом добавить к ним ещё что-то и передать в другую функцию как отдельные аргументы?

структуры изоморфны кортежам

Эээ

структуры изоморфны кортежам

возьмем например объект у которого 20 int64 полей то для 3тб получится 20млд объектов и если сильно оптимистически посчитать что процессор успевает просканивовать один объект за один такт то для 2ггц процессора получится 10 секунд, в реальности в разы больше (плюс кроме прохода по объектам надо еще выяснить те которые остались чтобы удалить), даже если и можно компенсировать это многоядерностью все равно получается порядок на десятки секунд что точно не вариант если gc не умеет делать сборку мусора инкрементально и будет приостанавливать обработку запросов на 10 секунд

в структуру запихни все полученные из функции данные и всё

И часто вы храните только инт? строк тонна будет

Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?

Как?

Можно написать её даже на питоне, но не нужно. У го 1) гц, 2) очень плохой оптимизатор, 3) совершенно не нужный для этой задачи рантайм

так а строки это просто ссылка на другой объект которая кодируется в виде int64, то есть под интами я посчитал не просто числа а и ссылки, плюс есть еще массивы где объекты друг за другом находятся и это тоже увеличивает процент памяти который надо сканировать

a, b, c := pook() s := MyStruct{a, b, c}

казалось бы, причем тут гц и оптимизатор

если нам не нужно, чтобы in-memory бд была быстрая, то почему бы не написать её на питоне?

потому что есть GIL? define "быстрая"

1) высокая скорость ответа 2) низкое потребление ресурсов 3) способность обрабатывать большое количество клиентов

если нам не нужно, чтобы in-memory бд была быстрая, то почему бы не написать её на питоне?

а зачем нужна медленная in-memory db?

Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?

какому из критериев не соответствует кокроч?

ну так парни уже завезли версию два, и там норм

+ 1/4 прибавки

Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?

при том что первая версия в 2 раза медленнее постгреса в лучшем случае

Народ подскажите пожалуйста а на go можно написать in-memory базу данных? У меня почему есть уверенность что все языки со сборщиком мусора не подходят для этого и go как язык с gc соотвественно тоже но хотелось бы уточнить. Для in-memory базы даннных важны минимальные задержки при сборке мусора а точнее даже чтобы эти задержки не зависели от количества объектов в памяти. Сейчас серверы могут иметь до 3 терабайт оперативной памяти (и еще больше терабайт если используется свап на быстрых nvme ssd дисках) и поскольку принцип работы сборщика мусора заключается в том чтобы просканировать все достижимые объекты с корня и очистить все остальные то только для сканирования 3 терабайт объектов потребуется несколько десятков секунд. Поэтому сразу возникает вопрос - умеет ли сборщик мусора в go работать инкрементально а не по принципу "stop the world" и насколько большие расходы в целом на gc в зависимости от количества объектов?

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

Проблемы есть, и тот же Убер в них влетел и о них много рассказывает

как может не подгорать стул, когда живешь в мире, где гуи приложения пишут на электроне, а перфоманс и латенси критикал софт на го?

как может не подгорать стул, когда живешь в мире, где гуи приложения пишут на электроне, а перфоманс и латенси критикал софт на го?

как может не подгорать стул, когда живешь в мире, где гуи приложения пишут на электроне, а перфоманс и латенси критикал софт на го?

а если работу с памятью написать на С и кросс компиляцией бахнуть?

>Rust это новый язык со всеми шнягами и безопасностью из-коробки и незначительно медленее C вы в 1С не работаете? формулировки прямо как из брашуры по битриксу

>Rust это новый язык со всеми шнягами и безопасностью из-коробки и незначительно медленее C вы в 1С не работаете? формулировки прямо как из брашуры по битриксу

как может не подгорать стул, когда живешь в мире, где гуи приложения пишут на электроне, а перфоманс и латенси критикал софт на го?

я против C/C++ в новых проектах, но единственная серьёзная альтернатива этим языкам это Rust, не Go, Go он про другое

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

вот смотрите - https://www.techempower.com/benchmarks/ , на первом месте С, потом С++, потом Джава, потом голанг (Фастхттп)

я против C/C++ в новых проектах, но единственная серьёзная альтернатива этим языкам это Rust, не Go, Go он про другое

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

эта часть всегда связанна с Application Programming'ом. Не systems

тем не менее rocksdb(c++), tarantool(c/c++), spanner(c++)

так можно на современном C++ переписать, разве не лучше?

тем не менее rocksdb(c++), tarantool(c/c++), spanner(c++)

нет, не лучше. Compile-time безопасности как у Rust там не будет (без спец. анализаторов, которые нужно отдельно настраивать и возможно даже покупать потому-что статически анализировать C++ код это то ещё удовольствие)

тем не менее rocksdb(c++), tarantool(c/c++), spanner(c++)

А НИЧЕГО ЧТО КАНАЛ ПО GO?

А НИЧЕГО ЧТО КАНАЛ ПО GO?

го обогнал го?

ну так все эти проекты начали писать до выхода раста в стабильный релиз

compile-time безопасности может быть и не будет, но это быстрее, чем переписывать полностью на Rust

есть живые проекты, которые вышли после релиза?

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

ну так все эти проекты начали писать до выхода раста в стабильный релиз

баз данных?

мы вроде про них говорим, да

Раст слишком молодой и ещё на многих производит ощущение "выглядит клёво, но в жизни на этом писать не буду"

на русте тоже не все в actix сидят

https://github.com/rust-unofficial/awesome-rust#database

вопрос времени

и время покажет найдет ли раст себе нишу

с Go всё проще потому-что язык простой и не про системное программирование. Был бы Go более low level то он бы тоже так не взлетел, конкурировать с C++ очень сложно

?вроде уже показывает: https://www.rust-lang.org/en-US/friends.html

что из этих 4х живое и используется в проде?