Это повод выпить или кидаться какашками?
Если какашками, то друг в друга или в Apple Swift?

Зачем эти восторги от технологии 60х здесь?

Чет какая-то полная фигня. И не то чтобы я был в восторге от «beautifull straight code» в асинхронщине в яве, но вот уж c#(CSP то там тож есть) и scala(akka) тут рулят и педалят, а по сравнению с ними go смотрится недоязычком из прошлого века.

go смотрится недоязычком из прошлого века

Go — это Python done right. Кто-то может возразить, что питон ну никак не сделать «right», но не в этом дело.

Go не претендует (да, и никогда не претендовал) на отгрызание доли Java или .Net. А вот у Перла-Питона-Руби — вполне.

Думаю что Go напару с Hack, в ближайшей временной перспективе похоронят питон с руби. Go, именно как «для тех кого тошнит от ООП», а Hack как мейнстримовая ООП-модель с плюшками.

Go — это Python done right. Go ... претендует ... на отгрызание доли ... у Перла-Питона-Руби

Пока не добавят генерики и апи для работы с коллекциями - сомневаюсь.

Автор точно не знает питона. Сложность и медленность C<->Python вызовов? Колбеконли асинхронность? Да он упоролся.

Забанься, камадрочер

http://talks.golang.org/2014/gocon-tokyo.slide

Пока не добавят генерики и апи для работы с коллекциями

У питона нет и не может никаких генериков, а «удобное» API для работы с коллекциями проистекает главным образом из динамической природы языка.

В Go пошли совершенно левым путем, запихнув array и map на низкий уровень языка, тут согласен. И это — плохо. С одной стороны... А с дугой стороны эффективно предотвращает разнообразный структуродрочинг. И это — хорошо.

То есть http://www.reddit.com/r/golang/comments/276d3s/go_90_perfect_100_of_the_time/

Сложность и медленность C<->Python вызовов?

http://csl.name/C-functions-from-Python/

Это по-твоему просто?

а «удобное» API для работы с коллекциями проистекает главным образом из динамической природы языка.

а если язык не просто сахарок над map, то надо добавить generics и написать удобное api для работы с коллекциями.

Еще одна Java не нужна. Используй кодогенераторы, Люк.

Это по-твоему просто?

Еще как... Предполагается, что на C конечный юзер собирает/парсит объекты языка самостоятельно... Поэтому, я тоже как-то не очень понял, что автор имеет ввиду насчет «медленности».

Это по-твоему просто?

Еще как...

Посмотри тогда, как это сделано в Go, и возрадуйся.

http://blog.golang.org/c-go-cgo

Это по-твоему просто?

Вот, автор слайдов, походу, тоже эту хрень нагуглил. Смотри cffi, cython, ctypes (на худой конец).

Используй кодогенераторы, Люк.

Лучше ещё один c++?

Напиши мне на питоне аналог вот этого:

package rand

/*
#include <stdlib.h>
*/
import "C"

func Random() int {
    return int(C.random())
}

func Seed(i int) {
    C.srandom(C.uint(i))
}

что автор имеет ввиду насчет «медленности».

XS делает толстые обертки, проверяющие кучу вещей.

Все правда, только решение задачи, имхо, кривое. Во-первых, он выбрал http, который сам по себе костыль. Во-вторых, задачу можно и лучше в его случае решить через standalone application, аля обычное нативное приложение. В-третьих, Go не разрулит проблем с хранением, резервным копированием, доступом к данным на несколько сотен террабайт. Либо все уже решено (не на го!), либо у автора в запасе несколько десятков свободных лет, о которых он умолчал.

Из 100% возможностей Go, автору нужно лишь 5%:

• легковесные потоки. Он же будет закачивать и смотреть один? ну максимум с женой возле монитора
• сетевая поддержка, http. Он решил переложить разработку интерфейса на движок браузеров, которые через 100 лет могут уже не поддерживать допотопный html5
• масштабируемость. Он решил, что делает гугло-пикасу для всего мира и якобы поэтому нужна масштабируемость. 2000 год, ACDSee 2.x решала большинство задач автора.

И так далее. Вобщем, успехов автору, надеюсь он реально вампир и сможет закончить свой проект через 100 лет.

Поэтому, я тоже как-то не очень понял, что автор имеет ввиду насчет «медленности».

