Я тоже в этом плане скорее оптимист, какие-то хорошие идеи будут взяты на вооружение. Сейчас без lock-файлов вообще не понятно, как это должно работать, а раньше их отсутствие было данностью.
Для меня тоже остаётся загадкой этот момент. Упоминаний про какие-то особенные возможности по скорости интерпретации или jit у JavaScriptCore не видел. Видимо старт у него и начальное потребление памяти действительно немного меньше, чем у V8.
В bun скорее фишка в том, что рантайм переписан с учётом скорости.
Декларируется, что Dragonfly написан с нуля, а не является чьим-о форком.
Вопрос с одной стороны риторический, потому что вряд ли кто-то будет сейчас именно переписывать Redis. С другой стороны создатели продолжают топить, что потоки от лукавого, однопоточный Redis крут, масштабируйтесь горизонтально и все в таком роде :)
В логике авторов данные всегда размазаны по Redis Cluster равномерно, соответственно если одна машина выходит из строя, то чем больше машин было в кластере изначально, тем большая часть данных по прежнему доступна.
А может еще добавите в статью, в какой версии TypeScript появилась возможность вот так использовать "индексатор числа [number]". Это может быть полезно для тех, кто внимательно следил за TypeScript раньше, а сейчас немного ослабил хватку :)
В их эксперимент они запускают Redis Cluster, в котором данные шардируются по ключам. То есть память достаточно адекватно должна в такой схеме расходоваться, не x40.
Меня тоже эти $21 миллион как-то удивили для такого технологического проекта. Под впечатлением пошел посмотреть, сколько привлекли KeyDB (тоже многопоточный убийца Redis из 2019 г.). Оказалось, что у них было $1.3 миллиона в Seed-раунде, а потом их поглотил Snapchat. Может и тут какая-то похожа история выйдет...
У меня скрипты из package.json действительно немного быстрее работают. Установка зависимостей вроде ощутимо быстрее.
Тут легко проверить, с очень высокой вероятностью все просто запустится через bun run.
Согласен. Сам почувствовал, что пока читал и переводил немного сахар на зубах начал скрипеть от того, как все волшебно, blazing fast и так далее ?
За полной версией анонса сюда - https://habr.com/ru/articles/760002/
Вас TypeScript вообще не обязывает писать в ООП. На старте это было так, сейчас же масса функционального кода отлично использует TS.
Ну, и по чесноку, TypeScript - это, наверное, лучшее, что произошло с JavaScript в 2010ые.
А разве новые идеи и попытки что-то сделать иначе и лучше не двигает разработку вперёд? :)
Я тоже в этом плане скорее оптимист, какие-то хорошие идеи будут взяты на вооружение. Сейчас без lock-файлов вообще не понятно, как это должно работать, а раньше их отсутствие было данностью.
Для меня тоже остаётся загадкой этот момент. Упоминаний про какие-то особенные возможности по скорости интерпретации или jit у JavaScriptCore не видел. Видимо старт у него и начальное потребление памяти действительно немного меньше, чем у V8.
В bun скорее фишка в том, что рантайм переписан с учётом скорости.
Как тяжело читать эту гигантскую простыню... :)
Декларируется, что Dragonfly написан с нуля, а не является чьим-о форком.
Вопрос с одной стороны риторический, потому что вряд ли кто-то будет сейчас именно переписывать Redis. С другой стороны создатели продолжают топить, что потоки от лукавого, однопоточный Redis крут, масштабируйтесь горизонтально и все в таком роде :)
Спасибо за "многопроцессный", исправил.
Да, если добавить пометку, что речь про шардированный и реплицированный Redis Cluster, то абзац станет менее спорным :)
А в какой логике это ухудшает отказоустойчивость?
В логике авторов данные всегда размазаны по Redis Cluster равномерно, соответственно если одна машина выходит из строя, то чем больше машин было в кластере изначально, тем большая часть данных по прежнему доступна.
Спасибо!
А может еще добавите в статью, в какой версии TypeScript появилась возможность вот так использовать "индексатор числа [number]". Это может быть полезно для тех, кто внимательно следил за TypeScript раньше, а сейчас немного ослабил хватку :)
Кстати, очередь как будто немного ожила с середины 2022 года https://github.com/tarantool/queue/releases
Спасибо, за список. Я бы добавил в шпаргалку пункт про VACUUM, MVCC и зачем это все нужно.
Мое искажение восприятия говорит мне, что современный чип AMD лучше, чем Intel и я бы купил именно его. Маркетинг работает :)
В их эксперимент они запускают Redis Cluster, в котором данные шардируются по ключам. То есть память достаточно адекватно должна в такой схеме расходоваться, не x40.
А KeyDB не тестировали? А то про него хайпа меньше, а толку может и больше)
Меня тоже эти $21 миллион как-то удивили для такого технологического проекта.
Под впечатлением пошел посмотреть, сколько привлекли KeyDB (тоже многопоточный убийца Redis из 2019 г.). Оказалось, что у них было $1.3 миллиона в Seed-раунде, а потом их поглотил Snapchat. Может и тут какая-то похожа история выйдет...
А мы с вами от конкуренции даже выиграем :)