Вышел Go 1.5

Жиденько. Чем именно коллекции в go убоги?

Нет списков и множеств. Нет map/filter/reduce.

Видел я этот костыль сто раз.

Вышел Go 1.5 (комментарий)

Без нормальных дженериков чего-то лучше ждать не приходится.

Ставишь собственно Nim, затем nimble, затем

>nimble update
>nimble install sdl2
>nim -d:release -d:ssl -d:useSysAssert -d:useGcAssert --threads:on c life.nim
>./life

Если что-то пойдет не так или будут вопросы - задавай)

Не флейму ради, но Go как раз исправляет родовой вывих C с объявлением переменных. Привычный да, но кривизна же явная.

чеоо?

Удивляет массовое фапание на Go в последние пару лет. Ну примитивщина же неудобная и невыразительная. Полтора шага от C, и вдруг столько восторгов. Томпсон и Пайк конечно уважаемые дядьки, но кажется провели лет 30 в анабиозе...

И что хипcтота в Go нашла? Понятно было с Ruby, JS - такая сексуальная альтернативщина. А этот топор им чем приглянулся?

А этот топор им чем приглянулся?

Тем что это топор? Не всё же выбирать для рубки дров между бензопилой и швейцарским ножом.

> А этот топор им чем приглянулся?
Тем что это топор?

Ага, новейший топор с перламутровой ручкой. Видимо в этом дело.

Ага, новейший топор с перламутровой ручкой. Видимо в этом дело.

Таки нету большого выбора топоров. С — это что-то боевое, чем слишком легко порезаться, java — тяжелей и в рантайме, и для кодера (в общем и среднем мощнее, но всегда ли топор надо заменять «универсальным режущим инструментом»), скриптовые языки — ну это совсем из другой области, скажем — газонокосилка, а никакой не топор. Из всего прочего зоопарка я что-то тоже претендентов на нишу Go не вижу. Pascal/Oberon? Ну не смешно…

d, nim, sbcl, rust - это из тех, что на слуху. Еще наверное десяток «безвестных» (читать как «без раскрутки корпорациями»)

Вон, вольфрам, казалось бы какой узкий нишевый продукт, а из-за грамотного пиара постоянно всплывает то тут то там

Современное состояние Си можно сравнить с дёгтем на асфальте, который НИКАК не удаётся удалить.

Почему то сразу вспомнилось про ядро. Походу его пишет кучка идиотов, ага!

d, nim, sbcl, rust - это из тех, что на слуху. Еще наверное десяток «безвестных» (читать как «без раскрутки корпорациями»)

Да всё это понятно, но топора тут нет. То есть языка, простого как мычание, понятного любому мейнстримовому программисту и надёжного как топор. Достаточно эффективного и ориентированного на бэкэнд. Rust явно из другой оперы. D, как улучшенный C++ — примерно из той же, что и Rust. SBCL в той же нише, но его плюсы и минусы в том что он Лисп. Nim — интересен, и да, где то рядышком, но по первому впечатлению той простоты изучения уже нет. Ну и да ждём версию 1.0. А так Dependent ML / ATS вроде тоже на данную нишу претендует (надо будет пощупать)

Вон, вольфрам, казалось бы какой узкий нишевый продукт, а из-за грамотного пиара постоянно всплывает то тут то там

Пиар да, знатный. Но после 100500 статьи на хабре про веб-серверы и прочую непрофильную ерунду на нём, хочется забыть про такой продукт. Кстати в той же нише есть хороший открытый продукт, как Julia, хотя там в силу молодости наработок меньше, конечно.

Спасибо! Попробую.

лапша из if/elseif/elseif/else

Специально для тебя.

Специально для тебя.

Очевидно пример был неудачен, но это ж не повод шланговать.

Очевидно, пример был неудачен, но это ж не повод шланговать.

Очевидно, стоит привести удачный пример.

Не замечаю явности этой кривизны, прошу пояснить вкратце.

Может я и прогнусь «под рынок труда» однажды и буду писать на Go, хотя мне пока достаточно возможностей Qt/C++, где я не использую явное управление памятью, в моих программах нет new/delete...

