поэтому без implicit cast - обратная совместимость с Go 1.x не может быть гарантирована

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

😞

@Romshark

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

данный proposal не ломает совместимость. То что он фактически ломает её explicit cast’ом - это ошибка, которую надо исправить

потому-что Go не systems programming язык (IMHO), зачем писать интерпретатор на Go 🤔

Потому что проще всего встроить в Go интерпретатор, способный родным способов вызывать код на Go, если он написан на Go

моё имхо обосновано) но я не понимаю смысл проекта) он серьёзный? или это просто ради фана?

Он серьёзный. Там даже два проекта — сам язык и построение сообщества. Контекст был в докладе на GoWay, в ближайшие дни постараюсь написать текстом

Он серьёзный. Там даже два проекта — сам язык и построение сообщества. Контекст был в докладе на GoWay, в ближайшие дни постараюсь написать текстом

Но мб взять что то готовое?

„Gosh is an interpreted language for Go ecosystem written in Go.“ он нацелен решить какие-то конкретные проблемы в экосистеме?

Отсутствие интерпретируемых встраиваемых языков для Go с живым сообществом

Отсутствие интерпретируемых встраиваемых языков для Go с живым сообществом

https://github.com/google/skylark

Про готовое тоже напишу. Если краткого — нет живого

Не?

12 дней назад коммит

Вполне живое

Их много разных. Но живых, больше чем с одним активным контрибьютором, особо нет

Их много разных. Но живых, больше чем с одним активным контрибьютором, особо нет

Скайларк выше

Ну skylark не про то почти полностью

Он живой, более 1 контрибьютера

Это не язык программирования :)

Ну skylark не про то почти полностью

Язык? Язык. Интерпретатор? Интерпретатор. На го? На го

Skylark is a dialect of Python intended for use as a configuration language. Like Python, it is an untyped dynamic language with high-level data types, first-class functions with lexical scope, and garbage collection

Я не хочу делать язык для описания конфигураций

Я не хочу делать язык для описания конфигураций

Ну это ограниченный сабсет питона

Он не только под конфигурации катит

Первое предложение в твоей собственной цитате

Они не хотят его развивать в язык более общего назначения

Первое предложение в твоей собственной цитате

Ну при всем при этом там ограничений достаточно мало чтобы он подходил для весомого куска задач общего назначения

Ну и более одного контрибьютора — это очень условно: https://github.com/google/skylark/graphs/contributors

Хорошо, я не буду больше спорить :)

Добавлю только, что я его видел, трогал и общался с Аланом

Ок)

Добавлю только, что я его видел, трогал и общался с Аланом

Ну можно просто с этого и начинать)

Сразу тогда напишу, что то же относится к Anko, Neugram, Goby, Agora и к разным вариантам Lisp, Lua и JS

Ого сколько gosh'ей на гитхабе

Всем привет! Расскажите, зачем вообще го нужна?

😁 Олег в разнос пошел

Олег, где макет?

Всем привет! Расскажите, зачем вообще го нужна?

Чтобы проверять, что err не равно nil.

@madgopher так в чем плоха модель памяти в Го? Расскажи пожалуйста

@madgopher так в чем плоха модель памяти в Го? Расскажи пожалуйста

+1

как назвать функцию

которая результат записывает в мап

ну обычно getSomeShit

если возвращает

а как обозвать assignSomeStat ?

или как

add, write, create, update, Append, post

writeStatsFromQuery ?

там sql

writeStatsByQuery?

вообще по солид функция которая возвращает записи и которая записывает должны быть разными

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

особенно для статы

add, write, create, update, Append, post

put

но хороший нейминг и слабая связность лучше, чем плохой нейминг и слабая связность

put

👍 как не пришло такое в глову

runQueryAndPutStats хорошо говорит что функция делает

но and свидетельствует о слабой связности

которая результат записывает в мап

Set же

ты как будто говоришь о том что херого код пишешь)

set мне кажется меньше подоходит, там словарь, а сет скорей для сколярных переменных

Ещё раз здравствуйте! Не подскажете, как можно реализовать это самое переиспользование *sql.DB? Конкретно сейчас юзкейс довольно простой: 1. Подключаюсь к БД в main() 2. В том же main() стоят http.Handler() на контроллеры, например Registration(w http.ResponseWriter, r *http.Request) 3. В нём проверяются введённые данные и вызывается func (u User) Create() Собственно, как передать *sql.DB в эту функцию? Или где почитать о контекстах?

Мне уже предложили реализовать такой middleware: func RegistrationHandler(db *sql.DB) http.HandlerFunc { return Registration(w http.ResponseWriter, r *http.Request) { //use db db.Query(...) } } Но мне это не особо нравится, хочется либо контекста, либо элегантности.

Мне уже предложили реализовать такой middleware: func RegistrationHandler(db *sql.DB) http.HandlerFunc { return Registration(w http.ResponseWriter, r *http.Request) { //use db db.Query(...) } } Но мне это не особо нравится, хочется либо контекста, либо элегантности.

реализуй все хендлеры как методы структуры и храни коннект к базе в этой структуре

а чем это неэлегантно?

самый простой и элегантный путь

реализуй все хендлеры как методы структуры и храни коннект к базе в этой структуре

То есть, реализовать упрощённую версию ОРМ?

То есть, реализовать упрощённую версию ОРМ?

можно и так

То есть, реализовать упрощённую версию ОРМ?

насколько я понял, Андрей про https://golang.org/pkg/net/http/?#Handler, можно реализовать интерфейс Handler, и в самой структуре хранить коннект к бд и прочее

реализуй все хендлеры как методы структуры и храни коннект к базе в этой структуре

Ха, дошло: это скорее предложение реализовать свой фреймворк, чем ОРМ? То есть, свой кастомный вариант контекста, где ядром выступает моя структура и её методы?

насколько я понял, Андрей про https://golang.org/pkg/net/http/?#Handler, можно реализовать интерфейс Handler, и в самой структуре хранить коннект к бд и прочее

Надеюсь, у нас с вами совпало понимание?

причем тут ОРМ, и фреймворк я не понял, но вроде бы вы начали думать в правильном направлении

причем тут ОРМ, и фреймворк я не понял, но вроде бы вы начали думать в правильном направлении

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

@marperia вот так попробуйте https://habr.com/post/329582/ мне понравилось, осталось только привести к божескому виду.

А кто-нибудь знает, как (можно ли) реализовать нечто вроде глобального контекста, чтобы не лезть во все методы и не переписывать нахрен бизнес-логику?

Спойлер: в текущей Б-Л используется db.Close() в каждой сраной функции.

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

вы можете сделать отдельно структуру App у которой будут реализованны хендлеры, отдельно структуру BD у которой будут реализованны методы работы с базой и первая будет зависть от второй через интерфейс

казалось бы, где связь между бизнесс логикой и db.close)

на самом деле, только таким образом на го и можно построить поддерживаемую кодовую базу

вы можете сделать отдельно структуру App у которой будут реализованны хендлеры, отдельно структуру BD у которой будут реализованны методы работы с базой и первая будет зависть от второй через интерфейс

Ну да, но это не то, чтобы решает мою проблему. То есть решает, конечно, но это всё равно переписывание всех методов.