Go 1.7

Олсо, когда-то смотрел бенчи D vs Go, и они были не в пользу последнего. Впрочем, сейчас найти не могу, да и, возможно, получше стало.

Не знаю насчет д, но от си на микробенчмарках го практическии не отстает: http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=go&lang2=gcc

Ну чтение из файла и запись в структуру в памяти это и есть сериализация

Ну да, ну да. Особенно если это файл устройства.

Не знаю насчет д, но от си на микробенчмарках го практическии не отстает

Ну да, на половине бенчей сливает от двух раз. Вот Жаба от Го практически не отстаёт, а Го Сям сливает с треском.

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

Это да, это может быть. Хотя, возможно, разработчики сначала придумают, как эти дженерики урезать.

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

Перед тем, как дженерики появились в Яве, было несколько прототипных реализаций. А для Go что-то есть?

Хотя, если руководствоваться принципом, что для обобщённых решений производительность не так важна, а для чего-то более оптимизированного под задачу они слишком обобщённые, может и без них… В общем поживём — увидим.

https://github.com/golang/go/issues/15292 Думают, как избежать HashTableMap<string,AnotherType<ThidTypeEtc>>

Я про микробенчмарки говорил. Всякие регекспы - да, не очень. В boehm gc test си вообще пул использует, вместо честных malloc/free. Но если задействовать пулы, то Го не медленнее си и на этом тесте: https://github.com/pi/goal/blob/master/internal/tests/benchmarkgame-binarytre...

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

А чем с интерфейсной точки зрения отличается файл на диске от файла ком-порта? И там и там read(fd). Или тебе термин «сериализация» не нравится? Это общее название процесса. А конкретно чтение из файла и запись в структуру в памяти называется «десериализация», если быть педантичным.

Думают, как избежать HashTableMap<string,AnotherType<ThidTypeEtc>>

А что с ним не так и что они хотят вместо него?

Длинно очень. Что хотят - пока ничего конкретного, только думают. Мне вот такое, например, нравится: https://github.com/golang/go/issues/15292#issuecomment-215540504 (нечто типа метаклассов в Смолтоке)

А что придумают - не известно. Это все пока вилами на воде писано. Основной аргумент против - «нафига нам городить сложную инфраструктуру в компиляторе, что бы потом этим пользовалось полтора писателя писателя библиотек общего назначения». Очень они не любят усложнения всякие.

А чем с интерфейсной точки зрения отличается файл на диске от файла ком-порта? И там и там read(fd).

Разницу в интерфейсах между конкретно COM-портом и дисковым файлом ты можешь узнать, например, в стандарте POSIX.

https://github.com/golang/go/issues/15292

Тоска. И это тоже тоска: https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4...

Разницу в интерфейсах между конкретно COM-портом и дисковым файлом ты можешь узнать, например, в стандарте POSIX.

Для ком-порта какой-то свой read/fread? Я заинтригован.

Для ком-порта какой-то свой read/fread?

Свой read. Ты не знал?

Я заинтригован

Это печально.

Свой read. Ты не знал?

Нет, не знал. Я думал в юниксе файловый дескриптор - это штука универсальная. А какой там особый read для ком-порта?

Для ком-порта какой-то свой read/fread?

Свой read. Ты не знал?

Нет, не знал. Я думал в юниксе файловый дескриптор - это штука универсальная.

А read реализован в файловом дескрипторе. Между 15 и 17 битом.

Извини, я тебя не понимаю. Ты там певком уже закинулся?

может он имел ввиду ioctl и подобное

Нет. Я имел в виду именно read. Он работает по-разному для дисковых файлов и символьных устройств.

Интересно на самом деле. Можешь в двух словах рассказать, в чем разница?

Ты про кишки? Да кому они интересны. read читает байты и возвращает их количество или ошибку. Это все что нужно. А всякие таймауты, стоп-биты и тому подобные интимные подробности к сериализации уже не имеют отношения. Что бы не уводить далеко в сторону, будем считать что связь с девайсом идеальная и он всегда правильно отвечает на запрос данных.

http://pubs.opengroup.org/onlinepubs/009695399/functions/read.html

Ты про кишки? Да кому они интересны.

Мне.

read читает байты и возвращает их количество или ошибку

Ты перепутал сигнатуру с интерфейсом.

Ты перепутал сигнатуру с интерфейсом.

Ладно, ты победил. Надоело что-то.

https://github.com/golang/go/issues/15292 Думают, как избежать HashTableMap<string,AnotherType<ThidTypeEtc>>

А не как они не избегут, если только в 4-ое или 5-ое измерение эту информацию запрятать.

Чтобы уменьшить информационную нагрузку на программиста читающего код, нужно уходить от текстовых редакторов из 80-х для написания/чтения кода. Но и IDE не подойдут. Нужна какая-то новая эволюция IDE, нужен ресерч в этом направлении.