сразу вспомнилось про ядро. Походу его пишет кучка идиотов, ага!

Его пишет куча старперов с детской травмой от переписывания ядра на Си++ 25-летней давности.

языка, простого как мычание, понятного любому мейнстримовому программисту

Go не простой, а именно примитивный. Дизайн очевидно наколеночный. Делали примерно так: нужен C со сборкой мусора - ок, а вот еще бы хэшмапы как в питонах - ладно, прибили гвоздями к компилятору. ООП? Вот вам интерфейсы, ну что смогли. Генерики? Ой, тут че то не получается, звиняйте. Вот и все, приехали. Зачем нам обобщенные коллекции, правда. Будем как диды массировать массивы циклами. И т.д. и т.п. Все это мне напоминает «дизайн и эволюцию» PHP.

Ты применил очень хороший демагогический приём — «завалим собеседника кривыми аналогиями, авось он запутается и ему станет труднее отстаивать свою позицию». Вот кто сказал, что C/C++ это «пещеры»? Кто сказал, что Go это «комфортабельный дом»? Это ты сейчас всё придумал.

ITT царя привезли от бабушки в деревне, а школа ещё не началась.

Генерики? Ой, тут че то не получается

Им не нравятся существующие реализации, причем тут «не получается»? А придумать чего получше пока, действительно, не получается...

Это я не к тому что бы кого-то завалить. И даже не к тому что С[++] это пещеры, а Go это убийца или панацея. Я к тому, что развитие человечества устроено так, что просто необходимо открывать и разрабатывать что-то новое. Часто что-то новое, на момент своего появления, уступает старому но отработанному (дескать стабильному). Но если в это новое вложить времени хоть половину, которого вложили в старое - оно расцветёт, и цвет его затмит старый строй. Хотя статистика говорит о том, что далеко не каждый такой случай обречён на такой сценарий, но сказать что «у нас есть С[++], и к большему просто незачем стремиться» - это просто похоронить индустрию.

PS: надеюсь все понимают что это всё только о «разговорах за чаем с печенецем да перед потрескивающим камином»

PPS: не утверждаю что именно Go это то самое «новое», просто о том, что не следует самих себя сажать в оковы бесперспективности

PPPS: но при этом Go мне очень по душе, работа с ним вызывает у меня только удовольствие; и как минимум потому что его неудобства для некоторых задач, просто приводят к мыли о необходимости выбора более правильного инструмента (и это позиция самого языка и его сообщества), а не к страданиям и сизифовому труду, с которым почти всегда сталкиваются адепты '«я могу всё» С++', скажем

Поддерживаю Ваш позыв. Если человечество не станет разрабатывать новое то просто прогресс остановится. А когда останавливается прогресс неизменно начинается регресс.

ОМГ, на лоре новый луговский вылупился. Только старая версия была куда лучше.

Перестаньте кормить царя, его и так слишком много.

Не замечаю явности этой кривизны, прошу пояснить вкратце.

Дык см. Вышел Go 1.5 (комментарий)

Лень мне объяснять очевидный факт, что объявления в C - это вывих мозга. Привыкнуть можно, а если с C начинать, легко поверить что так и надо… Откройте хороший учебник C/C++ и помедитируйте над главой про то, как эти объявдения читать

Компания Docker пишущая на Go — вошла в число компаний со стоимостью, превышающей миллиард долларов США.

Прикладное баззворд-строение?

d, nim, sbcl, rust

Ним и раст моложе и сырее (особенно первый) чем го, если что.

У одного имбецила синдром Туретта, требует всё ему доказывать и показывать профит того что он не понимает. Другие в ответ пытаются использовать все слова которые знают.

Интерпритатор и компеляция.

Интерпритатор и компеляция.

ох… это да… я начитавшись этого птичьего языка уже написал сингатура вместо сигнатура… пестьня…

ох… это да… я начитавшись этого птичьего языка уже написал сингатура вместо сигнатура… пестьня…

А что если в этом и был весь глубокий посыл? Испортить лор :D

