Первый стабильный релиз Go

Ты так говоришь, как будто это что-то хорошее.

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

Нет, я конечно понимаю, что низкоуровневое программирование ЧСВ повышает

Заметь, про ЧСВ ты заговорил, для меня системное программирование это просто очень интересное ремесло приносящее мне доход.

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

Нет, пока не вижу.

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

Ну молодцы раз не течёт. Но зачем другим тратить время на ручное управление памятью?

недоучкам выдавать свои поделки за нечто годное

Нет, пока не вижу.

Правда?

такс

как ваш коллектив сохраняет когерентность в использовании памяти?

Анонимусы лора учат создателей UTF-8 Пайка и Томпсона делать уникод правильно.

А!! Так вот кто эти дебилы.... я-то думаю, что за му**ак взял кириллицу и сунул её БЕЗ СОРТИРОВКИ!! Теперь вместо тривиального сравнения кодов нужно вызывать специальную магическую^W функцию, которая внутри себя через жопу и хардкод выдаст, что 'а' < 'ё'!
Не говорите больше о юникоде, это ещё блевотнее, чем win.exe в autoexec.

я-то думаю, что за му**ак взял кириллицу и сунул её БЕЗ СОРТИРОВКИ

Это не они, они только придумали как юникод закодировать. Другой вопрос, что в UTF-8 переменная длина символа и спец функции всё-равно нужны :-)

Внезапно, такой язык уже есть, это --- D2

+174. Но ведь D сделали не в Гугле! :) А такая большая корпорация не может не иметь собственный говноязычок, иначе она так и останется «успешным поисковиком».

И что смешно, Гугл похож на банду студентов-головастиков, которым всё-равно что писать - лишь бы был гениальный код! Хотя индустрия остро нуждается в светлых умах на улучшение действительно нужных вещей - Minix, D, Motif, даже СУБД ещё хорошей не придумано - mysql и postgres - лишь раздутые наколенные поделки.
Вощем, Гугл опять «гугльнул в лужу». :)

...Другой вопрос, что в UTF-8....

Это было переходное решение. Зачем этот маразм было затевать в UTF-32?!?!

на каждый malloc свой free не забывать

В принципе, это даже не так сложно, если не забыть один раз инициализировать все указатели NULL'ём. Тогда можно перед каждым присваиванием вызывать free.

Сложнее становится, когда на одно место в памяти ссылаются из нескольких мест. Тогда нужно вводит учёт этих ссылок (ref/unref как в gobject).

Да и malloc/free - это не такой уж низкий уровень: ведь учёт кучи можно реализовывать по-разному, как и существуют разные подходы к сборщику мусора.

Сборщик мусора считается непредсказуемым, но он в отличие от malloc/free может оптимизировать распределение памяти и препятствовать её фрагментации. А так если очень часто ручками дёргать malloc/free не упадёт ли производительность работы с памятью?

В glib есть idle_func. Вот в такой ситуации и можно было бы дёргать сборщик мусора/оптимизатор.

Почему такая неюниформенность синтаксиса? Сишкавыродки не могут в языковой дизайн?

package main (без кавычек)

но

import «fmt» (<- в кавычках)

import может иметь ещё следующий вид:

import "launchpad.net/mgo/bson"

pp := (<- с двоеточием) new(Point); (<- точка с запятой)

":=" краткий вариант присваивания с объявлением переменной

";" (точку с запятой) можно отпустить

iv = (<- без двоеточия) pp (<- уже без точки с запятой)

переменная iv значит до этого уже была объявлена и ей можно присваивать значения

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

Сложнее становится, когда на одно место в памяти ссылаются из нескольких мест. Тогда нужно вводит учёт этих ссылок (ref/unref как в gobject).

А лучше использовать сборщик мусора: нет необходимости следить за циклами в ссылках, операции ref/unref не бесплатные и могут негативно сказаться на производительности, да и удалять объекты лучше не по отдельности.

Но ведь D сделали не в Гугле! :) А такая большая корпорация не может не иметь собственный

Тут надо смотреть не на то, что Гугл сделал, а на то, кто именно разрабатывал язык. Гугл просто помог претворить идеи разработчиков B, C из Bell Labs, к которым присоединились другие талантливые люди, в жизнь.

Если D - это новый C++ без обратной совместимости. То Go - это, насколько я понимаю, C, если бы он был создан в наши дни, где на компилятор и среду исполнения благодаря наработкам за прошедшие десятилетия удалось переложить дополнительные операции, ранее кодируемые вручную.

я тут пытаюсь уменьшить в размерах программу в 10 Кб, а они тут на хелловорлд несколько мегабайт тратят

А если так попробовать?:

package main

func main() {
	println("хелловорлд!")
}

";" (точку с запятой) можно отпустить

Это «мегафича» появилась ещё в фортране 90, если не ошибаюсь, 77 знаю слишком плохо. Потом её удачно спёрли в Питон.

То Go - это, насколько я понимаю, C, если бы он был создан в наши дни

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

В этом Го 50% синтаксиса из него

Да и malloc/free - это не такой уж низкий уровень

Это уровень libc, на системном уровне у тебя есть по большому счету только sbrk(2).

А так если очень часто ручками дёргать malloc/free не упадёт ли производительность работы с памятью?

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

Этот вопрос универсален, его можно задавать до бесконечности. Примеров успешного перехода с С на Java полно, при этом обратное уже не верно.

У тебя какие-то проблемы с пониманием и логикой))

Не у меня.

Я как раз и прошу объяснить на что ты ответил «нет».

Еще раз, для тормозов: тебе отказано в просьбе.

Примеров успешного перехода с С на Java полно, при этом обратное уже не верно.

Света один раз дала по пьянке, но не удачно, вернуться обратно в коллектив девственниц, ей мешала подписка КГБ.

Иди сладенького поешь, чтоб меньше злиться)

Релиз — это хорошо. А GUI на сабже писать можно? Хоть что-нибудь простое, вроде:

#include <QApplication>
#include <QLabel>
int main(int argc, char *argv[])
{
  QApplication app(argc, argv);
  QLabel label("Hello, LOR!");
  label.show();
  return app.exec();
}

PS: язык плох хотя бы тем, что гуглится он хреново.

САБЖ не нужен, ИМХО

Говорить «не нужно», может быть, увлекательно, но совершенно бесполезно без хотя бы поверхностного знания языка.
Читни http://golang.org/doc/effective_go.html

А GUI на сабже писать можно?

Можно:
http://mattn.github.com/go-gtk/
https://github.com/norisatir/go-gtk3

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

гугли как golang, иногда помогает

я недостаточно умён что бы писать на С++

а на русском? Уж простите )

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