сервис с3 готов

и ограничения не влияют

например, у Gluster данные будут кэшироваться по дефолту в памяти на ноде, которая их запросила. При раздаче популярного медиаконтента такое будет делаться внутри CDN

когда контент надо быстро отдавать, брать его с диска - не вариант

независимо от того, 1 там мегабайт или 1024

тебя понесло, эти все данные в "популятрых" бд не хранят

дай еще раз прямо спрошу, объектные хранилища - не бд для тебя?

все что угодно можно назвать бд, если оно хранит данные, даже винт

но не надо цепляться за терминологию

логично

вот и не цепляйся :) ежу понятно, что под s3 вряд ли стоит постгрес

но базой он от этого быть не перестает

конечно не стоит, я говорю о том что 16 мегабайт хоть и ограничение неприятное, но цифра тем не менее довольно таки большая, я очень сомневаюсь что когда либо ее превышу, я даже сомневаюсь что когда нибудь к ней близко подойду

конечно не стоит, я говорю о том что 16 мегабайт хоть и ограничение неприятное, но цифра тем не менее довольно таки большая, я очень сомневаюсь что когда либо ее превышу, я даже сомневаюсь что когда нибудь к ней близко подойду

ну просто у тебя данные такие вот, а у медиасервисов и прочих артефактных штук могут быть совсем другие

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

я бы монгу не использовал бы для таких целей которые ты описываешь

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

я бы монгу не использовал бы для таких целей которые ты описываешь

вот и я бы тоже, что я выше и писал - это искусственное ограничение сильно мешает ее универсальности

Да я и без этого ограничения не использовал бы в таких схемах ее

Как можно протестировать функцию, которая возвращает функцию?

Как можно протестировать функцию, которая возвращает функцию?

протестировав функцию, которую она вернула

?

я серьёзно, вариантов других толком нет

Я так подумал, что это просто поразрядное отрицание (хотя как бы я вижу что символ другой), но тогда у меня нет предположения что это.

Это и есть поразрядное отрицание, в результате которого получается -6. Посмотрите что такое отрицательные числа в комп вычислениях.

я серьёзно, вариантов других толком нет

Получается, что так

Хотя я лично хотел бы язык с простым ООП, нравится мне оно. Но многие тут боятся ООП как огня.

> 2к18 > ООП Вы вообще видели трейты/тайпклассы/имплиситы/протоколы?

вот без encapsulation жить сложно, это значительная часть OOP, её бояться не стоит

Каждый из базвордов ООП ничего не значит без остальных двух.

Каждый из базвордов ООП ничего не значит без остальных двух.

в любом случае наследование явно лишнее и приносит в большей степени только беду нежели пользу

> 2к18 > ООП Вы вообще видели трейты/тайпклассы/имплиситы/протоколы?

Видел. Но ООП проще.

Видел. Но ООП проще.

> ООП > проще Звучит как минимум забавно.

в любом случае наследование явно лишнее и приносит в большей степени только беду нежели пользу

Без наследования нет сабтайпинга, без сабтайпинга нет ООП. Кстати, сабтайпинг как правило самая сложная часть в системах типов и если его убрать, то все становится значительно проще.

> ООП > проще Звучит как минимум забавно.

А чего забавного? Если это действительно так.

Как создать с помощью го файл, на другом компьютере?

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

Без наследования нет сабтайпинга, без сабтайпинга нет ООП. Кстати, сабтайпинг как правило самая сложная часть в системах типов и если его убрать, то все становится значительно проще.

я с вами не согласен. Значительная часть OOP это encapsulation, если убрать subtyping то OOP никуда не исчезнет, станет лишь на 1 фактор менее влиятельным на код)

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

перекреститься не забыть от segfault'ов

я с вами не согласен. Значительная часть OOP это encapsulation, если убрать subtyping то OOP никуда не исчезнет, станет лишь на 1 фактор менее влиятельным на код)

Ну во первых OOP это message passing и максимально позднее связывание. Во вторых - сабтайпинг. Вызов функции через точку — не ООП.

Ну во первых OOP это message passing и максимально позднее связывание. Во вторых - сабтайпинг. Вызов функции через точку — не ООП.

да не в . операторе дело)) а в энкапсуляции данных))

А чего забавного? Если это действительно так.

А ну-ка определение ООП мне расскажите. А расскажите мне ещё за ковариантность, контравариантность. И за паттерны тоже расскажите. А потом расскажите что их этого так просто?

да не в . операторе дело)) а в энкапсуляции данных))

Инкапсуляция данных это что такое? Насколько я понимаю инкапсуляция данных есть и в Go и в Rust и даже в Haskell, в которых ООП нет в принципе.

