Kirill
нужен будет норм дизайнер, который сделал бы тебе нормальный лендинг и брендинг — напиши. дам контакт
Kirill
я облако своё уже второй год пишу
Kirill
и мне ещё, как до луны эфиру
Roman
нужен будет норм дизайнер, который сделал бы тебе нормальный лендинг и брендинг — напиши. дам контакт
для начала нужно поднять нормальный MVP. Мы помоему 3 раза всё это дело переписывали, начали тогда с вообще с Node.js потом нахер всё бросили. Теперь понимаю что буду переписывать всё на Go
Kirill
Kirill
просто времени не хватает
Roman
просто сделали ошибку что погнались за слишком большим "оно умеет всё, оно PaaS платформа" хотя нужно было сфокусироваться на файловой системе отдельно.
чуть позже была у нас встречка с owncloud.com в Штутгарте, они хотели нас в рабство завести
Kirill
я сейчас качу в прод самохилку
Kirill
посмотрим, как будет жить
Roman
короче проект наверное года 2 находился в стадии R&D
Roman
хм?
Kirill
я сейчас качу в прод самохилку
херовина пережила 50 прогонов jepsen'ом при кроссдатацентерном кластере
Roman
да потому-что нода совершенно была непригодна для этого задания.
1. javascript сам по себе язык не очень для большого "монолита"
2. closed source никак не реализуешь с нодой
3. performance, она просто сосёт на простой операции по древу, потому-что блокирует event loop и всё вообще нахрен встаёт, а писать C++ модули для логики так себе идея.
Roman
нет, не просто, там речь шла о распределённой файловой системе. Думаю этим всё сказано без лишних деталей. Там основная часть логики в сервере а не в бд.
Бд там в идеале должна быть kv, потому-что её легко распределять по узлам.
Дело в том что архитектура планируется таким образом чтоб это было удобно для пользователя. Поставил второй комп, поставил на него контейнер, связал компы в кластер в UI'ке облака - вуаля.
Roman
там стороняя БД вообще никак не годится, потому-что это усложняет деплой и добавляет сложности, а "QubeOS" (как мы её называли) можно просто блоками собирать и растить
Roman
В идеале я бы тут вообще взял Rust. Если бы я был не человеком а демиургом и мог бы писать код 128 часов в сутки))
Но на расте писать в среднем в 3-4 сложнее и дольше, поэтому Go тут самый лучший компромис
Roman
ибо таки Go это не безопасный язык, всегда можно упустить segfault, race condition etc. А это для монолита который работает у клиента "дома" просто катастрофа
Roman
да что там говорить... банально иммутабельных типов нет
Roman
но чёрт подери он простой и на нём я смогу своими силами поднять MVP
Kirill
Kirill
Kirill
и пошёл писать
Alexey
да там всего не хватило))
и опыта, и денег, и контактов. Проект пока заморожен ибо баблы нужны, но не свёрнут
А жаль, меня прямо-таки заинтересовало.
Sergey
коллеги доброй ночи начинаю изучать раббит в го И есть вопрос сделал демона который читает очереди и выдирает из них данные Но у меня вопрос как сделать так чтобы вычитывать только часть данных а не все подряд Тоесть например у меня очередь итз 1000 а мне надо взять только 10 Код https://play.golang.org/p/tq03MoG7Juh
Roman
А жаль, меня прямо-таки заинтересовало.
проект не мёртв, просто заморожен.
просто у меня сейчас сложная жизненная ситуация и нужно поднять бизнес поменьше дабы укрепить свой финансовый фондамент. Сейчас занимаюсь fitcat.pro, но обязательно вернусь к qbeon.com как только смогу
Ευγένιος
Зато в последствии ты будешь писать меньше кода, больше доверять типам, и в принципе писать более красивый и менее мусорный код.
Ευγένιος
Языки то отлично, а программисты херово.
Roman
я вот фантазирую о гипотетическом фузионировании Rust и Go в язык с частично опциональным GC, runtime'ом, и preemptive компилятором который тебе сразу по рукам будет бить если шариш мутабельный стейт...
Ευγένιος
Доверия — нет, как я могу доверять тому что может изменить своё состояние?
Джинериков нет, соотвественно полиморфизм как в расте не получим, соответсвенно кода будем на разные типы, писать больше.
Ну а красота это такое дело, мне нравится ФП подобный код.
Pavel
коллеги доброй ночи начинаю изучать раббит в го И есть вопрос сделал демона который читает очереди и выдирает из них данные Но у меня вопрос как сделать так чтобы вычитывать только часть данных а не все подряд Тоесть например у меня очередь итз 1000 а мне надо взять только 10 Код https://play.golang.org/p/tq03MoG7Juh
Посмотрите метод Qos в пакете amqp.
Ευγένιος
Ну так вопрос был в «Доверия типам» а изменяемость это их свойство, если они изменяемы, я им не доверяю.
Т.е я должен явно отслеживать изменения и боятся в принципе.
Ευγένιος
У меня заряда мало, так что я словами/псевдой набросаю.
val list = List(("Name", 22))
val secondList = func(list: List, name: String, age: Int) = {
list.map(p => (name, age))
}
Ευγένιος
У нас желательно, должно быть 2 листа по персоне в каждой.
Ευγένιος
Это если код имутабельный.
Если он мутабельный, то у нас будет один лист и персона внутри изменится.
Мы теряем персону, просто берём, и теряем.
Разве это хорошо?
Ευγένιος
В го все копируется?
Не знал.
Ευγένιος
val list = List(("Name", 22))
val secondList = list.map(p => ("F", "20"))
Ευγένιος
Ну вот пример, другой.
Ευγένιος
Подверженный той-же проблеме.
Ευγένιος
Пам это функтор который получается каждое значение коллекции и применяет к нему функцию.
Ευγένιος
Функция короче.
Ευγένιος
Пропала первая персона, где он?
Roman
https://github.com/romshark/Go-2-Proposal---Immutability#111-ambiguous-code-and-dangerous-bugs
Ευγένιος
Это псевдо код, конечно.
Ευγένιος
Заряд сел подвёл.
Roman
дело в том что pointer aliasing это mutable shared state, а это опасно
Roman
нет
Roman
1. копирование это зачастую дорого
2. в слайсе у тебя могут быть указатели, скопировав слайс у тебя по прежнему останется pointer aliasing на хранимое в нём
Roman
мы хотим иммутаьбельность гарантируемую компилятором 🙂
если попробуешь мутировать немутабельный тип - компилятор быстро надаёт по пальцам молоточком
Roman
нет, совершенно нет, воспринимай их как "read only" типы. Их можно читать, но мутировать нельзя
Roman
ну вы конечно копируйте, но я буду бороться за иммутабельность в системе типов пока я использую Go
Roman
это серьёзный недостаток языка. Аргументации предостаточно
Kirill
я наоборот иногда пишу на сях
Kirill
потому что там проще получить всё неиммутабельное
Kirill
прям вообще нигде
Roman
значит скорее всего вы ещё не дебажили проблемы, которые породил mutable shared state и всё ещё впереди 🙂
Kirill
я вот дебажил
Kirill
но мне часто нужно самому контролировать, что у меня и как
Roman
я в JavaScript и C++ этого наелся вдоволь, так что аж тошнит))
Kirill
в js не то))
Kirill
дык в гошке геморройно как раз(
Kirill
копию самой функции или копию чего-то дать в какую-то функцию? О_о
Kirill
можно
Kirill
только костылём
Kirill
но можно же
Kirill
не, там некрасиво
Roman
жаль что вы не понимаете, что копирование зачастую это последствие отсутствия иммутабельности.
Видите ли, копирование не решает одной проблемы совсем: ambiguous code (двусмысленный код)
func TakeSlice(slc []string)
сегодня в документации написано что slc не мутируется и вы естественно не копируете передаваемый slc, потому-что зачем писать лишний код и лишний раз тратить CPU и память, верно?...
а завтра, одним комитом позже, он уже вдруг мутируется 😋 а ведь ваш код продолжает компилироваться и работать, но вот результаты выдаёт уже неверные, и вы скорее всего заметите это когда будет слишком поздно и большая часть данных уже коррупированы, здорово, не правда ли?
Никто не гарантирует, все только обещают, здорово жить в мире обещаний без гарантий? 🙂
Roman
жаль что вы не понимаете, что копирование зачастую это последствие отсутствия иммутабельности.
Видите ли, копирование не решает одной проблемы совсем: ambiguous code (двусмысленный код)
func TakeSlice(slc []string)
сегодня в документации написано что slc не мутируется и вы естественно не копируете передаваемый slc, потому-что зачем писать лишний код и лишний раз тратить CPU и память, верно?...
а завтра, одним комитом позже, он уже вдруг мутируется 😋 а ведь ваш код продолжает компилироваться и работать, но вот результаты выдаёт уже неверные, и вы скорее всего заметите это когда будет слишком поздно и большая часть данных уже коррупированы, здорово, не правда ли?
Никто не гарантирует, все только обещают, здорово жить в мире обещаний без гарантий? 🙂
а теперь решение:
func TakeSlice(slc const []string)
этот код не двусмыслен, он однозначен: slc не будет мутирован, это гарантирует компилятор.
даже если автор этой функции вдруг ошибётся - у него не скомпилируется.
а если он таки намеренно пожелает мутировать slc то ему придётся изменить интерфейс и поломать совместимость:
func TakeSlice(slc []string)
а это значит что не скомпилируется теперь уже у вас - и вы обратите на это внимание, потому-что передаёте немутабельный слайс туда, где ожидается мутабельный. Вы сразу заметите ошибку и недопустите коварный баг до продакшна.
Roman
const []string это не копия, это всё тот-же слайс, но на нём запрещено выполнять мутирующие операции
🏁Александр
2 часа ночи....
🏁Александр
что тут за холивар?
Roman
это НЕ копия, товарищь 🙂
Roman
это immutable reference
Roman
что тут за холивар?
холивар это когда без аргументов и в деструктивном тоне, а это обычный спор 🙂
🏁Александр
я тут скажу свое фи, мне кажется если вы хотите "защитить обьект" ну сделайте сеттеры и геттеры
🏁Александр
и саму структуру с маленькой буквы
Roman
дак неважно скопируется ли сам struct слайса или нет, важно то что массив, на который этот слайс / эти слайсы будут указывать - не будет изменён TakeSlice'ом