мне надо http сервер, которьій будет стабильно работать и не падать. С миграцией БД я уже решил ?

vibe работает вроде

мне надо http сервер, которьій будет стабильно работать и не падать. С миграцией БД я уже решил ?

Вам зачем стабильность?

ну судя по жалобам на етом канале оно долго не умеет работать и течет

как зачем стабильность?)) мьі же в евросоюз только ради етого идем

мне надо http сервер, которьій будет стабильно работать и не падать. С миграцией БД я уже решил ?

Nginx?

ну судя по жалобам на етом канале оно долго не умеет работать и течет

та вы его грохайте иногда да и всё, systemd умеет

как зачем стабильность?)) мьі же в евросоюз только ради етого идем

?

Nginx?

+1

Та давно пора свою, костыльную, реализацию написать ввиде небольшой библиотеки

И не вспоминать о этом vibe.d

в итоге упремся в кооперативную многозадачность, и небольшая библиотека превратится в vibe.d)

Ну...

Возможно

Но не попробуешь - не узнаешь

+ не вижу ничего плохого в том, чтобы сделать свой vibe.d

Но ты его будешь знать от А, до Я

И сможешь быстрее реагировать на проблемы

да собственно, ядро vibe.d — это евентлуп и магия с файберами

да собственно, ядро vibe.d — это евентлуп и магия с файберами

Лично я предпочитаю такое самому писать

и всё говно, которое не дает прользоваться vibe.d по-взрослому, тоже происходит там)

да собственно, ядро vibe.d — это евентлуп и магия с файберами

И это, я тебе скажу, не так уж и сложно

На самом то деле, там много Г... потому, что там поддержка всех ОС

Лично я, если и буду писать что-то подобное, то исключительно под Linux

Не вижу смысла в вебсервере на винде

Хотя я сам сижу на Винде и сильно ее люблю

Но сервер под этой ОС не должен быть, имхо

иногда кажется, что в vibe.d уровней абстракции больше, чем слоев в лазаньи, сложна там всё)

Хотя я сам сижу на Винде и сильно ее люблю

Ыы бывает же

Есть старая идея сделать нечто подобное, но с несколькими уровнями: - отдельная библиотека с интерфейсами - отдельные библиотеки с реализациями каждой отдельной сущности (евентлупа, http, валидаторов, работы с бд...) - подключением шаблонизатора и самих шаблонов через *.so

Ыы бывает же

?

И немного жалко, что структуры не могут имплеминтировать интерфейсы

Для этого хочется сделать небольшой миксин или UDA, который на момент компиляции будет проверять сигнатыру интерфейсов и структур

Тот еще костыляка, но иногда нужно

Хорошая была бы фича

типа компил тайм интерфейсы

И немного жалко, что структуры не могут имплеминтировать интерфейсы

https://github.com/atilaneves/concepts

я вообще сам сначала такое сделал, а потом это нашел

?

Не помню, как можно любить винду. ) но, пожалуй, нет смысла эту тему поднимать

Не помню, как можно любить винду. ) но, пожалуй, нет смысла эту тему поднимать

)))

https://github.com/atilaneves/concepts

Вот что-то типа такого

Та давно пора свою, костыльную, реализацию написать ввиде небольшой библиотеки

++, но времени на такое не дадут

та вы его грохайте иногда да и всё, systemd умеет

ужас)) так не подовдет, spring приложения у нас месяцами работают без проблем

Лично я, если и буду писать что-то подобное, то исключительно под Linux

читать: Plan9

читать: Plan9

Ну такое. Я не видел сервера на ней

ужас)) так не подовдет, spring приложения у нас месяцами работают без проблем

teamcity на spring написан?

Ну такое. Я не видел сервера на ней

Движение жизнь. Если линукс выбрать на всю жизнь останешься в аутсайдерах

явно на нашей памяти появятся принципально новые процы и ОС

Да, возможно

