>> Сравнивать с С и С++

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

Хм... Вот tcl - это шедевр. Такой кривизны больше ни у кого не видел. Остальные вряд ли будут шедеврами.

:)

Вот почта автора книги:
miek@miek.nl

Подскажите этому доброму человеку, как сделать оформление книги лучше.

Ага. Уже сделал биндинг для libogg.
А разве так не во всех языках делается?

Некоторые идут другим путём :)
http://www.linux.org.ru/news/java/4977007

Ну так а примеры хоть одной из сильных сторон гоу по сравнению с джавой будут? Хоть в чём нибудь?
1) ООП может быть лишним только для тех, кто его не осилил.
2) Производительность у Гоу никакая. Тем более она никакая по конкурентной обработке данных, там джава местами нахлобучивает си.
3) Плохая кроссплатформенность. Под каждую платформу нужен отдельный бинарник. Поди чей ещё и работает один код на разных платформах непредсказуемо. В джаве это отточено
4) У джавы - целая огромная инфраструктура, под неё есть всё.
Короче я пока не вижу ни одного преимущества, одни недостатки.

Эх, лучше бы гугловцы вложились в разработку языка D. Лично мне он видится отличной заменой Си++ без недостатков последнего.

Просто для Жабы были реализации.

>по крайней мере не надо управлять памятью ручками

вот, не в обиду Java, но лучше никакой Garbage Cleaner, чем такой как в Java. Я уж как нибудь по старинке сам разберусь что мне нужно от памяти и когда мне перестанут быть нужными переменные

> 1) ООП может быть лишним только для тех, кто его не осилил.
Аргумент в духе «сам дурак». Удачный ход, но не по делу.

2) Производительность у Гоу никакая. Тем более она никакая по конкурентной обработке данных, там джава местами нахлобучивает си.

Это вопрос реализации.

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

Согласен, тут она в плюсе.

4) У джавы - целая огромная инфраструктура, под неё есть всё.

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

Из удачных моментов в Go:
* обработка ошибок. Мне понравилась очень.
* прозрачные динамические массивы (через слайсы), хеши.
* каналы просто шикарны.
* Необычная но довольно не плохая реализация модульности и методов (функции относящиеся к struct)

Мне кажется писать всякие сервера на Go намного удобней чем на Java. Язык намного более лаконичный чем Java.

«У нас» на ТНТ рекламируют сайты дома-2, предлагают скачать выпуски камеди клаба и т.д. Так что «типичный» телезритель вполне бывает в интернете и реклама хрома и голосового гуглопоиска вполне уместна.

>а «Типичный телезритель» банально не вкуривает - о чем собсно в рекламме идет речь

Деда, вылазивай из окопа - 90е уже 10 лет как кончились

>Из удачных моментов в Go:

Слушай, еще немного и они изобретут Перл! А может даже Руби! А может даже Пайтон! А может си-диез!!!

>> Из удачных моментов в Go:

Слушай, еще немного и они изобретут Перл! А может даже Руби! А может даже Пайтон! А может си-диез!!!

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

>даже VP8 ?

Ненужен вдвойне так как велосипед

Пока они изобрели АЛГОЛ68

Пока они изобрели АЛГОЛ68

Т-с-с, Brand X, же!

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

чувак у тебя с аваратки, герой из халфлайфа же

Не правильное название для учебника по языку Go, более подходящее «Learning Junk».

JAVA, Go, C# все это называется одним емким словом Junk.

а что тогда не junk?

За все языки не скажу, я всех не знаю :) Но, по сути, язык С (иногда плюсы) как был основным языком программирования так до сих пор и остается. Все новье годно лишь для рисования пользовательских интерфейсов. Что тоже, на мой взгляд, очень важно.

>привязки к БД и простенькие веб-фреймворки
Это, конечно, интересно, но этим может похвастаться почти каждый язык программирования. Что-нибудь еще интересное?

go

не нужно. есть Lisp

fixed