Но всем пох, на весь ИТ только три IDE... Да куча упористов с vi. Куда уж там до ресерчев новых направлений.

100% прагматичный подход. У них в продакшене зашёл GC с такими паузами, у их пользователей зашёл. Они пилили другие фишки, которые на тот момент были более насущными. Потом пришли чуваки с Твича и сказали: «Ребят, у нас ваш GC плохо заходит, паузы. Вот вам логи профилировщика». Ок, разработчики Go на конкретной задаче занялись оптимизацией GC и добились хорошего результата, потом ещё немного улучшили его и у них появились мысли, как это лучше допилить в будущем. Решили конкретную задачу успешно, плюс сделали хорошо другим пользователям.

Это в 1000 раз лучше, имхо, чем если бы разрабы Go сидели в кружке и такие: «Блин, нам нужен реально быстрый GC...» и мумировали бы над мучительно выдуманными кейсами и писали бы синтетические тесты, на которых бы добивались синтетических результатов. Лучшего тестирования, чем на реальных проектах, не бывает. Пользователь может ТАК использовать твою программу, что у тебя волосы зашевелятся. Разрабы эту энергию, которую бы они затратили на мучительное высасывание из пальца бенчмарков, направили в другие области разработки и там что-то улучшили. Молодцы.

Критикуя, предлагай.

ну вот я пишу IDE(а заодно язык который можно настроить под себя и выточить из него хоть С++, хоть жаву, хоть жаву с шаблонами)

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

Ваш подход известен в программировании промышленных контроллеров. И это лютая хрень, как по мне.

Так я и говорю нужен ресерч, так сходу не скажу, занят пока другим.

Не надо ничего рисовать это тупиковый путь. Система должна быть смартовой и автоматически преобразовывать написаное в какой-то более удобный формат. Чтобы вещи типа HashTableMap<string,AnotherType<ThidTypeEtc>> в этом формате становились читабельными.

c++:

typedef templateType<int> concreteType;

Го (гипотетически):

type concreteType = templateType(int)

Го (гипотетически):

type concreteType = templateType(int)

И в чём прикол? Заменят <...> на (...)? Так у них скобки получатся контекстно-зависимыми, и вся их хвалёная быстрая компиляция накроется медным тазом.

И да, я не понимаю, чем HashTableMap<string,AnotherType<ThidTypeEtc>> хуже, чем HashTableMap(string,AnotherType(ThidTypeEtc)).

Прикол в type concreteType После этого можно писать my := &concreteType{} вместо my := &templateType(int){}. Explicit temlate instantiation в общем, навроде плюсового typedef.

Да, скорость компиляции замедлится. Придется создавать экземпляры шаблонных классов, генерить аст под них, или использовать аст-ноды без конкретных типов, что поломает к черту апи аст. Много гимора, а выгода сомнительна. Вот и думают пока.

После этого можно писать my := &concreteType{} вместо my := &templateType(int){}.

И что? Кресты так давно умеют, но в них всё в большинстве случаев пишут templateType<int>().

Да, скорость компиляции замедлится.

Я говорил конкретно про скорость парсинга. Когда при парсинге компилятор видит myType(int){} - непонятно, является ли первая скобка началом преобразования к типу, или началом списка параметров шаблона, и парсинга в один проход не получается.

Много гимора, а выгода сомнительна.

Выгода очевидна.

Выгода очевидна.

Можно конкретный пример? Не из стантадрных библиотек/буста.

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

Можно конкретный пример? Не из стантадрных библиотек/буста.

Чем тебе стандартные библиотеки и буст не угодили?

Тем, что в плюсах стандартная библиотека шаблонна потому, что нет шаблонных встроенных типов. Пример: unordered_map<int,string> - это map[int]string в Го. Мне поэтому и интересны конкретные примеры, где шаблоны так круто заходят.

Пример: unordered_map<int,string> - это map[int]string в Го.

А map<int, string>? А deque<string>?

[]string

[]string

Он сливает дэку, когда нужна частая вставка/удаление элементов, особенно в начало.

Это очень серьезная проблема. Кстати, когда ты последний раз дек использовал? Вот и я никогда.

Вам рисовать не надо а мне например очень даже надо.

И к тому же. Я не понимаю что такое смартовая система. Предложения должны быть конкретными а не в духе «должно быть большк и лучше»

Кстати, когда ты последний раз дек использовал?

Года четыре назад, в студенческой поделке для работы с текстом. Впрочем, я и кресты со студенческих лет не юзал - ушёл ближе к железу.

Вот и я никогда.

Мир веб-погромированием не ограничивается.

И сколько гигабайт текста поделка в секунду обрабатывала?

И сколько гигабайт текста поделка в секунду обрабатывала?

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

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