Состоялся (https://blog.golang.org/go1.10) релиз языка программирования Go 1.10 (http://golang.org), который развивается компанией Google при участии сообщества как гибридное решение, сочетающее высокую производительность компилируемых языков с такими достоинствами скриптовых языков, как лёгкость написания кода, быстрота разработки и защищённость от ошибок. Код проекта распространяется (https://golang.org/dl/) под лицензией BSD.
Синтаксис Go основан на привычных элементах языка Си с отдельными заимствованиями из языка Python. Язык достаточно лаконичен, но при этом код легко читается и воспринимается. Код на языке Go компилируется в обособленные бинарные исполняемые файлы, выполняемые нативно без использования виртуальной машины (модули профилирования, отладки и другие подсистемы выявления проблем на этапе выполнения интегрируются в виде runtime-компонентов (http://golang.org/pkg/runtime/)), что позволяет добиться производительности, сопоставимой с программами на языке Си.Проект изначально разрабатывается с оглядкой на многопоточное программирование и эффективную работу на многоядерных системах, в том числе предоставляя реализованные на уровне операторов средства для организации параллельных вычислений и взаимодействия между параллельно выполняемыми методами. Язык также предоставляет встроенные средства защиты от выхода за допустимые области выделенных блоков памяти и обеспечивает возможность использования сборщика мусора.
Основные новшества (http://golang.org/doc/go1.10), представленные в выпуске Go 1.10:- В утилите go обеспечена поддержка автоматического кэширования результатов сборки и тестирования пакетов;
- При тестировании пакетов командой "go test" реализован автоматический запуск команды "go vet" для выявления значительных проблем перед запуском тестов. Для отключения vet-проверок следует запускать тесты командой "go test -vet=off";
- В cgo, механизм для организации вызова кода на C/C++ из программ на языке Go, добавлена возможность прямой передачи строковых значений между кодом на Go и Си. Функции на языке Си могут принимать строки языка Go, используя тип _GoString_, а также получать прямой доступ к строкам при помощи вызова _GoStringLen и _GoStringPtr;
- Задаваемые в cgo флаги компиляции (#cgo CFLAGS) теперь проверяются на предмет допустимости применения. В случае применения флагов, отсутствующих в белом списке, будет выдана ошибка (например, злоумышленник может использовать (https://golang.org/s/invalidflag) в пакете флаг "-fplugin" для запуска произвольного кода на этапе сборки);
- В языке разрешено использование операций индексирования x[1.0 << s] в случае если "s" является нетипизированной константой;
- В утилите go обеспечена попытка автоматического определения корня инструментария на основе текущего файлового пути, если не выставлена переменная окружения GOROOT, что позволяет распаковать бинарный дистрибутив Go в любом каталоге и начать использовать его без дополнительных настроек;
- Команда "go build" теперь определяет устаревшие пакеты только на основе содержимого файлов с исходными текстами, заданных сборочных флагов и метаданных из скомпилированных пакетов (время модификации больше не учитывается);
- При выполнении "go build" флаги "-asmflags", "-gcflags", "-gccgoflags" и "-ldflags" теперь применяются только к пакетам, перечисленным в командной строке и не передаются при сборке зависимостей;
- Команда "go install" теперь устанавливает только пакеты, перечисленные в командной строке (для установки сборочных зависимостей следует явно указывать флаг "-i");
- В ассемблере для архитектуры x86_64 добавлена поддержка 359 новых инструкций, включая AVX, AVX2, BMI, BMI2, F16C, FMA3, SSE2, SSE3, SSSE3, SSE4.1 и SSE4.2;- В компилятора проведена оптимизация скорости генерации кода для различных архитектур. Сборщик мусора оптимизирован для снижения задержек и минимизации негативного влияния на производительность во время своей активности;
- Режимы сборки портированы для новых архитектур: "c-shared" теперь работоспособен для архитектур linux/ppc64le, windows/386 и windows/amd64, режим "pie" для darwin/amd64, а "plugin" для linux/ppc64le и darwin/amd64;
- Прекращена поддержка FreeBSD 9, для работы теперь требуется как минимум FreeBSD 10.3. Возобновлена поддержка NetBSD (работа возможна только с экспериментальной кодовой базой NetBSD 8). Go 1.10 является последним выпуском с поддержкой OpenBSD 6.0, OS X 10.8 "Mountain Lion", OS X 10.9 "Mavericks", Windows XP и Windows Vista, в дальнейшем для работы потребуется как минимум OpenBSD 6.2, OS X 10.10 "Yosemite" или Windows 7.
URL: https://groups.google.com/forum/#!topic/golang-announce/IQeq...
Новость: https://www.opennet.ru/opennews/art.shtml?num=48096
Ждем дженерики...
я как узнал, что в го нет дженериков, так тут же понял, что язык игрушечный. Без дженериков добро пожаловать обратно в дельфи, где если надо создать список чего-то, то надо возводить для этого отдельный класс списка: TStringList, TIntList etc. В норм языках все проще: List<String>, List<Integer>... И не нужно дублировать функционал.зы Ща нагуглил delphi generics, и обнаружил, что с 2009 они уже есть. А я работал с Borland Delphi 2005 (там на диске еще древнегреческая голова статуи какая-то). Ну молодцы, чо. Значит го хуже, чем даже дельфи 2009.
Почитал в комментариях, наткнулся на слова "защита от дурака и художника", все встало на свои места. Просто есть люди, которые не могут без джкнериков физ-баз написать.
>"защита от дурака и художника"Тля! Это великолепно! Одной фразой - всю суть! :-)
Дай URL если найдёшь.
>Без дженериков добро пожаловать обратно в дельфиТолько вот в делфи они есть вообще-то, и самым серьезным недостатком для меня остается секция var.
> Только вот в делфи они есть вообще-токоммент до конца не читай
@
сразу отвечай
В Go такие вещи делаются с помощью интерфейсов. Идеология языка подразумеват отсутствие дублирования возможностей, значит раз без дженериков можно обойтись — они не нужны.
> и какой же там интерфейс списка?Интерфейс списка? Ты о чём? Есть тип списка в стандартной библиотеке: https://golang.org/pkg/container/list/
> принимает какой-нибудь самый базовый класс Object в своем методе add?
Сядь поплотнее в кресло, сделай глубокий вдох, приготовься к взрыву мозга: в go не тклассов. А так — принимает interface{}.
> go не тклассовНу нормас так. Что, ФП головного мозга? Обратно в 70-ые?
> А так — принимает interface{}.
Потыкал запускалку примеров по твоей ссылке и сразу обнаружил, что вам приходится явно возводить .(string), чтобы привести значение элемента списка к строке. Я ж грю - ничем не отличается от void* в глибе.
--------------------
package main
import (
"container/list"
"fmt"
)
import "strings"
func main() {
// Create a new list and put some numbers in it.
l := list.New()
e4 := l.PushBack("Four")
e1 := l.PushFront("One")
l.InsertBefore("Foo", e4)
l.InsertAfter("Bar", e1)
l.InsertAfter("Baz", e1)
// Iterate through list and print its contents.
for e := l.Front(); e != nil; e = e.Next() {
// Хаха :-)
//
// fmt.Println(strings.ToUpper(e.Value))
//
// prog.go:20:32: cannot use e.Value (type interface {}) as type string in argument to strings.ToUpper: need type assertion
// А вот с явным приведением типа работает. Го-программерам без дженериков приходится явно указывать типы там, где в норм языках они указываются на основе дженериков
fmt.Println(strings.ToUpper(e.Value.(string)))
}
}
>> go не тклассов
>Ну нормас так. Что, ФП головного мозга? Обратно в 70-ые?Что, не можешь представить ООП без классов? А оно бывает.
> Го-программерам без дженериков приходится явно указывать типы там, где в норм языках они указываются на основе дженериков
А вот у тебя, по ходу, жаба головного мозга. Если так хочешь сэкономить несколько символов, посчитай всё-таки, сколько их расходуется в том и другом случае.
Не распинайся. Высказывания ниже за авторством Роба Пайка. По-моему он просто тролль.For example, I've been examining generics recently, but I don't have in my mind a clear picture of the detailed, concrete problems that Go users need generics to solve. As a result, I can't answer a design question like whether to support generic methods, which is to say methods that are parameterized separately from the receiver. If we had a large set of real-world use cases, we could begin to answer a question like this by examining the significant ones.
I was asked a few weeks ago, "What was the biggest surprise you encountered rolling out Go?" I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.
И правда, почему C++ программеры не любят Go?
Наверное, потому что привыкли к STL, к параметрическому полиморфизму.
Наверное, конструкция вида
var mySet map[someKeyType]bool
как замена для множества выглядит оверкиллом. (Го-программер не увидит ничего плохого в том, что )
Кому нужно что-то еще кроме хеш-мапы и массива/слайса? Тем, кому нужно, вон, запилят такие вот свои контейнеры, как указанный лист из их стандартной библиотеки. Да, анон, суперкрутой range не для твоих контейнеров. И касты, больше кастов богу кастов! Больше крови из глаз! На самом деле, ты очень быстро привыкнешь выгонять данные фором в массив, потом, например, сортировать его перед выдачей, вместо того, чтобы заюзать мапу на разновидности бинарного дерева поиска. Тебе больше не нужно знать структуры данных, проблема выбора снята. Оставь свои терзания, начни писать свой код. Пусть он снимается с твоего мозга как энцефалограмма. Пиши его, пиши его больше, не думай, повторяй одно и то же again and again, херачь утиные интерфейса, разноси методы по всем модулям трансляции! Во славу гугла! Во славу анти ^W Роба Пайка.
> И правда, почему C++ программеры не любят Go?
> Наверное, потому что привыкли к STL, к параметрическому полиморфизму.Да. И ещё ко многим другим извращениям.
> Кому нужно что-то еще кроме хеш-мапы и массива/слайса? Тем, кому нужно, вон, запилят такие вот свои контейнеры, как указанный лист из их стандартной библиотеки. Да, анон, суперкрутой range не для твоих контейнеров.
Кому оно действительно нужно в больших количествах (и они могут это обосновать), очевидно, go не подходит. Но мапы и слайсы покрывают никак не меньше 90% реальных задач.
> Да. И ещё ко многим другим извращениям.Ну что поделать, люди разные, одни программисты способны слегка менять способ мышления, когда переходят к другому языку программирования, а другие на любом языке будут пытаться писать код на С++(Fortran/C/PHP/Perl/bash/любой_другой_ЯП). Поэтому первым стоит изучать как можно больше разных ЯП и подбирать язык под задачу, а вторым сосредоточиться на своем любимом и подбирать задачи под язык. Каждому своё, главное не перепутать.
>Поэтому первым стоит изучать как можно больше разных ЯП и подбирать язык под задачуЭтой мантре уже 100 лет в обед, но на практике она не работает.
>И правда, почему C++ программеры не любят Go?Потому что И правда, почему C++ программеры не любят _всё_ , кроме С++!
Не благодари :)
>И правда, почему C++ программеры не любят Go?Потому что C++ программеры не любят _всё_ , кроме С++!
Не благодари :)
Год копался в Go, Rust, Nim, Idris. Как язык лучше всех Idris. Но пользоваться им нереально. И если Rust имеет интересную концепцию управления памятью, то в том же Go я абсолютно не вижу смысла, т.к. nim обходит по всем фронтам.
Вообще, возникает ощущение, что гугл запилил его для вчерашних студентов. Си они не осилили на достаточном уровне, а работать надо.
> Год копался в Go, Rust, Nim, Idris. Как язык лучше всех Idris.
> Но пользоваться им нереально. И если Rust имеет интересную концепцию управления
> памятью, то в том же Go я абсолютно не вижу смысла,
> т.к. nim обходит по всем фронтам.
> Вообще, возникает ощущение, что гугл запилил его для вчерашних студентов. Си они
> не осилили на достаточном уровне, а работать надо.Ага, я тоже, только Idrtis не смотрел. Nim интересен, но по факту он не заинтересовал большинство. Rust достаточно сложен в освоении, но система владений просто невероятна (до него не думал, что можно как-то по другому управлять памятью кроме как GC и ручной контроль через malloc и т.д.)
Сейчас вот изучаю Go, но после полугода его использования (ага и на проде тоже) он оставил о себе впечатление зрелого и удобного инструмента.
> он оставил о себе впечатление зрелого и удобного инструмента.Rust или Go?
>Rust достаточно сложен в освоении, но система владений просто невероятнавообще-то она скопирована с RAI в С++, только там сделана попытка реализовать это без классов и объектов и как-то передавать в функции и возвращать из них...
> Год копалсяА могли бы работать и пользу приносить.
> лучше
> нереально
> кажется
> интереснуюДостойные аргументы.
Раз уж вы начали, то перечисляйте объективные критерии, по которым вы проводили сравнение.
> А могли бы работать и пользу приносить.Работать != Пользу приносить
Почему я не могу тратить свое свободное время на изучение новых языков? К тому же, я сделал несколько фиксов в проектах на Rust и Nim.> Раз уж вы начали, то перечисляйте объективные критерии, по которым вы проводили сравнение.
> Как язык лучше всех Idris.Какое объективное сравнение вам нужно? Речь ведь о языке, не реализации. А здесь, на мой взгляд, всё субъективно. Лично мне понравилось автоматическое доказательство. Просто непередаваемое ощущение, когда на этапе компиляции обнаруживаются не только синтаксические ошибки, но и ошибки архитектуры. У меня ни с какими тестами и покрытием не было ощущения, что программа будет работать точно так, как я задумал. А с Idris есть, при чём не надо описывать 100500 ограничений.
> Но пользоваться им нереально.
Да потому что компиляция не сильно сложных примеров занимала у меня 3-5 минут. Кто-то в чате писал, что у него проект собирается полчаса. И там явно вещи не уровня офиса/браузера.
> Rust имеет интересную концепцию управления памятью
А какая здесь может быть объективность? Оно лично мне интересно, ибо такого я ранее не видел. И, судя по комментариям на опеннете, я не одинок в этом.
> Go я абсолютно не вижу смысла, т.к. nim обходит по всем фронтам.
Опять-таки сравнение языков. Это субъективно. Лично мне понравился DSL и система макросов в Nim. Го ничего подобного уровня предложить не может. А всё остальное нужное мне есть в обоих языках.
Сравнение реализаций(бенчмарки) ищите сами. Когда я смотрел последний раз, Nim был на уровне Си. Go чутка отставал.
а D не смотрели? великолепный же язык.
Так кто спорит, великолепный.
Жаль под него нет достойного нативного гуи-фреймворка, это была бы бомба.
Не смотрел. Беглого просмотра сайта и википедии явно недостаточно. Но из прочитанного каких-либо преимуществ перед Nim не заметил.
D хороший язык. Плюсую.
Экосистема пока не очень развитая, но достоинств языка это не умоляет.
я вот боюсь что не пока, а уже.
мысль кого-то с хабра: dlang попал в цикл непопулярности - непопулярный потому что не развита экосистема, экосистема неразвита потому что непопулярный.
за ним не стоит гугл, чтобы вбивать в головы неофитам, о замечтательности языка.
Ну там идёт какое-то движение http://www.modulecounts.com/
И в основных индексах держится
https://www.tiobe.com/tiobe-index/
https://spectrum.ieee.org/static/interactive-the-top-program...
В любом случае, как уже сказал, медленное развитие экосистемы достоинств языка не умоляет.
Использовал его немного в работе, очень понравилось.
умАляет - делает малым, меньшим
умОляет - молит, настойчиво просит
Пардон, в лингвистических клубах не числюсь.
Но, спасибо, что поправили.
> Пардон, в лингвистических клубах не числюсь.
> Но, спасибо, что поправили.Блин, простого "спасибо" было бы достаточно, а первое предложение все испортило. А так наверное и angra ни в каких лингвистических клубах не значится и бОльшая часть опеннетовской аудитории тоже, хотя это слово написала бы правильно.
D мертв потому что пытался угодить всем со своим GC/noGC режимом. Библиотеки под него в двух вариантах писать никто не будет ну и копаться выяснять с каждой конкретной либой в каком режиме работать.
>> Rust имеет интересную концепцию управления памятью
> ... Оно лично мне интересно, ибо такого я ранее не видел. ...Objective-C c ARC, Swift.
>>> Rust имеет интересную концепцию управления памятью
>> ... Оно лично мне интересно, ибо такого я ранее не видел. ...
> Objective-C c ARC, Swift.Питон тогда уж. Тоже ссылочки считает в рантайме. А еще вроде бы Perl, пых или VB<=6 (но тут за детали не скажу - никогда не интересоваля внутренностями).
В общем, хвала маркетологам ябла, сумевших и тут создать свом "брэнд" для классических вещей.Правда, вся изюминка растовой концепции - проделывать этот фокус в компайлтайме.
Иначе вся эта **ля с владениями и отслеживанием времени жизни резко теряет смысл.
https://habrahabr.ru/company/mailru/blog/327966/#lekciya-1-v...Лекции по Go. Посмотрите начало первой лекции, там специалист из mail.ru объясняет, зачем этот язык разработали и какая у него ниша, какие плюсы и минусы. Скажем так, пока Вы не будете работать в команде из хотя бы 4-5 человек более нескольких лет, Вы не поймёте, чем Go лучше Си.
> специалист из mail.ruЗвучит сильно.
> Лекции по Go.Открыл. Это видеоуроки. Вы серьёзно? Смузи вам в глотку.
В Вашем ответе 0 полезной информации. Могли просто промолчать или похихикать.
это для фанатов игого ноль. А для меня вот очень полезная информация - сэкономил минуту на открытие ссылки.
И потратил её в пустую написав это каммент
> Си они не осилили на достаточном уровне, а работать надо.лол, кек, чебурек
Го придумал Пайк, который написал культовое эссе о Си-кодинге ещё до вашего рождения.
Как это противоречит с написанным мной?
наверное как минимум то что он(Пайк) разбирается в теме побольше многих Д-аналитиковпо поводу Nim и Idris то тоже выскажу своё личное мнение
Здесь наблюдается такая же картина как и с дистрибутивами linux, поменял обои добавил пару фич и вуаля готов новый дистрибутив, так и здесь Nim и Idris это по сути надстройки над Си со своими шл..ми и блекджеком. Для меня например язык считается взрослым если он как минимум может сам себя скомпилировать и скомпилировать хорошо.по поводу вашего высказывания
> гугл запилил его для вчерашних студентова для кого Bell Labs пилил язык СИ ?
> Для меня например язык считается взрослым если он как минимум может сам себя скомпилировать и скомпилировать хорошо.На счёт Idris не скажу, он вроде бы на Haskell написан. А вот Nim сам на себе написан. И уже давно спокойно собирает сам себя.
> Здесь наблюдается такая же картина как и с дистрибутивами linux, поменял обои добавил пару фич и вуаля готов новый дистрибутивТакое ощущение, что вы знакомы только с языками на одной парадигме. Уже функциональные, декларативные и императивные парадигмы отличаются сильно, что не идёт ни в какое сравнение со сменой обоев. А уж Idris это вообще нечто новое. Если вы до этого писали только на c/c++/java/c#/php/js/etc, то используя просто Haskell будете удивлены. А Idris идёт ещё дальше.
Кстати, не рекомендую знакомство с Idris без понимания Haskell'a. Слишком сложно будет.
> наверное как минимум то что он(Пайк) разбирается в теме побольше многих Д-аналитиковРазве я где-то ставил под вопрос компетенцию авторов языка? Я говорил лишь о том, что Go - упрощённый язык, специально заточенный под вчерашних студентов, которых уже сейчас надо посадить работать.Точнее у меня возникает такое ощущение.
Ну ещё и гугл. Не люблю гугл, м.б. из-за этого такое мнение.
> На счёт Idris не скажу, он вроде бы на Haskell написан.да вы правы, там Haskell правит балом. Значит надстройка на над хаскелем, что в принципе не отменяет его не зрелости.
> А вот Nim сам на себе написан. И уже давно спокойно собирает сам себя.ну насколько он сам себя собирает спорный вопрос, возможно в каком-то очень и очень урезанном варианте.
Если смотреть на его код на github то больше четверти(27%) кода это СИ и СИ++, для сравнения у rust это где-то 1.4%, у Go 0.4%
да и на самом сайте Nim пишут
>> By compiling to C, Nim is able to take advantage of many features offered by modern C compilers. The primary benefits gained by this compilation model include incredible portability and optimisations, which have been implemented over more than 40 years by various individuals and influential companies.
> Разве я где-то ставил под вопрос ...повторю вопрос:
Для кого Bell Labs писал язык СИ ?
С писал не абстрактный bell labs, а вполне конкретный инженер - Деннис Ритчи. Писал для себя и своего коллеги - Кена Томсона, для конкреной цели - заменить платформенно-зависимый ассемблер для ОС UNIX.
а с чего тогда сейчас анонимные диванные аналитики считают что Go пишет абстрактный Google ?
> Го придумал Пайк, который написал культовое эссе о Си-кодинге ещё до вашего рождения.Написано выше в этой ветке
> у насколько он сам себя собирает спорный вопрос, возможно в каком-то очень и очень урезанном варианте.
> Если смотреть на его код на github то больше четверти(27%) кода это СИ и СИ++, для сравнения у rust это где-то 1.4%, у Go 0.4%Вот это Аналитика. Вот это да.
Сорцы на си представлены специально для хейтеров бинарников. Их можно скачать и собрать компилятор с помощью gcc/шланга/мсс/etc. Однако это никак не мешает собрать Nim с помощью самого Nim'a(В процессе компиляции появятся те самые сишные/++ файлы).
Предвидя некоторые дальнейшие бесполезные замечания по поводу кодогенерации, предлагаю обратить внимание на то, то у nim есть backend который сразу в llvm компилит.
> Вот это Аналитика. Вот это да.ага, с анонимным высосанным пальцем это не сравнится
> Сорцы на си представлены ...
как я писал выше нимовцы сами пишут что их компиляция полная лажа и не идёт не в какое сравнения с сишной
>> By compiling to C, Nim is able to take advantage of many features offered by modern C compilers. The primary benefits gained by this compilation model include incredible portability and optimisations, which have been implemented over more than 40 years by various individuals and influential companies.а то что репозиторий языка завален по вашим словам "Сорцы на си представлены специально для хейтеров бинарников" как раз и говорит о незрелости языка
> как я писал выше нимовцы сами пишут что их компиляция полная лажа
> и не идёт не в какое сравнения с сишнойА сами нимовцы знают, что они это пишут?
что конкретно ? ихняя цитата с этой( https://nim-lang.org/features.html ) страницы ?
или вам не понравился мой вольный перевод ?
> что конкретно ? ихняя цитата с этой( https://nim-lang.org/features.html ) страницы ?Про лажу. Какое-то обоснование будет? Только чур, с общепринятой интерпретацией употребляемых терминов.
> или вам не понравился мой вольный перевод?Скорее, вольный передерг. Да еще и "нимовцы сами пишут".
у вас проблемы с пониманием слова лажа ?
> Да еще и "нимовцы сами пишут"а что не пишут, или вы не умеете читать между строк ?
>> ... The primary benefits gained by this compilation model include incredible portability and optimisationsкомпиляция в Си даёт им очень хорошую переносимость и оптимизацию
без этого хоть сам компилятор хоть программы будут собраны с плохой оптимизацией и переносимостью
Без этого надо реализовывать всё самим. К тому же теряется возможность подключить либы написанные на си. Коих за 40 лет набралось прилично.
да это приличная работа, но это и рубеж зрелости, ведь если ты предлагаешь обществу язык для написания любых программ, а не только хелловорлд, то будь добр продемонстрируй это. Таким экзаменом для языка и является написать/переписать самого себя на самого себя.
А для программ(не компилятора) подключение сторонних либ на си не должно является проблемой(взять тот же го или раст)
> у вас проблемы с пониманием слова лажа ?У вас трудности с пониманием слова "компилятор"?
>> Да еще и "нимовцы сами пишут"
> а что не пишут, или вы не умеете читать между строк ?Пишут обычно прямым текстом. Остальное - "приписывают".
> Пишут обычно прямым текстом. Остальное - "приписывают".а в чём проблема ? прямую цитату с ихнего сайта я привёл, свой вольный перевод предоставил, только отобразил под другим углом, но суть написанного оставил.
Вам не понравилась слово лажа ? замените его на то слово которое будет ласкать ваш слух
о, молодец, нашел наконец к чему придраться
> Хотел почитать опеннет, а теперь мне надо в душ.да, иди подмойся, а то родные наверное уже косо смотрят
> а то что репозиторий языка завален по вашим словам "Сорцы на си представлены специально для хейтеров бинарников" как раз и говорит о незрелости языкаИли о том, что автор решил не мудрить излишне с бутстрапингом.
Увлекательная игра "для компиляции компилятора нужен уже скомпилированный компилятор" даже при более серьезной поддержке (как в мозилловском расте на второстепенных платформах) не всем потенциальным пользователям интересна.
> Или о том, что автор решил не мудрить излишне с бутстрапингом.это и говорит о незрелости языка
go три года назад тоже перешел на "самого-себя", хотя большую часть и транслировали на автомате.
После чего принялись за переписывание и хорошую оптимизацию того что автоматом перегнали из си в go.
>> Или о том, что автор решил не мудрить излишне с бутстрапингом.
> это и говорит о незрелости языкаЭто говорит о том, что полной самодостаточности (self-hosted) нет. Но она для такого проекта как бы даже не контрпродуктивна.
> go три года назад тоже перешел на "самого-себя", хотя большую часть и
> транслировали на автомате.Го стал self-hosted, что немножечко не одно и то же, что и "сам себя скомпилировать".
> Это говорит о том, что полной самодостаточности (self-hosted) нет. Но она для такого проекта как бы даже не контрпродуктивна.до определенного этапа да, но для развития языка это барьер, вернее сдерживающий фактор.
Ведь новый язык создали как минимум для того что-бы преодолеть "сложности старого языка", а если новый язык(компилятор) содержит эти самые сложности от которых пытается избавить других то при развитии его компилятора эти сложности будут только нарастать.
> Здесь наблюдается такая же картина как и с дистрибутивами linux, поменял обои
> добавил пару фич и вуаля готов новый дистрибутив, так и здесь
> Nim и Idris это по сути надстройки над Си со своими шл..ми и блекджеком.А JS по такой "сути" надстройка над асмой ...
Ним вообще-то ближе к паскалю, чем к си. Хотя намешали там много чего (на мой взгялд, даже черезчур). Есть мощная система макросов c доступом к АST, классы из хаскеля, ООП.
Чего нет, так это пользователей и разработчиков, чтобы довести все это до "нормального" уровня - выловить детские баги в компиляторе, std и либах, отполировать синтактические шероховатости.
> Для меня например язык считается взрослым если он как минимум может сам себя скомпилировать и скомпилировать хорошо.Нда, "надстройка над Си" уже намекала на уровень осведомленности в обсуждаемой теме ...
https://nim-lang.org/
> The Nim compiler and tools are all *written in Nim* and licensed under
>> The Nim compiler and tools are all *written in Nim* and licensed underсмотри мой ответ выше
> А JS по такой "сути" надстройка над асмой ...
всё дело в количестве прослоек
а то с таким подходом можно будет называть новой операционной системой виндовс запущенную на виртуальной машине под linux> Ним вообще-то ближе к паскалю, чем к си.
я говорил о возможности собрать самого себя, а не к чему и кто ближе
>>> The Nim compiler and tools are all *written in Nim* and licensed under
> смотри мой ответ вышеИ? Альтернативная интерпретация значения "компилятор" и чтение между строк ("нимовцы сами пишут что их компиляция полная лажа") - не аргумент ни разу.
Компилятор на самом ЯП есть, а то что бэкэндом может выступать не только маш-код ... так и gcc в него уже давно не компилирует сразу.
>>> Nim и Idris это по сути надстройки над Си
>> Ним вообще-то ближе к паскалю, чем к си.
> я говорил о возможности собрать самого себя, а не к чему и кто ближеЯ так понимаю, что наброс с наскоку не удался, теперь будет (абсолютно не интересный мне лично) юлеж и переливание из пустого в порожнее?
> Я так понимаю, что наброс с наскоку не удался...ваш, да
а мне интересно отвечать по теме обсуждения или моих утверждений, а не когда оппонент пытается тебе что-то приписать и на этом выехать в нужное ему русло
>> Я так понимаю, что наброс с наскоку не удался...
> ваш, да а мне интересно отвечать по теме обсуждения или моих утверждений, а неТ.е. по теме ответа не будет?
> когда оппонент пытается тебе что-то приписать и на этом выехать в
> нужное ему руслоЯ разве неправильно процитировал? Тогда еще раз:
>>> Nim и Idris это по сути надстройки над Си
>> Ним вообще-то ближе к паскалю, чем к си.
> я говорил о возможности собрать самого себя, а не к чему и кто ближеКто-кто говорите кому что приписывал?
> Кто-кто говорите кому что приписывал?еще раз мне не интересно обсуждение к чему Ним ближе к паскалю или си, разговор идёт исключительно о бутстраппинге зрелых языков
а "надстройки над Си" если вы читали сообщения выше относилось исключительно к прослойке компиляции
> Для меня например язык считается взрослым если он
> как минимум может сам себя скомпилировать и скомпилировать хорошо.Что-то эдакое насчет жабы и хаскеля я подозревал )
Но ведь и си (если брать за основу компиляторы, умеющие компилировать хорошо, т.е. clang/gcc) см.
http://gcc.gnu.org/ml/gcc/2012-08/msg00015.html:
> 1- The compiler can only be built with a C++ compiler.попадает под этот критерий.
> Для меня например язык считается взрослым если он как минимум может сам себя скомпилировать и скомпилировать хорошо.Сарзу нарисовывается список невзрослых языков : php, bash, SQL и т.п.
Пайк не на даче фо фан писал, он и есть инженер Гоогле.
> Вообще, возникает ощущение, что гугл запилил его для вчерашних студентов. Си они не осилили на достаточном уровне, а работать надо.Идея гугл такая: все должны писать простой в понимании код. Тогда ты типа написал проект, тебе дали новый, а твой отдали на поддержку нубам. Иначе, если код сложен, тебя будут вечно держать на проекте, так как только ты его понимаешь.
Это неоднократно говорилось на презентациях по голангу.
>простой в понимании кодИз https://stackoverflow.com/questions/21326109/why-are-lists-u...
мы можем узнать, что вместо списков в Go следует использовать слайсы с таким замечательным синтаксисом:Delete:
a = append(a[:i], a[i+1:]...) // or a = a[:i+copy(a[i:], a[i+1:])]
Delete without preserving order:
a[i], a = a[len(a)-1], a[:len(a)-1]
Pop:
x, a = a[len(a)-1], a[:len(a)-1]
И что же здесь не так? Автоматичекое управление памятью в Go существует вовсе не для того, что бы программист вообще не понимал, как идет работа с памятью. Наоборот, детали реализации массивов, срезов, списков, отображений совсем не скрываются и их понимание приветствуется.
Представленый код очень даже простой, если ты все-таки ознакомился с тем, как работают срезы. Если очень хочется, то программист может написать однострочные функции обертки для таких "высокоуровневых" операций как delete и pop.
> вместо списков в Go следует использовать слайсы с таким замечательным синтаксисомДа, это превосходная иллюстрация к тому, что значит простой код. Особенно если сравнить это с удалением из массива в C, где придётся использовать memove и realloc для того же, или даже если мы в C забьём на скорость, и будем использовать список, где придётся десятку указателей менять значения, обрабатывая при этом всякие специальные случаи, то этот код -- просто эталон простоты.
В том же rust'е, как и в C, удаление элемента из массива/слайса -- это настолько геморройная операция, что она вынесена в специальную функцию.
> даже если мы в C забьём на скорость, и будем использовать список, где придётся десятку указателей менять значения, обрабатывая при этом всякие специальные случаи.Зачем? Для обоих случаев в односвязном списке достаточно изменить ровно один указатель. И делается это вполне элегантно. Опять таки скорость самого удаления в случае списков выше, а не ниже. У них проблема со скоростью на совсем других операциях, например на поиске элемента для удаления. Сдается мне, тебе стоит повторить теорию.
Подмена понятий "массив" и "список". Срочно учить теорию.
Ты не способен проследить дискуссию длиной в целых три поста? Никто ничего не подменял.
>> даже если мы в C забьём на скорость, и будем использовать список, где придётся десятку указателей менять значения, обрабатывая при этом всякие специальные случаи.
> Зачем? Для обоих случаев в односвязном списке достаточно изменить ровно один указатель.
> И делается это вполне элегантно.Угу, менять надо один указатель и это можно сделать элегантно, но при выполнении ряда условий:
- список _односвязный_, а односвязные списки неудобны, потому что для удаления элемента надо либо иметь указатель на предыдущий элемент, либо перемещать содержимое следующего элемента в этот, что уже неэлегантно и не один указатель, да ещё и не работает с последним элементом
- удаляемый элемент выкидывается, и поэтому не требуется в нём менять значения указателей на что-нибудь типа NULL, во избежание возможных трудноотлавливаемых багов с "висячими" указателями
- список организован не "в лоб", а несколько хитрее, чтобы специальный случай удаления первого элемента не требовал бы специальных телодвижений -- например, это список с заголовкомКстати я не уверен, что эти условия совместимы, что действительно можно придумать односвязный список (в котором достаточно поменять ровно один указатель), с которым не придётся обрабатывать краевых случаев. Двусвязный циклический с заголовком достаточно красивым получается, но там большинство операций -- это изменение четырёх указателей. Плюс подчастую приходится трогать три списочных ячейки, случайным образом разбросанные по памяти, а это потенциально три кеш-промаха.
> Опять таки скорость самого удаления в
> случае списков выше, а не ниже. У них проблема со скоростью
> на совсем других операциях, например на поиске элемента для удаления. Сдается
> мне, тебе стоит повторить теорию.А что теория? Теория говорит о каких-то абстракциях, типа O(1) или O(n). То есть всё что она говорит, это то, что существует такое N, что при всех n>N удаление элемента из массива окажется медленнее, чем удаление из списка. И чё мне с того? При каком N такое случится? Теория отказывается отвечать на эти вопросы, а зря. Ведь если, допустим, это случается при N=10000, то подавляющее большинство моих контейнеров будет удалять элементы быстрее, если я буду использовать массивы, потому что я довольно редко использую массивы из десятков тысяч элементов и больше.
Списки -- это всегда кеш-промахи в промышленных количествах. А раз кеш-промахи, значит алгоритм в целом начинает упираться в скорость доступа к DRAM, а эта скорость никакая. Она десятилетиями наращивает отставание от скорости процессоров. И не видно признаков тому, что этот тренд сломается в обозримом будущем. Насколько я понимаю этот вопрос -- скорость доступа к памяти зависит от размера этой памяти (я подозреваю, что там логарифмическая зависимость), объёмы памяти постоянно наращиваются, и если мы не получаем замедления DRAM с годами, то лишь благодаря самоотверженному труду разработчиков микросхем памяти. Но если мы не получаем _абсолютного_ замедления, то _относительное_ (в сравнении с процессором) тем не менее имеет место.
Процессоры заточены на работу с массивами, а вот рандом-акцесс им даётся сложно, и при таких раскладах, теоретический O(1) может быть медленнее, чем практический O(n). А если мы ещё вспомним, что при удалении элемента из списка надо не забыть скормить освобождённую списочную ячейку в функцию free, то есть дёрнуть тормозную кучу и её структуры данных, то легко может выйти, что O(n) времени на memmove килобайта памяти, вызванный удалением элемента из массива, займёт меньше времени, чем O(1) на удаление элемента из списка.
Последую совету одного финского парня "Talk is cheap. Show me the code".Односвязный список https://play.golang.org/p/rBDrCbJ9zUi
Собственно удаление занимает одну строчку и состоит в изменении одного указателя, место выделено комментарием. Удаление головы также занимает одну строчку и состоит в возвращении указателя на следующий элемент. Никакой специальной обработки последнего элемента, никаких перемещений значений. Никаких апдейтов десятка указателей и прочей чуши.Двусвязный список https://play.golang.org/p/pl7FOfdiUDb
Удаление даже выделено в отдельную функцию, которая принимает только удаляемый элемент. Состоит в апдейте максимум двух указателей. Не четырех, нет
Хых. Мы ушли от общей идеи удаления элемента в вакууме к частому случаю в конкретном контексте. Я не к тому, что я против, я лишь хочу отметить этот момент, для ясности.
Вот фильтрация на C. Я Go не знаю и ставить его мне лень, а синтаксически неверное подражание ему писать не охота, поэтому на C. Но это детали и не важно.struct Vec {
size_t len;
int *buf;
};void filter(int val, struct Vec *vec) {
size_t write = 0;
for(size_t read = 0; read < vec.len; read ++) {
if(vec.buf[read] != val) {
vec.buf[write++] = vec.buf[read];
}
}
vec.len = write;
}Тут виден чёткий последовательный доступ к памяти, который очень хорошо ложиться на стратегии кеширования процессора, и мы видим, что это короче. Код со списками содержит практически такой же цикл, и я не вижу никаких существенных различий между этими циклами *с точки зрения*, простоты как основы *читабельности и возможности поддерживать код*. Но мы видим, что в случае списков, перед циклом и после цикла возникает та самая обработка краевых условий, о которых я говорил.
>[оверквотинг удален]
> }
> vec.len = write;
> }
> Тут виден чёткий последовательный доступ к памяти, который очень хорошо ложиться на
> стратегии кеширования процессора, и мы видим, что это короче. Код со
> списками содержит практически такой же цикл, и я не вижу никаких
> существенных различий между этими циклами *с точки зрения*, простоты как основы
> *читабельности и возможности поддерживать код*. Но мы видим, что в случае
> списков, перед циклом и после цикла возникает та самая обработка краевых
> условий, о которых я говорил.[add]
> Состоит в апдейте максимум двух указателей. Не четырех, нет...Угу. Но это потому что списочная ячейка после удаления перестаёт существовать, отправляясь в свободную память в куче. Это очень часто не так, когда используется список с принудительной связью, чтобы снизить количество мелких аллокаций в куче (хотя это, я думаю, менее релевантно для языков со сборкой мусора, потому что им не надо вызывать free на каждую освобождаемую ячейку, плюс дефрагментация кучи тотальна и условно бесплатна). И в этом случае списочная ячейка продолжит существовать, но в "плохом" состоянии: она будет выглядеть как валидная списочная ячейка включённая в список. Поэтому её указатели стоит отресетить в NULL, или на саму себя (в зависимости от тонкостей реализации списков), а это удваивает количество изменяемых указателей при операциях удаления и приравнивает его к количеству изменяемых указателей в случае вставки. Это вряд ли существенно влияет на производительность, которая в любом случае упрётся в скорость DRAM, но код захламляет. Что опять же не очень важно, поскольку эти вещи всё равно выносятся в inline-функции, но разговор ведь начался с того, что синтаксис слайсов слишком заморочен, и вроде как списки выглядят лучше.
У тебя тоже проблемы с отслеживанием дискуссии на три поста? Вернись и почитай, что именно я оспаривал, а с чем молча согласился. Потом подумай, как написанное тобой относится к моим возражениям. В чем ты сейчас меня пробуешь убедить, мне совершенно непонятно.Отдельно отмечу, что перед циклом я обрабатываю не краевой случай, а условие передачи нулевого указателя и мой код отработает в этом случае корректно, а твой свалится с сегфолтом. Еще веселее, что при всех заумных разговорах о стратегиях кеширования процессора, твоя реализация будет вынуждена при добавлении элемента каждый раз заново выделять память на весь массив и осуществлять его полное копирование, ведь ты забыл предусмотреть хранение размера выделенного буфера в отдельном поле.
> У тебя тоже проблемы с отслеживанием дискуссии на три поста?Естественно. Ты мечешься между "списки быстрее массивов" и "списки писать проще чем массивы", сложно отследить, что именно тебя волнует в данный момент больше. Поэтому, на всякий случай, лучше бить по площадям.
> Вернись и
> почитай, что именно я оспаривал, а с чем молча согласился. Потом
> подумай, как написанное тобой относится к моим возражениям. В чем ты
> сейчас меня пробуешь убедить, мне совершенно непонятно.В том, что а) синтаксис слайсов из Go -- это превосходный и лаконичный синтаксис для работы со "списками", в смысле с контейнерами-последовательностями; б) там где есть такой синтаксис, связные списки не нужны. Причём не нужны не только в стандартной библиотеке, но и в качестве наколенной реализации.
> Отдельно отмечу, что перед циклом я обрабатываю не краевой случай, а условие
> передачи нулевого указателя и мой код отработает в этом случае корректно,
> а твой свалится с сегфолтом.В мой код не будет передан нулевой указатель, в этом нет никакой нужды. Там есть поле len, которого более чем достаточно для того, чтобы функция filter не выходила бы за рамки safe поведения.
> Еще веселее, что при всех заумных
> разговорах о стратегиях кеширования процессора, твоя реализация будет вынуждена при добавлении
> элемента каждый раз заново выделять память на весь массив и осуществлять
> его полное копирование, ведь ты забыл предусмотреть хранение размера выделенного буфера
> в отдельном поле.Мой код, если ты не заметил, не добавляет элементов. В нём даже не реализована неспецифическая операция удаления элемента, есть лишь функция filter, которая де факто элементы удаляет, но специфическим образом. Так что кто из нас "заумнее" -- это ещё посмотреть надо.
Понятно, разговариваешь с голосами в голове, ну или со всеми в этом треде сразу, не различая, кто что говорил. В любом случае не буду мешать.
Где именно упадет твой код, ты так и не понял, а ведь там всего несколько строк. Зато умные слова про кеши процессора знаешь. Молодец, начальство таких любит.
> Понятно, разговариваешь с голосами в голове, ну или со всеми в этом треде сразу, не различая, кто что говорил.Ты всегда, когда у тебя заканчиваются аргументы, переходишь на обсуждение личностей? Ты с самого начала пытался сделать это -- я выше перечислял, основные направления твоих высказываний, и умолчал про то, что ты с самого начала не мог и двух предложений написать на техническую тему, не внедрив в них каких-нибудь своих идей о личностных свойствах собеседника. Но здесь, как-то, ты совсем ушёл от технических аргументов.
Цитирую себя: "Зачем? Для обоих случаев в односвязном списке достаточно изменить ровно один указатель. И делается это вполне элегантно. Опять таки скорость самого удаления в случае списков выше, а не ниже. У них проблема со скоростью на совсем других операциях, например на поиске элемента для удаления. Сдается мне, тебе стоит повторить теорию."Это ВСЁ, что я написал тебе на тему списков. Когда ты с этим не согласился и начал толкать речи про кеши, я подтвердил свои слова кодом. Без каких либо переходов на личности, которые ты себе навоображал. Дальше ты начал разговаривать с голосами в голове и доказывать им неизвестно что. Им, не мне. Так как я не знаю, что они тебя шепчут и на что ты отвечаешь. Какие в этом случае вообще могут быть аргументы с моей стороны? Разве что прокомментировал огрехи в твоем коде, который непонятно что должен был продемонстрировать. Если с твоей точки зрения это уход от технических аргументов, то я уж не знаю, что ты будешь считать таковыми. Наверное только безоговорочное соглашение с твоей ахинеей про апдейт десятка указателей.
> Цитирую себя: "Зачем? Для обоих случаев в односвязном списке достаточно изменить ровно
> один указатель. И делается это вполне элегантно. Опять таки скорость самого
> удаления в случае списков выше, а не ниже. У них проблема
> со скоростью на совсем других операциях, например на поиске элемента для
> удаления. Сдается мне, тебе стоит повторить теорию."
> "Сдается мне, тебе стоит повторить теорию."
> "Без каких либо переходов на личности, которые ты себе навоображал."=)
Не, ты действительно думаешь, что обсуждение того, что мне следует повторить -- это обсуждение технических проблем, а не моей личности?
Я тебя наверное сейчас очень удивлю, но таки это не имело вообще никакого отношения к твоей личности.
Но зато сейчас я с удовольствием перейду на личности и сообщу, что твоя личность в некоторых аспектах имеет развитие моего 4-летнего сына. Он тоже, когда ему указываешь на объективные недостатки в его поведении, например раскидал и не собрал игрушки, вместо их ликвидации устраивает нытье на тему "меня обидели". Шестилетний сын уже так себя не ведет, перерос.
> Я тебя наверное сейчас очень удивлю, но таки это не имело вообще
> никакого отношения к твоей личности.Люди превосходно умеют видеть себя именно такими, какими хотят. А хотят они себя видеть белыми и пушистыми, поэтому даже когда они совершают гадости, они уверены, что они поступили хорошо и правильно. А если и не хорошо, то у них всегда наготове десяток оправданий своему поведению. Люди умеют вытеснять, и видеть в своём поведении только те аспекты, которые им хочется видеть. Так что нет, то что ты не видишь в своих словах перехода на личности, никоим образом не может меня удивить.
> Но зато сейчас я с удовольствием перейду на личности и сообщу, что
> твоя личность в некоторых аспектах имеет развитие моего 4-летнего сына. Он
> тоже, когда ему указываешь на объективные недостатки в его поведении, например
> раскидал и не собрал игрушки, вместо их ликвидации устраивает нытье на
> тему "меня обидели".Если ты указываешь на недостатки поведения своего сына в том же стиле, как и в этом разговоре ты указываешь мне, то в этом нет ничего удивительного. Более того, потенциально ты создаёшь своему сыну кучу психологических проблем, с которыми ему придётся жить всю его оставшуюся жизнь.
Если ты хочешь говорить о недостатках поведения в настоящем, то надо говорить о недостатках поведения в настоящем, а не о недостатках личности, которые привели к этому поведению, и не о мерах, которые человеку следует предпринять, чтобы исправить эти недостатки личности.
Если ты будешь говорить ребёнку о недостатках личности, или даже не о недостатках, а вообще о свойствах личности, ребёнок начнёт считать эти свойства своим неотъемлимым свойством.
Если это непонятно в абстрактном изложении, то представь себе ребёнка, которому один сказали "жадина какая, с братом не хочет делиться", и который когда к нему в следующий раз докопались с идеей поделиться, ответил "естественно я не поделился, я же жадина". Ещё интереснее, если замечания касаются интеллекта -- я вижу вокруг себя множество людей, которые даже не пытаются применять интеллект, потому что заранее уверены, что у них ничего не получится. И я уверен, что в большинстве случаев, им благодарить за это надо родителей. Ну и наконец, если ты своими сообщениями транслируешь ребёнку общие идеи о том, что он плохой (ну или, что его поведение -- это признак "плохости", ребёнку без разницы), то результатом будет ребёнок с самооценкой, которая разрушена в целом, а не в отдельных аспектах.И я бы посоветовал, начав с того, чтобы научиться видеть переход на личности в своей речи, затем совершить ещё один шаг в развитии своей речи, и освоить "Я-сообщения" и говорить не о _объективных_ недостатках поведения, а о субъективных -- не "ты ведёшь себя плохо", а "мне не нравится, когда ты делаешь так-то и так-то". То есть, говорить даже не о свойствах поведения, а о своих чувствах в отношении этого поведения. Почему это полезно можно очень долго говорить, там много интересных последствий, но я не буду этого делать, именно потому, что это долго. Но ты можешь взять и почитать, что-нибудь. Я понимаю, с этим проблема, потому что совершенно неграмотной около-психологической писанины в интернете на порядок больше, чем осмысленных вещей, но вот смотри, это список литературы, которую нам кидали к зачёту по семейной психологии:
Петрановская. Тайна опора: привязанность в жизни ребёнка.
Млодик. Как быть неидеальными родителями.
Гиппенрейтер. Общаться с ребёнком. Как.
Гиппенрейтер. Продолжаем общаться с ребёнком.Эти книжки написаны психологами для не-психологов. Имеет смысл прочесть все, но если ты считаешь, что во фразе "тебе следовало бы повторить теорию" нет перехода на личности, то, мне кажется, что Гиппенрейтер будет наиболее полезной. Я сам не читал её, но насколько я помню обсуждение книжки на семинаре, это довольно грамотно написанная книжка, плюс с Гиппенрейтер я сталкивался по другим вопросам, и считаю, что звание "доктор психологических наук" более чем заслужено ею. И, насколько я помню, там написано как раз то, что нужно тебе, чтобы осознать, что именно ты говоришь, когда открываешь рот.
Мне ты можешь говорить как тебе угодно, и что тебе угодно -- я в достаточной степени сформировавшаяся личность, чтобы пропускать любые твои замечания о моей личности через фильтры психологических защит, ребёнок же ещё не имеет таких возможностей. И если ребёнок обижается на твои слова, значит _ты_его_обижаешь_. Особенно если мы говорим о ребёнке 6 лет, который ещё не утратил детскую непосредственность. Он пока лишь подошёл к возрасту утраты её.
> Шестилетний сын уже так себя не ведет, перерос.
Или может не просто подошёл, а прошёл через эту утрату. Или может ты, к его шести годам, научился говорить ему об "объективных" недостатках поведения, как о субъективных. Или не как о субъективных, но не в обидном ключе. Или, что скорее (и хуже), он адаптировался: дети учатся быстрее родителей.
Ты серьезно думаешь, что кто-то будет слушать советы по воспитанию детей от человека, чье психологическое развитие в отдельном аспекте уступает нормальному шестилетнему ребенку? Тут мне остается только повторить известное высказывание:"папе своему советы давай, если он у тебя конечно есть" и попрощаться.P.S. Ошибку в своем коде ты хотя бы нашел? Вопрос риторический.
> Ты серьезно думаешь, что кто-то будет слушать советы по воспитанию детей от
> человека, чье психологическое развитие в отдельном аспекте уступает нормальному шестилетнему
> ребенку? Тут мне остается только повторить известное высказывание:"папе своему советы
> давай, если он у тебя конечно есть" и попрощаться.Ну, что я могу на это сказать? Посочувствовать ребёнку, имеющему такого отца? Я тебе дал список литературы -- если ты не веришь моим советам, читай советы специалистов. Не хочешь читать, ну так будь мужиком, признайся себе в этом честно, и не придумывай себе оправданий, сваливая ответственность за эти решения на уровень моего развития.
> P.S. Ошибку в своем коде ты хотя бы нашел? Вопрос риторический.
Нашёл, но я уверен, что это не та ошибка, о которой ты говоришь. У меня есть подозрения, о чём ты говоришь, но это настолько глупо, что я не хочу даже говорить об этом, чтобы нечаянно не обидеть тебя: вдруг я ошибаюсь и ты о чём-то другом, не столь глупом?
> скорость самого удаления в
> случае списков выше, а не ниже.Ну-ка, рассчитай нам скорость удаления последнего элемента из массива и из односвязного списка размером 100 элементов.
А если массив/список на пару десятков тысяч элементов длиной в сотню байт каждый и надо удалить не первый или последний, а что-то в средине?
Так мы медленно пришли к проблеме выбора корректного контейнера. В Go вам всего хеш-таблица, и массив со слайсом.
Ну если для тебя использовать стандартную либу западло, а написать реализацию связного списка самому является слишком сложной задачей, то наверное в Go тебе еще рано. Поищи себе ЯП в котором связные списки есть на уровне языка. Интересно, есть ли такой вообще.
C++?
Java?
C#?
Я должен писать список под каждый тип, или через interface{} сделать?
Go generate не предлагаете?
На экзамене валить не будете?
> C++?
> Java?
> C#?
> Я должен писать список под каждый тип, или через interface{} сделать?
> Go generate не предлагаете?
> На экзамене валить не будете?Ох, сорян. На уровне языка. На уровне языка у меня инструментов, чтобы не городить в стандартной и в сторонней либе кучу костылей, завязанных на рантайм и тайп ассерты
> Ох, сорян. На уровне языка.Заметь, это не я первым предложил.
> Я должен писать список под каждый тип, или через interface{} сделать?
В зависимости от задачи. Причем само собой писать под каждый тип вручную не нужно, достаточно общий шаблон. Еще ты почему-то забыл самый практически применимый вариант - писать под конкретный интерфейсный тип.
> На уровне языка у меня инструментов, чтобы не городить в стандартной и в сторонней либе кучу костылей, завязанных на рантайм и тайп ассерты
И в go они тоже есть.
> Go generate не предлагаете?
Почему нет? Именно его и предлагаю, тем более, что он решает более широкий класс задач, чем дженерики.
> Ну если для тебя использовать стандартную либу западло, а написать реализацию связного
> списка самому является слишком сложной задачей, то наверное в Go тебе
> еще рано. Поищи себе ЯП в котором связные списки есть на
> уровне языка. Интересно, есть ли такой вообще.Это есть в LISP. Но ни в лиспе, ни где-либо ещё я не буду создавать список из 10k элементов. Если так уж всё упирается во вставки и удаления, то напрашиваются оптимизации массива, а не список из 10k элементов.
Во-первых, можно пересмотреть алгоритм, которому нужно вставлять и удалять, и что-нибудь в нём поменять, с тем чтобы либо не надо было бы вставлять/удалять, либо чтобы при вставках/удалениях можно было бы игнорировать порядок элементов. Во-вторых, операции вставки и удаления можно выполнять батчами по нескольку штук. В-третьих, на крайняк, можно создать что-то a la gap-buffer'а, имеющего N gap'ов, что, в среднем, поделит время вставки/удаления на N (если N на два-три порядка меньше 10000), ценой увеличения времени рандом-акцесса с O(1) до O(log(N)).
Первые две альтернативы, кстати, вполне себе объединяются в одну: если совсем отказаться от упорядоченности нельзя, то элементы можно вставлять в конец массива, удалять их можно тоже с конца массива, предварительно переместив их туда операцией swap. А перед операциями требующими упорядоченности выполнять сортировку массива каким-нибудь алгоритмом, заточенным на сортировку "почти отсортированных" массивов, который будут давать "почти линейное" время сортировки. Или их можно не объединять, но придумать свой lazy-"процессор" вставок/удалений, который получая запросы на вставки/удаления будет лишь записывать, что надо сделать, но ничего не делать, а когда придёт время, он возьмёт список вставок/удалений, оптимизирует его, переупорядочив их так как ему удобнее и выполнит одним проходом по массиву. Это будет гораздо сложнее, чем push+swap_remove+sort (что минус с точки зрения возможности дальнейшей поддержки кода), и не факт, что даст выигрыш по скорости, но если заняться нечем и хочется реализовать свой контейнер, то отличная практика для скиллов составления алгоритмов.
Если вставка/удаление в случайные места массива тормозит, и требуется оптимизация, то замена массива на список -- это не оптимизация, а жест отчаяния. Если же массив не тормозит, то тем более не стоит заменять его на список. В lisp'е можно создать список вместо массива, но только если этот список достаточно мелкий, и если это происходит в коде, производительность которого нас не колышет, и это в lisp'е, просто потому что в нём очень удобно работать со списками, гораздо удобнее чем с массивами.
Так и представляю себе slab-аллокатор для ОС или драйвер для какого-нить контроллера написанный на го без ручного управления памятью, чтоб отдать нубам и чтоб не сложно было.
Кроме slab-аллокаторов и драйверов для контроллеров, конечно же, софт вообще нигде и никакой не нужен и писать его незачем.Почитав комменты на опеннете в очередной раз порадовался, что я не программист а просто сисадмин, которому иногда надо написать код для решения прикладной задачи. Можно взять Go, например, и решить всё, что нужно было с приемлимой скоростью и без избыточного головняка с управлением памятью, сэкономив себе при этом кучу времени благодаря стандартной библиотеке. Спасибо, Пайк & Co. Ну и в целом, спасибо вселенной, что можно быть свободным от перемывания костей ЯП, какой «православнее».
Ту потом свой хеллоу-ворлд запусти через strace и посмотри на результат своих "без головняков с управлением памятью".
Дай мне хоть олну причину для того, чтобы это делать, если скорость работы на порядок выше минимально необходимой, код работает корректно и я сделал за день то, на что раньше уходили недели? Чем вывод strace читать, я лучше лишний раз друзей повидаю или вот комментарий на опеннете оставлю пока барышня чай заваривает.
"для решения прикладной задачи" вам хватит и шелла/перла/питона. Зачем городить огород с го?
"вам хватит и шелла/перла/питона"
Golang пошустрее будет и системных ресурсов жрет поменьше. Гвоздь можно забить лбом, камнем, молотком и с помощью специализированного инструмента. Результат будет один, но вот процесс будет отличаться.
Так и есть, и действительно долго хватало Питона с Башем ну буквально для всего. Но со временем «всего» стало в десять раз больше, а тайминги стали короче, и Питона перестало хватать. Переписывание же прямо в лоб на Го дало прирост скорости настолько большой, что пока всего не станет раз в тридцать больше, можно не тратить время ни на какие оптимизации и просто оставить как есть. То, что можно написать на Баше я пишу на Баше. А что нельзя — то сразу на Го, чтобы потом снова не переписывать. Это, конечно же, совершенно неправильно, и софт так не разрабатывют, и писать надо всенепременно на Си с ручной оптимизацией на ассемблере, но мне моё время дорого и, как я уже писал выше, мне его есть чем занять кроме работы.
На любом языке можно непонятно писать. Знаю нескольких индивидов, которые намеренно усложняют написанный код.
Я тоже знаю. Все они, почему-то, любят Rust, что настораживает меня в отношении этого языка.
ЧСВ и выпендреж. И только
Вы абсолютно правы. И обще известный факт в том, что главная фишка Go - защита от дурака и от "художника", чтобы все люди писали простой тупoй код в котором сложно напортачить, сложно перемудрить и который легко понять и поддерживать. А в качестве бонуса даётся внезапно очень неплохая производительность.
> Си они не осилили на достаточном уровне, а работать надо.ты не поверишь, но именно для этого его и запилили, цель достигнута. язык с защитой от дурака, ограниченным функционалом. щщщикарно!
> Как язык лучше всех Idris. Но пользоваться им нереально.Посмотрите тогда на Ocaml. Если использовать его в паре со стандартной библиотекой Core, то это фактически единственный ML-подобный язык, которым реально удобно пользоваться.
Это тот который из-за кривизны синтаксического анализатора не поддерживает оформление фигурных скобок по GNU нотации ?
Есил ты пытаешься идти против мейнстрима, то в любом языке ты за это будешь получать по голове. А по поводу GNU-нотации: ты явно пытаешься делать что-то неправильно.
Прошу простить великодушно, однако у вас какая-то особая возбудимость на вопрос. Вы невнимательны. Кто-то говорил что-то против мейнстрима ? Но я вас прощаю. У меня лишь пара вопросов. К чему вы упомянули слово мейнстрим ? Что вы имеете в виду говоря о том что я делаю что-то неправильно ? Ведь я не говорил в своем вопросе о том что я что-то делаю.
> Что вы имеете в виду говоря о том что я делаю что-то неправильно ? Ведь я не говорил в своем вопросе о том что я что-то делаю.Ты ничего не делаешь, но рассказываешь всем, как правильно, — вот что ты делаешь неправильно.
Рискну предположить что у вас аналогичная неприятность что и у предыдущего автора. Вы тоже невнимательны. Смиренно прошу указать мне где я что-то утверждал о правильности чего бы то ни было. Я лишь задаю вопросы. На которые вы не можете дать конкретных ответов. Жалкие высказывания которые я получаю лишь подтверждают мои опасения. Предыдущий автор утверждал что я что-то пытаюсь делать, при том что я этого не говорил, вы утверждаете что я ничего не делаю, при том что я этого тоже не утверждал. Вы уж определитесь, господа, что конкретно вы имеете ввиду. Господа, не теряйте лицо, сконцентрируйтесь. Постарайтесь быть логичными в своих суждениях.
Анон не может потерять лицо. ;)
> Я лишь задаю вопросы.Хреновый из тебя Сократ.
> Это тот который из-за кривизны синтаксического анализатора не поддерживает оформление
> фигурных скобок по GNU нотации ?Это тот, в котором есть своя нотация для оформления кода.
В Арче прилетела обнова, которая на 392 Мб больше чем 9 версия, спрашивается, откуда такой размер?
обновись, уже 1.10-2 прилетело (исправили)
https://git.archlinux.org/svntogit/packages.git/log/trunk?h=...
Язык, который отчаянно пытается избежать ООП, но вместо того чтобы предложить более гибкую систему типов взамен, мастерит костыли. Язык в котором если нужно поместить данные разных типов в коллекцию нужно делать коллекцию пустых интерфейсов.
Язык, в котором изначально заложено ключевое для ООП понятия интерфейса, не может избегать ООП.Можно сказать, что Go избегает C++-подобного ООП, с его наследованием. Если же под ООП понимать Smalltalk, то в Go вполне себе ООП.
> Можно сказать, что Go избегает C++-подобного ООП, с его наследованием. Если же
> под ООП понимать Smalltalk, то в Go вполне себе ООП.Интересно, что вы хотели сказать. Что в Smalltalk нет наследования, или что в Smalltalk есть интерфейсы, как отдельная сущность, или что в Smalltalk нет upcasting и downcasting? Я бы побоялся сравнивать Go с таким мастодонтом, как Smalltalk - не дорос он ещё, даже Java и C# ещё не доросли.
Тут надо зрить не в синтаксис и детали реализации, а в корень, в смысл вещей.Гошные интерфейсы это и есть обмен сообщениями между объектами, только с проверкой времени компиляции. Сам объект не в курсе, что он реализует интерфейс.
> Язык в котором если нужно поместить данные разных типов в коллекцию нужно делать коллекцию пустых интерфейсов.А как надо было делать в типизированном ЯП? Покажи. Заодно раскрой, как это связано с ООП.
ООП давно не в моде.
А нехер помещать данные разных типов в коллекцию.
Давайте тогда сделаем так, чтобы мне не нужно было их кастить к тому единственному типу, который я туда положил, когда я хочу их получить назад и своего, например "container/list".
Гугловцы сами заявляли, что Go для неопытных студентиков, которые только-только из универов пришли, типа чтобы не накосячили давайте им просто руки свяжем
За спиной
это для тех студентов которые учат Си на первых курсах ?
а может вы что-то приврали ?
Сейчас и ЕГЭ можно на Си здавать.
> Сейчас и ЕГЭ можно на Си здавать.
> здавать.Здавальщикам виднее.
Чтобы на С++ писать, его недостаточно "изучить"
"The key point here is our programmers are Googlers, they’re not researchers. They’re typically, fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They’re not capable of understanding a brilliant language but we want to use them to build good software. So, the language that we give them has to be easy for them to understand and easy to adopt."
– Rob Pikehttps://channel9.msdn.com/Events/Lang-NEXT/Lang-NEXT-2014/Fr... , 21:20
Это все, что нужно знать о Go приличному человеку.
>21:2020:44
Полная противоположность Go с этой точки зрения - Perl. Интересно, "приличные люди" им владеют или он для них слишком сложный и непонятный?
за приличных людей не скажу, но самом пишу в основном на Go, а раньше писал на Perl (и учился на нём), всё ок, брат жив (но его нет)
Дык, я и сам такой. Разве что Perl был далеко не первым и я по-прежнему его активно использую для части задач. Но интересно всё-таки мнение "приличных людей" :)
И что в этом плохо? Или это что-то из рассказов прос настоящих мужиков, которые бреются бензопилами?
Буквально вчера повторно наткнулся на перевод Виктора Черкасова (n0xi0uzz) (тут -> http://netsago.org/ru/docs/1/16/) статьи GoForCPPProgrammers (тут -> https://github.com/golang/go/wiki/GoForCPPProgrammers).Привёл обе ссылки, так как перевод слегка устарел и чутка отличается от оригинала.
P.S. Ни разу не фанат Go, но считаю что ознакомится с этой статьёй всё же стоит. Хотя бы для формирования собственной точки зрения, хоть на чём-то основанной...
P.P.S. Там же, на Netsago.org есть подобная статья про Objective-С (http://netsago.org/ru/docs/1/15/). Тоже в переводе от n0xi0uzz.
UPD: Включите же уже наконец мне фильтр ввода с поддержкой html-тегов для комментов. Злоупотреблять не буду. :-)
Статья(оригинал) в целом годная, но есть в ней одна повторяющаяся ошибка. В go не передачи по ссылке, только по значению. Все случаи, когда в статье упоминается передача по ссылке, на самом деле происходит передача значения. Другое дело, что значением является структура с указателем в одном из полей.
Время нынче такое, что если нет ISO/IEC стандарта, то использовать язык можно только ради сиюминутных поделок -- для серьезных приложений нужна прежде всего стабильность. У нас есть софт (с, фортран), который почти 20 лет (с 1999 г.) используется практически без каких-либо изменений и только периодически пересобирается под новое окружение и железо. Я даже представить себе не могу, что было бы сегодня, если бы тогда не уговорили заказчика писать под солярис -- заказчик очень хотел NT. Сегодня все это работает и под солярой 20-летней давности и под разножёпицей нынешних линуксов.
Да где эти серьёзные приложения? Они есть, конечно, но захлынула масса как раз одноразовых приложений. А вот тут-то раздолье...
> Время нынче такое, что если нет ISO/IEC стандарта, то использовать язык можно
> только ради сиюминутных поделок -- для серьезных приложений нужна прежде всего
> стабильность. У нас есть софт (с, фортран), который почти 20 лет
> (с 1999 г.) используется практически без каких-либо изменений и только периодически
> пересобирается под новое окружение и железо. Я даже представить себе не
> могу, что было бы сегодня, если бы тогда не уговорили заказчика
> писать под солярис -- заказчик очень хотел NT. Сегодня все это
> работает и под солярой 20-летней давности и под разножёпицей нынешних линуксов.То что у вас есть сейчас возможность собирать софт под современное рабочее окружение и железо, как раз таки заслуга не Солярки, а разножёпых линуксов, которых кроме приверженности к GNU порой действительно больше ничего не объединяет. Но и это, на самом деле довольно много и ценно само по себе.
А тот же компилятор Go входит в поставку и набора компиляторов GNU GCC и в виде самостоятельного кроссплатформенного компилятора.
P.S. Ни разу не фанат Go. :-)
> Время нынче такое, что если нет ISO/IEC стандарта, то использовать язык можно
> только ради сиюминутных поделок -- для серьезных приложений нужна прежде всего
> стабильность.Муахаха. С релиза 1.0 ни разу обратную совместимость не сломали, а вот в компиляторах стандартизированных плюсов ломают регулярно.