Если 20 лет назад вузы ругали за обучение студентов на корпоративных продуктах, то теперь маятник находится в протовоположной точке: студентов учат на "ванильных" опенсорсных продуктах.
В результате выбор делают по простой схеме: "У меня был успешный курсовик на постгресе, теперь буду делать на нём что-то посеръёзнее, зачем платить за неизвестный энтерпрайз если можно взять на помойке скачать бесплатно"
В геометрии визуально многое наглядно. Если вы геометр землемер, то этого достаточно. Если ученый - то все равно придется формально доказывать ваши построения, и тогда выяснится, что "всё не так однозначно".
Оверхеда нет лишь в том случае, если родной SQL engine заменяется новым, опираясь на storage API, включая переписанный оптимизатор. Можно ли назвать это постгресом? Вопрос риторический. Далее в исходнике встречается CREATE CLUSTERED INDEX или CREATE PARTITION FUNCTION и на этом эксперимент завершается костылями ввиду ограничений storage.
Тот же конвертер, только динамический, но требующий, по сути, переписать SQL engine и системные хранимые процедуры с трансляцией в язык целевой СУБД. Дальше все это заткнется на ограничениях storage engine. К тормозам самого постгреса добавляем еще и оверхед слоя трансляции "на лету".
Не нашел ни слова о том, что компилятор у Go неоптимизирующий, в отличие от С/С++, Rust и даже C#. Борьба с GC - первый признак того, что инструмент не вполне адекватен задаче.
Много слов о процессе (версионность промпта-псевдокода тоже опущена), но мало о цели. Судя по кратким фразам, функциональная сложность на уровне "записная книжка". Это неплохо, просто надо помнить, что такие примеры приложений создавались без написания даже одной строчки кода и 30 лет назад при помощи RAD типа Delphi.
Писать относительно много кода (сотни строк в день) требуется только на этапе "нулевого цикла". Очень быстро все приходит к норме "несколько десятков строк в день". Кодирование всегда занимало в среднем 10-20% времени, да и программирование - не кодирование.
Если 20 лет назад вузы ругали за обучение студентов на корпоративных продуктах, то теперь маятник находится в протовоположной точке: студентов учат на "ванильных" опенсорсных продуктах.
В результате выбор делают по простой схеме: "У меня был успешный курсовик на постгресе, теперь буду делать на нём что-то посеръёзнее, зачем платить за неизвестный энтерпрайз если можно
взять на помойкескачать бесплатно"Были же нормальные аджайл-коучи и криптоцыгане, зачем ушли в "интеллект"?
В геометрии визуально многое наглядно. Если вы
геометрземлемер, то этого достаточно. Если ученый - то все равно придется формально доказывать ваши построения, и тогда выяснится, что "всё не так однозначно"."Господь, жги!" (ц) :)
Можно начать отсюда: SQL Server as key-value store versus Redis
См. комментарий выше. По поводу "исполняются с той же скоростью" смешно пошутили.
Оверхеда нет лишь в том случае, если родной SQL engine заменяется новым, опираясь на storage API, включая переписанный оптимизатор. Можно ли назвать это постгресом? Вопрос риторический. Далее в исходнике встречается CREATE CLUSTERED INDEX или CREATE PARTITION FUNCTION и на этом эксперимент завершается костылями ввиду ограничений storage.
Тот же конвертер, только динамический, но требующий, по сути, переписать SQL engine и системные хранимые процедуры с трансляцией в язык целевой СУБД. Дальше все это заткнется на ограничениях storage engine. К тормозам самого постгреса добавляем еще и оверхед слоя трансляции "на лету".
В Париже из трех бед две ушли: каршеринг умер на начальной стадии, а самокаты убрали после многочисленных выступлений граждан.
Потому что NoSQL - это ребрендинг СУБД и моделей данных, существовавших до SQL
Не нашел ни слова о том, что компилятор у Go неоптимизирующий, в отличие от С/С++, Rust и даже C#. Борьба с GC - первый признак того, что инструмент не вполне адекватен задаче.
Если и тесты генерируют другие "промпты", то есть более дешевая альтернатива - кропить сервера святой водой.
В каждой шутке есть доля шутки :)
Много слов о процессе (версионность промпта-псевдокода тоже опущена), но мало о цели. Судя по кратким фразам, функциональная сложность на уровне "записная книжка". Это неплохо, просто надо помнить, что такие примеры приложений создавались без написания даже одной строчки кода и 30 лет назад при помощи RAD типа Delphi.
Писать относительно много кода (сотни строк в день) требуется только на этапе "нулевого цикла". Очень быстро все приходит к норме "несколько десятков строк в день". Кодирование всегда занимало в среднем 10-20% времени, да и программирование - не кодирование.
Скорее, претензия к компетентности авторов в теме сиквела. Открываем результат "призера" о3 и видим
то же яйцо, но сбокуту же проблему и ошибку.Открываю первый же запрос o3-mini‑high:
трудносопровождаемый copy-paste код, требующий примерно столько же комментариев, сколько и сам запрос
ошибка при выводе/формировании результата (для величин < 8.005)
Не финтехом единым. ERP или её подобие есть на любом предприятии. Это core system.
Просто вспомните о том, что когда бизнес меняет приложения, то данные мигрируют в новую систему. Потому что данные - основной актив.