Не знаю как в питоне, но в перле это выражается в том, что сама обвязка вызовов и преобразование данных из си-шных структур в нативные-языковые довольно тормозная. Пример, на входе сишной функции ожидается тип int, из ЯП приходит данные в виде строки. Динамическое преобразование типов средствами языка и есть ботлнек по мнению автора. На самом деле там еще куча ньюансов, но я дал лишь простой пример для наглядности. Тем не менее, автор забыл учесть, что задач, где преобразование типов является ботлнеком крайне мало. Одна лишь конвертация картинок из BMP в PNG займет больше времени.

С точки зрения человека, процесс до готовой реализации на Си потребует больше времени. Прототип пишется на нативе (на питоне). Потом, через прогонку профайлером обнаруживается ботлнек. Пишется реализация на сях. Потом профилирование сишного кода. Да, такая разработка медленнее, чем изначально писать на Сях/Го. Если таких задач будет куча, рано или поздно начнешь изначально проектировать программу с использованием сишных модулей. И проблема исчезнет :)

Пожалуйста. Я просто скопировал строчки из мана.

from cffi import FFI

ffi = FFI() 
ffi.cdef("""
   long int random(void);
   void srandom(unsigned int seed);
""")
C = ffi.verify("""
#include <stdlib.h>
""")

Seed = C.srandom
Random = C.random

то надо добавить generics

MapType в golang и есть генерик. И не забывай что MapType отображает Type в Type. Т.е. можно зафигачить отображение Type -> InterfaceType, что решает вопрос хранения полиморфных данных.

Философия go предполагает что мы объявляем type ... interface {...}, и запиливаем fold самостоятельно. Т.е. удобное API для коллекций лежит на совести программиста.

Вот только до недавнего времени в stdlib этого cffi не было. Добавили только в 2013-м или 2014-м году.

Не знаю как в питоне

В питоне получше. Используя код выше:

/tmp$ python2 -m timeit -s 'from rand import Random' 'Random()'
10000000 loops, best of 3: 0.0423 usec per loop

По моему совсем не плохо. Четыре сотых микросекунды.

cython был в 2010. И код выглядел бы вообще похожим на твой. Только нужно было бы запускать компилятор и линкер. А так да, cffi молод, но уже стал удивительно прекрасным инструментом.

Т.е. удобное API для коллекций лежит на совести программиста.

вот вот. Не надо такого, надо чтобы и map, и fold/reduce, и filter и прочие всякие были сразу и из коробки.

Это вкусовщина, с одной стороны, потому как написать свой маленький модуль со всем этим (я правда не знаю как, но верю вам на слово, что можно) и таскать его куда надо - не проблема. А с другой стороны, массовость пистонов с рубями, да сишарпов именно в том, что все плюшки сразу есть, почему я и сомневаюсь в том, что go заменит ruby/python

go заменит ruby/python

Не заменит, хотя бы потому, что го не умеет однострочники.

Автор считает, что Go лучшая замена для nginx + ruby on rails. Только задач уровня триллион запросов в день решают компании, а не персоны в отдельности. И никаких особых плюсов в данном случае нет. Сервер (локалхост) как держал одновременно 1000 клиентов, так и держит, что на го, что на nginx. Если будет больше, то следует задуматься о деньгах за такой проект. Будут деньги -> будут сервера. Вот таже лицокнига пришла к сокращению издержек на сервера спустя десятилетие.

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

Ну если в этом смысле, дык, она и *будет* «тормозная», т.к. придется копировать данные из X в сишную кучу, и из сишной кучи в X. Но, тут, либо — девественность, либо — оргазм.

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

вот вот. Не надо такого, надо чтобы и map, и fold/reduce, и filter и прочие всякие были сразу и из коробки.

map и filter — это частные случаи fold.

А вообще, «бойтесь своих желаний», ибо generic fold, они даже в хаскеле — лютый п..ц с точки зрения программиста (см. напр. пакеты lens и syb), не говоря про техническую сторону в виде существенного усложнения системы типов и рантайма.

Т.е. конечно, можно запилить годный сахарок для стирания типов (как в яве)... Но, это ведь не труЪ.

надо чтобы и map, и fold/reduce, и filter и прочие всякие были сразу и из коробки

В go вместо них есть for.

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

