• Почему дизайн Go плох для умных программистов
    0
    По хорошему-то нужно делать то, что отлично делает perl и хорошо делал python (пока они там все белены не обьелись) — что-нибудь типа

    using C++20;

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

    Тогда от них можно было бы отказываться постепенно…

    А так — каждый новый стандарт делает вид, что он существует «в вакууме», старых программ «типа нет» — но при этом мы всё время о них думаем… Шизофрения какая-то…
  • Почему дизайн Go плох для умных программистов
    +1
    Несомненно. Но с учётом того, что у меня есть знакомый, который отличненько осваивал курс, написанный под Turbo C 2.0 с использованием последней версии GCC и Clion… я думаю что проблема-таки в издателях… Ну или в горе-программистах, которые в учебных примерах используют всякие <conio.h>, которые большинством компиляторов никогда не поддерживались.
  • ReactOS 0.4.7: Павел Дуров больше не Пюыщн
    0
    Тут что — конкурс по натягиванию совы на глобус кто-то обьявил?

    Какое имеет отношение Amiga (да и Atari) к рабочим станциям? То, что звук у IBM PC был «никакой» долгое время — это правда… но к расчётам гидродинамики звуковую карту не прикрутить… как и Genlock, долгое время удерживавший Амиги в телестудиях.

    А что касается «сравнимой с Windows NT» многозадачки — так это курам на смех: да, многозадачность там вытесняющая, не кооперативная, вот только защиты программ друг от друга нет никакой даже в AmigaOS 3.9 (а на PC она появилась ещё в Windows/286) — а без такой «мелочи» гонять счётные задачи, которые могут работать часами — самоубийство.

    Да и про 4096 цветов я бы помолчал: одномеременно можно было выводить не более 64 цветов, что, конечно, гораздо круче чем в CGA с его 4 цветами, но бит на пиксель там было максимум 6, то есть даже до VGA оно не дотягивало, а с полноцветным фреймбуффером и сравнивать было нельзя. Для 3D-графики HAM не шибко-то годится.

    Но главное — мощности процессоров и обьёмы оперативки были несравнимы! Так что тут скорее Amaga играла роль «цветного калькулятора», ограниченного тем, что могла сделать Motorolla. А могла она сделать сильно меньше, чем Sun (SPARC) или SGI (MIPS). Интелу потребовались-таки годы, чтобы их «догнать и обогнать», а Motorolla… Motorolla — «сошла с дистанции».
  • Почему дизайн Go плох для умных программистов
    0
    Для человека, который свой первый язык учит по этой книге, которая для него основной источник информации и об языке, и о программировании вообще, это может быть большой проблемой.
    Для книги и обучения — да, это проблема. Для языка — нет. И показателем качества языка это не является ни разу (показателем качества книги — таки да).
  • Почему дизайн Go плох для умных программистов
    –2
    Что-то во времена студенческие я не видел ни одного учебника по С++ (в особенности от авторов языка) в котором хотя бы 4/5 примеров компилировались
    Если что-то не скомпилировалось — так это ж хорошо: вы увидите проблему и её исправите. Это вообще не проблема.

    А вот если оно скомпилировалось и делает не то, что ожидалось… это бяда. В этом отношении JavaScript и PHP не переплюнуть… хотя C++ и старается, да.
  • Почему дизайн Go плох для умных программистов
    0
    Возможно мне действительно не хватит знаний продолжить диалог, но стало любопытно: а если член структуры является полиморфным типом, разве компилятор сможет в каких-то случаях избежать перерасхода памяти?
    Нет. Таблица виртуальных методов будет прописана всегда, конструкторы/деструкторы тоже будут вызываться всегда.

    В любом случае тут как бы «небольшие накладные расходы всегда» vs «никаких накладных расходов если полиморфность не нужна, но весьма внушительные — если нужна».

    Было бы интересно сравнить на реальных задачах, но на маленьких примерах всё очевидно, а большой проект для этого делать дважды вряд ли кто будет…
  • Arrays, Collections: Алгоритмический минимум
    +1
    А откуда вы берёте это «не заглядывая в википедию»?
    На онлайновых интервью — это типичное требование.

    Но почему-то все, кто слышит про подобные вещи считают, что от них ожидают фотографической памяти и умения воспроизвести 100-200-500 строк кода из Википедии «как стихи». Чего, в общем, и близко нет. Вот тут человек описывает — зачем такие вопросы задаются и чего хочется в результате увидеть.

    а если вы боитесь задавать вопросы, то это очевидный преогромный минус вам, а не интервьюерам.
    А вот это — не в бровь, а глаз.
  • Почему дизайн Go плох для умных программистов
    0
    У меня отец физик, и ему хаскель (и интуитивный подход к вычислению программы как к редукции графа) будет сильно понятнее, чем Go или JS.
    Вы бы ещё про математиков вспомнили!

    Да, есть люди, которые функциональный подход воспринимают легче, чем императивный. Но где-то для 90% программистов (и, боюсь, для 98%-99% людей вообще) иперативная «поваренная книга» воспринимается проще.

    Даже несмотря на то, что в школе, вроде как, математике учат всех…
  • Почему дизайн Go плох для умных программистов
    0
    А оно надо? Я бы предпочёл, чтобы компилятор имел возможность проверить, всё ли я определил и тайпчекается ли оно, в точке определения реализации интерфейса.
    Ну значит вам больше понравятся другие языки. У обоих подходов есть плюсы и минусы.

    А вообще это сурово пахнет концептами C++, а соответствующий пропозал появился до релиза Go, ЕМНИП.
    Я бы сказал, что Go'шный ООП очень сильно пахнет GNU C++ сигнатурами, которым, если бы они были людьми, уже можно было пить и курить — это ж почти четверь века назад было всё релизовано! Не исключу, что и раньше, чем в Haskell подобные вещи пробрались, но точно не скажу — это нужно целое расследование проводить…

    И да — некая схожесть с концептами и type class'ами наблюдается, но в целом — это не совсем то.

    В гошных тайпклассах есть, кстати, multiparam type classes? Fundeps?
    Вроде бы нет, но на 100% не уверен.
  • Почему дизайн Go плох для умных программистов
    0
    Никак — и да, это может быть проблемой. Ну так система типов и не обещала отловить все ошибки.

    На практике, впрочем, с подобными проблемами (когда у вас не просто есть два разных интерфейса с одинаковыми сигнатурами, но и из ещё реально нужно различать в рантайме) приходится сталкиваться редко. А вот необходимость опционально поддержать разные вещи — встречается часто. Потому Go «заточен» под второе, а не под первое.
  • Почему дизайн Go плох для умных программистов
    0
    То что я не пишу implements BasicLocable — это фигня. Главное — что я при этом не вытаскиваю и не включаю в проект модуль, где этот BasicLocable описан.

    То есть я могу поддержать все интерфейсы требуемые MySQL'ем, PostgreSQL'ем и, скажем, Oracle'ом одновременно — и не втягивая в проект библиотек MySQL'я, PostgreSQL'я и Oracle.

    Причём для этого мне не нужно «городить огород» с генераторами фабрик, как в Java, а несоотвествие типов таки будет выявлено в момент сборки, а не в рантайме.
  • Почему дизайн Go плох для умных программистов
    0
    Ну я всё-таки исхожу из идеи что программу пишет не макака. И если произошла подобная коллизия, то передавать обьект туда, где он не уместен разработчик не будет.

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

    Так вот описывать интерфейсы там, где они потребляются и не заставлять из описывать там, где они реализуются — просто удобно.
  • Почему дизайн Go плох для умных программистов
    +1
    По количеству WAT Go может влёгкую побороться за второе место после JavaScript.
    Только за третье и то не факт. Первое-второе места забиты намертво за JavaScript'ом и PHP, которые всё никак не выяснят какой из них кривее.
  • ReactOS 0.4.7: Павел Дуров больше не Пюыщн
    0
    NET/2 к 1993 году уже полностью переписали — так что ничего 386BSD и потомкам не грозило.
    Извините, но — нет. Не переписали. Переписали с нуля как раз только 6 файлов, которые нужно было добавить к NET/2, чтобы получить полноценную OS.

    Судьба всего остального была под вопросом до тех пор, пока Novell иск не отозвал.

    И не только Alan:
    Да и сам Linus, в общем, то же самое говорит: I have never even checked 386BSD out; when I started on Linux it wast available (although Bill Jolitz series on it in Dr. Dobbs Journal had started and were interesting), and when 386BSD finally came out, Linux was already in a state where it was so usable that I never really thought about switching. If 386BSD had been available when I started on Linux, Linux would probably never had happened.

    Но как видите проблема была не в 80387м! А просто в том, что Linux появился в 1991м году, а 386BSD — в 1992м.

    Я сильно сомневаюсь, что большинство пришло с MINIX — это была игрушка, которая мало где использовалась.
    В ранние дни и Linux был игрушкой. Когда на нём GCC запустили и другой GNU'сный софт — вот тогда и другие начали подтягиваться. Вначале его и запустить-то иначе, как из Minix'а было нельзя!
  • Почему дизайн Go плох для умных программистов
    0
    А в python просто, pip install package и погнали.
    Серьёзно? А давайте я вам SunOS какой-нибудь постарше дам питона — и вы на ней pip install package без установки PYTHONPATH и PYTHONHOME погоните. А я посмеюсь.

    Или, если SunOS не нравится — могу дать MacOS и скрипт на Python3.

    Это я про GOPATH и GOROOT. Вот в ubuntu это все еще не делается из под коробки, а значит надо устанавливать самому. А я в то время не знал как.
    И что — это делает язык сложным? Python точно так же требует установки переменных окружения. Просто в Ubuntu это уже сделали за вас, на этапе сборки, собственно, питона.
  • Почему дизайн Go плох для умных программистов
    –1
    А как вы поймете, что lock и unlock связаны с тредами, а не совершенно другая логика класса Gate?
    Никак — и в этом весь смысл. Совершенно неважно: захватывает lock какой-нибудь mutex или тыкву. Важно, что lock — захватывает ресурс, а unlock — его освобождает. Для класса, которому нужен BasicLocable — этого достаточно.
  • Почему дизайн Go плох для умных программистов
    +1
    Я бы этот момент рассматривал как небольшую странность а не как ключевую особенность.
    Если это не «ключевую особенность», а «небольшая странность», то почему вокруг добавления подобного подхода в C++ сломано столько копий?

    Ну вот ни разу не было необходимости писать реализацию интерфейса раньше его самого…
    Вопрос не в написании реализации интерфейса раньше описания интерфейса, а во вполне эквивалетной этому возможности по реализации интерфейса, на описание которого вы, при написании вашего класса, вообще не смотрели. Какие-нибудь интерфейсы типа BasicLockable или Swappable, как правило, оказываются реализованы без явного намерения их реализовать.
  • Почему дизайн Go плох для умных программистов
    +1
    Замечание принято. Да, пожалуй в C# этой проблемы нет. Там среди прочего всякого добра напихано и решение этой проблемы тоже.
  • Rust vs. C++ на алгоритмических задачах
    +2
    Есть и ещё более патологические случаи. Мы как-то пытались померить скорость работы на ARM'е. Оказалось, что ни на одном доступном нам телефоне ничего толком померить нельзя с точностью до 1% — ибо перегреваются они, собаки.

    Спас ChromeBook (уже не помню какой модели): он достаточно велик для того, чтобы на однопоточных тестах, по крайней мере, охлаждения хватало и тормозов бы не было.
  • Rust vs. C++ на алгоритмических задачах
    +1
    Для близких пар языков вроде C++ и Rust это может быть не особо существенно, но конечно Java и Rust так уже сравнивать совсем нельзя.
    А почему нельзя-то? Что вы такое собрались делать, что время запуска для вас неважно, а скорость работы — важна?

    Что-то долгоживущее — это, обычно, что-то в чём вы язык выбирать по скорости не будете. Писать плагин для emacs'а вы будете на Lisp'а, а для CLion'а — на Java или Kotlin'е. Rust ни там, ни там не подходит. И не из-за того, что он медленный.

    А если вы делаете отдельную утилитку — то скорость её работы будет определяться, в том числе, временем запуска. Писать её на языках, в которых рантайм запускается настолько долго, что на этом фоне незаметно, сколько времени сортируется массив на несколько миллионов элементов — просто глупо. И да, если в результате этих замеров «неожиданно» окажется, что python или perl лучше и быстрее java… то это потому, что так оно и есть — для подобных задач, разумеется…
  • Необязательные аргументы в функциях Go
    0
    Не путайте C++ и Go/Java/PHP/JavaScript/etc. Это в C++ стараются сделать «сахар» таким, чтобы компилятор мог его полностью «растворить». В другия языках часто «сахар» замедляет исполнение в десятки раз — но люди с этим мирятся ради гибкости.
  • Необязательные аргументы в функциях Go
    +2
    Это всё психология. Тот факт, что «всегда находятся другие, более очевидные места, где можно подкрутить производительность» просто-напросто обозначает, что 90% всех ресурсов ваша программа тратит просто на нагрев воздуха.

    Если писать сразу с учётом всех этих «краевых» эффектов, то можно, как правило, создать программу, которая будет в 5-10 раз быстрее, но оно вам надо? Как правило ответ — «нет, не надо», возможность быстро менять программу при изменении требований важнее.

    Но, собственно, Go на выжимание «всех соков» из процессора и не претендует — для этого C++ есть (хотя, в последнее время, rust начал на ту же нишу претендовать).
  • Необязательные аргументы в функциях Go
    –1
    Ну уж нет. Синтаксический сахар почти всегда увеличивает количества кода. Вот количество текста в исходном коде — он должен уменьшать… и уменьшает…
  • Новая уязвимость в Android позволяет злоумышленникам изменять приложения, не затрагивая их подписи
    +1
    За них не стоит переживать по другой причине: количество известных дыр в старых ядрах Linux'а таково, что никакой Janus им не нужен… хотя конкретно вот этой уязвимости — у них нет.
  • Новая уязвимость в Android позволяет злоумышленникам изменять приложения, не затрагивая их подписи
    +1
    Тоже мне, удивили. А миллиард домашних роутеров, которые никогда никто обновлять не будет?

    Интересно скорее какого размера потребуется «жареный петух» и кого он должен будет клюнуть, чтобы об этом вообще задумались бы?

    P.S. Хотя может и не будет никакого «петуха»: как-то же эпоху до ssh/ssl с передачей паролей открытым текстом пережили — и катастрофы таки не случилось…
  • ReactOS 0.4.7: Павел Дуров больше не Пюыщн
    0
    То есть вот прямо так как есть — 30-летняя программа выполняется в машкодах на последней винде.
    То, что она исполняется в машкодах — не значит, что там нет эмуляторов, извините.

    Без эмуляторов.
    Таки с эмуляторами. То, что машинный код не транслируется — это правда, процессор Windows-системы не меняли (в отличие от Mac'ов). Но даже намёка на ядро оригинальной Windows 1.0 в Windows XP нету. Все его функции эмулируются ядром NT.

    То же самое, похоже, будет и у Гугла когда (и если) призойдёт отказ от Linux'а в пользу Fuchsia. Хотя, может быть, Fuchsia так и останется мёртворождённым исследовательским проектом типа Singularity. Увидим.
  • ReactOS 0.4.7: Павел Дуров больше не Пюыщн
    0
    Вы, вероятно, путаете 386BSD и BSDi (BSD/386). К 386BSD никаких претензий не было, она благополучно дала жизнь FreeBSD и прочим *BSD на PC.
    Претензии касались 4.3BSD NET/2, которая была основой как бесплатной 386BSD, так и платной BSDi.

    То, что суд начался после релиза BSDi роли не играет: если бы 4.3BSD NET/2 была признана нарушающей права AT&T, то 386BSD и все потомки (включая FreeBSD и прочие *BSD на PC) точно так же попали бы под запрет, как и BSDi…

    386BSD требовала 80387, у бедных студентов его не было, вот и появился Linux.
    Написать эмулятор было бы проще, чесслово. То, о чём вы говорите — конкретно Алана привело. Но большая часть разработчиков — пришли из Minix'а, который, опять-таки, в те годы распространялся под комменческой лицензией, но главное — его автор совершенно не горел желанием жертвовать красотой кода ради производительности!
  • Почему дизайн Go плох для умных программистов
    +1
    Если он другой и на него нужно переучиваться, значит он не простой.
    Нет. Так у вас все языки, кроме C++, сложными станут. Потому что с ним я работаю последние 10 лет и мне в нём всё понятно. А чтобы освоить даже Lua — потребуется время.

    Простота/сложность языка определяется временем, которое требуется на его освоение человеком, который не знает ни одного языка программирования. С этой точки зрения — Go и JavaScript просты. А C++ и Haskell — сложны.

    А вот если вы уже имеете опыт работы на другом языке программирования — то тут ситуация может немного другой оказаться.

    Вот python простой, что бы начать писать на нем какой-то рабочий код достаточно вводной статьи и 15 минут времени. Да, качество кода будет так себе и все прочее, но в целом оно неплохо работает.
    Та же самая ситуация и с Go, как бы.

    И в обоих случаях вам потребуется несколько месяцев, чтобы начать писать идеоматичный код. Поначалу вы будете писать код в стиле того языка, который использовали до того — и плеваться, когда будете упираться в разные «странности».

    Я в течении этого времени только искал, как же нормально задать переменную окружения навсегда.
    Что значит «задать переменную окружения навсегда», как это сделать в Python'е и почему в Go это сделать сложнее?
  • Почему дизайн Go плох для умных программистов
    0
    Я и не говорил, что это что-то суперновое. Но в тех вот языках, о которых автор перевода говорит (C++/Delphi/Java/PHP) — этого нет. Есть только в «остальных ООП» языках, но в «остальных ООП», есть, как бы, вообще всё…
  • Rust vs. C++ на алгоритмических задачах
    +6
    Вопрос не в баг-репортах, а в алгоритмах.

    лучше в принципе запретить такие вещи чем получать баг-репорты «у нас был ученик со странным именем и вся база данных накрылась»
    Фильтрацией такие вещи не делаются, увы. Вернее делаются — но очень быстро ломаются при добавлении функционала.

    или думать «почему страница текста отрисовывается полсекунды».
    А вот здесь, как раз, UTF-8 спасает. Ибо у вас нет соблазна делать 100500 раз вещи, которые, вообще говоря, при полной поддержке юникода требуют O(N), но конкретно у вас, кокретно у вас, конкретно в первой версии программы — укадываются в O(1).

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

    То, что код на UTF-8 «ломается» в случае использования не только русского языка, но и даже каких-нибудь банальных ö или ü, если пользоваться индексом в строке как позицией на экране… это же прекрасно! Ошибки обнаружатся быстрее и быстрее же будут исправлены.

    Та же идея, что и со статической типизацией, современным C++ и rust'ом вообще: чем раньше будет обнаружена ошибка — тем дешевле её исправить!

    В UTF-16 же только эмодзи и спасают.
  • ReactOS 0.4.7: Павел Дуров больше не Пюыщн
    0
    Если в 2 словах — андроид вытеснит винду?? Так
    Не совсем. Операционка от Гугла вытеснит операционку от Microsoft.

    А вот как она к тому времени будет называться — интересный вопрос. Это к маркетологам.

    Заметьте, что та Windows, которая привела к разводу IBM и Microsoft (Windows 3.0) и та Windows, которая убила рабочие станции (Windows XP) не имеют между собой ничего общего. Все программы для Windows 3.0 исполняются под специальным эмулятором.

    То же самое и тут будет, скорее всего.

    Ну-у-у-у… можно конечно подискутировать
    Мы сейчас на ранней стадии процесса. Где-то 1987-1988й. Кто-то где-то использует ChromeOS и ARC++, но это — скорее исключение, чем правило. «Windows 3.0 от Google» ещё впереди… но всему своё время. «Колесо истории» движется медленно, но неотвратимо…
  • ReactOS 0.4.7: Павел Дуров больше не Пюыщн
    +1
    Будет вообще шикарно — если есть древний драйвер для какого-нибудь старого уникального железа, то говорим системе «сделай вид для этого драйвера что ты win95».
    Ага. А потом этот старый драйвер берёт — и без зазрения совести начинает править код операционной системы прямо на лету. Дальше что?

    Уж не говоря о том, что любой драйвер Win95 свято уверен, что в системе, кроме него, никого нет и можно делать с любыми своими данными что угодно и когда угода — достаточно только прерывания запретить…

    P.S. Сам лично участвовал в проекте где дравер именно так был устроен. Ну не получалось там иначе: нужные интерфейсы Microsoft закрыл, они были доступны только для «своих» драверов на раннем этапе загрузки, а потом отключались.
  • ReactOS 0.4.7: Павел Дуров больше не Пюыщн
    +1
    Вот только в тот момент, когда Linux зарождался его судьба была под вопросом.

    Да и не был Linux тогда такой уж большой и важной частью GNU/Linux системы. А, собственно, утилиты GNU создавались и использовались потому что AIX'ы, HP-UX'ы и прочие всякие Windows на это всё малость подзабили увлёкшись улучшением ядра…
  • Почему дизайн Go плох для умных программистов
    0
    Вроде же все наоборот утверждают, что Go очень простой.
    А тут другая проблема: он простой — но другой. Человек, не видевший ничего, кроме GW-BASIC'а его легко освоит. А людям, работающим на других языках, приходится переучиваться. Это занимает время.
  • Почему дизайн Go плох для умных программистов
    0
    Серьёзно? В каких из этих языков реализация интерфейса пишется независимо от самого интерфейса и, в принципе, может быть «залита» в VCS до того, как туда попадёт описание самого интерфейса?

    О том, что GNU C++ signatures (которые и явились прототипом интерфейсов в Go) «срисованы» с Haskell type classes — сами разработчики говорят. Но вот «abstract class в C++, interface в Java/Delphi/PHP/остальных ООП языках» — это совсем о другом.
  • Почему дизайн Go плох для умных программистов
    –1
    Есть такая штука, что далеко не у всех людей каждый коммит содержит код, который вообще собирается.
    И вот «с этой штукой» и нужно бороться. Trybots для этого и существуют.

    Более того, версионность позволяет не только жестко фиксировать версии, но так же и задавать диапазоны версионности, что бы у вас не возникало по три-пять разных версий пакетов в одном и тот же проекте.
    Откуда у вас возьмутся «три-пять» версий пакетов (и вообще пакеты, как таковые) при использовании одного репозитория? Или вы про master/release/release-stable и т.п. ветки? Ну так они «внутри себя» все согласованы…
  • Почему дизайн Go плох для умных программистов
    –1
    Если кто-то изменяет библиотеку в модульной архитектуре, то им надо только проверить, что она собирается
    А работоспособность кто проверять будет? Пушкин?

    сборка, проверка вышестоящих библиотек — это задача тех, кто будет обновлять зависимости.
    Ага — вот только они, в большинстве случаев, ни разу не заинтересованы в переходе на новую версию если у них всё «и так работает». И в результате вам либо приходится поддерживать 10 версий библиотеки, либо ваша библиотека оказывается 10 раз форкнута и засунута в разные проекты в разных видах. Либо и то и другое одновременно.

    Когда у вас между проектами — административная граница, то у вас, в общем-то, нет выбора. Но если её нет — общий репозиторий лучше. Собственно все большие проекты так всегда и собирались — и UNIX, и OS/360 и многие их последователи.

    Только GNU/Linux, по политическим причинам, устроен не так. Ну так то — вынужденная мера, а не то, к чему стоит стремиться.

    но билды все равно должны быть сделаны и артефакты все равно должны куда-то упасть.
    А в случае с несколькими проектами и несколькими репозиториями это не так?
  • Почему дизайн Go плох для умных программистов
    0
    Вот те самые, которые в Qt делаются через кодогенерацию, а в MFC и других подобных тулкитах — через ещё более сташные извращения.

    ООП в стиле CLOS, принятый в Go решает эту проблему абсолютно естественным способом: так как интерфейсы и их реализация напрямую не связаны с типами, которые их реализуют, то страшные трюки в стиле WTL (когда у вас обьект-предок приходится делать шаблонным, чтобы он мог как-то обратиться к потомку) не нужны.

    Впрочем, как я уже сказал, полноценных библиотек виджетов, сравнимых с Qt для Go пока нет, так что сказать на 100%, что всё пройдёт гладко и удастся обойтись без костылей типа кодогенерации (а макросы это тоже кодогенерация, пусть и примитивная) — пока нельзя.
  • Почему дизайн Go плох для умных программистов
    –3
    Разве что в случае с ресурсными файлами, как мне указали правильно, и, например, настройкой GUI через стороннее приложение.
    А чем ресурсные файлы уникальны? Чем ORM, RPC, FSM хуже? Тем, что ваша IDE их не знает? Ну так научите! Или успокойтесь уже и признайте, что «магическая лицензия» для кодогенерации не нужна.

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

    Или там, которая будет автоматически пробрасывать ошибки наверх, например.
    А вот этого, пожалуйста, не надо. «Автоматическое пробрасывание ошибок наверх» — это то, с чем создатели Go пытаются извести. Можно эту точку зрения любить или ненавидеть, но если вам нужно «пробрасывать ошибки наверх» — то вам точно не нужен Go.
  • ReactOS 0.4.7: Павел Дуров больше не Пюыщн
    +1
    Хоть это и мало вероятно, но будет весело, если кто-то сумеет свернуть Windows :)
    Ха. Мы уже, собственно, знаем — кто это сделает и, примерно, как, хотя очень приблизительно знаем — когда.

    Просто нужно посмотреть на предыдущий подобный переход. MacOS появилась в 1984м, Windows 1.0 — через пару лет, но до появления сначала Windows 3.0 (первая по настоящему популярная версия Windows) в 1990м году и Windows NT в 1993м о переходе с рабочих станций на PC никто толком не думал.

    А вот уже примерно к 2000му году, когда персоналки догнали по мощности рабочие станции все эксклюзивы типа CATIA и Maya были портированы под Windows.

    А в 2009м рабочие станцию под Unix перестали производиться перестали. Эпоха кончилась.

    Что важно: развитие PC шло фантастически быстро, а развитие рабочих станций стагнировало, потому что оттуда ушли деньги в 80е — но «запаса прочности» хватило на два с лишним десятилетия…

    Сейчас деньги «ушли» из рынка персоналок и «пришли» на рынок смартфонов. Случилось это 10 лет назад примерно. При этом история перехода настолько похожа, что иногда становится смешно. Как Sun периодически пытался все 90е перепрыгнуть на платформу x86 (SunOS 4.0 с поддержкой 386го процессора вышла в 1988м году), так и Microsoft периодически пытается перескочить на ARM (вот — последняя отчаянная попытка), как Microsoft начал с клона CP/M, а потом перешёл на новое ядро, так и Google начал с того, что валялось под ногами, но со временем решил сделать новую платформу с нуля (но со слоем совместимости), как и в прошлый раз, почти наверняка, новую платформу сделаеют — а вот убедить программистов всё под неё переписать с нуля — не смогут… но Windows, тем не менее, удушат… хоть и не сразу.

    Всему своё время… но очень забавно наблюдать за всем этим.

    P.S. Подрывные инновации — страшная штука. Интересно: ощущали ли работники Bucyrusа то, что сейчас ощущают работники Microsoft'а когда их клиенты медленно но неуклонно переползали к Ка́терпиллеру (который в конце-концов Bucyrus просто купил)? И ведь процесс так же неотвратим и ещё более неспешен… Всё это крайне забавно, да…