Царя ссаными тряпками из девелопмента выгнали, так он теперь простому люду с главной проповеди устраивает.

Царь, ты еще на пхп.ру куда-нибудь зайди - вообще звездой станешь.

Ну чо, царь опять всех победил? Или где там?

Подебил, подебил.

Вот много споров было про вузы, про уровень преподавания, стоит ли туда идти и т.п. Похоже, что очень даже стоит, пусть даже и в заборостроительный.

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

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

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

Школьным царям, анонiмусам и спуфингам этого никогда не понять.

Отличный пост. По теме - ещё можно погуглить Blub paradox.

Царь феерический идиот. Берется рассуждать о том, в чем ни хрена не смыслит. Кобол появился во времена мейнфреймов и перфокарт, какие домохозяйки? Дальше его бред не читал.

Дженерики на Go: https://youtu.be/KY8OXFi3CDU

Вот это манямир.

Спасибо, поржал.

facepalm.jpg

бессмысленный фейспалм.

Python вполне масштабируется с помощтю multiprocessing

еще раз и по буквам: в традиционных скриптовых языках нет нормального мультитрединга/мультипроцессинга. Ибо парадигма языка не дает его сделать нормально.

читайте про ваш питон вот отсюда: https://docs.python.org/2/library/multiprocessing.html

там сразу идет отсылка вот сюда: https://docs.python.org/2/glossary.html#term-global-interpreter-lock

вкратце ситуация следующая. если в Pyhton, Perl, и прочие подобные языки всунуть мультипроцессинг/мультитрединг и оставить синтаксис такой какой он в них есть, то у тех, кто пишет язык всего два выхода: или вешать лок внутрь каждой переменной или вешать глобальный лок. и тот и другой подходы - ущербны. Без изменения языковой семантики других выходов нет.

в итоге во всех языках мультитрединг/мультипроцессинг «как бы есть», но реально везде отключен и не используется. а в реальных приложениях используют обычный юниксовый fork/exec с юниксовыми IPC.

Если говорить о других выходах масштабирования по CPU, то с изменением семантики языка они доступны. Например отказ от переменных как таковых (Erlang) или внесение единицы исполнения в язык (Go).

Go (можете фейспалмить сколько влезет) - это попытка всунуть масштабирование по CPU в язык.

читайте про ваш питон вот отсюда

вкратце ситуация следующая

Бгг. Ты мне будешь о Python рассказывать? Ну ваще офигеть.

если в Pyhton, Perl, и прочие подобные языки всунуть мультипроцессинг/мультитрединг

Для начала научись не путать язык и его реализацию.

всего два выхода: или вешать лок внутрь каждой переменной или вешать глобальный лок

Или использовать STM.

в итоге во всех языках мультитрединг/мультипроцессинг «как бы есть», но реально везде отключен и не используется. а в реальных приложениях используют обычный юниксовый fork/exec с юниксовыми IPC.

multiprocessing _и есть_ fork, всегда был, это никогда не скрывалось. И сделано оно так из-за ограничений конкретной реализации - CPython. Никто не отказывается от multiprocessing ради fork и IPC.

И да, multirocessing хорошо масштабируется.

Go (можете фейспалмить сколько влезет) - это попытка всунуть масштабирование по CPU в язык.

С этим никто и не спорит. facepalm относился к «событийно-ориентированной парадигме программирования». Кстати, расскажи о ней побольше - я думаю, будет весело.

Ты мне будешь о Python рассказывать? Ну ваще офигеть.

учись, студент, никогда не поздно

Для начала научись не путать язык и его реализацию

еще раз: для реализации мультитредов в семантике традиционных языков пока придумано только два выхода: множество локов (в каждой переменной/функции) либо глобальный лок.

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

multiprocessing _и есть_ fork, всегда был, это никогда не скрывалось. И сделано оно так из-за ограничений конкретной реализации - CPython

не ограничения конкретной реализации, а невозможность реализации в рамках семантики языка.

С этим никто и не спорит. facepalm относился к «событийно-ориентированной парадигме программирования». Кстати, расскажи о ней побольше - я думаю, будет весело.

