Pull to refresh
114
0
Протько Сергей @Fesor

Full-stack developer

Send message
> а так же максимально приближенное к реальности ООП.

значит вы плохо понимаете что такое это самое ООП. В этом плане наиболее «приближен к реальности» Erlang. А если под ООП вы классы подразумеваете — без inner классов хотя бы сложно структурировать адекватно, все время приходится на компромисы какие-то идти.

Ну и в целом PHP как язык — очень плох. Прям очень (чаще всего выражается это в полумерах, принятых в языке). И если вам так не кажется — то либо мы говорим о PHP как о платформе (с этой точки зрения все прекрасно) либо у вас специфичные вкусы.

На сегодняшний день у php достаточно конкурентов, и аргумент что разработчиков найти проще уже не очень правда… во всяком случае адекватных разработчиков найти не проще чем на любом другом языке.
справедливости ради — node или go или python с точки зрения экосистемы намного больше подходят для таких вещей. Ну вот прям… сильно.

Проблема повторюсь в экосистеме а не в языке. Все же асинхронщина на php пока занимает умы подавляющего меньшинства. Да и нюансов больше.
оно блочит воркеры. Следует это помнить. То есть если у вас скажем 10 воркеров, и все 10 начали что-то там делать после запроса, то новые запросы уже некому обрабатывать. Потому finish_request подходит для каких-то совсем уж простых вещей.
А значит можно взять 3 байта на id, а не 4.

а выравнивание?

> Если вы считаете, что пользователям нужны именно тормознутые и жрущие мессенджеры

Нет конечно, и повторюсь — я за если кто-то возьмет и сделает достойный продукт. Реалии рынка в целом такие, что никто особо не парится. И да, не раз бывало когда на рынок выходит продукт, который чуть-чуть поднимает планку качества и только после этого остальные начинают что-то делать.

Я потому и говорю о невидимой руке рынка и все такое. Есть предложение и есть спрос. Спрос на более качественные продукты есть, но за неимением предложения в целом все мирятся с тем что есть. Это приводит к спросу на телефоны с 6-ю гигами оперативки, что уже не особо удивляет.

> И почему именно webrtc?

Ну webrtc это довольно удобный (относительно) стандарт. Во всяком случае альтернатив не особо много да и по распространенности и наличию готовых решений конкурентов у него на данный момент нет.
«GraphQL лучше REST»?

для того что бы не скатываться в религиозную дискуссию достаточно признать очень простой факт — и то и то — RPC over http. Просто в одном случае есть конкретика (формат, протокол если хотите) а во втором — его нет. То есть в целом решая те же проблемы что решает graphql (удобная композиция данных для клиента) вы переизобретете оный (возможно в более приятном для вас виде). Как пример — json api в целом еще в версии 1.0 предлагал очень похожие плюшки, просто масштабы были не те и приоритеты другие.


OpenAPI, Swagger и т.д. — это лишь попытка формализовать описание контрактов. Причем ни graphql ни сваггер в этом плане не являются универсальными решениями. Вопрос гибкости и расширяемости стандарта. Сваггер скажем упирается в ограничения спецификации json schema, в то время как graphql имеет мягко скажем примитивную систему типов, которая на хоть сколько нибудь серьезном проекте обрастает кучей кастылей.


Чет меня понесло… Короче суть — ограничивать себя выбором одного из двух — это глупо.

du -sh ./vendor

просто шутки ради.

4 гига для тулинга для сборки — это норма. Да, вам скорее всего нужно из этого только 10%, проблема в том что предсказать какая часть понадобится разработчику сложно, а заставлять его как-то по хитрому конфигурить все это добро — как-то глупо.

в Go, например нет while

Нет отдельного кейворда, да, просто потому что for уже это покрывает.


А так же в C++ долгое время не было foreach

а еще C++ довольно долгое время крайне медленно развивался. Ну и добавление for_each лишь пример миграции фич из разных языков.


SQL:2003 тоже нет FOR и WHILE.

Насколько я помню, стандарт SQL он как бы только про декларативные штуки, а императивщина это про SQL/PSM который вроде как расширение спецификации. Но я не разбирался.

Что, простите?


Вы об этом?


The easiest way to acquire the build tools is by installing Microsoft Visual C++ Build Tools 2017 which provides just the Visual C++ build tools.

Так это что бы быстро и просто получить весь тулинг, который необходимен вам для сборки приложения на rust под винду. За размеры винить надо не раст а мелкософт тогда уж. Ну и с C++ будет та же история в целом. И думаю не только с ним.


Добавлю что вся Visual Studio вам не нужна. С ней у вас может и получится 4-5 гигов, а вот сколько весит только билд тулз — проверьте сами.


Ну и опять же — это зависимости исключительно для сборки (сборка, линковка и прочие прелести).

Не наблюдал таких проблем. Но не исключаю их возможности, не разбирался как они там чего делают.
Возможно у нас различаются способы использования слэка.
> На мой вкус

Это очень субьективно, если сравнивать vscode и какой-нибудь neovim + tmux то в целом я может быть и согласился бы что различия несуществественны, но вот слэк с стерминалом сравнивать…

По сути, вы либо слэком не пользуетесь (к слову, пользуетесь ли?) либо у вас очень интересные вкусы. Нет, если вы представите концепт того как слэк в терминале сделать — мне будет любопытно (даже очень). Повторюсь — слэк это не только чатики.
звонки у слэка тотго же тоже неплохие, как и шаринг экрана. Так что остается только инерция корпоративного сектора.

p.s. за последние 3 года пользовался скайпом исключительно через web.
Вы же понимаете что телеграм это не просто текстоый меседжер? Стикеры, аттачи аудио, различные графические ресурсы (аватарки), форматирование текста, ну и webrtc, шифрование всего этого дела.

Невидимая рука рынка так решила, что месенджеры отжирающие по 300 метров памяти нужны, значит они нужны. Иначе спроса бы небыло.

Другой вопрос что возможно рынок так решил потому что качественно лучше ничего нет. Может быть вам стоит сделать свой продукт качественно лучше чем все что есть на рынке, и возможно на ваш продукт будет высокий спрос.
групповых чатов штук 20, приватных — штук 100, может больше, не знаю где посмотреть. сообщений в день прилетает под пару сотен (почти все в мьюте). Нет не электрон — тот который официальный нативный на плюсах и все такое.
В джаве есть дженерики

ну дженерики и метапрограммирование на темплейтах это все же разные немного вещи.

HTA все еще должны работать если запускаются в режиме совместимости с 9-ым IE.

В целом да, но пока в webstorm не будет полноценной поддержки language server я предпочту использовать vscode для всяких там typescript-ов.

ну да, хай рез сплэш скрин для загрузки или крутой пак иконок под тот же хай рез туда не запихивали.

Information

Rating
Does not participate
Location
Минск, Минская обл., Беларусь
Date of birth
Registered
Activity