Наши проекты:
Журнал · Discuz!ML · Wiki · DRKB · Помощь проекту |
||
ПРАВИЛА | FAQ | Помощь | Поиск | Участники | Календарь | Избранное | RSS |
[3.144.202.167] |
|
Страницы: (7) 1 2 [3] 4 5 ... Последняя » все ( Перейти к последнему сообщению ) |
Сообщ.
#31
,
|
|
|
Сообщ.
#32
,
|
|
|
JoeUser ну возьми PHP... Суть от этого мало поменялась.
То что ты знаешь - это ОДНО, а то что лучше подойдет для реализации задачи - это совсем другое... Это ты мне сейчас заявил - я знаю что есть молоток, но пользоваться им не умею, и учиться не собираюсь... Хороши спецы пошли... Добавлено JoeUser и еще: я однажды подобную ошибку совершил. Хорошо задача была небольшая, переписал на PHP, а то что было написано на плюсах закопал и забыл... Потому что для каждой задачи хорош свой инструмент. |
Сообщ.
#33
,
|
|
|
Цитата korvin @ Можно писать на Kotlin. Можно. Но это о5 нужну учить язык. Более того ... Тот же Rust ввозможно имело бы смысл, ибо он компилиться в нативный код платформы. |
Сообщ.
#34
,
|
|
|
Цитата JoeUser @ Про это читал, отзывы неочень. При том, при всем, что многое прячется и интерфейс удобный - оверхед по сравнению с тем же libevent существенный Зависит от того, как готовить И вообще ты уверен, что именно тут будет узкое место? Высоконагруженные системы живут благодаря архитектуре больше. Какие у тебя занания в области масштабирования, например? Цитата А мне скорее всего понадобится kqueue юзать, серваки на FreeBSD мне как-то роднее. asio его и юзает под FreeBSD Не думаю, что тебе действительно нужно такая производительность, чтобы руками юзать kqueue и тратить кучу времени(или жертвовать качеством и надёжностью) на свою реализацию. |
Сообщ.
#35
,
|
|
|
Цитата FullArcticFox @ Это ты мне сейчас заявил - я знаю что есть молоток, но пользоваться им не умею, и учиться не собираюсь... Хороши спецы пошли... Это твоя интерпретация. Я могу сказать по-другому твою фразу: "все твои синие молотки неправильные, надо пользоваться красными молотками, потому что сейчас это модно!". Добавлено Цитата D_KEY @ Какие у тебя занания в области масштабирования, например? Никакие Цитата D_KEY @ asio его и юзает под FreeBSD Не думаю, что тебе действительно нужно такая производительность, чтобы руками юзать kqueue и тратить кучу времени(или жертвовать качеством и надёжностью) на свою реализацию. Не kqueue на прямую не буду конечно. Ибо нефик: Цитата Currently, libevent supports /dev/poll, kqueue(2), event ports, POSIX select(2), Windows select(), poll(2), and epoll(4). |
Сообщ.
#36
,
|
|
|
Цитата D_KEY @ Высоконагруженные системы живут благодаря архитектуре больше. Какие у тебя занания в области масштабирования, например? Насколько я понял, у него один сервак под клиента/инсталляцию-приложения, так что о масштабировании можно не думать. Добавлено Цитата JoeUser @ Но это о5 нужну учить язык Дело не хитрое. Цитата JoeUser @ Тот же Rust ввозможно имело бы смысл, ибо он компилиться в нативный код платформы. Зачем тебе нативный код платформы? Но опять же, в этом случае Go был бы всяко проще. |
Сообщ.
#37
,
|
|
|
Цитата JoeUser @ Это твоя интерпретация. Я могу сказать по-другому твою фразу: "все твои синие молотки неправильные, надо пользоваться красными молотками, потому что сейчас это модно!". Где я сказал про моду и тд?? Не надо мне приписывать то, чего я не говорил! Причем тут мода? Тем более С++ и PHP или Питон отличаются друг друга далеко не только цветом.... Добавлено Цитата JoeUser @ Можно. Но это о5 нужну учить язык А почему это плохо? Мне казалось что наоборот, чем больше языков знаешь, тем лучше.. Уж лишним явно не будет |
Сообщ.
#38
,
|
|
|
Цитата FullArcticFox @ Мне казалось что наоборот, чем больше языков знаешь, тем лучше.. offtop Не совсем, во многих случаях это не сильно полезное знание. Если только ты сам не участвуешь в разработке какого-то языка. Но это отдельная тема для обсуждения =) Соглашусь, однако, что изучение языка, более пригодного для решения задачи, вместо того, чтобы использовать тот, с которым хорошо знаком, но который подходит для задачи в меньшей степени, действительно не представляет ничего плохого и даже, скорее, наоборот. И большого труда составлять не должно |
Сообщ.
#39
,
|
|
|
Цитата FullArcticFox @ Где я сказал про моду и тд?? Цитата JoeUser @ Это твоя интерпретация. Я могу сказать по-другому твою фразу: Цитата FullArcticFox @ А почему это плохо? Я хочу начать делать продукт. Пусть его сделаю сносно - но сделаю. Сейчас вопрос не стоит об обучении. Вопрос стоит о том, чтобы не начать делать его плохо, а тем более очень плохо. Добавлено Цитата korvin @ Зачем тебе нативный код платформы? Работает быстрее, даже того же JIT. Требует меньше накладных расходов. |
Сообщ.
#40
,
|
|
|
Цитата Купленный софт от Oracle еле-еле ворчается А не в руках ли дело? |
Сообщ.
#41
,
|
|
|
Цитата Астарот @ А не в руках ли дело? Дело в Оракле. Выкупил он пару компаний с потрохами. Слепил бисквит из своей БД и купленных поделок (которые большей частью на Java, и Java-аплетах на фронт-энде) и наняли кучу дистрибьюторов. Шаг в право, шаг влево - "пишите в представительство Oracle, вам там под заказ разработают модуль за 25к евро". Спрашиваю, а зачем прикладному АРМ обязательное наличие домена? Зачем на 5 рабочих станций 4 сервера? Таковы требования Oracle. Да в гробу я видал этот "боинг" на ослиной тяге. |
Сообщ.
#42
,
|
|
|
Цитата JoeUser @ Работает быстрее, даже того же JIT. Спорное утверждение. У JIT больше информации о workflow и железе. Так или иначе, в веб-софте эта «абстрактная быстрота» значительно менее заметна, чем в каких-нибудь числодробилках, потому что чаще упирается в IO и тому подобные внешние ограничения, от языка не особо зависящие. Где-то недавно на ЛОРе вроде была ссылка, где Java показывала лучшую производительность, чем Си, при работе с файлами, из-за адаптивной буферизации. Т.е. наверняка, на Си можно было написать такой же быстрый код, но потребовало бы это значительно больших усилий. И я повторюсь, что в твоём случае никаких преимуществ в производительности ты не увидишь. Добавлено Цитата JoeUser @ Зачем на 5 рабочих станций 4 сервера? На 5 рабочих станций не то что 4 сервера, там даже БД не особо нужна, в крайнем случае sqlite даже может хватить. Проблема не в Oracle, а в том, что эта твоя подопечная контора не умеет адекватно оценивать требования. Oracle берут, когда у тебя 50000 рабочих станций или больше. |
Сообщ.
#43
,
|
|
|
Цитата JoeUser @ Зачем на 5 рабочих станций 4 сервера? Таковы требования Oracle. А зачем на 5 рабочих станций писать на плюсах? )) Таковы требования JoeUser? ))) Добавлено Цитата korvin @ На 5 рабочих станций не то что 4 сервера, там даже БД не особо нужна, в крайнем случае sqlite даже может хватить. Вот для меня это тоже загадка, что за данные такие и настолько в реальном времени что кэшировать не вариант... |
Сообщ.
#44
,
|
|
|
Цитата FullArcticFox @ А зачем на 5 рабочих станций писать на плюсах? )) А может я вообще это реализую в виде хрени типа а-ля Microtik & RouterOS ... Может быть и вообще просто на Cи. Пока просто пристрелка. |
Сообщ.
#45
,
|
|
|
Цитата JoeUser @ Не kqueue на прямую не буду конечно. Ибо нефик: Цитата Currently, libevent supports /dev/poll, kqueue(2), event ports, POSIX select(2), Windows select(), poll(2), and epoll(4). asio тоже юзает kqueue. Кстати, для работы по http и websocket есть boost beast, работающий на asio libevent мне не понравился в свое время. И интерфейс неудобный и баги какие-то были. Но я так и не понял, зачем тебе C++. Я видел на бэкендах кресты, но это были специфичные случаи. И частенько их переписывали потом. И C++ оставался совсем за кадром, для обработки данных, вычислений и т.п. А иногда уходил и оттуда. Добавлено Вообще в лучших традициях российских форумов тебе не на вопрос отвечают, а объясняют, почему ты не прав |