дык сходи почитай. просветлись. начни отсюда: https://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование

вкратце: мютексы оч плохо по CPU масштабируются. а передача евентов и очереди - очень хорошо. передача евентов и очереди - это событийная ориентация. в Go это - каналы между горутинами.

для реализации мультитредов в семантике традиционных языков пока придумано только два выхода: множество локов (в каждой переменной/функции) либо глобальный лок.

CSP можно реализовать в любом языке. Есть реализации для Python, Java, Си++ и еще хз скольких «обычных» языков, а ты носишься с Go, как дурень с писаной торбой.

в итоге во всех языках мультитрединг/мультипроцессинг «как бы есть», но реально везде отключен и не используется. а в реальных приложениях используют обычный юниксовый fork/exec с юниксовыми IPC.

multiprocessing _и есть_ fork, всегда был, это никогда не скрывалось. И сделано оно так из-за ограничений конкретной реализации - CPython. Никто не отказывается от multiprocessing ради fork и IPC.

в продакшенах будут использовать обычные юниксовые форки и ipc. а не твои мегареализации

Мде. Трудно, наверное, не уметь читать?

facepalm относился к «событийно-ориентированной парадигме программирования». Кстати, расскажи о ней побольше - я думаю, будет весело.

дык сходи почитай. просветлись. начни отсюда: https://ru.wikipedia.org/wiki/Событийно-ориентированное_программирование

Ох ты господи, ссылка на русскую Вики по компьютерному вопросу... ну да ладно:

«парадигма программирования, в которой выполнение программы определяется событиями — действиями пользователя (клавиатура, мышь), сообщениями других программ и потоков, событиями операционной системы (например, поступлением сетевого пакета)»

Изложение этой «парадигмы» занимало 15 минут на лекции 25 лет назад. И использовалась «парадигма» аж для программирования 16-битовой венды. На Си, ага %)

мютексы оч плохо по CPU масштабируются.

А это смотря как их использовать. Ядро построено на локах и мютексах, при этом нормально масштабируется. И, прикинь, CSP тоже построен на мютексах.

ссылка на русскую Вики

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

Изложение этой «парадигмы» занимало 15 минут на лекции 25 лет назад.

ВСЕ парадигмы программирования разработаны более 25 лет назад. за все эти годы в IT НИЧЕГО нового не появилось. Python не дал никакой новой парадигмы, Ruby не дал никакой новой парадигмы. только мода и жажда разрабов написать еще один язык программирования.

это жизнь. кстати то что предлагает Go, тоже было до него.

это смотря как их использовать. Ядро построено на локах и мютексах, при этом нормально масштабируется. И, прикинь, CSP тоже построен на мютексах.

во, оно еще и по ядру специалист оказывается.

У меня большие сомнения, что писуны, постоянно нуждающиеся в каких-то рамках, напишут что-то хорошее. Я бы к своим проектам таких людей не подпускал, а вы?

Был опыт работы в команде по разработке на С++. У нас куча времени ушло, но то, чтобы договориться какой стиль форматирования использовать и какой туллчейн, как это всё будет настроено, чтобы можно было выявить проблему на этапе сборки и т.п. Я бы с удовольствием тогда перешел бы на Go или Python, только потому, что там есть стандарты и правила, когда можно ткнуть человека в PEP8 или в оф. доку, где написано как надо форматировать код. А то выходит, что один учил С++ по книгам Дейкстры и у него такое форматирование, другой пишет в BSD стиле и т.п. Кому то удобнее писать в Eclipse, другому QtCreator, а один отщепенец вообще только в виме пишет.

С четкими правилами и рамками проще нанят людей менее квалифицированных и создать их них команду, чем причесывать группку таких вот «экспертов», у которых всё своё и непохожее друг на друга, а для контроля качества существует немало различных техник.Тем более если основной язык разработки к таким рамках и стандартам располагает(в отличие от С++).

И отвечая на вопрос - да, при правильном руководстве, можно справиться и без команды супергероев.