Лет 10 назад перевел свой проект с C++ на Python чтоб убрать компиляцию. Время полной перекомпиляции проекта - более часа. На таких проектах ты дорабатываешь какой-то модуль, ну т.е. dll-ку, которая компилируется порядка минуты. Но полный цикл отладки всё равно занимает порядка 10 минут.
остановить основное приложение, чтоб оно освободило dll-ку
скомпилировать dll-ку
запустить основное приложение - это тоже порядка минуты
проверить функционал - получить сбой
подключиться дебаггером - это нужно найти все воркеры в системе, относящиеся к основному приложению
отладится - понять что что-то не учел в ответе от другого модуля
Это мало того что медленно, из-за больших пауз теряется фокус внимания. А постоянное переключение внимания сильно утомляет.
Вместо всего этого в питоне пишешь что-то типа if is_local_stend: imp.reload(<модуль>) и у тебя следующий же запрос идет с использованием нового кода. А дебагер практически никогда не нужен (он в питоне тормозной) - при такой скорости перезапуска можно просто добавлять вывод данных в лог-файл.
Еще один интересный круг: в начале нулевых все браузеры поддерживали микрософтовский VBScript. Он был сложнее JavaScript, потому что там была типизация (не строгая, но была), поэтому от него отказались. Сейчас все переходят на TypeScript, именно из-за наличия в нем типизации. Причём язык, опять-таки, разрабатывается MS-ом.
Еще аналогия - серверный рендеринг. Сначала веб-сервера выдавали html-ку, потом стали рендерить веб страницу на клиенте с помощью JS. Теперь запускают этот JS на сервере, рендерят им html-ку и опять отдают клиенту готовую веб-страницу.
Попробую по другому объяснить. Есть внешняя, динамически-подключаемая, библиотека, которая тоже написана на Rust. Но, несмотря на то, что она написана на Rust-е, я должен вызывать её методы в Unsafe-блоках. В Java, C#, Python и т.д. в аналогичной ситуации внешний вызов не отличается от вызова внутренней функции и соблюдаются все защиты, заложенные в языке.
А большие приложения никогда не идут одним исполняемым файлом, т.е. Rust не готов к использованию в больших приложениях.
Как в Rust-е сделать объектную динамически-подключаемую библиотеку.
На Java, C#, Python и т.п. объекты стандартизированы. Т.е. ты в своем классе реализуешь какой-то интерфейс и подключаешь свой плагин к основной программе.
В Rust-е, я так понимаю, можно реализовывать только Си-шные функции. И вся прелесть раста при этом теряется.
ИМХО, самая глубинная причина хорошести html-а кроется в особенностях человеческого зрения. Наш глаз не идеален и текст должен быть очень удобен для восприятия его им. Например, нельзя увеличить текст в два раза - нужно обязательно изменить его пропорции. К этому еще добавляется и неидеальность даже современных мониторов: буквы могут размыться, у них может появится цветной ореол, могут стать угловатыми и т.д.
Поэтому нельзя изначально знать, сколько места текст займет на экране, и все остальные элементы должны подстроиться под него только во время отрисовки. Было множество попыток упростить вывод на экран и отрисовать всё по координатам: java-аплеты, activeX-компоненты, silverlight... Разумеется, они сработали, т.к. игнорировали особенности человеческого зрения. Сейчас продвигаются Blazor и Flutter. Слышал, что flutter уже столкнулся с проблемой мутного текста, какие-то решения этого в нем есть, но насколько они полноценны мне пока не понятно.
Шардирование, как и секционирование нарушают идею реляционной базы данных. В результате теряется ссылочная целостность; нельзя просто sql-запросом получить все данные; появляется необходимость в распределенных транзакциях. Это сильно усложняет разработку, по сравнению с тем, что было в Oracle.
Единственное, можно делать readonly-реплики для горизонтального масштабирования. При этом архитектура системы практически не усложняется, но есть некоторые нюансы, такие как ограничение времени работы запросов и лаг в обновлении данных.
В целом, асинхронный подход (имхо) нужен только в двух случаях:
1) ваш язык не поддерживает многопоточность
2) вы слушаете более 10 тысяч сокетов одновременно
В остальных случаях асинхронность не дает преимуществ, а сложностей добавляет существенно. И в типовых веб-сервисах рабочие потоки в основном проводят время в ожидании ответа от базы данных или другого сервиса, поэтому вполне можно запускать до сотни потоков на ядро (ориентируясь на фактическую загрузку процессора).
Не важен формат пенсионной системы - всё равно, в конечном счёте, всё сводится к соотношению работающих и пенсионеров. Единственный вариант, как выше было сказано - автоматизация всего что только можно.
Отец в конце 90х использовал CorelDraw вместо AutoCAD-а при работе с заказчиками, т.к. первый позволял делать гораздо более красивые и наглядные "чертежи". В малом бизнесе это имеет большое значение. Ну, а Inkscape сейчас повторяет возможности CorelDraw. Из недостатков, помнится, с такого "чертежа" нельзя снимать размеры для производства - слишком большие погрешности. И окружности на больших радиусах превращались в многогранники.
А arm-ноутбуки не смотрели ? - linux-у же не обязателен x86.
Лет 10 назад перевел свой проект с C++ на Python чтоб убрать компиляцию. Время полной перекомпиляции проекта - более часа. На таких проектах ты дорабатываешь какой-то модуль, ну т.е. dll-ку, которая компилируется порядка минуты. Но полный цикл отладки всё равно занимает порядка 10 минут.
остановить основное приложение, чтоб оно освободило dll-ку
скомпилировать dll-ку
запустить основное приложение - это тоже порядка минуты
проверить функционал - получить сбой
подключиться дебаггером - это нужно найти все воркеры в системе, относящиеся к основному приложению
отладится - понять что что-то не учел в ответе от другого модуля
Это мало того что медленно, из-за больших пауз теряется фокус внимания. А постоянное переключение внимания сильно утомляет.
Вместо всего этого в питоне пишешь что-то типа if is_local_stend: imp.reload(<модуль>) и у тебя следующий же запрос идет с использованием нового кода. А дебагер практически никогда не нужен (он в питоне тормозной) - при такой скорости перезапуска можно просто добавлять вывод данных в лог-файл.
Netscape Navigator - это конец 90-х. К 2000-м он уже сдулся и, по большому счету, остался только IE.
.. и, кстати, VBScript изначально "из коробки" работал на сервере :)
Еще один интересный круг: в начале нулевых все браузеры поддерживали микрософтовский VBScript. Он был сложнее JavaScript, потому что там была типизация (не строгая, но была), поэтому от него отказались. Сейчас все переходят на TypeScript, именно из-за наличия в нем типизации. Причём язык, опять-таки, разрабатывается MS-ом.
Еще аналогия - серверный рендеринг. Сначала веб-сервера выдавали html-ку, потом стали рендерить веб страницу на клиенте с помощью JS. Теперь запускают этот JS на сервере, рендерят им html-ку и опять отдают клиенту готовую веб-страницу.
Попробую по другому объяснить. Есть внешняя, динамически-подключаемая, библиотека, которая тоже написана на Rust. Но, несмотря на то, что она написана на Rust-е, я должен вызывать её методы в Unsafe-блоках. В Java, C#, Python и т.д. в аналогичной ситуации внешний вызов не отличается от вызова внутренней функции и соблюдаются все защиты, заложенные в языке.
А большие приложения никогда не идут одним исполняемым файлом, т.е. Rust не готов к использованию в больших приложениях.
Или я ошибаюсь?
Как в Rust-е сделать объектную динамически-подключаемую библиотеку.
На Java, C#, Python и т.п. объекты стандартизированы. Т.е. ты в своем классе реализуешь какой-то интерфейс и подключаешь свой плагин к основной программе.
В Rust-е, я так понимаю, можно реализовывать только Си-шные функции. И вся прелесть раста при этом теряется.
Не уловил, в чём связь проблемы саг и DDD ? Вроде, если пишешь на хранимках у тебя такие же проблемы возникают.
У меня дома такие philips-ы валяются. Рабочие. Лет пять пользовался, потом наушники с микрофоном понадобились.
>> Почему HTML так хорош?
ИМХО, самая глубинная причина хорошести html-а кроется в особенностях человеческого зрения. Наш глаз не идеален и текст должен быть очень удобен для восприятия его им. Например, нельзя увеличить текст в два раза - нужно обязательно изменить его пропорции. К этому еще добавляется и неидеальность даже современных мониторов: буквы могут размыться, у них может появится цветной ореол, могут стать угловатыми и т.д.
Поэтому нельзя изначально знать, сколько места текст займет на экране, и все остальные элементы должны подстроиться под него только во время отрисовки. Было множество попыток упростить вывод на экран и отрисовать всё по координатам: java-аплеты, activeX-компоненты, silverlight... Разумеется, они сработали, т.к. игнорировали особенности человеческого зрения. Сейчас продвигаются Blazor и Flutter. Слышал, что flutter уже столкнулся с проблемой мутного текста, какие-то решения этого в нем есть, но насколько они полноценны мне пока не понятно.
Шардирование, как и секционирование нарушают идею реляционной базы данных. В результате теряется ссылочная целостность; нельзя просто sql-запросом получить все данные; появляется необходимость в распределенных транзакциях. Это сильно усложняет разработку, по сравнению с тем, что было в Oracle.
Единственное, можно делать readonly-реплики для горизонтального масштабирования. При этом архитектура системы практически не усложняется, но есть некоторые нюансы, такие как ограничение времени работы запросов и лаг в обновлении данных.
Почему мультимастер в Postgres актуален ? - даже Сбербанк начал использовать Oracle Real Application Cluster только в 2014-м году. И то, не совсем честный - узлы кластера имели свою специализацию: https://coolfinans.ru/news/perekhod_na_orac_kart_sberbanka/2014-12-10-129
Или PostgreSQL технически слабее Oracle из-за чего алгоритмические недостатки требуется компенсировать горизонтальным масштабированием.
В целом, асинхронный подход (имхо) нужен только в двух случаях:
1) ваш язык не поддерживает многопоточность
2) вы слушаете более 10 тысяч сокетов одновременно
В остальных случаях асинхронность не дает преимуществ, а сложностей добавляет существенно. И в типовых веб-сервисах рабочие потоки в основном проводят время в ожидании ответа от базы данных или другого сервиса, поэтому вполне можно запускать до сотни потоков на ядро (ориентируясь на фактическую загрузку процессора).
Не важен формат пенсионной системы - всё равно, в конечном счёте, всё сводится к соотношению работающих и пенсионеров. Единственный вариант, как выше было сказано - автоматизация всего что только можно.
Какова ориентировочная стоимость такого робота: 100тыс, 500тыс, 1млн.. ?
Отец в конце 90х использовал CorelDraw вместо AutoCAD-а при работе с заказчиками, т.к. первый позволял делать гораздо более красивые и наглядные "чертежи". В малом бизнесе это имеет большое значение. Ну, а Inkscape сейчас повторяет возможности CorelDraw. Из недостатков, помнится, с такого "чертежа" нельзя снимать размеры для производства - слишком большие погрешности. И окружности на больших радиусах превращались в многогранники.
Может, самое лучшее - это что-то типа Еxcel с VBA: там и алгоритмы можно, и интерфейс. И практический опыт работы с электронными таблицами.
Я настроил Punto switcher на левый ctrl. Это самый удобный вариант - переключать язык можно не двигая рукой - просто ладошкой надавливая.
Ха, в школе я делал педальку переключения языка из степлера, замыкая контакты lpt-порта.