Но идею я описал выше

Описывается интерфейсы, а реализация отдельно

Никто не мешает сделать свою реализацию под свою ОС

Та даже свою реализацию под уже имеющуюся ОС (свой драйвер)

Вот чего так vibe.d не сделал, не пойму

Ну думаю так же думали авторы vibe

Linux-у в обозримом будущем альтернатив не будет (лет 10 точно)

Движение жизнь. Если линукс выбрать на всю жизнь останешься в аутсайдерах

Кому-то важно быть толпой, да)

у нас вот сервера под HP-UX крутятся)

правда, в том году собираемся на красную шапку мигрировать

у нас вот сервера под HP-UX крутятся)

из-за какого-то софта типа оракл?

у нас тут SAP ERP, которая крутится на оракле)

земля вам пухом

в общем, очень специфичный и сугубо кроваво-энтерпрайзный случай)

угу

причем, у редхэта есть даже какое-то затюненое конкретно под наш лучай ядро

вот решили купить и слезть с иглы hp-ux)

https://pp.userapi.com/c849128/v849128046/d326/r_pmAPklzfo.jpg

ERROR: S client not available

АЗАЗАЗ

А вы говорите файберы

LOL

Очередь, ахахаха

машин лёрнинг и датамайнинг

это блокчейн

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

похоже на попытку забороть проблему капчи

типа кому надо те должны потерпеть 30 минут

параллелить такое затруднительно, якобы

Вместо капчи подождать 30 минут? ?

Вместо капчи подождать 30 минут? ?

Ну капчку автоматически разгадать - не проблема. А вот 30 минут подождать - значит тебе реально нужно)))

Ну, можно было hashcache использовать. Лучше 30 секунд ждать пока вычисления пройдут, чем 30 минут ждать пока таймер оттикает.

А такое как сейчас решение... Можно параллельно много ожиданий начать. Один фиг получается.

А такое как сейчас решение... Можно параллельно много ожиданий начать. Один фиг получается.

Нельзя - IPv4 кончились

На самом то деле, там много Г... потому, что там поддержка всех ОС

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

Можно написать веб сервер на голом epoll например и близко к betterC, но 1) либо это будет 1 тред на каждый коннект, что медленно 2) либо это будет асинхронная обработка, что влечет за собой callback-hell 3) либо это будет разработка на файберах что влечет за собой написание всех обвязок и примитивов, вовлечение GC и т.д. то есть приходим к тому же vibe

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

Не согласен

Можно написать веб сервер на голом epoll например и близко к betterC, но 1) либо это будет 1 тред на каждый коннект, что медленно 2) либо это будет асинхронная обработка, что влечет за собой callback-hell 3) либо это будет разработка на файберах что влечет за собой написание всех обвязок и примитивов, вовлечение GC и т.д. то есть приходим к тому же vibe

Не такой уж там и ад будет))))

В JS был а тут не будет? Impossibru

И ни одной IO функции нельзя заюзать нормально, все нужно реализовывать на колбеках

Так что это фтопку, возвращаемся к файберам, а тут как раз vibe-core минималистичный

Баг с зависанием в цикле вроде исправили, по поводу протечек - не знаю что там, может это клиентский код течет.

Ну так вот и гуд!

А я сделаю свой

Люблю костыли

Я на них быстро бегаю!)

Оу ну это что-то из разряда заблуждений программистов ) И дилеммы инноватора

Сначала есть кривые инструменты, все от них плюются. Потом кто-то начинает активно писать и продвигать свои велосипеды, потому что они "управляемы, контролируемы, ничего лишнего". И так вот пишешь пишешь велосипеды, а потом замечаешь что индустрия уже софт исправила и убежала далеко вперед, и продукты создаются парой строк кода. Пока велосипедист бегает и поддерживает свои легаси велосипеды :(

Да, возможно

Но твой велик ездит быстрее, чем их балид...