Комментарии 332
2) беглое прочтение статьи показывает что из всего перечисленного для Go уникальным является только «Go поддерживается Google.», это (без иронии) мощный агрумент.
если бы не одна история во время его разработки.
За языком не следил, но любопытно. Можно в двух словах?
Как я понял, гугл не захотел добавлять виртуальную машину для Dart в хром
Извините, но вы сейчас привели глупое сравнение
Почему глупое? Я просто акцентировал на том, что факт поддержки Гуглом ничего не означает
Тоже самое могу сказать и про изображение «Эффективность и производительность для компьютера»
Go запускается непосредственно на железе
Rust тоже.
Код, написанный на Go, легко поддерживать.
Сложно назвать легко поддерживаемым код на языке, в котором можно случайно забыть написать «if err != nil». Rust за это надаёт по ушам ещё при компиляции, да даже C++ выкинет исключение во время работы.
Классов в Rust нет, наследования нет, конструкторов нет, исключений тоже нет (про остальное точно не помню)
Go почти так же эффективен как С/С++
Rust тоже
Синтаксис Go очень стабилен
Подозреваю, синтаксис Rust ещё более стабилен)
Go поддерживается Google
Rust поддерживается Mozilla и целым сообществом и используется много кем
Горутины, думаю, можно заменить на Futures и в будущем async/await.
А ещё у Rust zero-cost abstractions и отсутствие gc.
И почему же мы должны учить Go, а не Rust? :)
(на правах вброса:)
Сложно назвать легко поддерживаемым код на языке, в котором можно случайно забыть написать «if err != nil».
Ну, вроде как, Go все же возмутится за неиспользование переменной err на уровне сборки.
И почему же мы должны учить Go, а не Rust? :)
Я думаю тут большим аргументом выступит порог вхождения в эти языки. У первого он, я считаю, на порядок ниже.
Лично я не записывал и не тыкал, просто выразил мнение. Но Растариане не дремлют :)
Логика мне видится примерно такой: низкий порог вхождения ведет к росту комьюнити вокруг языка, широкое комьюнити оправдывает использование языка в коммерческих проектах, удачные примеры проектов — потенциальные инвестиции в развитие самого языка и его экосистемы, что опять приведет к росту количества практикующих на этом языке разрабов.
Если она была присвоена — да, а если нет — то нет.
foo()
Если функция `foo` возвращает значение типа `error`, то этот код вполне себе скомпилируется. Правда, для обнаружения таких проблем есть линтер: https://github.com/kisielk/errcheck
А это ещё целая тема для срача, минус ли «не для средних умов» или таки плюс :D
Но вообще я считаю себя весьма посредственным «средним умом», но после питона основы раста выучил довольно легко, и в чужом коде уже доводилось копаться без особых проблем, так что возможно всё не так уж плохо)
Знаете, я вот совсем недавно интересовался, для каких языков есть клиентские библиотеки к docker. Среди тех, что мне были интересны, были и Go и Rust.
Де факто мой практический опыт для обоих языков почти одинаков и невелик. Так вот, для меня не было никакой сложности в том, чтобы читать код на обоих. И Rust ничем тут не сложнее. Я больше скажу — думаю что для тех, кто видел java generics (или другие языки с параметризованными типами данных, скалу скажем или хаскель), или алгебраические типы, знает хоть один язык из функциональных — читать Rust значительно проще.
Ну и каждый желающий вполне может эти реализации сравнить живьем. Это тот редкий случай, когда функциональность идентична — в обоих случаях мы имеем место с клиентом для REST сервиса.
Go запускается непосредственно на железе
Rust тоже.
И на голом железе без особой потери функциональности. В отличии от Go, в котором есть сборка мусора.
if err != nil
По крайней мере выдаст варнинг, если не поставить затычку.
А ещё там можно вызвать функцию от nil. И даже нормально обрабатывать это. Где-то в недрах stdlib даже используется.
конструкторов нет
Есть же. Но не как часть синтаксиса, а как часть хороших практик.
type Thing struct { a int }
func NewThing() Thing { return Thing { 10 } }struct Thing { a: isize }
impl Thing {
fn new() Self { Self { a: 10 } }
}При этом в rust ещё и трейт Default есть.
исключений тоже нет
Но раскрутка стека есть. В golang перехватываемая при помощи recover. В rust убивает весь поток выполнения, но из родительского потока перехватывается. При этом в последнем есть оптимизации на этот счёт.
Go почти так же эффективен как С/С++
Rust тоже
Rust на текущий момент лишь чуть медленнее оных (примерно на разницу между llvm и gcc/msvc и компанией).
Go не особо быстр в сравнении с фаворитами, но намного быстрее скриптовых ЯП. Он больше про экономию памяти при общем удобстве, чем про чистую скорость в отличии от.
Кстати. И у того и другого есть костыли для полуавтоматического транслирования с няшной сишечки. Иногда даже получается.
Подозреваю, синтаксис Rust ещё более стабилен)
Не на столько стабилен. Но обратная совместимость поддерживается в пределах мажорной версии. Кроме того есть достаточно годная система ввода новых возможностей в язык.
Rust поддерживается Mozilla и целым сообществом
С корпорацией добра и зла не сравнить, да.
Горутины, думаю, можно заменить на Futures и в будущем async/await.
Пф. Уже есть https://github.com/dpc/mioco А каналы в stdlib присутствуют.
А ещё у Rust zero-cost abstractions и отсутствие gc.
И приятная боль от borrow-checker'а.
И почему же мы должны учить Go, а не Rust?
Сначала golang, потом rust. :3
Но раскрутка стека есть. В golang перехватываемая при помощи recover. В rust убивает весь поток выполнения, но из родительского потока перехватывается. При этом в последнем есть оптимизации на этот счёт.
Начиная с 1.9.0 не верно, можно изолировать панику не на уровне нативного потока, см. https://doc.rust-lang.org/std/panic/fn.catch_unwind.html
Когда я последний раз ковырял Rust, они постоянно что-то меняли, ломали совместимость и т.д. Не знаю, как с этим счас, это было давно.
https://blog.rust-lang.org/2015/05/15/Rust-1.0.html — 1.0 давно уже вышел, с того времени строгая обратная совместимость поддерживается.
Отсутствие ООП — странное преимущество, очень странное.
C++ позволяет выстрелить в ногу, если случайно забыть про меры предосторожности. Rust позволяет выстрелить в ногу, только если явно воткнуть в код стопицот предупреждений «да, я в здравом уме и твёрдой памяти хочу выстрелить в ногу ради всегобщего блага».
А остальное касается любого другого языка, сабжа в том числе, и на ООП свет клином не сошёлся
ООП как таковое и не отсутствует. Отсутствуют классы и наследование. Вместо них трейты и композиция. Принципы ООП при этом никуда не делись.
В статье вроде как про Go, а ваш комментарий касался Rust.
Ну и как бы основной целью ржавчинки является создание языка с полной потокобезопасностью и отсутствием утечек памяти и прочих неприятных ошибок и при этом иметь не слишком большой оверхэд во время исполнения в сравнении с теми же плюсами. В плюсах бороться с утечками даже с умными указателями на порядок сложнее. Про потокобезопасность в плюсах можно даже не начинать. Без статического анализатора такого добиться почти нереально. Зато быстро.
основной целью ржавчинки является создание языка с… отсутствием утечек памяти
кхем, нет, с утечками железных гарантий не дают — https://habrahabr.ru/post/281370/
Наследование (на классах ли, на прототипах ли, может ещё на чём) — один из основных факторов отделяющих ООП от других парадигм.
Ну реально, в мейнстримовых интерпрайз языках все что можно было запретить в ООП — запретили, все что можно было порезать — порезали, ибо
а) Наследование не работает. Ну реально, больше 2 ступенек иерархии наследования уже трудно-сопровождаемые (я как-то видел глубину наследования в 20+ классов — это был страшно), наличие наследования заметно заметно снижает скорость вызова функций (наплодить сотни тысяч и миллионов экземпляров класса СO2, который является наследником классов C и O, а те в свою очередь являются наследником абстрактного класса H и все это заставить моделировать термодинамику — увы и ах, но не получится), плюс к этому огребаем кучу неприятных моментов, как сильное связывание, хрупкие базовые классы и прочий рутинный трешняк
б) Полиморфизм тоже не работает. С множественным наследованием нас обламалали, напридумывали всяких там еретических интерфейсов. В общем ромбик уже не тру
в) Ну классы/типы вроде как какую-то пользу приносят, вот только всякие там структуры были еще задолго до этого вашего ООП
г) В принципе использование ООП несет большие накладные расходы. Сейчас правда все ошалели от гигагерцев частоты и гигабайтов памяти… в итоге требования к ресурсам растут и растут, а вот функционал — нет. Если честно в программах с HPC все кладут болт на на это ООП и переходят на композицию
Ну т.е. реально, на бумаге и когда рядом стоит умный архитектор, который сходу придумает структуру всего проекта и учтет все ньюансы, то ООП красиво выглядит, а вот когда надо выпустить совершенно новый продукт… в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали, а самые ответственные куски кода в итоге выполняются, например, как описано в этой статье https://habrahabr.ru/company/mailru/blog/319194/
в общем за 15 лет я еще ни разу не видел что бы ООП работало как обещали
А как обещали?
Но мы не будем говорить о наступлении кодерского коммунизма, т.к. ключевые обещания: наследование, инкапсуляцию, полиморфизм и абстракцию нифига не выполняются дальше чем сферовакуумные примеры.
Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.
Smalltalk в 2017 году? Увольте.
Не думаю, что древний legacy-код на Smalltalk вообще может обладать хорошей архитектурой.
Ну т.е. Вы тока что расписались, шо чистое ООП — это УГ, и подтвердили мои слова :-)
Вы знайте, по возможностям ООП Java от Smalltalk отличается менее чем никак (на самом деле Жаба все же более куцая, в отличии от неё Smalltalk использует чистую ОО модель, компиляторщики вон говорят, что он так вообще — первый и единственный ООП язык, а они люди вумные — с ними лучше не спорить). Ну у C# правда есть еще мультиметоды — супер-достижение, которое перебивается паттерном Визитёр.
В общем, если не копаться в глубь (шо нынче не в моде), то существенной разницы не заметите:
|f|
"A comment"
f := Foo new: 'AString';
Foo f;
// A comment
f = new Foo("AString");
Разница просто гигантская, не правда ли? :-)
initReports
"Initialize the list of reports by reparsing the index file."
| parser |
self resetReports.
parser := IndexFileParser
documentBase: self documentBase
source: self getIndexFileStream.
[parser atEnd]
whileFalse: [self addReport: parser next]
/*
* Initialize the list of reports by reparsing the index file.
*/
public void initReports(String reportBase)
{
IndexFileParser parser;
Report report;
resetReports();
parser = new IndexFileParser(getDocumentBase(), getIndexFileStream());
while ((report = getNextReport(parser)) != null) {
addReport(report);
}
}
Ну я все-таки подскажу одно значительное отличие на котором попадаются все хелоувордщики:
|i|
i := 1+(5*6).
int i;
i=1+5*6;
Впрочем порой он даже более читабелен:
Rectangle width: 100 height: 200
new Rectangle(100, 200);
Спасибо за примеры, интересно взглянуть на синтаксис (да, разница колоссальная).
1/ Он появился слишком рано и сообщество, как и оборудование было не готово с ним работать,
2/ За этим языком не стояло никакой корпорации Зла, зато ее Жаба с ним конкурировала, я вообще про Смоллтолк узнал, когда знал уже C# (лучше бы не знал)
3/ Ну и последнее, это потому что чистое ООП оказалось не практичным и торчать в рамках одной парадигмы не тру, что С++, что Жаба, что C#, что Object Pascal — все они гибридные и мультипарадигменные языки, а в некоторых из них ООП так вообще не главное, и вероятно это не с проста.
Собственно все эти Расты, Голэнги и F# которые вообще исповедуют совершенно другие принципы появляются также не с проста. Я правда хз — взлетят ли они.
Синтаксис у Смоллтолка, конечно немного архаизмов, но в целом все тоже самое получается шо и в современных языках, некоторые вещи кажутся вполне себе даже удачными (пример с Rectangle)
Легаси — это скорее состояние кода, при котором сложно прогнозировать последствия даже минорных изменений, обычно из-за того, что не осталось в команде ни одного человека, который этот код достаточно хорошо знал.
Паттерны, очевидно, про хорошие способы решения типовых задач. Вот только на практике задачи редко бывают настолько типовыми, и без доработки напильником паттерны из той книги на задачу не натягиваются.
Впрочем их вообще не надо ни откуда наследовать, Data oriented design и композиция отлично справляется, но это уже нисколько не ООП :-)
При таком понимании ООП понятно, откуда у вас такие претензии…
Мартышка к старости слаба глазами стала;
А у людей она слыхала,
Что это зло еще не так большой руки:
Лишь стоит завести Очки.
Очков с полдюжины себе она достала;
Вертит Очками так и сяк:
То к темю их прижмет, то их на хвост нанижет,
То их понюхает, то их полижет;
Очки не действуют никак.
«Тьфу пропасть! — говорит она, — и тот дурак,
Кто слушает людских всех врак:
Всё про Очки лишь мне налгали;
А проку на-волос нет в них».
Мартышка тут с досады и с печали
О камень так хватила их,
Что только брызги засверкали.
К несчастью, то ж бывает у людей:
Как ни полезна вещь, — цены не зная ей,
Невежда про нее свой толк все к худу клонит;
А ежели невежда познатней,
Так он ее еще и гонит.
В иерархии классов стандартной библиотеки Java очень часто встречается многоуровневое наследование. Уровней пять могу припомнить легко. Думаю что 10 найдется.
Ну и достоверность остальных аргументов тоже слегка того… упрощаете вы. Или излишне обобщаете.
Я прекрасно помню, как выглядело скажем программирование на PL/1. Или Фортран. До ООП, в общем. И не надо далеко ходить, чтобы понять, что сегодня прикладные программисты в значительной степени занимаются тем, что собирают программы их готовых уже кусков. Не везде и не всегда — но там где это прокатывает (в первую очередь по ресурсам) — там это реально ускоряет разработку.
Так что термин "ООП не взлетело" я бы переформулировал скорее как "не смогло захватить мир". Так будет правдивее.
Тем более Java наглядный пример того, что не все йогурты одинаково полезны — там вообще много чего можно и много чего есть, но это не значит что это хорошо (иногда даже об этом предупреждают) — тут даже на хабре можно много примеров найти.
Дык, на Фортране я и сейчас отлично иногда программирую — отличный язык, жалко шо бабосов стоит немерено (хотя один фиг выходит дешевле Матлаба), и при написании больших моделей выполняемых на супер-пупер-компьютерах (да и вообще для научных вычислений) выбор тут не особо велик: либо Фортран, либо Си.
Что касается того шо программисты собирают программы из готовых кусков, то эта тема не нова: злые языки поговаривают, что так и Модула умела в 70-ых года и вероятно такой подход был известен и ранее. Ну а всевозможные LAPACK, LINPACK и прочие BLAS, рожки которых торчат там где нужно выполнять операции сложнее сложения двух чисел, также были написаны на упомянутом Вами Фортране еще до того как я наверное родился (это чисто гипотеза)… не ну иногда встречаются велосипеды переписанные на Си, но без этих ваших ++ Т.е. заслуги очередной серебряной пули под названием ООП я тут не вижу.
А по поводу взлетело-невзлетело, это уже вопрос личной терминологии. И вот по-моему мнению ООП как раз таки смогло захватить весь мир: посмотрите — все мейнстримовые ЯП пытаются реализовать так или иначе ООП (мыши кололись, плакали, но продолжали есть кактус). Есть конечно небольшая группа лямбда-извращенцев, растаманов и прочих хипстеров из фанклуба Гугла, но это пока все попытки выйти из порочного круга и погоды они не делают. А вот взлететь ООП как раз таки не смогло, начиная с самого простого — любые нетривиальные абстракции текут (вроде изобретатель stackoverflow.com сказанул как-то не подумав) а дальше уже начинается… Ну или например где это ваш полиморфизм (вот только сегодня думку думал кагбэ мне написать супер-полиморфные функции, которые смогут переварить 100500 самых разных типов данных)? Мне вот нравиться как это сделано в С++ или в богомерзком Пухтоне, можно даже ромбиком наследоваться, но все кругом считают шо это не тру, поэтому давайте напридумываем всяких бесполезных интерфейсов…
По-моему вы путаетесь в показаниях. Либо ООП "не взлетело", либо "смогло захватить мир". Либо ничего серьезно лучше нет — либо одно из двух (с).
Да, про Оракл вы просто гоните, потому что ситуация в коде скажем Spring примерно такая же — пять и более уровней наследования даже долго искать не придется, откроете документацию — и вот оно. Не везле, далеко не везде — скажем, один класс из десятков, но такая вложенность встречается, во вполне промышленных количествах.
И я вам даже на пальцах объясню, откуда она берется — да, один паттерн это как правило 1-2 слоя, больше вряд ли. Но это совершенно не значит, что в сложном фреймворке есть только один паттерн. Вот отсюда она и берется. А вот четыре иерархии и 10 уровней наследования — это совершенно перпендикулярные вещи.
Но в любом случае имеем в Юнити всего 4 иерархии наследования, не 5, а именно 4 — отделяйте мух от котлет, точнее говнокод от фреймоврка, вы еще посчитайте сколько иерархий наследований в сорцах ОС и тоже их добавьте ;-)
При этом: object — в принципе обязательный (без него никак), а component — необходимый для реализации игровой логики, т.к. Юнити это вообще не про ООП, там изначально используется компонентная модель, если что.
Юнити это вообще не про ООП, там изначально используется компонентная модель
С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.
который является родителем всего и всея (внезапно)
Внезапно, я говорил о
UnityEngine.Object, а не о System.Object.Правда Юнити далеко не образчик стабильности — после каждого обновления обнаруживается несовместимость со старым API
Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API?
производительность движка оставляет желать лучшего, что кагюбэ намекает ;-)
Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах. О каких проблемах с производительностью вы говорите? Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.
могут добраться своими кривыми ручками
Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?
С каких пор паттерн «Компонент» перестал быть ООП? Юнити очень даже про ООП.
С таких, что компонентно-ориентированное программирование это независимая парадигма программирования, которая была придумана Виртом для решения проблем внезапно возникших у ООП, и реализованная в языке, который является ОО менее чем никак
https://ru.wikipedia.org/wiki/Оберон_(язык_программирования)
Оттуда КОП ушло в ныне мейнстримовые языки и стало их частью, т.к. действительно, в большинстве случаев композиция предпочтительнее наследования. Тут же на хабре, уже ни раз обсуждали разницу между КОП и ООП.
Да, если они переписывают какой-то компонент, то иногда меняется API. А вы можете привести пример, как добавить новую функциональность не изменив API
Вот только недавно это на работе обсуждали, правда в контексте Python 2 RIP: программа написанная на С++ в 1989 году, компилится в 2017, программа написанная на C# под .NET 1.0 в 2002..2003 годах (язык был стандартизирован по ISO в 2003 вроде бы, а бета-версию вроде как опубликовали эдак в году 2001), точно также внезапно скомпилится и заработает в 2017 году. Хотя там тоже бывали костыли, например, до появления Джнерик-типов в .NET 2.0, в общем обратная совместимость худо-бедно выполняется. Хз, чего там у Жабы — не занимался такой глубокой интроспекцией в ней, но думаю худо-бедно норм.
Однако в большинстве своем все не так безоблачно.
Так проблема в количестве иерархии, или в том, что «могут добраться»? Ибо если в том, что «могут добраться», то и с 1 уровнем можно добраться. Или вы думаете, что если использовать композицию вместо наследования добраться внезапно становится нельзя?
Ну потому что, то что зарыто внутри фреймворка, разработчика уже не касается, т.к. отнаследовавшись один раз для него вот энта проблема:
https://ru.wikipedia.org/wiki/Хрупкий_базовый_класс
еще не актуальна, все что внутри фреймворка — это уже головная боль его создателей. К счастью, у них индусов (в штате, на аутсорсе, на аутстафее) вероятно больше чем классов а также есть вумные архитекторы-надсмоторщики с кнутами, так что они могут себе позволить сопровождать, поддерживать и развивать ПО где объемы наследования очень-очень велики.
Так что в условиях неограниченных ресурсов (как индусо-часы, так и ресурсы вычислительных машин) — это работает. Но у большинства ресурсы ограниченные — и тут выясняется, что сложность программы (как разработки, так и цикломатическая сложность) растет экспоненциально от глубины наследования. В тоже время какой-то учитель математики по фамилии Степанов в 3.5 написал STL, которая уже больше 20 лет успешно используется и включена в стандарт. Заранее предупрежу, что STL это тоже не про ООП, а Степановтак вообще один из самых ярых критиков ОО-подхода.
Это универсальный игровой движок, который способен выдавать 60+ fps сложной логики с физикой и рендером на слабых мобильных устройствах.
Слабое мобильное устройство — это Нокиа 1100, еще космические спутники (там до сих пор летают на 51-ой архитектуре и килобайтами памяти). А современные говносмартфоны и говнопланшеты по вычислительной мощности круче домашних писюков начала 2000-ых. К слову сказать Unreal и Quake были изначально написаны на чистом Си еще в 90-ых
Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.
Вы просто всего 2 движка знайте
… способен выдавать 60+ fps сложной логики с физикой....
Уравнения Максвелла тожее умеет решать, или кварк-глюонную плазму смоделирует? В физике там ничего особенного: коллизии, 2-ой закон Ньютона, уравнение движение и т.п. — примерно 1-ый курс… потом студенты в рамках лабораторных работ/курсовых сами пишут куда более сложные физические модели.
способен выдавать 60+ fps
Если там на сцене живет 3.5 МоноБихеавор, то да, а так:
https://forum.unity3d.com/threads/general-performance-optimization-tips-for-unity.386338/
В общем удже давно известно, что производительность и Юнити ТрыДэ это несовместимые понятия. Но Unity3D не за это любят, а за
Это универсальный игровой движок
Но за все надо платить https://ru.wikipedia.org/wiki/Технический_долг
Более производительный только Unreal Engine за счет С++, но там ровно такое же ООП.
Обычно там внутри что-то типа такого:
https://www.youtube.com/watch?v=rX0ItVEVjHc&t=270s
Что тоже не ООП. У меня вон тоже, когда говнокодю на C# начинают плодиться всякие unsafe:
public unsafe static Matrix UnsafeMultiplication(Matrix A, Matrix B)
{
int h = A.Height;
int w = B.Width;
int l = A.Width;
Matrix resultMatrix = new Matrix(h, w);
unsafe
{
fixed (double* pM = resultMatrix._matrix, pA = A._matrix, pB = B._matrix)
{
int indexA, indexB;
for (int i = 0; i < h; i++)
{
indexA = i * l;
for (int j = 0; j < w; j++)
{
indexB = j;
double result = 0;
for (int k = 0; k < l; k++, indexB += w)
{
result += pA[indexA + k] * pB[indexB];
}
pM[i * w + j] = result;
}
}
}
}
return resultMatrix;
}
Это примерно раз в 10 быстрее чем вот такое:
public static Matrix NaiveMultiplication(Matrix A, Matrix B)
{
Matrix resultMatrix = new Matrix(A.Height, B.Width);
for (int i = 0; i < resultMatrix.Height; i++)
{
for (int j = 0; j < resultMatrix.Width; j++)
{
resultMatrix[i, j] = 0;
for (int k = 0; k < A.Width; k++)
{
resultMatrix[i, j] += A[i, k] * B[k, j];
}
}
}
return resultMatrix;
}
Правда unsafe это вообще не про .NET, а так — грязный трюк (да, мыши кололись, плакали, но продолжали жрать кактус). И ООП тут встречается в гомеопатических количествах, лишь при описании собственного класса Matrix. Впрочем к версии 4.5 .NET все же узнал, шо есть такая офигенная штука как SIMD (Intel Pentium MMX, 1997 год, 16кБ L1, 166 МГц), так что жить стало лучше, жить стало веселее.
Потом да, потом это все будет обернуто со стороны клиента уже в читабильный ООП-код
По-моему вы путаетесь в показаниях. Либо ООП «не взлетело», либо «смогло захватить мир». Либо ничего серьезно лучше нет — либо одно из двух (с).
Открою тайну — это два разных понятия, если не догадались. Что значит «не взлетело» — я пояснил, что значит «захватило мир» — я тоже пояснил, так что Ваше непонимание вызывает у меня недоумение 0_0
Да, про Оракл вы просто гоните
Т.е. Вы считайте, что у них классов все же больше чем индусов? Ну допустим.
Не везле, далеко не везде — скажем, один класс из десятков, но такая вложенность встречается, во вполне промышленных количествах.
Так не везде или все же в промышленных масштабах? Определитесь уже. Вы похоже пытайтесь выдать исключительную ситуацию за рядовую, при этом мой рекорд в 20+ иерархий наследования так и не побили. При этом я могу дать подсказку (по крайней мере для .NET), где искать большую вложенность — обычно в компонентах UI любят наплодить дофига наследников (но правда 20+ Вы там все равно не найдете), на то даже есть свои причины
Другое дело, шо как форма отражения цикломатической сложности, снимок стэка вызовов должен отразить её повышение при использовании наследования
Не бойтесь, не путаю. Просто вы не осилили прочитать название спойлера.
1) Какое это имеет отношение к сабжу (если забыли, то это Go)
2) Как это имеет отношение к срачу про наследование
То что Вы осилили Java.lang.Thread.getStackTrace() меня, конечно, несказанно радует, но не обязательно об этом на каждом углу кричать? А то вдруг набижит бородатый погромист и выложит свой дамп :-)
Я вот только про игру с таким названием слышал
Показательно, только не в том смысле, что ты думаешь.
Так шо я даже хз, представляет ли слово Rust хоть какой-нибудь интерес за пределами одноименной игры :-) Вероятно нет — все его хвалят, но никто замуж не берет, пичалька :-)
и прочие Дропбоксы
Ссылку на rust-friends для сравнения судя по всему сами в состоянии найти ;-)
Ещё даже пары лет не прошло как раст релизнулся, просто не успели же ещё ничего накодить, это вам не фигак-фигак и в продакшен, ну шо Вы ей Б-г прям как маленький :)
Помниться мне первая версия C# появилась одновременно с появлением самого языка в 2002 году и она уже была стабильна, через год — в 2003 году — язык был стандартизирован в ISO, а в 2005 вышла уже 2.0 в которой он уже предстал полностью сформированный языком (дальше пошли свистели и переделки, да синтаксический сахар для индусов). И да, никаких проблем с обратной совместимостью (это правда не значит что хорошо использовать ArrayList!) За 15 лет существования.
Аналогично можно сказать и за Голэнг — он причем ровесник Раста, но первая версия релизнулась еще 5 лет назад :-)
Ну так результат наглядно виден: Rust намного более тщательно проработан чем Go или C# :D
Да, первый релиз спустя 5+ лет существования языка это конечно достижение :-)
Учитывая постоянные передёргивания, на нормальный ответ не надёюсь, но всё-таки. Про C# пишут, что в январе 1999 была уже сформирована команда, которая занималась языком. Причём мне что-то подсказывает, что видение конечного результата было уже сформировано. Раст же начинался как проект одного человека, язык прошёл через множество экспериментов до того как окончательно оформился. Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.
В общем, даже если сравнивать время первого упоминания, то получается не так, как ты рассказываешь, а уж если сравнить человеко-часы, так тем более.
Сообществу .NET был предоставлен сразу рабочим (ну почти, где-то за год подписчики msdn получили бета-версию .NET, меня в их числе естественно тогда еще не было — я с говнокодингом на нем познакомился лишь в 2005 году), после чего он очень шустро был стандартизирован, и тут же пошел в продакшен и начал набирать популярность. Java конечно он не переплюнул, но вполне с ней конкурирует и даже вопреки политике Microsoft стал кросс-платформенным языком, да и Java куда старее и к моменту появления C# у неё уже было устойчивое сообщество погромистов. И всю свою публичную историю существования этот язык идет по пути расширения и добавления новых свистелок и переделок.
И это важно, т.к. предыстория появления языка может быть очень долгой и богатой — вообще C# можно считать потомком Delphi, создавали их одни и те же люди, вообще папа Delphi и C# — создатель компилятор Turbo Pascal, так что при желании можно отследить историю языка начиная с даты рождения Вирта. А еще у Корпорации Добра была своя Жаба.
Но вот история конкретно языка начинается все же с его обнародования и начала использования — официальная дата его рождения: 2000-ый год (я так понимаю его тогда анонсировали), а в 2002..2003 пришла Visual Studio.NET где он был. Так что история использования языка и платформы .NET начинается с 2002 года. Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).
Причём мне что-то подсказывает, что видение конечного результата было уже сформировано.
Об этом я собственно и толкую. С видением проект у создателей Раста явно какие-то проблемы (но сейчас вроде обещают, что все стало норм), а вот у создателей его ровесника (и вероятно конкурента) — Golang, который тоже кстати показали людям до того как выкатился в релиз, с этим дело обстоит вероятно несколько лучше. С видением всяких Java и прочьих дотНетов вероятно вообще все замечательно.
Я уж не говорю о том, что ресурсы мозиллы и майкрософта не сопоставимы.
Об этом я тоже где-то здесь уже писал (Оракл и его тысячи и тысячи индусов). Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL. А еще вот всопмнился язык D — его тоже одиночки поднимали. Не сказать что он убер-популярный, скорее совсем непопулярный, но кое-кто им пользуется, я даже кусок живого проекта на нем видел.
Ясно, что до этого его упорно разрабатывали несколько лет и никому не показывали (шоб народ не спугнуть).
Так в чём вред того, что язык показали ещё до релиза? Никто ведь, на тот момент, ничего не обещал, даже наоборот — всячески предупреждали, что использовать можно только на свой страх и риск. В итоге большинство поглядывали на прогресс с "безопасного расстояния", зато заинтересованные люди могли повлиять на конечный результат. С майкрософтом о последнем можно только мечтать.
Поэтому дорелизные события интересны исключительно как история: почему были приняты те или иные решения. Если оно кого-то пугает — ну что ж, жаль, но я точно могу сказать на своём примере, что открытый процесс разработки "некоторым" кажется наоборот преимуществом.
С видением проект у создателей Раста явно какие-то проблемы
Не очень согласен, но безотносительно этого: как по мне, лучше пусть будет много экспериментов до релиза, чем потом будет язык из стороны в сторону бросать. Интересно было бы послушать если ли какие-то претензии к языку в этом плане после версии 1.0.
Впрочем я также упомянул и товарища Степанова, который с еще одним человеком написал STL.
Ну положим они больше пруф оф концепт делали, чем конечную (современную) реализацию.
А еще вот всопмнился язык D — его тоже одиночки поднимали.
Вот мне кажется, что все эти метания с D1/D2 и фобос/деймос, в немалой степени, тому причина. И если бы они подольше подержали язык в "дорелизном" состоянии, то этого, возможно, удалось бы избежать.
Дык, изначально речь шла о том, что вообще никто кроме мозиллы не использует? Рад, что мы достигли взаимопонимания, что это неправда.
Может еще лет через 7, когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)
Ну то есть, все, кто перечислен в списке "друзей раста" — это те самые три с половиной фанбоя? Если так фактами оперировать, то и правда можно доказать всё, что угодно.
когда выйдет очередная «теперь точно стабильная версия» на нем и начнут что-нибудь выпиливать интересного :-)
А это к чему? С версии 1.0 совместимость вполне обеспечивается. Есть конкретные претензии или это просто сотрясание воздуха?
Показательно это то что Rust в продакшене не используется от слова «совсем»
Лично мне достаточно, что у нас есть проект на расте. Правда пока показать не могу, но относительно скоро будет выложен в опенсурс.
Проект на Растет и у меня был, но пока не наберется критической массы таких проектов, говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво. Голэнг уже успешен, Растт — нет, он даже в 20-ку языков по версии IEEE и TIOBE не входит — гордо тусуется в компании всяких узкоспециализированных Верилогов (но им не стыдно, ибо эртээльщики народ особый и их мало), а вот Scratch входит :-)
говорить о суперуспешности Раста в контексте Голэнга говорить несколько опрометчиво
А кто говорит о суперуспешности? Изначальное утверждение звучало совсем не так. Я просто хочу сказать, что на расте работу найти реально. Да, её (очень) мало, но тот самый "продакшен" имеется.
Ну и поразительная осведомлённость, как для человека, который "только про игру с таким названием слышал".
А еще у меня в универе был знакомый который на протяжении нескольких лет запилил на асме игровой движок (ТрыДэ!) — что, конечно, круто, но не понятно, нафига это. Ну в общем хвалиться не прикольно.
Впрочем у Раста в этом плане все же дела лучше — хз на сколько, но вот про вакансии Java-программистов с опытом разработки в Rust и Golang 0_0 я уже слышал, ну и по крайней мере его хотя бы Samsung начал активно педалить. Но все равно пока это «самый любимый язык программирования на котором никто не кодит» https://stackoverflow.com/insights/survey/2016#technology-most-loved-dreaded-and-wanted
а самымой популярной технологией по-прежнему остается богомерзкий ЖабаСкрипт https://stackoverflow.com/insights/survey/2016#technology-most-popular-technologies
Хз, может он и через пару лет выбъется в топ-20 используемых языков общего назначения (и холивары Go vs Rust станут еще более острее, что не может не огорчать)
но это не делает его языком выбора, не смотря на все его достоинства и няшность.
Почему? Если в каком-то определённом случае достоинства перевешивают недостатки, то как по мне, язык вполне можно рассматривать
Ну в общем хвалиться не прикольно.
Конкретно в моём случае ситуация несколько другая — это не я "продавил" использование раста, наоборот позвали на существующий, пусть и молодой, проект. И насколько я могу судить со своей колокольни, выбор языка выглядит вполне вменяемо: команда пока небольшая, новых людей находить удаётся, не-растовых зависимостей не особо много, сложностей с самим языком тоже не возникает.
Мы тоже пилим небольшой проектик на rust, который пойдёт в open source (под GPLv3+, т. к. samba, которая используется внизу, под GPL). Когда запилим пока неясно, т. к. висят более приоритетные задачи.
Есть ещё одна библиотека, которую я планирую нафигачить сам с перспективой использование на работе. Только там сначала надо написать dissector для wireshark'а и отреверсить протокол xD
Вы не осилили в поиск по гитхабу или как?
Languages
14 C#
13 C++
11 Python
4 C
2 JavaScript
2 Jupyter Notebook
2 Matlab
1 Go
1 Java
1 Julia
Хм… чего-то не хватает. Ок, Гугл, нука покажи nonlinear optimization:
Languages
26 Matlab
17 C++
14 C
11 Python
6 Java
6 R
5 Julia
4 Fortran
4 Jupyter Notebook
3 HaskellХм… Хаскель — есть, C# — есть, Фортран — есть, Джулия — есть, Пухтон тоже есть, как и R, C/C++, C#, Java, внезапно даже сбаж [если не забыли, то говорили о Go] есть.
Хм, что я делаю не так? Ах да, точно, можно же было бы посмотреть сводную статистику, например тут https://octoverse.github.com/
Понимайте, мне нет нужды целенаправленно выискивать сорцы языка Мозиллы и прожектеров, т.к. есть 20 десятка наиболее везде-используемых языков + нишевые специализированные языки (типа Verilog или VHDL), на половине из которых я худо-бедно говнокодю. А еще на них говнокодят миллионы других людей, а еще больше пользуются их продуктами.
А вот по логике веще, что-то выискивать и показывать должны фанбои Раста. В контексте холивара я даже привел пример Докера и список компаний использующих Golang, в ответ: какие-то скриншоты и обещания: «вот мы на нем говнокодим, скоро-скоро будет релиз, и вы все офигейте».
Но вообще-то для конструктивной беседы было бы хорошо провести сравнение с языком сабжа [еще раз напомню — это Go]: какие компании пользуют, сколько выпущено реальных проектов, какой был получен перфоманс в индусо-часах при переводе проекта на этот язык, сделать разбивку по нишам и секторам, ну и провести прочий серьезный анализ. И все это даже влезет в компактную таблицу, которая будет играть явно не в пользу Rust. При этом Go и Rust вообще-то ровесники.
Может быть, когда-нибудь, когда на Марсе начнут сажать яблони (а может даже и завтра), к Rust проснется вторая волна интереса и на нем начнут массово писать, тогда да, тогда Rust будет интересен, сейчас куда более интересен тот же COBOL, например.
Тоже похвастаться хочется, но сдержусь до того момента как проект официально анонсируют и когда можно будет ссылку на гитхаб дать. (:
Go нагибает Rust вовсе не из-за что кто-то там не заморозился. Бизнес и инженеры выбирают Go потому, что это язык для жизни. А Rust отправляют в помойку потому, что это оверинженеринг, состоящий сплошь из неудобных в использовании костылей (которые почему-то называют zero-cost abstractions, забывая про ментальный cost) во имя memory safety и data race safety.
Заморозили бы раньше — было бы больше кривых моментов, так что не факт, что была бы выгода. Вон макросы, как по мне, лучше бы ещё придержали, но сделали их более удобными. С другой стороны, без них многое было бы менее удобно.
Ну и не думаю, что раст и го прямые конкуренты. Кое в чём они, конечно, близки, но местами разница очень значительна: и в деталях реализации и в "философии".
Как круто, автор наконец изобрел универсальную объективную метрику "красоты и естественности кода"! Ну вот теперь заживем, теперь-то узнаем, кто говнокодит, а кто рефакторингом занимается! Интересно, в чем она измеряется, в сусликах/1k LOC, или еще как-то? Хотелось бы так же узнать точные значения для js/perl/python/ruby и прочих неудачников из левого нижнего угла, чтоб выяснить раз и навсегда, кто наименее отстойный.
Вот это щас обидно было!
А вы вообще заметили, в каком месте он находится на графике?
но удобным и читаемым я бы его тоже не назвал бы.
К примеру, отобразите на другом языке такое лаконичное в JS:
let sobaka = { klichka: «Jim», poroda: «dog», say() {console.log( this.klichka + ":gav" )}};
sobaka.say();
К примеру, отобразите на другом языке такое лаконичное в JS:
C#. Никто в здравом уме, конечно, такое делать не будет:
var jim = new {
Name = "Jim",
Breed = "Dog"
};
Console.WriteLine( jim.Name + ":woof" );
scalafiddle.io
val sobaka = new {
val klichka = "Jim"
val poroda = "dog"
def say() = println(klichka + ":gav")
}
sobaka.say()
1) Полное отсутствие типизации. Меня это дико напрягает. Это удобно в использовании, но в оочевидности.
2) Когда this может оказаться совсем не this.
3) В реальном коде в нём часто куча артефактов от html. Сам html убирается всякими библиотеками, а вот классы несколько мешаются.
4) ES6 явно позитивно не сказался на его читаемости.
Я бы его в самый низ графика ясное дело не засунул, но и в самую верхушку тоже.
Тут люди думаю достаточно привели не менее лаконичных примеров.
Разберём эти примеры на лаконичность:
TheShock C#.
var jim = new {
Name = "Jim",
Breed = "Dog"
};
Console.WriteLine( jim.Name + ":woof" );
Хм, зачем тут new? — И это же структура, а не объект. Не так ли?
Поэтому вам и пришлось использовать внешнюю функцию, которая никак не связана со структурой jim
Печально.
Sirikid F#
type Dog =
{
name : string;
breed : string;
say : Dog -> unit;
}
member self.callSay () = self.say self
let jim =
{
name = "Jim";
breed = "unknown";
say = fun self -> printfn "%s: woof!" self.name;
}
jim.callSay ()
Хм, это лаконично?
Я не понял — а как jim связан у вас с «type Dog»?
Эта строка — «member self.callSay () = self.say self» — очевидно крутая, и имеет наверное какой-то смысл, но явно не лаконичный.
«say = fun self -> printfn „%s: woof!“ self.name;» — тут похоже «fun» от слово «function», но не помешало бы убрать его вообще, заменив на ().
%s глазами нужно сопоставить с self.name? Это конечно было давно придумано. Привыкнуть можно. Но и глаза ломаются, если много параметров надо в шаблон подставлять. Имхо.
Ну, ладно, я бы по лаконичности поставил этот код не на первое место.
senia Scala.
val sobaka = new {
val klichka = "Jim"
val poroda = "dog"
def say() = println(klichka + ":gav")
}
sobaka.say()
Scala — это здорово. Особенно отсутствие запятых, их похоже заменяют слова «val» и «def»
А «println(klichka + »:gav")" — без лишних (обрамляющих скобок в данном случае) — это лаконично.
Так и не использование «this» в строке:
def say() = println(klichka + ":gav")
Это впечатляет, однозначно.
Слово new конечно не даёт лаконичности, но ладно. Терпимо. Имхо.
neit_kas
Что лично мне не нравится в читаемости js:
1) Полное отсутствие типизации. Меня это дико напрягает. Это удобно в использовании, но в оочевидности.
Типизация — это признак "бюрократичности" языка.
Конечно, она помогает.
Но иногда её хочется не использовать. В JS её можно применить (Flow, TypeScript — ну, это конечно, не так бронебойно как в иных языках) или нет. Выбор есть.
neit_kas
2) Когда this может оказаться совсем не this.
Вот тут не поспоришь. Кое-что меняется — стрелочные функции. Но всё же тут надо думать, это верно.
neit_kas
4) ES6 явно позитивно не сказался на его читаемости.
Но лаконичности добавилось. Это несомненно. Имхо, конечно, имхо (С)
P.S. и ещё пример на лаконичность (JavaScript):
var klichka = 'Jim';
var poroda = 'dog';
var sobaka = { klichka, poroda, say(){console.log(`${this.klichka} : gav` )}};
sobaka.say();
В коде создаётся объект:
Object {klichka: "Jim", poroda: "dog", say: function}
Ну, разве это не лаконичное создание объектного литерала?
(А как же лаконично выглядит сейчас выражение без "+" в console.log метода say()!)
К примеру, отобразите на другом языке такое лаконичное в JS:
Видите ли, ваша задача в такой постановке вопроса не имеет смысла. Даже когда я пишу на JS — я не пишу такой плохой код, ибо пускай он лаконичный — он:
1. Не имеет смысла в таком виде (например, зачем тут вообще использовать метод?)
2. Не расширяется.
Так что на любом языке задачу в такой постановке можно записать очень кратко:
Console.WriteLine("Jim:gav")
Вопрос обычно к реюзу кода, а тут что в JS, что в C# код будет приблизительно одинаковый и все более выравниваться с увеличением кодобазы.
Так что на любом языке задачу в такой постановке можно записать очень кратко:
Я привел пример лаконичного создание объектного литерала и вызова у него метода.
Я это выше выделил и не раз.
Остальные либо не привели ничего такого, либо, как вы, не поняли, что же нужно привести в пример лаконичного.
Ну, а что касается С# — возможно это и лаконичный язык, но пока это не видно мне, но зачем его вообще придумали я даже не знаю (он же "улучшатель" Java, не более того).
Вот давайте я вам приведу пример шоковицкого (от моего никнейма) куска кода на C#:
public class Progression
{
public readonly int Time;
public int Progress { get; private set; }
public bool IsReady {
get { return Progress >= Time; }
}
public Progression ()
{
Progression(0);
}
public Progression (int time)
{
Time = time;
Progress = 0;
}
}
Видите, как шоковицки у меня получилось? Просто 10 из 10. Попробуйте повторить на JS! И как только у вас на JS получится так же шоковицки, то я обязательно вам напишу лаконично все, что захотите.
Конечно, данная метрика никакого отношения к практическому написанию кода не имеет. Как и ваша, впрочем.
И в JS для этого раньше использовались методы-конструкторы. Сейчас появился синтаксис с классами, а ещё лучше — полноценная типизация с Flow.
В этом отношении мой пример на Scala был призван продемонстрировать то, что на других языках так не пишут не потому, что так не получится, а потому, что бесполезно. И лаконичными делают на этих языках полезные конструкции. Но иногда, как на Scala, и бесполезные конструкции случайно оказываются лаконичными. Не стоит из этого делать далеко идущие выводы.
В этом отношении мой пример на Scala был призван продемонстрировать то, что на других языках так не пишут не потому, что так не получится, а потому, что бесполезно. И лаконичными делают на этих языках полезные конструкции
TheShock
Конечно, данная метрика никакого отношения к практическому написанию кода не имеет. Как и ваша, впрочем.
«Сражение в Фермопилах было выиграно персидским царём Ксерксом, но… известен лаконичный ответ царя Леонида на предложение сложить оружие в обмен на жизнь: «Придите и возьмите»» (Википедия)
Так что полезность (практичность) и лаконичность — это перпендикулярные понятия. (С)
TheShock
Видите, как шоковицки у меня получилось? Просто 10 из 10. Попробуйте повторить на JS!
Повторить что? Ваш совсем не лаконичный код что делает то?
P.S.
Пример на JS лаконичной, но по мнению автора этих строк — «сонной сортировки» — "sleep sort")
var numbers = [7, 1, 77, 15, 145, 9, 5];
numbers.forEach( num => {
setTimeout(() => {console.log (num)} , num);
});
Разве это не супер! ;-)
Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш "лаконичный" код содержит только глупую шутку в стиле "смотри как я могу".
Мне кажется, вы лаконичность с краткостью спутали. Лаконичный ответ Леонида содержит много смысла в малом количестве слов. А ваш «лаконичный» код содержит только глупую шутку в стиле «смотри как я могу».
Сами понимаете, что отличие пошлого(или глупого) анекдота от остроумного — оно не в количестве текста анекдота, а в голове внимающего, хотя всё же «Скверный анекдот» — это рассказ.
Что касается JS — то он и был фактически создан для лаконичного написания кода, выполняющегося в броузере, в отличии от развесистого синтаксиса Java и прочих подобных языков.
codemax
Нет, не супер. Все эти дрочерства на призрачные и в общем случае не самые полезные метрики типа «лаконичность» и «смотри как я могу» обычно заканчиваются трудночитаемым и трудноподдерживаемым кодом.
На любом языке можно написать трудно читаемый код. Но есть языки на которых
Нет классов.
Не поддерживает наследование.
Нет конструкторов.
Нет аннотаций.
Нет дженериков (универсальных шаблонов. — прим.перев.).
Нет исключений.
сложно будет написать поддерживаемый код.
Хотя если развить мысль «Go станет серверным языком будущего», в направлении, что всё уйдет на клиент и у нас будет огромный объем клиентского кода на js, и тоненький бэкенд на go, то все может быть =)
Например, в Rust для всего этого предоставлены довольно удобные альтернативы, которые юзать иногда таки сильно проще чем классическое ООП (композиция, типажи, функции у структур (не экземпляров), Option/Result, замыкания итп), возможно в Go тоже что-то такое есть
Вот по дженерикам да, плачу и мечтаю.
тоненький бэкенд на go, то все может быть
Естественно, если программа занимает строчек 100-200 кода, то все вышеперечисленное конечно не нужно (можно легко без этого обойтись).
Поэтому если применять Go там где ему место, то все будет отлично.
Чем проще синтаксис тем лучше подходит язык для узкой ниши для которой этот синтаксис задуман.
Чем более богат синтаксис, тем более универсален язык, но и писать на нем не так удобно, зато можно сделать большее. Эдакая диалектическая борьба простого со сложным.
В этом плане отличный пример — это язык HQ9+
Писать на нем программу типа "Hello world". Очень просто и удобно. Никто на нем микросервисы писать не будет.
Ну и на Go не надо писать огромные программы, где все ограничения языка очень быстро вылезут наружу.
Горутины сжаты (multiplexed. — прим.перев.) в малое количество потоков ОС.
multiplexed это не «сжаты». Я бы сказал, что это «распределены» в данном контексте.
Гошники, или как правильно? К вам вопрос: это по сути пул worker-thread'ов, которые выполняют поток команд в легковесных нитях?
Вышеназванные изменения отличают Go от остальных языков и это делает программирование на нём не похожим на программирование на других языках
Я бы сказал, что это делает его современным BASICом, в хорошем смысле. Низкий порог вхождения, богатая библиотека, возможность быстро сделать серьезную вещь.
он компилируется с человекопонятного кода в байт-код, который понятен для JVM или другой виртуальной
машине, которая запускается поверх ОС. При выполнении, VM интерпретирует этот байт-код и конвертирует его в
двоичный код, понятный процессору.
Серьезно? А пацаны-то (James Gosling) думали, что там JIT compiler.
Не поддерживает наследование.
Нет конструкторов.
Нет аннотаций.
Нет дженериков (универсальных шаблонов. — прим.перев.).
Нет исключений
Я бы сказал, что это именно минусы, причем очень и очень существенные.
Если есть альтернативы, это может быть и плюсом, не стоит подпускать ООП головного мозга)
Он не взлетел, может потому что его Гугл не пропихивал?
Почему отсутствие конструкторов — минус?
Я знаю, что это не совсем техническое преимущество. Но Go разработан и поддерживается Google.
Это можно отнести и к недостаткам, см. кладбище Google.
"Go быстрый" — сомнительно мне очень
"Go простой" — слишком простой, я бы сказал.
И не указаны уникальные преимущества этого языка:
- очень быстрая компиляция, значительно облегчающая TDD/turnaround
- очень быстрый старт приложений (привет, Java!)
- компиляция в единственный бинарник, что упрощает деплоймент
- очень хорошая поддержка модульности вкупе с очень простым языком позволяет натравить на один проект орду миддлов с шансом на успех
компиляция в единственный бинарник, что упрощает деплоймент
Кто сейчас так не умеет? Динамическая линковка — это, как правило, фича.
Джава разве умеет создать один бинарник со всем своим рантаймом?
Очень удобно получать именно единый бинарник, который достаточно скопировать на целевую систему с голой ОС, ничего на ней не устанавливая.
Мало-мальски нетривиальное потащит за собой libpthread, libc, linux-vdso.so, ld-so.
$ go build
$ ldd main
linux-vdso.so.1 => (0x00007fffd4bf7000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc4679b7000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc4675f0000)
/lib64/ld-linux-x86-64.so.2 (0x000055cfc4c89000)
но, при определенных условиях это не так
$ CGO_ENABLED=0 GOOS=linux go build -ldflags "-s -w" -a -installsuffix cgo
$ ldd main
не является динамическим исполняемым файлом
http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/self-contained-packaging.html
java, .NET, python...
То есть собрать в один файл все добро со всеми зависимостями — это не проблема, чаще же напротив, для гибкости (релиза, деплоя) и модуляризации стремятся разнести по разным сборкам различные компоненты. Пример такой идеологии — .NET Core, представляющий собой (в перспективе) аналог огромного во многих частях монолитного .NET Framework.
Опять эти сказки. В который уже раз — JVM стартует быстро. Я уже как-то демонстрировал, что маленькие классы на groovy, которые делают примерно следующее:
- сконнектиться к JMX порту
- взять там некие метрики процесса
- обработать все это, и отдать скажем в Nagios (просто записать в файл)
Так вот это вот все отрабатывает меньше чем за секунду, если JMX порт локальный, и сервер отвечает тоже быстро. Т.е. JVM успевает за секунду запуститься, отработать класс, и завершить работу.
А медленный старт — это медленный старт приложений. Самих.
Что до поддержки модульности — то извините, но это мимо. Есть множество языков, где с этим намного, намного лучше. Скажем, все языки из мира JVM — ну просто потому, что модули уже собраны, под любую платформу, лежат в стандартном репозитории мавен централ, с известным API, в общем — вокруг этого есть инфраструктура.
А что взамен мы видим у Go? Guthib? Ну это как бы не самое плохое решение, но далеко не самое универсальное. Понятно, что у языка компилируемого в бинарник под конкретную платформу, с этим все сложнее by design, но тем не менее факты налицо.
Кстати, что там с работой за файрволом? Вот в случае maven, скажем, в 99% случаев достаточно завести внутренний репозиторий, и переключить всех клиентов на него (одним пинком ноги). А что делается в случае go get, если вы в интранете?
Сама jvm стартует быстро, да. helloworld запускается меньше, чем за миллисекунду. Но загрузка и JIT занимают существенное время и способа написать на java большое быстро стартующее приложение нет. Предкомпиляция в java9 может улучшить ситуацию, но не принципиально — она выдает на выходе объектники в 100-200 мегабайт.
Ну так давайте формулировать преимущества как-то более корректно что-ли?
А то я могу написать примерно так: запускаем (написанный на Go) docker что-нибудь, а он, собака, отрабатывает сто лет. А почему? А потому что нужного нам image не оказалось в наличии, и мы пошли его загружать, а registry медленный, потому что интернет, а диски тоже не очень быстрые, ну и пошло-поехало. Вывод — Go медленный, не? )))
Поэтому все эти оценки — они слишком субъективные (хотя и не кажутся такими на первый взгляд). И реально сделовало бы оценивать с учетом архитектуры, оптимальной для каждого случая.
Хотите быстрый старт в Java? Сделайте так, чтобы JVM вообще не поднималась, а была запущена всегда. Так можно, и так делается легко — таких приложений множество.
Хотите продемонстрировать реально быстрый старт приложения на Go (а не просто какого-то мелкого бинарника) — покажите реальное приложение, которому нужна куча ресурсов (скажем для UI, картинки всякие, шрифты, и прочие разности) — и посмотрим, сколько времени оно это будет загружать с диска, и насколько у него эффективные механизмы для этой цели.
В общем, суть вопроса в том, что вы упрощаете, формулируя преимущества. Не сильно, но тем не менее.
компиляция в единственный бинарник, что упрощает деплоймент
А представьте, что у вас много хостов разной архитектуры (ну например, вы деплоитесь на смартфоны). Вы все еще уверены, что единственный бинарник упрощает задачу деплоймента, а уже не наоборот?
Какая уж тут субъективность :-)
На JIT языках без предкомпиляции нельзя писать приложения с быстрым стартом, а на компилируемых языках можно. Вот и вся разница.
Быстрый старт, как правило, нужен в двух случаях — тяжелые утилиты командной строки и GUI приложения. Если в первом случае оставлять экземпляр в памяти после завершения выполнения имеет смысл, то во втором — значительно страдает UX, т.к. юзер либо долго ждет первого запуска, либо приложение загружается при старте системы — замедляя загрузку и потребляя память.
Я имел в виду отсутствие зависимостей, которые нужно ставить на целевую систему. Давайте оставим в покое телефоны, у них свой подход к деплойменту. У Go немного другая сфера применения.
Про телефоны я просто для ясности — очевидно что бывают такие случаи, когда мы разворачиваемся на разных устройствах, с разной архитектурой, и нужны как разные бинарники, так и разные ресурсы. И тут такое свойство, как "компиляция в единственный бинарник" вовсе не очевидно, что реально упрощает деплоймент. Скорее наоборот. Сказать, что это не сфера применения Go — ну это же не ответ, очевидно.
А про быстрый старт… ну вот смотрите — любой GUI на базе web, для простоты, как пример. http сервер запущен, и всегда готов к работе. Время его старта никого никогда не волнует. И это с таким же успехом может быть тяжелый сервер типа вебсферы, или легкий и примитивный, потому что критерии быстроты тут уже другие.
Это к тому, что архитектура, обеспечивающая быстрый старт, она просто должна учитывать, что именно нужно пользователю.
Это почему оно не работает? Собственно, в ссылке автора на закон в первых же строках:
«He noticed that the number of transistors per square inch on integrated circuits had doubled every year since their invention.»
Мур ничего не говорит про тактовую частоту. Он говорит о плотности транзисторов.
Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц
Да, частота меньше. Но сколько ядер в процессоре Macbook Pro 2016 и сколько ядер в Pentium 4. При этом размеры процессоров одинаковы.
«При этом красота и естественность» у джса, с++, джавы и питона одинаковая и сильно проигрывают с#)
Вы, наверное, хотели сказать "мало за эту неделю"?
Возможно даже (не берусь утверждать на 100%), что ни про какой другой язык здесь не выходило такого количества однообразно оформленного восхищения.
Тогда каким образом объясняется создание таких языков как Ada и Erlang в середине 80-х годов?
Ой, да бросьте. Это не более чем малограмотный вброс. Вы бы еще спросили, зачем в Java класс Thread, с первой версии (а это 1996 где-то). А еще средства координации потоков, разнообразию которых Go может только позавидовать белой завистью.
Источник: github.com/golang/go/wiki/GoUsers
Я не нашёл там Abode, обманщик!
Go
Красота кода
Выберите что-то одно.
Пожалуйста, перестаньте оценивать языки по субъективным критериям. На любом языке можно сделать как и совершенно нечитаемый, так и наглядный код. Не постите больше подобных графиков. Хотите сравнить языки — пишите об особенных фичах и как их использовать.
Не поддерживает наследование. Это упрощает модифицирование кода. В других языках, типа Java/Python, если класс ABC наследует класс XYZ, и вы при этом делаете какие-то изменения в классе XYZ, то это производит дополнительное изменения во всех наследованных от него классах. К тому же, без наследования, код Go становится более простым для понимания (так как нет super классов, на которые нужно обращать внимание при изучении участков кода).
Т.е. повсеместно будет использоваться агрегация и изменения класса XYZ коснуться всех классов, которые содержат XYZ… так в чем тут преимущество у Go?
Вообще, статья про то как превратить особенности языка в его сплошные преимущества.
превратить особенности языка в его сплошные преимущества
Именно
«Общеизвестно, что поворот налево — опасный маневр, потому создатели автомобиля Гоу использовали гениальное решение — автомобиль может поворачивать только направо, а при необходимости повернуть налево — просто поверните направо трижды. Одного этого факта достаточно, чтобы понять, насколько Гоу лучше других автомобилей!»
Вообще диаграмма крайне холиварная, в отношении того же erlang. (например строка = список чисел).
С производительностью тоже не всё в порядке — все интерпретируемые языки на картинке по оверхеду самого языка на производительность плюс-минус однохренственны, больше зависит от решаемой задачи и используемой библиотеки.
невидимые символы являются значимыми лексемами
Только в начале строки. А так как все всё равно форматируют код лесенкой, это не является проблемой
А влияние форматирования на интерпретацию — крайне холиварная тема.
Это да. Но pep8 настаивает на чётырёх пробелах, подключаем pylint для проверки сего и можно жить
Pre-commit хук и/или линтер на CI-сервере снимают проблему. Когда смесь табов и пробелов (очевидно, подавляющее большинство языков) не влияет, в коде средних и крупных проектов рано или поздно появляется каша, если нет явного битья по пальцам за несоблюдение code style. Наблюдаю во многих open source проектах, например.
Проблема больше во всяких мини-скриптах, небольших чужих приложения ( например, игрушки на питоне) — там, где ты редактируешь код быстро, и чаще всего — не из родного редактора.
Значимость невидимых на письме символов при компиляции — расходится с практикой естественных языков, не самая ожидаемая для человека вещь.
Я уже примерно 2 года как Go-пник. И мне это постепенно начинает нравится чорт вазьми! несмотря на все минусы, там реально всё проще, тоньше и быстрее в итоге — деплой, сопровождение, инструменты.
Все эти баги с мьютексами и "if err==nil" (и проч, что обычно приводят в доказательство ущербности go) на самом деле легко обнаруживаются при наличии минимальных юниттестов. Ну и стат.типизация даже без джененриков после петона и похапе — щастье же.
По поводу rust. Представим гипотетическую ситуацию, при которой коллективу кодеров приказывают на него перейти с условного жабопетона — взвоют. Go — поноют немножко, и будут кодить как ни вчем не бывало.
Посмотрел вакансии в родном городе, нашёл две вакансии по Go:
- одна с очень большим разбросом зарплат от джуниора до сеньора, требует Go, Python, Java и Scala
- другая с очень большой зарплатой, с требованием помимо Go знать ещё и PHP
Язык в настоящее время мало что значит для массовой разработки. Главное, его экосистема — библиотеки, фреймворки, вот это всё. Упускать это из обзора — или не понимать, что нужно от языка массовой разработки, или умалчивать скудность экосистемы.
Сорри, промахнулся и поставил минус. А хотел плюс.
Очень хороший пример, кстати, средства работы с базами данных в стандартной библиотеке, и наличие драйверов под все известные базы.
В смысле у Go? Мне они показались наиболее рабочими. После Java и .Net, скажем так, у которых пожалуй есть драйверы под все базы вообще, и API наиболее полноценный.
Да, универсально, пул под капотом, потокобезопастность тоже…
с другой стороны (это то что наболело)
— пул плохо настраивается, макс кол-во соединений и макс. кол-во простаивающих соединений и все, а я бы хотел задать мин. кол-во простаивающих соединений, кол-во соединений при старте, чтобы не ждать пока соединение откроется
— средств профайлинга нет. измерить время выполнения запросов можно и снаружи, а вот какие затраты были на установку соединения при вызове db.Query и были ли вообще — непонятно
— следствия универсальности: нет доступа к спец. возможностям субд, нельзя получить из пула соединение. Даже если разработчик драйвера предоставит методы для работы с API, то надо предоставлять механизмы для создания соединений и отдельный пул, т.к. к стандартному доступа нет. А если такое случится, то нафига тогда database/sql/
— с логированием, если ошибаюсь, тоже никак
Ну, если сравнивать с JDBC — то да, вы правы. Причем я бы так сказал — компилируемый язык, без VM, инструментировать код наподобие того, как делается в мире JVM, чтобы добавить профайлинг или логирование уже после разработки — это вряд ли.
Но если сравнивать например с Python, где драйвер MS SQL урезает строки до 100 — это все-таки более рабочее решение.
Не поддерживает наследование.
Нет конструкторов.
Нет аннотаций.
Нет дженериков (универсальных шаблонов. — прим.перев.).
Нет исключений
Go это реинкарнация PL/1 ?
В общем в контексте использования для concurrency Clojure мне видится более приятной чем Go.
Кого-то это сильно взбесило и он запилил сервис http://fuckinggodateformat.com
Код написанный на го, будет хотя бы собираться в новых версиях компилитора хотя бы через 3-5 лет? я молчу про такую «ынтерпрайзную роскошь», как «работать точно так же»…
Или будет как с руби? (гугль выпутит новую, улучшенную версию языка, не совместимую с предыдущей, и через 2 года снимет старую с поддержки, со словами, мол, " мы скорбим, что до сих пор ещё много проектов не смогли перейти на новую версию, из-за проблем с перерабокой исх. кода, но мы все-таки снимаем старую версию с поддержки. (читаем между строк: «Мы плевать хотели на ваши проблемы. Это ваши проблемы, трудоемкость и деньги. А мы будем дальше делать наш красивый язык, ибо нас волнует только красота нашего поделия.»)?
Ещё, во всей статье, так и не нашел позиционирования языка. Под какие задачи он заточен? Какой сдк и библиотеки под него есть?
Ещё вопрос, как разработчика с 20 годами стажа, которого, вопреки заявленному в статье тезису, никогда не сводили с ума новые языки, которого эта череда «новых откровений» банально достала: зачем нужен ваш язык, если всё, что нам надо, мы прекрасно делаем на уже существующих технологиях: java, javascript, с/с++? кто то еще вспомнит про си-диез (простите, не люблю я его — но и ладно..., живет и даже что ть полезное можно на на нем делать)… кто то вспомнит про питон ( скажу — «остыньте, уже не модно»), руби ( «и вы пойдете на свалку моды»), хацкель (подмигну -ну ты понял, посмтри на питон и руби)… Но чем го отличается от этого разношерстного безобразия? Это нишевый язык или общего назначения?
Да, вы проводите какие, весьма спорные, сравнения, очень пахнущие глубоким субъективизмом, картинки рисуете. Говорите про какую-то понятность… Но вот я так и не понял — это замена питону или башу в скриптах инициализации линукса?
Это скриптовый язык с возможностью компиляции и возможностью использовать .dll/.so? Или это легкое нечто которое позволяет набросать что то на коленке типа мини утилиты? Или это нечто для веб, компилируемое и мегашустрое в обработке мегатонн микро-запросов?.. Ведь нечто большое, мега-интерпрайзное этот язык, как сложилось впечатление, в силу отсутствия ооп -банально не потянет (в си же вон от структур и пакетов к ооп перещли?.. зачем, не понятно, наверное… но си, сегодня, остался, видимо, только при программировании микроконтроллеров...). Или го — это замены простому си, пригодному для програмирования микроконтроллеров?
Какие прикладные пакеты есть в го?(кодогенератор веб сервис-клиента из .wsdl-файла есть? Я могу тестовый скриптик типа как для junit набросать? А к базе данных могу подключиться? jdbc-драйвера он понимает? Нет? а odbc?) Какие средства для управления GUI есть? я могу его интегрировать с Qt? нет? а какие средства есть для воддержки веб-интерфейса? Поддержка вебсокетов есть?
Эти, и ещё полсотни других влпросов я могу задать, и не остановиться, потому, что есть еще много за этой полсотней…
Не должен я учить го. Не вижу я в этой статье, чем го отличается от мегасотен других «откровений». Извините.
Зачем мне писать что то серьезное на го, если никто не гарантирует, что завтра они не выкинут такой же финт как руби? или как питон не выпустят новую версию, на которой старый код не работает?
А если не серьезное — то что тогда писать? как этот язык поможет улучшить жизнь моему бизнес-заказчику? какие проблемы я могу на нем решать? плевать на синтаксис ( хотя, нет, не плевать — за отступы-табы-проблемы в питоне надо «бить в голову с ноги»)))))(шутка)) но как этот язык облегчит мне жизнь?
Обратная совместимость не только стабильностью синтаксиса гарантируется. В джаве вон синтаксис меняется, но обратная 100% совсестимость остается. То, что гугль заморозил синтаксис, это может быть и хорошо, но что с базовыми библиотеками? Или будет как в си? (через 5 лет, на другой платформе, теоретически, собрать софтину можно, но вот половины библиотек уже нет или они просто не перенесены на эту платформу? да и разрядность уже поменялась, потому вылазят нулл-поинеры да сег-фолты?)
Что у языка с кроссплатформенностью?
И повторюсь: не увидел, даже после перепросмотра статьи производственных задач, которые решаеются языком у тех или иных вендоров! Или вы как «свидетели руби» — обосновывают выбор руби для сложного «иниерпрайз» проекта с ЖЦ длительностью лет 10 тем, что «там-то оно используется» — а когда выясняешь как именно используется — выясняется что там 5-и строчники-скриптики для тестирования оборудования на нем пишут?)))
Компилите исходник в нужную платформу: о)
Странный вопрос канеш: о))) Не поленитесь потратить десять минут на Го ЧаВо.
На бумаге. На словах.
Но различные реализации интерпретаторов руби, под разные платформы, в разных средах, на практике оказываются малосовместимы друг с другом, или ведут себя по разному (код ведет себя по разному) (тут я сошлюсь на мнение знакомого рубиста. бывшего рубиста.).
И у с/с++ тоже с кроссплатформенностью все хорошо. Ну как хорошо — только анси-си в примитивном виде можно переести между платформами. Но это не точно. Не факт, что после сборки взлетит (банально, int у всех разной длины.).
Самый яркий пример красот кросскомпиляции C++ кода — необходимость фазы метакомпиляции в Qt, когда универсальный кроссплатформенный Qt/C++ превращается в код код конкретный компилятор. мол в линуксе — gcc, но код, который gcc проглотит, не проглотит майкросовтовская вижуал студия (ну не понмает она шаблонные классы — generic, и это в 21м веке, году 2010 от Рождества Христова....) и тд. и тп.
Потому и спрашиваю — как в гоу с кроссплатформенностью на самом деле. Хочу ответ услышать с деталями.
* Как обеспечивается кроссплатформенность. Как решены проблемы присущие С/С++ коду при сборке на разных системах?
* Eсть ли (как у джавы, снова) процедура сертификации компилятора/интерпретатора на соответствие стандарту? (ибо как вы собираетесь кроссплатформенность соблюдать без наличия четкого стандарта).
* Сам стандарт на язык вообще есть и в каком виде? или «оно как в питоне» — это некая малоформального вида бумага, поддерживаемая автором и сообществом?(поправьте если ошибаюсь).
А если уж отсылаете в фак, то надо отсылать с выдачей ссылки, а не посылать в пустоту. Где ссылка? Вы предлагаете мне продираться сквозь тонны рекламной мишуры? Дайте ссылку на самый правильный фак, какой вы сами считаете есть. Вы эксперт по языку, а не я. Я потенциальный потребитель, который пока задает вопросы, и не будет тратить время на ваш язык, если вы не в состоянии ответить на эти вопросы.
Ибо кроме вас есть еще руби, питон, раст, хаскель, свифт, сишарп, ди, 1с,… и каждый кричит — все просто, все на поверхности, вот почитай фак/идеологию/роадмап/вижен/идею… да вы что, все, смеетесь?)))
Вы эксперт — вы и ответьте, пожалуйста на вопросы. Со ссылками. Заранее спасибо.
Судя по вопросам, которые вы задали, как только вы получите на них ответы, следующий проект вы будете писать на Go :)
Вы, вместо громогласных заявлений, ответили бы для начала хотя бы на часть вопросов.
Рубисты/питонисты говорили точно так. Но нет, подташнивает. А ещё, все знают об "успехах" рубистов на проекте в росреестре. Сданый вовремя проект, довольный заказчик, коммерческий успех компании подрядчика, безоблачные перспективы команды проекта… ага...
Следующие свои проекты, особенно после прочтения статьи "50 оттенков го", я буду писать на java. Как и последние несколько лет.
Вообще-то, это был комплимент тому, насколько ваши вопросы свидетельствуют о хорошем практическом опыте разработки. Это правильные и нужные вопросы (ну, кроме "про драйвера jdbc понимает" — тут я даже усомнился в своей оценке), и главный конфликт Go с последователями других языков в том, что многие решения приняты из практического опыта, а не из теоретических фантазий академиков.
На вопросы себя тут не утруждаю отвечать, поскольку
- а) большинство из них лежат на поверхности, стоит только захотеть,
- б) я уже немало написал постов, в которых ответы на эти вопросы присутствуют и
- в) чем больше вопросов в одном посте, тем меньше вероятность получить исчерпывающий ответ на каждый из них, из чего можно сделать вывод, что вопросы были заданы не ради получения ответов, что подтверждается пунктом а).
Собственно, мой пост был к тому, что задавая такие вопросы, и захотев действительно узнать ответы, вы будете настолько приятно удивлены, что, учитывая низкий порог входа в Go, я не вижу причин, почему вам не захочется попробовать Go на практике в первую же неделю.
Но раз подташнивает, то пишите на Java, конечно, как и последние несколько лет, никто ж не заставляет :)
Как вы предлагаете мне приятно удивиться?
Вы говорите ледит на поверхности? на поверхности вон по wsdl например — лежит пакет goWsdl (спасибо камраду за ссылку). но из описания пакета, я понял, что в сравнении с тем, что умеет в этой части джава — goWsdl это дешевая студенческая поделка. Где генерация wsdl, где xsd 1.1, где сериализация и десериализация в код через аннотации?
Извините, не хочу я тратить время на изучение очередного изделия. Таких изделий каждый день -десятками плодится — на всех жизни не напасешься ознакамливаться. Надоело, если честно.
Если от идеологов нет ответов на конкретные вопросы — значит изучать уже никто не будет. И аргумент мол на поверхности, сразу найдете ответы — во первых не катит, потому что то что поверхности уже не впечатляет, а во вторых — это просто гнилой маркетинговый подход, согласитесь. Не буду я тратить время на изучение кота в мешке.
Особенно, плохо звучит такой ответ (начните изучать и будете приятно удивлены, вместо конкретного ответа) — если сравнить такой ответ с ситуацией, когда я спрашиваю у мастодонтов джавы «что есть в джаве для этого?» — мне говорят конкретный набор буков и я иду гуглить этот пакет или технологию.
парой пос ов пиже, я описал вполне конкретные вопросы и ситуации про вебсервисы, wsdl и soap. у вас есть что ответить? и да, ответ я много раз отвечал — тоже гнилой ответ. отвечали — дайте ссылку, сделайте фак и ссылайтесь на него. но не отсылайте в никуда)
Вот заладили вы со своим WSDL. На поверхности лежат ответы на вопросы про обратную совместимость, кросскомпиляцию, возможность использования .so и так далее. Я понимаю, что у вас нет времени открыть Golang FAQ и получить более, чем исчерпывающие ответы на эти вопросы — оно занято написанием длинных комментариев.
Отвечая про WSDL — приятно был удивлён, что оно ещё не умерло и кем-то используется, хехе — всё на что есть спрос в современной серверной разработке, в Go реализовано — коммьюнити то большое, и, в основном, очень технически сильное. То на что спрос особый — вообще в стандартной библиотеке.
Извините, не хочу я тратить время на изучение очередного изделия.
Да мне какое дело, вот прицепились ) Я всего лишь обратил внимание на то, что ваши вопросы намекают на то, что ответами (которые есть в FAQ) вы будете удовлетворены.
про WSDL — приятно был удивлён, что оно ещё не умерло и кем-то используется, хехе
Это говорит лишь об одном — определенной (узкой) направленности вашей работы. Попросту говоря, soap — это весь ентерпрайз. SAP какой-нибудь. А еще например Sharepoint. То что вы с этим не работаете — ни разу не означает, что этого нет в природе.
Кстати, у Go и с JSON тоже все не очень хорошо. По сравнению скажем с Groovy — так вообще не впечатляет. Та же клиентская часть докера — так это ужас-ужас какой-то (там собственно внутри же REST, поэтому оно все из такого кода состоит). Поэтому мне лично заявления "ну так докер же на Go" — они довольно-таки смешные. Читается этот код докера ужасно, и писать кучу такого же своего — никакого желания не возникает.
Пришел человек, задал некоторые вопросы, много вопросов задал, интересуют его ответы от кого-нибудь из Go-сообщества.
Пришел представитель сообщества и ответил только одно: «следующий проект вы будете писать на Go». Wat? Это всё? Даже секты как-то больше заморачиваются с объяснениями того, зачем все должны в них вступать :)
и ответил только одно: «следующий проект вы будете писать на Go»
Это не то что я ответил, но вы можете трактовать, как вам удобно :)
Пришел представитель сообщества и ответил только одно: «следующий проект вы будете писать на Go».
Очень простой и правильный встречный вопрос, позволяющий ответить "теперь точно нет" и не терять время.
Рантайм у го довольно легковесный, так что можно писать и для слабых встраиваемых систем.
Неполный список прикладных пакетов
Драйвера баз данных из этого списка
Вебсокеты поддерживаются отлично, для веба есть куча фреймворков разной степени удобности и быстроты.
Для бизнеса го выгоден из-за простоты и единообразия. Легко обучить разработчиков, которые писали на других языках и легко разбирать код из-за автоформатирования и простого синтаксиса. Насчет отступов и вообще форматирования кода, кстати, они расставляются автоматически, а соответственно, единообразно у всех. gofmt — это стандарт де-факто.
Го уже используется столькими проектами, что Гугл вряд ли просто так его выкинет.
А как он подходит к сложным бизнес-процессам? Тот же веб-сервис, но со сложной логикой, а не просто CRUD-морда к базе данных. Пока у меня о Go представление как о гибриде C как системного инструмента и чего-то типа NodeJS как инструмента создания мостов и фасадов к СУБД, сложным SOAP-сервисам и т. п.
Go приучает к простому и понятному коду, хоть и чуть избыточному, вместо писанины «смотри как я могу». Невольно эту практику переносишь в java/C#.
Не спорю, может rust не хуже в этом плане, даже лучше, никогда его не использовал, но go сам по себе — хороший практический язык.
ЯП в достатке — выбирай, пробуй, тестируй, работай, хвали, ругай, помогай в развитии. Адекватными при сравнении считаются аналитические заключения о соответствии ЯП целям поставленной задачи, остальное вода в ступе.
Некоторых прям неадекватно распирает от «экспертных» оценок.
Вот именно о задачах, которым соответствует описываемый язык — в статье нет ни слова. Не о чем делать аналитические заключения. Статья — реклама, рассчитанная на восторженного наивного, не отягощенного практикой новичка. Потому и "срач". Имхо.
А мне казалось, что для быстрой (псевдо)параллельной работы большого числа (псевдо)потоков. С требованиями к веб-сервисам это пересекается, но не более.
Это вебсервисы, потому что это они описываются в спецификациях с соответствующими названиями.
Если открыть википедию, то там как раз о wsdl/soap/xml и говорится.
А что для вас «вебсервисы»? о каких именно вебсервисах вы говорите, о которых «все» (кто эти все?) знают? — можете обозначить назвария технологий, номера специфицаций и стандарты, которыми описываются ваши «вебсервисы»?
для каких именно «вебсервисов» предназначен этот язык?
Получите абстрактный ответ. Да, Go поддерживает все эти буквы библиотеками + WDSL.
Собственно, он больше толком ничего и не поддерживает, как я посмотрю (но я тоже не гоадепт — web не моя экосистема).
а как именно «поддерживает»? вы эту «поддержку» с джавовским стеком сравнивали?
давайте по порядку: первое — кодогенератор по ссылке — это клиентская часть или серверная?
если серверная, то для какой серверной платформы или какого сервера приложений ?(такое понятие в гоу есть?)
я к чему — управление ресурсами в этом сервере есть? пул потоков, скажем? А то, знаете, видели мы тут недавеча «супер сервер». на руби писанный. Когда ему 5 потоков запросов в параллель пускаешь… он… падает. Понимаете, Карл,… падает!!! Не выдает 5хх-й код, не закрывает соединение с месседжем типа — превышены ресурсы, и продолжает работать, как это делает практически любой сервер приложений для всеми ненавидимой джавы… а просто падает.
Как в гоу решается вопрос управления русурсом подключений? Так же, как в руби на том сервере?)))
Ладно. Следующий вопрос: где генератор wsdl по коду? обратный, так сказать, генератор? я могу написать структуры, массивы, определить их обязательность или не очень, функции… а она мне — по моему коду — и wsdl, и опубликованный сервис на сервере и сразу подключайся-не-хочу… умеет? почему джава и сишарп (мать его))) — умеют, а гоу… для вебсервисов ориентированный, все поддерживающий — … умеет?
Теперь следующий вопрос: xml schema 1.1 — где? А то нам тут АТ-К прислали файлики как-то раз… так мы их едва открыли… кстати, не wsdl прислали, а xsd.
xds..., да, а что у нас с xsd? Что с валидацией xml, на соответствие xsd?
Что, с сериализацией/десериализацией xml? Есть в «красивом синтаксисе гоу» аналог джавовских аннотаций? Есть возможность просто «промаркировать» поля структуры xpath-ами — и отдать структуру в некую «фабрику», а на выходе — получить xml-заданной структуры? ну не охота мне руками раскладывать поля по элементам xml…
Что с ОРМ? Могу я в «аннотациях структур» гоу описать какое поле в какой таблице в какой колонке лежать? И что бы была просто фабрика, которой, подсовываешь струтуры, а она сама тебе и базу данных перестроит, и сохранение-восстановление сделает? и что бы мне — только одну строчку над каждым полем прямо в классе прописать. можно так в гоу? или только gowsdl пакет, который, судя по всему, упадет если ему на вход подать не корректную структуру?
и я ещё много могу рассказать чего у вас в вашем распрекрасном гоу нету, что есть в ненавидимой хопстотой «джаве-йе-йе».
…
просто я к чему? гоу, насколько я могу сейчас судить, находится на уровне технологичности джавы 1 или 2. аннотации, вон, и «рефлекшен» в какой джаве появиоись? в третьей кажется, поправьте? какой это год? начало 2000-х? вот и гоу сейчас — примерно на этом уровне готовности для «промышленной разработки». Играйтесь конечно, но прошу, давайте не портить пространство воплями типа «большой код», все умеет, вебсервисы… вы видели «большой код»? сколько читающих этот пост хотя бы знает о «монструозности» стека приложений «ibm websphere»? а «рейшионал»? вы пытались писать систему которая должна хранить ваши данные 75 лет после вашей смерти? Эта «простая задача» сейчас решается в пенсионке. На джаве и майфреймах ibm. Ну смешно же выглядят сказки про «большой код» на гоу, на фоне достаточно примитивного набора возможностей языка. Ну серьезно, народ)))) Не ведитесь.
Да, в нем есть, вероятно прикольные фичи типа горутин (так и не понял из статьи, что эта за фигня, кстати) — но это не делает картины на фоне провала по всем остальным фронтам. Не может сделать, извините.
В пхп вон тоже поддержка wsdl есть. и причем на уровне более серьезном, чем это единственное поделие «gowsdl»… только что с этого?..
Посмаковать синтаксический сахар на досуге — это прекрасно.
Но я описываю интерес практический. и я прошу оппоннта ответить на эти вопросы хотя бы самому себе.
Как язык поддерживает те или иные технологии, и что имено означает эта «поддержка».
В частности, к прмеру — была заявлена поддержка вебсервисов.
Я начинаю «разбираться» — описываю кейсы (рабочие ситуации) и проблемы с которыми мы столкнулись в жизни, с примерами «провала кейса» на «других модных языках».
Что бы узнать, как именно обстоят дела в части «поддержки всех этих букв» в сабжевом языке.
На самом деле, вероятный ответ я уже знаю, но мне важно, что бы оппонент осознал что, заявленная «поддержка буков» на ко оруб ор сослался — это филькина грамота, мало общего имеющая с потребностями в части «поддержки указанных буков»за пределами академической среды.
Хотя, остается шанс, что я не прав, и я буду приятно удивлен.
Увы, но такое впечатление, что очень многие идеологи новомодных языков и их последователи как правило мало подкованы в технической части и практике применения IT в жизни. Для них сложный код — это сложная курсовая. для них важнее запилит красивую модную фичу в язык, а не обеспечить 100% ьбратную совместимость. Их понимание того, что такое технология и как она применяется — толькь пара лежащих на поверхности случаев, причем о проверке валидности структур и об обработке ошибок и исключерий — они и не слышали, или даже хуже — сознательно выпилили это из языка.
Первое чему приходится учить стажера — это критический взгляд, и умение строить зашиту от дурака в своем коде/системе. Подавляющее число технологий на новомодных языках — не серьезны, и крайне плохо обрабатывают проблемные ситуации. Пример с руби сервером который падает на 5 потоках запросов — очень характерен для идеалистических выходцев из академической среды в розовых очках. Или для хипстоты.
Другая причина почему я это все говорю — надежда, что сегодняшний «свидетель гоу/руби/питона/хацкеля», погрущившись в детали технической части и сравнительный анализ возможностей языков — начнет изучать нечто более серьезное, и будет смотреть на вещи более критично. Для этого, имзо, достаточно просто ответить на вопросы которые я задаю. Только честно. Хотя бы самому себе )))
Адекватных инженеров очень мало.
Когда-то, мне перла для веб — вполне хватало. Для дипломной работы. Но потом был пхп, дельфи, си++, джава… Задали бы мне пяток таких вопросов в свое время…
Я не вижу, какой смысл в пуле потоков в Го, так как есть горутины. В промышленных приложениях работают сотни тысяч горутин.
Или у вас задача мапить потоки вашего приложения на потоки ОС и поэтому вам нужен собственный супервизор потоков?
Вобщем ваши вопросы звучат не для Го, потому что либо в Го таких вопросов нет, потому что они решены не вашими средствами, либо вы не знакомились с Го, поэтому ваши вопросы выглядят чужеродно: о)
Давайте по сути обсуждать, а не по форме?) я знаю что вам кажется все это чужеродным в отношении гоу ) да, я не понмаю «этом вашем гоу» — и я задаю вопросы в терминах, которые сейчас применяются в промышленных технологиях. В общепринятых тезнологиях. а Термин горутины — это специфиака. «Ваша специфика». Проведите параллели с промышленными терминами и объясните на пал цах как не дать гоу серверу вывалиться в нерабочее состояние при попытке перерасхода выделенных ресурсов? и как вообще ему выделять ресурсы?)
гоу — как я сейчас понимаю нишевый язык. очень нишевый. с, судя по всему, очень особенной поддержкой, которую устраивает текущее состояние, при котором многих бесят некоторые недофичи языка (ссылаюсь на статью «50 оттенков гоу»).
Так вот и опишите эти ниши. Конкретно. С техническии деталями и подробностями.
Так вы завоюете больше последователей. Мне вот все равно на чем писать на проекте — надо было -мы на сишарпе «прокси» с интерфейсом на вебсервисах для доступа с андроида к доксвижену сделали. Хотя сам я джаву люблю — но надо — ращобрались и сделали.) есть на Qt проекты. Будем понимать нишу гоу — почему бы на гоу не продать пару проектов — но нужны конкретные примеры с тех подробностями. Я вот не буду разбираться в интимных откровениях и проблемах недо-языков за свой счет — мне бы сделать бизнес-задачу, что бы клиент был доволен))) А гоу пока не ложится ну никак супротив джавы, имхо. и не будет ложиться, пока будут дешевые переводные статьия с рекламным буллшитом, вместо сухих технических данных и статистики с плюсами и минусами. когда мы инструменты для проекта выбираем — надо профиль понимать, и риски минимизировать.
… а вместо этого — половина сторонников гоу, в комментариях выше и ниже только радостными воплями разрождаются про то, как им понравилось, и какой экстаз они испытали… да плевать на это. глубоко плевать, извините) Факты давайте.
Внутри http оно может класть html, json или всякие другие данные, хоть вебсокет. Граница довольно размытая, на самом деле. Думаю, имеется ввиду, что приложение является при этом частью системы сайта.
Есть у меня друг — не программист. И я решил ради эксперимента, научить его программировать, причем сразу на Erlang'e. И вот глядя на то, как у него ничего не получается, прихожу к выводу, что да, синтаксис Erlang прост и логичен. То же самое я сейчас вижу глазами Elixir разработчика. Но Erlang сложен из за того, что надо понять, как правильно его применять, как решать на нем задачи, типичные приемы, идеологии ОТП.
А как с отладкой горутин? Какие отладчики существуют, что бы можно было пощёлкать контексты, посмотреть где что и в каком состоянии? А то мне в Asio понравилось писать с короутинами, но зело сложно отлаживаться с ткущим инструментарием.
Первый процессор Pentium 4 с тактовой частотой 3.0 ГГц был представлен ещё в 2004 году компанией Intel. Сегодня, мой Macbook Pro 2016 имеет тактовую частоту 2.9 ГГц. Таким образом, около десятилетия нет особого прогресса чистой вычислительной мощности.
Только производительность одного потока выросла в 3 раза.
Лучше бы вместо отого описали реальные кейсы, в которых Go применять действительно удобно.
Вобщем Го — красивенький, и на нём уже много критичных серверных приложений написано.
Сложную транзакционную бизнес-логику систем класса ERP, CRM и т. д. удобно писать? Задержки на секунды не критичны, если надежно обеспечена блокировка при старте транзакции, но простая команда типа signContract(contractId) может вызывать создание и изменение сотен записей в СУБД и генерацию десятка событий в MQ/шину.
Тут скорее речь про то, чтобы принять одно событие и сгенерировать по сложной логике с десяток.
Ну не замечал сложностей в Го для такой логики. а мож не сталкивался: о)
Но если нужно сожрать, переварить и выдать мегаллионы байт, то тут Го канеш безусловный фаворит.
Ключевое слово «сложная логика»
именно. то что вы не сталкивалсь с этим, говорит только о том, что вы мелко плаваете. или о том, что любимый вами язык никто в здравом уме не применяет для серьезных задач.
вопрос с интерпрайзом не в мегатоннах байт и простых запросов, а в сложных и часто постоянно плавающих бизнес правилах.
всем плева-ть на миллион запросов в секунду. совершенно.
важно, что бы хотя бы один отработал за преемлемое время, сопоставимое хотя бы с часом.
потому что когда воодушевленные хайлоад-конференциями школьники приходят и делают систему на этих модных «производительных» технологиях, а потом вдруг оказывается, что их творение не способно построить справку об исполнении поручений первого лица города за неделю, и уже 6 часов это «хайлоад творение» пытается собрать «просто отчет» (просто потому, что правила по которым вы понимаете исполнено поручение или нет — уже это сложно рассчитываемый признак) а потом ещё надо посчитать на сколько дней оно было просрочено поручение (рабочие дни! не календарные! ) и планируемый срок окончания — вот тут начинается совершенно иная песня.
особенно после того, как совещанме мэра начинается _без_ основной бумажки об исполнительской дисциплине. потому что язык, способный перелапачивать мегатонны байт в секунду, и миллины рест запросов — не смог за 6 часов построить один-единственный отчет, на горизонте событий 1 неделя, попоручениямодного человека
Например, из-за того, что модуль типа linq Go агрегировать данные из БД умеет только на стороне приложения, а генерировать SQL запрос с агрегацией на стороне СУБД не может. Пример абстрактный, без понятия есть ли вообще подобный модуль в Go.
Можно, но в целом это не дело прикладных программистов писать SQL-запросы руками. Это или разработчики/администраторы базы должны делать, или экосистема языка генерировать.
Тупые разработчики ОРМ, которые не могут написать генератор хороших быстрых SQL-запросов? :)
ну, вообще говоря, да :-)
ORM добавляет накладные расходы в виде анализаторов графов объектов/генераторов sql + не умеет писать оптимальные запросы. К примеру, сложности начинаются, когда в целях оптимизации нужно выбирать не все данные, переформулировать запрос иначе для лучшего понимания планировщиков или добавить хинты.
Сколько диалектов SQL есть хотя бы? А если в требованиях поддерживать хотя бы MS SQL, Oracle, MySQL и PostgreSQL, хотя бы пары последних версий?
Когда-то я и сам аргументировал за хибернейт именно так. Но суть в том, что приложения, которые должны работать на разных СУБД, достаточно редки. А проблема быстрой миграции на другую СУБД проще решается наличием тестов на слой DAO, а не ORM.
Для коробочных продуктов не такая уж редкость, если есть желание охватить как можно большую долю рынка, чтобы потребители не отказывались от решения лишь потому, что у них всё крутится на MySQL, есть специалисты по нему, а внедрение PostgreSQL потребует дополнительных вложений, без которых продукт нормально эксплуатировать будет весьма затруднительно вплоть до полной невозможности.
А вообще мой тезис в том, что обычный прикладной программист не должен уметь писать более эффективные SQL-запросы по сравнению с профессиональным генератором запросов. А если такого в экосистеме языка нет, то для прикладной разработки он мало пригоден, если отсутствуют в штате специалисты по конкретным СУБД, которые будут получать от прикладного программиста задания с описанием того, что он хочет получить и реализовывать получение оптимальным способом.
Всё равно одним инструментом решать сложные комбинированные задачи затруднительно. Проще разбить на отдельные микросервисы\приложения и использовать заточенный под эти задачи инструментарий. А если вспомнить про то, что существует большое наследие готовых и отлаженных библиотек для старых языков, языки используются, не заброшенны и развиваются, то и говорить о полном написании на одном универсальном языке не совсем корректно со стороны времени\сложности.
Так что фраза «Go станет серверным языком будущего» возможно и корректна, но берёт на себя слишком много.
Вообще можно найти свою область применения языка и на её примерах вещать о «сферическом языке в вакууме».
1. Программа на Го компилируется в один бинарник. Можете скомпилить бинарник на своём макпро, зааплоадить на сервер под линукс и там запустить. Никаких зависимостей!
2. Статические типы. Ошибки отлавливаются на этапе компиляции.
3. Го быстрый. Потому что компилится в исполняемый код целевого процессора.
4. Для работы с веб в Го достаточно стандартных пакетов из коробки.
5. Для Го есть не только плагины к IDE, но и отдельные IDE.
По мотивам 5 Reasons Why We switched from Python To Go
Для работы с веб в Го достаточно стандартных пакетов из коробки.
Что вы подразумеваете под работой в веб? Достаточно ли стандартных пакетов из коробки для создания веб-приложения (пускай чистого бэкенда с JSON HTTP API, фронт совсем отдельная разработка) по функциональности аналогичного 1С?
https://golang.org/pkg/encoding/json/
Это о том как отдавать результаты работы и как получать её параметры. А как собственно полезную работу делать?
мой ответ можно расценивать как расшифроку что понималось под фразой «4. Для работы с веб в Го достаточно стандартных пакетов из коробки.»
зы
не агитирую за го, но если конкретизируешь «полезную работу», может смогу что-то пояснить.
Автоматизация сложных бизнес-процессов для систем типа ERP, CRM и т. п., да даже банальній интернет-магазин с корзиной покупателя и накопительной скидкой. С ООП решается обычно созданием полноценных объектов с методами, отвечающими за бизнес-логику и достаточно прозрачный маппинг данных этих объектов на СУБД с помощью ORM с преобразованием связей между таблицами в связи между объектами.
Пока что я вижу по Go он хорош в качестве шустрой и простой прокладки (бридж, адаптер, гейт, шина и т. п.) между различными сервисами и протоколами, задача которой в основном преобразовывать данные из формата в формат (например из JSON в SQL и обратно), но только один пример за несколько лет "хайпа" попался пускай с примитивной, но попыткой прикладной разработки по DDD.
По второму — все так.
«Пока что я вижу по Go он хорош в качестве шустрой и простой прокладки (бридж, адаптер, гейт, шина и т. п.) между различными сервисами и протоколами, задача которой в основном преобразовывать данные из формата в формат (например из JSON в SQL и обратно)»
Да, это обычно самое первое применение Го при начале его применения — сделать быстро конвертер, который маленький, быстрый, не требует зависимостей, кроссплатформенный, понятный в чтении и сопровождении. Тут Го конечно фаворит.
Программа на Го компилируется в один бинарник. Можете скомпилить бинарник на своём макпро, зааплоадить на сервер под линукс и там запустить. Никаких зависимостей!
Зависимости появились не на пустом месте, а статическая линковка как была 30 лет назад так никуда и не делась.
Статические типы. Ошибки отлавливаются на этапе компиляции.
Не все, не всегда. Опять же статические типы данных далеко не нововведение.
Го быстрый. Потому что компилится в исполняемый код целевого процессора.
Вот эту часть не понял совсем. Дпя процессора? Язык со сборщиком мусора? Что-то я не видел приложений на го под AT.
Для работы с веб в Го достаточно стандартных пакетов из коробки.
Выше уже ответили.
Для Го есть не только плагины к IDE, но и отдельные IDE.
Это вообще какое отношение к языку имеет?
PS. И что же мы имеем в сухом остатке от этих «удобств»? да ничего.
PS. И что же мы имеем в сухом остатке от этих «удобств»? да ничего.
Похоже (чисто по подобным постам), что имеем C с ссылками на структуры данных вместо указателей на память, со сборщиком мусора для этих структур и каким-то подобием или реализацией зеленых потоков.
Ну, в целом примерно так и выглядит. Более-менее нормальная реализация корутин с сегментированным стеком и неблокирующаяся стандартная библиотека. Вот дёрнуть что-нибудь сишное и блокирующееся в go может быть фатально.
a, _ := foo() или _, err := foo()
- Только если специально постараться, иначе будут зависимости на libpthread, libc и ld.so, как минимум. А если используется что-то не из нативных библиотек, то может быть нереально собрать статический бинарник вообще.
- Ага, и
interface{}как самый статический используется регулярно. И ошибка "отлавливается" на этапе компилирования путём вставки в код if'а с паникой, если что-то пошло не так в рантайме.
3.1. Компиляция в бинарник ещё ничего не гарантирует. Можно собрать в один бинарник какой-нибудь интерпретатор и в соседнюю секцию положить код для интерпретации.
3.2. Компилируется код абстрактного процессора, в документации даже сходу не находится какого. Т. е. под какую архитектуру собирать (march/mcpu, если говорить про gcc), какие наборы команд включены (sse4.2/avx/avx2), какие оптимизации включены и пр. Откуда узнать, что он собрал под, скажем sandy+, а не под core2+? - Почему же тогда народ и в go, и в python тащит внешние библиотеки для веб-приложений? И там, и там достаточно стандартной библиотеки.
- Каким боком это является аргументом — не понятно. И для python'а есть отдельные IDE, и что?
Каким боком это является аргументом — не понятно. И для python'а есть отдельные IDE, и что?
Справедливости ради, у молодых языков с поддержкой IDE может быть плохо. Вот только я не уверен, что у Go всё прямо так шикарно в этом плане. Ну есть плагины и Gogland от джетбрейнс, которая ещё не зарелизилась.
Отлично (без сарказма), но тогда тем более странно преподносить наличие ИДЕ как преимущество.
В Гоу всё в одном файле, понятия "проект" не существует?
По большому счёту папка src, а внутри папки с исходниками разных частей.
о) Хватает редактора с подсветкой
А вы писали проекты, в которых больше 1000 строк кода на Гоу?
Разбиваем пакет на несколько файлов, просто внутри будет один оператор
package xxx
а содержание разное.
Я обычно делаю два-три файла на пакет, в одном у меня то над чем работаю сейчас, а в других файлах уже отлаженные части етого пакета.
А Го умеет собирать пакет из нескольких файлов.
Ну, ссылка "5 Reasons Why We switched from Python To Go" намекала на сравнение с python'ом, который молодым языком назвать сложно.
отличии от Go, в котором есть сборка мусора.
А отключить Сборщик Мусора (как в C#) возможно?
Нет дженериков (универсальных шаблонов. — прим.перев.).
Всё, что вам придётся сделать, это написать лишь на 2-3 строчки больше. Но зато, с другой стороны, это сделает ваш код более чистым и понятным.
Не представляю реализацию мат.библиотеки: vec2, vec3, vec4, mat3, mat4, quat, для разных типов, хотя-бы float и double, с оверхедом всего-лишь «в пару строчек» ))
Вам так сложно скопипасть кусок кода для каждого типа или сгенерировать код? Ну и пользователи библиотеки могут сделать то же для своих типов. /sarcasm
Вобщем такая гипертрофированная кнопка «убить всех».
Но реальная жизнь не терпит женериков, поетому женерики не нужны.
Абстрактный класс предполагает какую-то реализацию по умолчанию, интерфейс же — нет.
Это несущественное различие, различие скорее в реализации. Я бы сказал не функциональное. Потому что от того, что мы объект а.к. можем создать, он не становится полезным, это лишь пара полей для VMT в памяти.
Нет, я имею в виду, что:
- в абстрактном классе может быть свое состояние, причём даже скрытое от наследника
- в абстрактном классе могут быть дефолтные реализации методов, которые можно переопределить
- в абстрактном классе могут быть методы, которые вообще нельзя переопределить
- в абстрактном классе могут быть методы, использующие позднее связывание
В интерфейсах же могут быть только абстрактные методы, которые мы должны переопределить.
Почему вам стоит изучить Go?