Какие нафиг нативные объекты? Нативные объекты в асме? Вы когда-нибудь в иде про открывали бинарь скомпиленный? Если нет, то создайте в GO класс, скомпильте его и посмотрите как он в дизассемблере выглядет. ООП это исключительно абстрактная фигня, любой ооп код скомпилится в «макросы на ассемблере» нет никаких объектов нативных, на уровне бинаря, объект класса представляет собой по сути структуру, в которое просто лежат поинтеры на данные и на «методы» ( методы по сути являются функциями с соглашением вызова thiscall). Так что чушь не несите.
Dr.Pepper, Да откуда вы это берёте всё время, с хабры чтоль? Или с пабликов вк? Что в c++ нет, что есть в Java? Хотите сборщик мусора? Вот пожалуйста, юзайте смарт поинтеры. Хотите перегружать операторы? Да пожалуйста сколько угодно ( в java кстати этого делать нельзя! ). Хотите лямбда выражений? Да пожалуйста, c++17,c++14/c++11 в новых стандартах это всё есть. В c++ stl есть кстати futures/async, так что проблем с написанием вашего сервака вообще 0. Я подозреваю что вам неохото разбираться в низкоуровневых сокетах, хотя это однозначно было бы полезно. Ну это ваше право, хочется быстрее и без меньшего напряга делайте на джаве.
Go хорош, но для специфических задач. На самом деле он чутка разочаровывает во время использования: 1. Нету генериков. Мне не удобно. 2. Нету ид горутин, те недоэрланг какой-то. Каналы есть, а ид у горутин нету. 3. make - зачем? выглядит как костыль 4. Несколько вариантов присваивания итд. 5. Странная работа с пакетами - типа с гитхаба. Как по тагам тянуть-то. Ну и сюда - дам инсталл итд надо делать. ОЧень неоднозначно. 7. Кривожопое наследование. Ну ведь реально. 8. Вложения в структуры, и анонимно. Так нигде не делают в продакт языках. Как по мне го - это язык для микросервисов и автоматизации всего для админов и sre, в принципе он так и позиционируется. Большие провекты - есть несколько, просто язык хайповый. Если говорить про крипту, то там только в эфире он как-то важен (geth) в других местах - С/С++. Так что... Сеть правда в нем хороша.. Хотя думаю.. И черт с ней))
Проблема C++ в том, что все операции там выполняются по принципу "удалять гланды через анальный прооход". Когда в той же Java всё работает "из коробки" благодаря продуманному синтаксису, в плюсах всё делается при помощит так называемой "шаблонной магии", у которой есть масса недостатков: - медленная компиляция; - повторное инстанцирование и дублирование кода; - несовместимость казалось бы совместимых типов данных; - очень дикий мозговыносящий синтаксис; - дурацкий навязываемый всем паттерн RAII. Те люди, которым надоело играться в шаблоны и RAII, выбирают более удобные средства разработки. Те люди, которым это не надоело, остаются кодить на плюсах.
Соглашусь по-поводу синтаксиса, по-моему плюсовые сорцы сложнее читать чем дизасм какого-нибудь кернел мод апи винды в ядре)
Абсолютно верно, поэтому C++ бесполезен. В нем нет никакого смысла, потом что сделать структуру, написать поинтеры и выстроить ООП без использования "class" не составляет труда, сделать это можно намного эффективнее, потому что это никак не ограничивает полет мысли. Однако неверно говорить про любой ооп. В Java, .NET работает виртуальная машина, как впрочем и JavaScript, PHP. Там существуют полноценные объекты в рантайме. В принципе наличие гарбадж коллектора косвенно показывает о существовании управляемого ООП кода внутри рантайма. Возьмите например typeof в Javascript, который позволит вам проверить какому типу принадлежит аргумент и это абсолютный рантайм, никакой прекомпиляции. Андрей Александреску написал целую книгу о попытках проектирования С++, посвятив 50% книги таким вещам как typedef'ы внутренних типов и как правильно затыкать дырки в классах используя неинициализрованные конструкторы, чтобы запретить наследование и куча прочего стыда. В итоге это все закончилось тем, что человек просто создал свой язык D и этого достаточно, чтобы понимать всю суть.
Открою вам небольшую тайну, давайте обратимся к официальной документации https://msdn.microsoft.com/ru-ru/library/dn807190(v=vs.110).aspx "Перед выполнением какого-либо метода в первый раз JIT-компилятор компилирует IL-код в машинный код для локального компьютера." При этом JIT-компилятор способен определять возможности установленного процессора и компилировать наиболее оптимально с учетом специфики локальной системы, в отличии от компилятора C++, который должен учитывать возможность запуска на каком-нибудь старом железе. К примеру была такая статья от DICE: https://insights.dice.com/2015/12/09/can-c-ever-match-c-for-speed/ Поэтому C# и Java сегодня в ТОПе востребованных языков, как и Golang, для работодателей важно, чтобы наемный работник решал задачу с минимальным количеством лишнего кода, и желательно не тратил постоянно время на оптимизации по скорости. C++ абсолютно проигрывает в командной работе, когда каждый пишет свой сумасшедший стиль и всё в куче это создает мешанину в которой черт ногу сломит, здесь широкие возможности играют отрицательную роль, создавая гигантскую вариативность стилей. Об этом например позаботились в Java, и к слову в Си как правило все намного проще и аккуратнее.
Статья, конечно, так себе, но вот комментарии доставили: Перл про std::endl вообще доставил. Это как надо нелюбить разработчиков, чтобы производить на свет такие "стандартные" библиотеки.
Зачем вообще эти ваши Go, ява-скрипт? На Си надо чтобы писали все. Ввёл в командную строку - $ sudo mplayer -vo fbdev2 -zoom -x 1024 -y 768 ~/терминатор.avi. Смотришь видосик... Если кодек подошёл. Рожи правда вытянутые бывают. Надо разрешение определить до этого.
Прикалывает рвать шаблоны, играть на предрассудках людей. Возьмем JavaScript, любой рафинированный кодер C++ посмотрит на этот язык высокомерно, рассказывая о сверх-возможностях бесполезного языка. Но стоит ему показать что-то вроде этого https://bellard.org/jslinux/vm.html?url=https://bellard.org/jslinux/buildroot-x86.cfg И можно созерцать разрыв шаблонов с эдаким ахрениванием персонажа. Последним был Edmond [HT]. Наотрез отказался верить, в то что это полноценная VM под x86 которая загружает самый настоящий линукс. https://bellard.org/jslinux/x86emu.js
Fabrice Bellard, как обычно, молодец. И всё-таки, я не совсем понял: VM запускается на клиентской машине или сервере, а вывод терминала форвардится клиенту?
im., И что? Даже если там полноценная эмуляция x86 (в чем я ооочень сильно сомневаюсь) - в чем тут заслуга js? Здесь постарались конкретные люди, которые зачем-то решили реализовать такой совершенно бесполезный (онли poc) проект.
unc1e, заслуга в том, что нет смысла тратить время на костыльный С++ когда можно решать абсолютно любые задачи на JS, Golang которые из коробки имеют богатейший набор возможностей, те же регулярные выражения ))
im., Не читал тему, кроме пред. сообщения, но сразу однозначно скажу что вы думаете не верно. Суть в том, что на данный момент не важен инструмент реализации или сборки, важна лишь его стабильность. Скрипт это потенциальная дыра в безопасности, которую нельзя пофиксить на уровне скрипта, тоесть как бы грамотно вы не реализовали код, локально он будет соответствовать всем требованиям безопасности, но в общем он будет выполняться уязвимой вм/скриптом. Это значит что локальная корректность кода никакого значения не имеет, если уязвим глобальны ресурс. По этой причине все эти скрипты и считаются уг.
Ага, а потом можно и от сложны алгоритмов отказаться, использовать лишь сортировку пузырьком. А потом инженеры откажутся применять 10 нм < транзисторы. Какие скорости нас тогда ждут? В защиту c++ ничего не скажу, но js ничем не лучше.