C/C++ советы для начинающих В этой статье речь пойдет о таком языке программирования, как C/C++. Мы поговорим с Вами о том, как правильно выбрать методологию разработки для C/C++, как обсудить это со своим партнером по парному программированию и затронем еще много интересных вещей. Культура программирования C/C++ основана на ролевых играх в господство и подчинение, но в такие игры нужно играть очень осторожно. Потому как подобные развлечения предполагают использование специальных техник программирования, способных принести не только принести удовольствие от написания кода, но также боль и реальные травмы. Программирование на C/C++ включает в себя оскорбления и физическое насилие, поэтому очень важно, чтобы все происходящее за монитором, сначала было самым пристальным образом спланировано. Все приемы программирования, которые предлагает C/C++, должны сначала обсуждаться и утверждаться обоими партнерами. Вот несколько советов, которые могут пригодиться начинающим: Необходимо полностью довериться Вашему партнеру по парному программированию Парное программирование на C/C++ должны проводиться с людьми, которых Вы очень хорошо знаете. Кроме того, Вы должны быть в очень хороших отношениях на момент написания кода. Вы также должны быть очень хорошо осведомлены о предпочтениях Вашего партнера: узнайте, что ему нравится, а что не очень. Не перестарайтесь При программировании на C/C++ очень важно не «перегибать палку». Допустим, Вы используете кнут. Убедитесь, что начинаете порку с несильных ударов, и только с разрешения Вашего партнера увеличивайте силу и интенсивность. В противном случае, Вы можете нанести травму партнеру. Перед тем как что-то сделать, сначала определитесь Никаких неприятных сюрпризов! Советую все обговорить с Вашим партнером, потому что Вы можете думать о совершенно разных вещах во время программирования. Когда речь идет о C++, Вы должны точно знать, что происходит в голове Вашего партнера. Поэтому, прежде чем пускать в ход руки, согласуйте между собой все физические и моральные аспекты. Если что-то пошло не так, как Вы планировали, тогда Вам следует все обсудить со своим партнером, чтобы понять причину недоразумения, и чтобы в будущем, не повторять такие ошибки и чтобы все проходило на высшем уровне. Тише едешь - дальше будешь Погружаться в мир развлечений C/C++ нужно не спеша. Поверьте, так намного проще познать этот вид удовольствия. Интенсивность следует наращивать постепенно с течением времени. Не стоит сразу бросаться в омут чувств и возбуждения, тем более, если Вы еще не готовы к этому, как в физическом, так и в моральном плане. Такая спешка может повлечь за собой кучу проблем и неприятных моментов. Ваш партнер должен идти в ногу с Вами. Помните, всему свое время! При занятиях парным программированием на C/C++, обычно, один партнер исполняет доминирующую роль (господин), а другой, роль - покоренного (раба). Именно рабы испытывают большую уязвимость в этих сексуальных играх. Это чувство усиливается, если Вы завязываете ей (ему) глаза, используете кляп или наручники. Я бы посоветовал не прибегать к подобным игрушкам при первых занятиях C/C++, пусть Ваш партнер привыкнет к своей роли и психологически настроится, это только пойдет на пользу Вам обоим. Это лишь некоторые советы для начинающих любителей C/C++. Ваши познания в C/C++ будут расти по мере Вашего продвижения вперед и освоения этой культуры программирования. Удачи!

оказывается, есть такой язык

Не разберешься. Представь, что тебе нужно освободить, например, сразу большое дерево или хеш-таблицу. С ручным управлением ты надолго встанешь, пока все не будет вычищенно. Автоматический GC же подберет аккуратно, малыми порциями, не останавливая ни разу исполнения надолго.

> ...в этих сексуальных играх.