Кстати, не обязательно. Зачастую можно через unsafe прикастовать сишные структуры к гошным и работать без каких-либо оверхедов. Но оно, очевидно, будет unsafe.

map и filter — это частные случаи fold.

упоролся? map через fold получается уж больно тормозным. Плюс map в отличии от fold можно делоц параллельно.

Go — это Python done right.

Для веба, что-ли? Когда-то хотел ради смеха написать одну программку на Go под десктоп и столкнулся с тем что нет ни одного(!!) вменяемого тулкита для графена. Это как понимать?

Москва не сразу строилась

Глянул эту их презентацию - ну как обычно, типа заменяем скрипты(которые ещё с баша на питон даже не переписали, лол, ибо just works), работа с аудио-видео...

Язык-то хороший, но инфраструктуру у него ещё пилить и пилить довольно долго.

go-qml пилят.

Смотрел я на этот go-qml, как было с полгода назад альфа в состоянии полкоммита в день, так и осталось.

Да, я знаю, что это опенсорц «Хочешь программу - где твои коммиты?» и всё такое, но со стороны это выглядит так, будто оно ещё жутко сырое. Правда, я как-то читал интервью с командой разработчиков и Andrew Gerrand ответил, что:

...but developing a production-quality package is a significant undertaking. I have no doubt one will come in time.

А пока только:

In the meantime, the web is the most broadly available platform for user interfaces. Go provides great support for building web apps, albeit only on the back end.

Shared libraries

no shared libraries can't load Go code at runtime

Думаю что Go напару с Hack, в ближайшей временной перспективе похоронят питон с руби.

сильно сказано конечно, но пока перспективы у Hack очень мутные, очередная реализация языка в стенах «фирмы», кроме того он не быстрее PHP на данный момент, одного синтаксиса недостаточно, что бы начать использовать. Вот если Hack будет сравним с Java/Go по скорости, тогда можно будет смотреть на него.

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

map через fold получается уж больно тормозным.

С чего бы?

fld f z = go where
  go [] = z
  go (y:ys) = y `f` go ys

mp _ [] = []
mp f (x:xs) = f x : mp f xs

mp2 f = fld ((:) . f) []

Или код разных http://www.cplusplus.com/reference/algorithm/for_each/, http://www.cplusplus.com/reference/numeric/accumulate/, http://www.cplusplus.com/reference/algorithm/transform/, http://www.cplusplus.com/reference/algorithm/copy/.

Не проблема написать нормальный ленивый/энергичный fold через который можно было бы выразить нормальный ленивый/энергичный map.

Плюс map в отличии от fold можно делоц параллельно.

http://software.intel.com/ru-ru/node/506154

Ну и map/_reduce_ же :)

Мне хватило вот этого: https://github.com/conformal/gotk3

Будут деньги -> будут сервера.

И их количество не играет роли? Деньги есть? Айда сливать!

С чего бы?

Да, согласен, код получается практически одинаковым.

http://software.intel.com/ru-ru/node/506154

A parallel_reduce recursively splits the range into subranges to the point such that is_divisible() is false for each subrange.

Таки вот. Хотя в случае с map is_divisible() должен быть true на любых отрезках.

Go заменит Ruby? почему?

Хипсторы, сэр. Они любят новые игрушки.

хипсторы с руби уже давно убежали, поэтому о нем не слышно/не видно, там фанатики остались, наврядли они побегут

http://software.intel.com/ru-ru/node/506153

A parallel_for(first,last,step,f) represents parallel execution of the loop:

for( auto i=first; i<last; i+=step ) f(i);

A parallel_for recursively splits the range into subranges to the point such that is_divisible() is false for each subrange, and makes copies of the body for each of these subranges. For each such body/subrange pair, it invokes Body::operator(). The invocations are interleaved with the recursive splitting, in order to minimize space overhead and efficiently use cache.

Оно нужно чтобы разбить range на количество subrange для параллельной обработки, всегда true бессмысленно — range из 100500 элементов будет разбиваться на 100500 subrange по одному элементу с обработкой в 100500 тредов. Там ниже пример с grainsize и is_divisible.

Но вообще, особенно для параллельщины, есть смысл писать map и fold отдельно — в простых случаях хотя бы и для -O0, в более сложных могут вылезти какие-то различия.

а прибежали на скалу?:)

на ноду