Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>Надеюсь, ты догадываешься, что САПР это не одна только рисовалка, но и масса всяких вычислений. И тут либо придется числодробить на jscript, либо считать на сервере, и гонять по сети гигабайты данных.
Почему именно гигабайты данных? Амазон сдаёт внаём числодробилки.
Здравствуйте, Masterspline, Вы писали:
M>IMHO, упоминание стиля Александреску и его "укусов"
Укушенные Александреску не пишут как Александреску, но доводят идею параметризации до абсурда.
Я таких имел сомнительное удовольствие наблюдать в реале. Первый пришёл с вопросом "а чой это у меня компилятор не хочет мой код собирать и говорит что внутренняя ошибка", оказалось что просто память кончалась/
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
$>кто-то из жавы взад в сипипи. Но это всё против мейнстрима.
Так может это просто мейнстрим разворачивается? Сперва в мейнстриме были C и C++, ключевым фактором успеха была скорость вывода продукта на рынок. Поэтому безопасные языки с GC стали рулить неимоверно когда мощность компьютеров стала расти каждые полгода-год (память больше не ресурс и все такое). Теперь мейнстрим -- это Java, C#, Go, Python, Ruby и иже с ними. Скорость разработки у всех приблизительно одинаковая, зато стоимость владения теперь сильно определяется ресурсоемкостью приложений. И, оказывается, что Python и Ruby, да и Java, местами, сильно проигрывают какому-нибудь Go. Не говоря уже про C++ или Rust.
Поэтому Instagram переписывает часть своей инфраструктуры с Python на C++ и сокращает количество серверов с 700 до 40. А Dropbox переходит с Python на Go (и, местами, на Rust).
Здравствуйте, checkthestack, Вы писали:
C>Хочется уйти в бекенд, но не нахожу на него внятных вакансий на плюсах. Судя по hh плюсовики нужны в gamedev/обработке видео и изображений/Старых десктопных продуктах. C>Посоветуйте — пора валить из плюсов в какой-нибудь go? Или можно найти на плюсах нормальную работу, если у тебя не 6+ лет опыта в нём?
Если бекенд это веб-сервисы, то да, Go. Если не только, то присмотритесь к Rust, он после плюсов отлично заходит (но вакансий мало). Можно Erlang, там интересная концепция (но он для реал-тайм систем типа коммутаторов мобильной связи — тема очень интересная, но редкая). Haskell если хотите десктоп и функционалку, Scala если функционалку и бэк (по опять же, вакансий везде немного и языки специфические).
На плюсах много серьезной работы и будет много, так что ищите, плюсы долго еще никуда не денутся.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
Здравствуйте, kaa.python, Вы писали:
KP>Взять тот же антивирус Каcперского, так его клиентскую часть можно на 80-90% написать на Go + TypeScript и никто этого не заметит. Останутся только драйвера да действительно критичные к производительности фрагменты типа движка, чего не так уж и много на фоне всей остальной обвязки.
В клиентской части там как раз C#. И обвязка это как раз не самая большая часть, логика и бизнес-логика весят куда больше.
Проект Ребенок8020 — пошаговый гайд как сделать, вырастить и воспитать ребенка.
$>Здравствуйте, Stanislav V. Zudin, Вы писали:
SVZ>>$>А кому нужны десктопные приложения? Клепайте веб приложения, продавайте подписку.
SVZ>>Инженерам нужны. SVZ>>У некоторых доступ к интернету с рабочего места прикрыт. Тксзть, с т.з. безопасности.
$>Поднимайте приватное облако в локалке и вперёд.
Можно нанять "cтудентов", они напишут десктоп приложение. И это будет проще и дешевле в поддержке чем приватное облако в локалке и не менее безопаснее
S>Так может это просто мейнстрим разворачивается? Сперва в мейнстриме были C и C++, ключевым фактором успеха была скорость вывода продукта на рынок. Поэтому безопасные языки с GC стали рулить неимоверно когда мощность компьютеров стала расти каждые полгода-год (память больше не ресурс и все такое). Теперь мейнстрим -- это Java, C#, Go, Python, Ruby и иже с ними. Скорость разработки у всех приблизительно одинаковая, зато стоимость владения теперь сильно определяется ресурсоемкостью приложений. И, оказывается, что Python и Ruby, да и Java, местами, сильно проигрывают какому-нибудь Go. Не говоря уже про C++ или Rust.
S>Поэтому Instagram переписывает часть своей инфраструктуры с Python на C++ и сокращает количество серверов с 700 до 40. А Dropbox переходит с Python на Go (и, местами, на Rust).
почему стоимость владения на С++ оказалась меньше чем у Python
на С++ + boost код можно так завернуться, что надо реально потратить время что бы понять что он делает
а код на Python читаеться как книжка
Здравствуйте, Basil2, Вы писали:
B>Здравствуйте, checkthestack, Вы писали:
C>>Хочется уйти в бекенд, но не нахожу на него внятных вакансий на плюсах. Судя по hh плюсовики нужны в gamedev/обработке видео и изображений/Старых десктопных продуктах. C>>Посоветуйте — пора валить из плюсов в какой-нибудь go? Или можно найти на плюсах нормальную работу, если у тебя не 6+ лет опыта в нём?
B>Если бекенд это веб-сервисы, то да, Go. Если не только, то присмотритесь к Rust, он после плюсов отлично заходит (но вакансий мало). Можно Erlang, там интересная концепция (но он для реал-тайм систем типа коммутаторов мобильной связи — тема очень интересная, но редкая). Haskell если хотите десктоп и функционалку, Scala если функционалку и бэк (по опять же, вакансий везде немного и языки специфические).
B>На плюсах много серьезной работы и будет много, так что ищите, плюсы долго еще никуда не денутся.
А расскажите что пишут ныне на С++ кроме всяких ФГУП, НИИ и НПО в которых больше половины работающих это седовласые и лысые старцы 55+ и выпускники без опыта?
Посмотрел на hh: вакансий много, но частенько встречаются вакансии С#, PHP и тд и даже PHP.
Здравствуйте, sergey2b, Вы писали:
S>>Поэтому Instagram переписывает часть своей инфраструктуры с Python на C++ и сокращает количество серверов с 700 до 40. А Dropbox переходит с Python на Go (и, местами, на Rust).
S>почему стоимость владения на С++ оказалась меньше чем у Python
Потому, что стоимость 700 серверов + стоимость их эксплуатации + команда DevOps для их обслуживания будет выше аналогичных расходов для 40 серверов.
S>на С++ + boost код можно так завернуться, что надо реально потратить время что бы понять что он делает S>а код на Python читаеться как книжка
Вы сейчас всерьез будете утверждать, что любой код на Python читается как книжка?
Здравствуйте, уважаемый Basil2, Вы писали:
B>Если бекенд это веб-сервисы, то да, Go. Если не только, то присмотритесь к Rust, он после плюсов отлично заходит (но вакансий мало). Можно Erlang, там интересная концепция (но он для реал-тайм систем типа коммутаторов мобильной связи — тема очень интересная, но редкая). Haskell если хотите десктоп и функционалку, Scala если функционалку и бэк (по опять же, вакансий везде немного и языки специфические).
Тут есть некоторое опасение, что если язык экзотический, то устроиться на работу по нему не удасться.
Это значит — домашнее освоение в свободное время. В этом случае изучение и освоение языка рискует сильно затянуться
B>На плюсах много серьезной работы и будет много, так что ищите, плюсы долго еще никуда не денутся.
+100500
Хватит до пенсии, даже если твоя творческая карьера ещё только стартовала!
Здравствуйте, sergey2b, Вы писали:
S>в Boston MA примерно 6 милл жителей и 4 всемирно известных института S>в неделю меньше 10 новых вакансий на С++
S>а например для драйверистов 3 вакансии в месяц
Если тебе найти для себя только одну вакансию, ищи и найдешь!
Тебе, как я это понимаю, НЕ статистика важна, а именно новая работа.
S>рекруторы активно советуют, что если хочешь найти работу искать на чем то другом
Ну, если ты собрался уйти из разработки ПО в HR-ы, то также советуй
Здравствуйте, AlexGin, Вы писали:
AG>Так, если бы сделали сборку мусора, то это бы привело к возникновению недетерминированных задержек при исполнении кода AG>И если бухгалтеру некритично — за 5 секунд посчитает отчёт или за 6 секунд, то для системы перехвата ракет — это уже катастрофа...
Для немногих проектов, где задержки мешают, сборку мусора можно отключить. Для большинства же проектов она гораздо удобнее умных указателей, для которых кроме вырвиглазного синтаксиса нужно еще бороться с циклическими зависимостями.
У сложных вещей обычно есть и хорошие, и плохие аспекты.
Берегите Родину, мать вашу. (ДДТ)
Здравствуйте, уважаемый lpd, Вы писали:
lpd>Для немногих проектов, где задержки мешают, сборку мусора можно отключить.
Тогда — какой смысл её вводить, если вся прелесть — когда она выключена...
Смысл во всей этой затее?
Ну и архитектуру приложений, где критический (по быстроте) код — делается на C++,
а GUI и работа с БД делается на C# — также никто не отменял
lpd>Для большинства же проектов она гораздо удобнее умных указателей, для которых кроме вырвиглазного синтаксиса нужно еще бороться с циклическими зависимостями.
Ну, сбока мусора вещь полезная (знаю по работе с C#), но тем не менее — не являющаяся "серебрянной_пулей".
Это естественные издержки smart-pointers, но из-за них не нужно отказываться от работы с умными указателями.
Здравствуйте, lpd, Вы писали:
lpd>Для большинства же проектов она гораздо удобнее умных указателей, для которых кроме вырвиглазного синтаксиса нужно еще бороться с циклическими зависимостями.
Что-то мне подсказывает, что проблема с циклическими зависимостями возникает из-за попыток программировать на плюсах как на яве или шарпе.
Вот натурально, за 20+ лет ни на одном проекте не сталкивался.
_____________________
С уважением,
Stanislav V. Zudin
Здравствуйте, $$, Вы писали: SVZ>>Надеюсь, ты догадываешься, что САПР это не одна только рисовалка, но и масса всяких вычислений. И тут либо придется числодробить на jscript, либо считать на сервере, и гонять по сети гигабайты данных.
$>Почему именно гигабайты данных? Амазон сдаёт внаём числодробилки.
А как иначе? Ты предлагаешь рисовать и как-то работать на клиентской стороне, а хранить данные на удаленной машине?
маленькая платка с 14 слоями
Пара млн примитивов. И с ними надо работать искать, резать, строить различные модели.
То же, но покрупнее
Оставил видимыми 3 слоя, иначе вообще ничего не разберешь.
Отсылать каждый MouseMove/MouseClick на сервер, а обратно изменения в картинке? Так это называется RDP
P.S. Амазоновские машины мы используем для распределенных вычислений.
_____________________
С уважением,
Stanislav V. Zudin