Инкапсуляция данных это что такое? Насколько я понимаю инкапсуляция данных есть и в Go и в Rust и даже в Haskell, в которых ООП нет в принципе.

в Go нет OOP?))

в Go нет OOP?))

В Go нет ООП.

В Go нет ООП.

http://spf13.com/post/is-go-object-oriented/

читайте)

> Software Engineer > works at Google > this feels to me very much like an object Статья уровня лор talks.

Ну и вообще думаю, что человек разбирающийся в теории типов в Гугл работать не пойдет.

Совершенно верно, пойдет работать дворником.

http://spf13.com/post/is-go-object-oriented/

увидел домен и вспомнил, что недавно в завендоренном viper чинил data race при изменении мапы. С паникой.

причем возникало оно при работе с виперовскими же настройками

сложнааа ?

модель для http, модель для бд. Вопросов "как правильно слепить" больше чем ответов

Как это нет ООП? Структуры могут наследовать поля других структур - наследование. У стрктур могут быть приватные поля, если структуру и ее методы ложить в отдельный пакет - инкапсуляция. Структуры, реализующие один интерфейс, могут быть запихнуты в функцию, принимающую этот интерфейс - полиморфизм

Как это нет ООП? Структуры могут наследовать поля других структур - наследование. У стрктур могут быть приватные поля, если структуру и ее методы ложить в отдельный пакет - инкапсуляция. Структуры, реализующие один интерфейс, могут быть запихнуты в функцию, принимающую этот интерфейс - полиморфизм

Похоже, но на самом деле это немного другой подход.

Похоже, но на самом деле это немного другой подход.

да, с джавой разница есть, но это не значит, что ООП в Go нет. Мало того, что оно есть, так еще и позволяет пользоваться отдельными свойствами ООП, а не всеми сразу, если захочется.

да, с джавой разница есть, но это не значит, что ООП в Go нет. Мало того, что оно есть, так еще и позволяет пользоваться отдельными свойствами ООП, а не всеми сразу, если захочется.

Чсх в жабе ооп нет

Да, в жабе только жаба головного мозга ;)

Делать ООП умеют и асм и Си

То, что у других языков есть своё видение прекрасного, то просто отлично, но, опять же, такое видение - половые трудности самого языка

интересно как выглядит ооп на асме

оопэшно

мне интересно если мы конвертируем сущность А в сущность Б то мы должны конвектор на стороне А или на стороне Б делать

мне интересно если мы конвертируем сущность А в сущность Б то мы должны конвектор на стороне А или на стороне Б делать

Вообще я бы делал третью сущность, которая умеет из А в Б и обратно

B:= B.NewFromA(A) --- OR --- B := A.ToB()

мне интересно если мы конвертируем сущность А в сущность Б то мы должны конвектор на стороне А или на стороне Б делать

таиплассом отдельно xD

лучше отдельно, decoupling montherfucker, do you do it?

первый вариант конечно более гоувей звучит

а что значит отдельно?

мне интересно если мы конвертируем сущность А в сущность Б то мы должны конвектор на стороне А или на стороне Б делать

Если Б - объект бизнес логики, то на стороне которая создаёт сущности А перед передачей в слой бизнес логики. И наоборот

не в А и не в Б

Короче, отдельно

ну у меня А это модель для работы с HTTP, а Б это модель для работы с БД

Это обычный такой паттерн DTO и в той же самой джяве, которую некоторые местные ̶н̶е̶ ̶о̶с̶и̶л̶и̶л̶и̶ не любят, давно запили автоматические инструменты для этого, типа dozer или mapstruct

получается мне надо при завипи сконвертировать А->Б, при чтении обратно Б->А

А как http связано с БД?

func AToB(A) B { ... }

А как http связано с БД?

никак, но у него свои модели на структурах

func AToB(A) B { ... }

и в какой это пакет по вашему положить?

А как http связано с БД?

В хттп приходит что-то, это контроллер там свой объект, потом объект идёт в БЛ с ним что-то делают, потом объект надо положить в БД - это уже другая обычно модель и другой слой приложения

и в какой это пакет по вашему положить?

яровой

Отлично

какой хочешь ?

То есть никак

твой проект, твои пакеты, твои функции

просто еще одна сущность, опять не понятно куда она относится

Модель http, прости господи, никак не должен знать о бд

И наоборот

она и не знает

но делать еще условно пакет convert

ну такое

просто еще одна сущность, опять не понятно куда она относится

Завели отдельный

Модель http, прости господи, никак не должен знать о бд

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

100 пудов, должен быть мостик

ну такое

Зато тестами нормально обложишь!