The Go Programming Language
Я проснулся, а ты меня опередил.
Поскольку, гораздо больше знает о Ruby, чем о Go, дам краткую аннотацию. Go — это :
1. C-like язык, компилируемый в native code (поддерживаются x86, x86-64, ARM, native client-x86)
2. статически типизируемый, но с хорошим type inference. Т.е вместо
можно просто
3. сборщик мусора
4. duck typing: структура реализует интерфейс, если у нее есть нужные методы. Т.е. сама структура может и не знать, что есть такой интерфейс и что она его реализует.
5. очень быстрая компиляция (по сравнению с C++) за счет модульности и LL(1) грамматики.
6. встроенная поддержка unicode
7. легкие треды, примерно как в erlang. Т.е. можно запускать over 9000 goroutines.
8. Всякие нямки типа замыканий и tuples.
Этот язык внутри себя можно представлять как C, лишенный ряда недостатков и в котором не появилось новых. С другой стороны, Go имеет ряд неудобств, по сравнению с тем же C++. Например, нет исключений.
Основная цель, с которой делался язык: заменить C++ внутри Google. Собственно, поскольку исключения в C++ Google style guide запрещены, упомянутый недостаток не является аргументом против.
Заопенсорсили язык просто для приличия, я не вижу, кому он нужен снаружи.
Поскольку, гораздо больше знает о Ruby, чем о Go, дам краткую аннотацию. Go — это :
1. C-like язык, компилируемый в native code (поддерживаются x86, x86-64, ARM, native client-x86)
2. статически типизируемый, но с хорошим type inference. Т.е вместо
SomeLongTypeName a = new SomeLongTypeName("aalala");можно просто
a := newSomeLongTypeName("aalala");3. сборщик мусора
4. duck typing: структура реализует интерфейс, если у нее есть нужные методы. Т.е. сама структура может и не знать, что есть такой интерфейс и что она его реализует.
5. очень быстрая компиляция (по сравнению с C++) за счет модульности и LL(1) грамматики.
6. встроенная поддержка unicode
7. легкие треды, примерно как в erlang. Т.е. можно запускать over 9000 goroutines.
8. Всякие нямки типа замыканий и tuples.
Этот язык внутри себя можно представлять как C, лишенный ряда недостатков и в котором не появилось новых. С другой стороны, Go имеет ряд неудобств, по сравнению с тем же C++. Например, нет исключений.
Основная цель, с которой делался язык: заменить C++ внутри Google. Собственно, поскольку исключения в C++ Google style guide запрещены, упомянутый недостаток не является аргументом против.
Заопенсорсили язык просто для приличия, я не вижу, кому он нужен снаружи.
Собственно, поскольку исключения в C++ Google style guide запрещены, упомянутый недостаток не является аргументом против.очень странно... если верить кодегайду, эксепшены запрещены только для совместимости:
On their face, the benefits of using exceptions outweigh the costs, especially in new projects.Если на go пишется новый код (а как может писаться старый? =) то такой проблемы не стоит.
...
Things would probably be different if we had to do it all over again from scratch.
Новый код может использоваться старыми компонентам, поэтому exception-ы все равно не в тему будут.
Но вообще, мне тоже не понравился этот факт. Сделали они это для того, чтобы можно было легко потоки запускать, не боясь, что все упадет (т.е. проблемы, кто отвечает за исключение в потоке, не стоит).
Но вообще, мне тоже не понравился этот факт. Сделали они это для того, чтобы можно было легко потоки запускать, не боясь, что все упадет (т.е. проблемы, кто отвечает за исключение в потоке, не стоит).
Кто мне объяснит, почему гугол проводит политику на намеренное упрощение языковых средств. java ee обкастрировал, c++ вот тоже. Много полезного есть в предложенном языке, но отсутствие наследования меня удивляет своей неудобностью.
намеренное упрощение языковых средствс++ давно надо было обкастрировать. ещё в зародыше.
ну, упрощение языка, чтобы код был более поддерживаемым и больше свободы у компилятора. ты про это спрашивал?
компилятор - он же железный, чего о нём заботиться - удобство программиста важнее.
удобство последующих программистов ещё важнее, они не железные.
мне было предложено две причины
1. Удобство поддержки
2. Удобство компилятора
Я оспорил именно второй пункт, а не первый. С первым я не хотел бы делать никаких заявлений, пока не будет практических сведений о сложностей поддержки обоих языков: эта не та вещь, которую можно понять, только прочитав мануалы.
1. Удобство поддержки
2. Удобство компилятора
Я оспорил именно второй пункт, а не первый. С первым я не хотел бы делать никаких заявлений, пока не будет практических сведений о сложностей поддержки обоих языков: эта не та вещь, которую можно понять, только прочитав мануалы.
Кто мне объяснит, почему гугол проводит политику на намеренное упрощение языковых средств. java ee обкастрировал, c++ вот тоже. Много полезного есть в предложенном языке, но отсутствие наследования меня удивляет своей неудобностью.потому что у них другая задача, чем у другого мира.
у гугла задача - используя самых крутых программистов выжать максимум из того железа, что есть на "одной единственной задаче" - отсюда уменьшение удобства(упрощение/кастрирование) в пользу оптимизации кода
а у остального мира другая задача - с помощью обычных программистов упихать все многообразие постоянно появляющихся задач в железки.
соответственно, гугл - оптимизируют использование железа
остальные - оптимизируют использование программистов.
нифига ты не оспорил, когда компилятор рожает код несколько минут начинаются неудобства уже у программистов.
соответственно, гугл - оптимизируют использование железаДо чего-то похожего я догадывался. Вот только гугловский app engine используется уже не только гугловскими программистами, но и обычными тоже.
остальные - оптимизируют использование программистов.
До чего-то похожего я догадывался. Вот только гугловский app engine используется уже не только гугловскими программистами, но и обычными тоже.но так все равно они же инструмент под себя затачивают, отсюда и такие родимые пятна.
отсутствие наследования меня удивляет своей неудобностьюво-первых в некотором виде наследование есть. Можно сделать так (могу ошибиться в деталях):
type T struct {
field int;
}
func (t *T) doDomething {
}
type U struct {
T;
...
u := &U{1};
u.doSomething;Во-вторых, в Go мегаклевые интерфейсы, которые решают те задачи, которые в C++ приходится делать через наследование (со всеми проблемами, которые приводят к множественному наследованию и непотребному употреблению алкоголя по прочтении кода).
u := &U{1};а скастить теперь обратно в U?
соответственно, гугл - оптимизируют использование железане согласен (сильно не согласен).
остальные - оптимизируют использование программистов.
Оптимизируется не железо, а скорость разработки и читаемость кода. Т.е. оптимизируют использование программистов.
Опять-таки: скорость компиляции оптимизировали, чтобы было меньше простоев.
Железо — его много и каждый год все дешевле.
а скастить теперь обратно в U?не понял. На случай, если не было ясно, что значит верхний код, вот его длинная запись:
var u *U = &U{1};когда компилятор рожает код несколько минут начинаются неудобства уже у программистовполная пересборка проекта нужна редко, а один изменённый файл (если он не километровый) компилируется быстро. Кроме того, в отладочном режиме есть build-and-continue (не помню, так ли называется пересборка приостановленной в отладчике проги при изменении кода).
Оптимизируется не железо, а скорость разработки и читаемость кода. Т.е. оптимизируют использование программистов.да, понятно - что это оптимизируют тоже.
но смотря на google docs - очень хорошо видно, что оптимизируется, например, скорость,
а не безбажность
т.е., например, на google docs - очень хорошо видно, что наследование не в чести у google-программистов.
и одна и та же функция вызываемая из разных мест - ведет себя по разному (с разным поведением, и с разными багами).
var u *U = &U{1};а почему тогда функцию для T можно вызвать? если тип до сих пор U, а не T?
Во-вторых, в Go мегаклевые интерфейсы, которые решают те задачи, которые в C++ приходится делать через наследование (со всеми проблемами, которые приводят к множественному наследованию и непотребному употреблению алкоголя по прочтении кода).классическое определение гласит, что ООП основано на инкапсуляции, наследовании, полиморфизме. Из всего перечисленного go интерфейсы реализуют только полиморфизм.
а почему тогда функцию для T можно вызвать? если тип до сих пор U, а не T?Потому что такой язык!
Из всего перечисленного go интерфейсы реализуют только полиморфизм.1. Не могу сказать за Роба Пайка, но лично мне пофиг на классическое определение ООП. Более того, я готов признать, что Go не ООП. На это мне тоже пофиг.
2. Есть инкапсуляция на уровне пакетов (т.е. то же, что и в Java, где private members доступны всем из того же пакета)
Потому что такой язык!и соответственно runtime-типизации нет?
т.е. например в функции doSomething нельзя попытаться привести к U?
и соответственно runtime-типизации нет?runtime типизация и reflection есть.
т.е. например в функции doSomething нельзя попытаться привести к U?
То, что ты хочешь - я не знаю, будет ли работать. Скорее всего, да. Но не пробовал.
да, понятно - что это оптимизируют тоже.как бы в Гугле больше 10k программистов. Не могу поверить, что все они одинаковые. И что Роб Пайк каким-либо образом связан с Google Docs.
но смотря на google docs - очень хорошо видно, что оптимизируется, например, скорость,
а не безбажность
т.е., например, на google docs - очень хорошо видно, что наследование не в чести у google-программистов.
и одна и та же функция вызываемая из разных мест - ведет себя по разному (с разным поведением, и с разными багами).
мы же говорим о политике компании в целом, а не о конкретных её программистах
как бы в Гугле больше 10k программистов. Не могу поверить, что все они одинаковые. И что Роб Пайк каким-либо образом связан с Google Docs.внутри компании обычно одна идеология, одна политика.
т.е. очень редко бывает,
что в одной группе, политика - самое главное скорость, и черт с мелкой неточностью в поведении,
а в другой группе - самое главное это точность поведения, и фиг с ней со скоростью.
причем для поисковика - самое главное скорость, и черт с мелкой неточностью в поведении (подумаешь пару документов не нашли)
и видно - что google docs - построен по этой же методике - все летает, но точности в поведении нет.
компилятор - он же железный, чего о нём заботитьсяважнее, чтоб он выдавал код оптимальнее.
при прочих равных, вроде как, более простой язык легче соптимизировать компилятору.
т.е. то же, что и в Java, где private members доступны всем из того же пакетаprotected
ух тыж шыт, там всё в юникоде, даже идентификаторы!
ух тыж шыт, там всё в юникоде, даже идентификаторы!есть какое-то оправдание, или необходимость делать обратное сегодня?
просто довольно необычно
листал слайды с Tech talk http://golang.org/doc/go_talk-20091030.pdf
и внезапно где-то посередине заметил Θ в качестве идентификатора =)
листал слайды с Tech talk http://golang.org/doc/go_talk-20091030.pdf
и внезапно где-то посередине заметил Θ в качестве идентификатора =)
и внезапно где-то посередине заметил Θ в качестве идентификатора =)согласен, необычно.
такие идентификаторы с одной стороны наглядные, а с другой - очень сложные для последующего ввода.
есть такой язык http://en.wikipedia.org/wiki/Brain_Fuck
и?
а по-моему в тему
ок
Так это... в жаве и сишарпе тоже так, и даже в питоне начиная с какой-тов версии, где вы были последние десять лет, удивляющиеся?
(хотя нет, про питон гоню, юникодные сурцы понимает, но переменные должны быть латинскими буквами).
(хотя нет, про питон гоню, юникодные сурцы понимает, но переменные должны быть латинскими буквами).
Так это... в жаве и сишарпе тоже таквот по опыту использования в C# нелатинских идентификаторов и утверждаю, что
нелатинские идентификаторы, употребленные к месту - с одной стороны наглядные, а с другой - очень сложные для последующего ввода.поэтому даже с поддержкой уникодный идентификаторов - все равно выглядит не обычным, когда встречается нелатинский идентификатор.
(хотя нет, про питон гоню, юникодные сурцы понимает, но переменные должны быть латинскими буквами).пистон 3.x вполне понимает переменные в юникоде:
work:~$ python3.1
Python 3.1.1+ (r311:74480, Oct 12 2009, 02:14:03)
[GCC 4.4.1] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> сказать_ура = lambda: print("Ура!")
>>>
>>> сказать_ура
Ура!
>>>
осталось сделать алиасы на ключевые слова и можно на питон переводить 1С-овцев 
Оставить комментарий
nikita270601
Пока