Dorian
Хаскель.
Ну мне б грамотное читло с примерчиками не хеловорлд
Roman
Хаскель.
и привет STW?
Сергей
Хаскель.
А как там решается проблема связей
Dorian
А как там решается проблема связей
Та не проблема. Просто хочется другую парадигму изучить и понять
саша
Ну мне б грамотное читло с примерчиками не хеловорлд
Курс Москвина на степике, не читло, но на русском лучше ничего не найти
саша
и привет STW?
Привет что?
Алексей
ну всё, хаскель упомянули, ща Pawel гневно набежит
саша
А как там решается проблема связей
Там разделяются данные и поведения.
Сергей
Сергей
Как можно всё это заюзать в хаскеле
саша
А можно пример кода?
main = putStrLn "hello, world!"
саша
Как можно всё это заюзать в хаскеле
Не совсем понятно пример кода чего вам нужен
Roman
Привет что?
stop the world
Алексей
stop the world
а причём тут stop the world?
Dorian
ГэЦэ?
Сергей
Не совсем понятно пример кода чего вам нужен
Пример работы с бд. Что-то вроде ORM, только в хаскеле (ясно, что там объектов нет).
Roman
а причём тут stop the world?
https://making.pusher.com/golangs-real-time-gc-in-theory-and-practice/
Алексей
А как там решается проблема связей
А что за проблема связей?
Сергей
А что за проблема связей?
Связей между таблицами... Я так понимаю человек до меня задавал вопрос про FOREIGN KEY, а кто-то ему посоветовал хаскель
Сергей
Кстати, в gorm уже появилась автомиграция с внешними ключами?
Сергей
Коллеги, подскажите, есть ли какое-нибудь более удобное решение для работы с бд кроме gorm?
Dorian
Удобно не использовать ОРМ
Anonymous
Вообще пока сейчас разбирался с горм реально подумал что без неё проще было бы
Anonymous
Dk
Помогите. Как понять, вот создаю я хандлеры, или делаю через Mux допустим, затем http.ListenAndServe и оно однопоточное? Всмысле, при запросе нескольких клиентов где мне надо разваливаться на отдельные потоки (или не надо и оно уже встроено?)
Daniel
встроено
Aleksandr
автоматически
Dk
Кайф. Спасибо вам.
Roman
https://github.com/romshark/Go-2-Proposal---Immutability/issues/6
Roman
в таком случае интерфейс определяет, что опредлённые методы не должны мутировать объект имплементирующий этот интефейс, хорошо ли это? должен ли интерфейс иметь право запрещать мутации на определённых методах?
Je
Помогите. Как понять, вот создаю я хандлеры, или делаю через Mux допустим, затем http.ListenAndServe и оно однопоточное? Всмысле, при запросе нескольких клиентов где мне надо разваливаться на отдельные потоки (или не надо и оно уже встроено?)
Го настолько прост, что на многие вопросы ты можешь ответить сам и прояснить, здесь видно, как принимается соединение и обработка в горутине) https://golang.org/src/net/http/server.go#L2805
Алексей
скорее нет, чем да
Roman
вот надо подумать
я пока что не вижу проблем. Но может есть таки кейсы в которых это бы было недопустипо? В таких ситуациях без помощи зала… вернее community не обойтись
Алексей
так как всё равно нет запрета на мутацию вложенных по указателю данных, как я понял
Алексей
то есть имеет ли смысл выносить такие тонкие вопросы в язык?
Je
Обнаружил в горилле вебсокетах такое - вместо timeout автор оперирует понятием deadline и ждет time.Now()+таймаут, потом вычитает из него time.Now(), кто знает, зачем это было сделано? https://github.com/gorilla/websocket/blob/master/conn.go#L393
Roman
так как всё равно нет запрета на мутацию вложенных по указателю данных, как я понял
запрета на мутацию вложенных по указателю данных? ты о чём?
Алексей
запрета на мутацию вложенных по указателю данных? ты о чём?
ну вот структура, в ней указатель на другую структуру, метод не меняет саму исходную структуру, но меняет структуру по указателю (сам указатель не меняется при этом)
Je
https://github.com/gorilla/websocket/issues/52
Интересно, спасибо, я уже хотел было PR повесить)
Roman
https://github.com/golang/go/issues/27443
Je
так в стандартной библиотеке сделано - там тоже не таймаут, а дедлайн. позволяет не хранить внутри "время последней операции"
Тогда неконсистентно, здесь уже таймаут, например, в клиенте https://github.com/gorilla/websocket/blob/master/client.go#L71
Je
Все в го так говорят
Daniel
смысла нет со мной это обсуждать, тем не менее
Roman
ну вот структура, в ней указатель на другую структуру, метод не меняет саму исходную структуру, но меняет структуру по указателю (сам указатель не меняется при этом)
type Object struct { parent *Object } func (o *Object) SetParent(newParent *Object) { return o.parent = newParent // Mutation } func (o const *Object) ReadOnlyMethod() { // You can’t call a function with a non-const receiver // on an immutable receiver „o“ o.parent.SetParent(&Object{}) // Compile-time error }
саша
Я конечно понимаю, что писать const *const Object неприятно, но что поделать, если в го всё мутабельно по дефолту
Алексей
мммм прям крестами запахло
саша
мммм прям крестами запахло
ну так ведь это реально разные вещи и значат они совершенно разное. const *Object значит что указатель нельзя поменять, а *const Object значит, что память на которую указывает указатель менять нельзя.
Алексей
ну да, но всё же
саша
Ещё нужно добавить оператор &const
.
Жесть
саша
Жесть
Ну иначе иммутабельность в го будет кривая
саша
И придётся снова городить костыли, чтобы срезать углы
Roman
Странное на самом деле. Сразу не увидел. У тебя что нету разделения на const *Object и *const Object? Непорядок
да вот я и не знаю, стоит ли так усложнять или не стоит. потому-что тогда у нас 3 вариации: 1. "мутабельный указатель на иммутабельный объект" 2. "иммутабельный указатель на мутабельный объект" 3. "иммутабельный указатель на иммутабельный объект" может стоит облегчить сиё дело в Go и если указатель иммутабельный то и объект тоже?
.
Честно говоря от таких извращенских конструкций чуть воротит
.
Начинаешь задумываться а надо ли оно))
Roman
Начинаешь задумываться а надо ли оно))
надо, иначе бы нам не нужны были типы, компиляторы и т.д. ибо нафиг безопасность!
Daniel
так
Daniel
2 и 3 - это одно и тоже, иначе мы с ума сойдем
Daniel
я тут понял, что в пропозал я сегодня не напишу, поэтому кратко отчитаюсь здесь
Daniel
вариантов два: 1. мы взяли нечто, и присвоили его иммутабельной переменной. оно стало иммутабельным 2. мы зяли нечто, сделали его иммутабельным и присвоили переменной
саша
2 и 3 - это одно и тоже, иначе мы с ума сойдем
А тут никак, либо только один const *Object, либо добавлять модификатор указателя и появляется 4 комбинации вместо 2-х. Это же комбинаторная логика.
Daniel
по эффектам это должно быть ± одно и то же
Daniel
но!
Daniel
парадигма разная
Daniel
и мне кажется, что парадигма 2 лучше подходит для go - у нас переменная появляется позже сущности