Эх, анонимус-анонимус! Одной фразой всю шутку загубил((( Внимательнее надо было править.

Продолжай Вjaveвать . go не для тебя

Go проще жабы и особено жабы2. раскажи о том как прекрасно обмазыватся инер класами.

Наследование - та ещё радость

а про ООП: Алан Кей не знал про С++(Java) когда ООПил

да и вообще в языке где тока статическая типизация ООП не есть инструмент облегчения жизни.

Го это императивные ноды и CSP-Хоара промеж нод. «британские маркетологи» обещают что если модель CSP хорошо ляжет на многоголовость то тормоза в 1.3 раза на ноде по сравнению с убероптемизированым С будет компенсироватся дешёвой ценной размазывания кода по ядрам.

у godoc литературное программирование с меньшей бюрократией чем у жабы с @javadoc

тоталитарный gofmt.

если сравнить что писал пайк в 1989 про С под plan9 обнаружится что go это С.

go который сам компилирует ща в x86,в amd64, в ARM ужастно кроссплатформен - да.

4) совершено верно . даже леденец.

зы. я Java не осилил - очень сложно.

Junk у вас в голове, сударь.

язык АДА вестимо.

> Нене, ссылки на cat-v.org - это прекрасно. Сразу ясен диагноз.

Правило демагога №123: «Если факты опровергают вашу теорию — попытайтесь дискредитировать их источник.»

> вот, не в обиду Java, но лучше никакой Garbage Cleaner, чем такой как в Java.

Garbage Cleaner

И этот человек позволяет себе с космическим апломбом рассуждать о Java internals.

>Даже древние версии Ворда намного эстетичнее pdf генерили.

Обычно продукт экспорта из «древних версий Ворда» страдает отвратительными ссылками в содержании/оглавлении [из-за слабой компьютерной подготовки пользователей].

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

Александреску

вменяемый

/0

> а что тогда не junk?

LISP, Haskell, Smalltalk, Brainfuck. Очевидно же.

> ссылки на cat-v.org - моветон
ЯП не мой, я просто разместил объяву.
Опять-таки, язык писал не гугл, язык писал Роб Пайк, который совершенно случайно работает в данный момент в гугле.
А cat-v это очень Пайк-релейтед.

tailgunner

cat-v вызывает у него острые приступы ДИСКОМФОРТА, так что его аргументы могут быть некорректны.

реализация тормозит!

Создатели языка следовали принципам простоты и создали маленькую реализацию без каких-либо особых оптимизаций. Они не хотели создавать нечто подобное GCC, huge'n'bloated и unhackable, превращающее процессор в чайник, жрущее сотни ОЗУ и генерирующее быстродействующий буйный бред. Они сделали всё гораздо проще.
Так что рекомендую вам сравнивать Go с чем-то вроде tcc, а не с буйволами опенсурса.

Анонимус, ВЫДЫХАЙ! :)))

> Обычно продукт экспорта из «древних версий Ворда» страдает отвратительными ссылками в содержании/оглавлении

Только если Вордом пользоваться на уровне секретарши, с форматированием пробелами и т.п.

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

Ну вот и какого хрена они его не сделали фронтэндом к GCC или LLVM? Глупая же отмазка, что мол некогда было монстра рожать. Монстров уже родили, можно тупо брать и пользоваться.

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

ЕМНИП речь шла о enterprise-языках. Ты уж извини, но Brainfuck - это эзотерика и for fun. Насчет остального - не уверен, но при достаточной ловкости рук использовать их в энтерпрайзе можно

а, и да - я не программирую на Java, я так сказать поматросил и бросил, ибо C++ роднее. так что могу себе позволить не знать специфику, а мое мнение по поводу этого языка следует читать как ИМХО и в случае откровенного идиотизма с моей стороны - не ржать, а поправить. В назидание...

Garbage COLLECTOR, никак не «cleaner». И ты явно в теме совершенно не разбираешься - в современных JVM GC продвинутее чем где бы то ни было.

Вот тебя и поправили, с примером про хэш-таблицу на 500Mb. Ты не просто в java и c++ не разбираешься, ты вообще плохо понимаешь, что такое memory management.

> 1) ООП может быть лишним только для тех, кто его не осилил.

Я осилил. Но так и не вижу, на кой хрен эта дурная цацка нужна. Может хоть ты расскажешь, раз такой вумный?

упс, вот это я лоханулся так лоханулся

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

В относительно большом проекте без такой удобной штуки как ООП очень напряжно. Нужно городить собственный костыль, если не используется ООП. Ну или иметь прокачанный перк пользования 10000+ функций, явно не связанных друг с другом

о Модульности.

«пространства имён» декомпозиция

мда ООП мозга.