в классы я функции не группировал, ибо не нашел абстракцию

в итоге решил создать пакет из 1 файла

2 пакета по 1 файлу

это норма пакет из 1 файла ?

best pracrtice, imho.

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

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

Сделайте прототип, а там или работать будет или увидете, что изменить

Привет, я тут немного подумал. Дженерики не сильно хочу, ибо они усложняют читабельность. А это чуть ли не главная фишка го. На го 2.0 можно будет легко перейти, если сделают gofmt, который предыдущий код переписывает на 2.0. Недавно надо было читать код на питоне. Было больно, так как, все пишут как хотят, pep это конечно хорошо, но он не обязательный, поэтому gofmt лучше. Плюс даже с pycharm сложно было посмотреть, что функции давать в аргументы. </ Нести бред>

Привет, я тут немного подумал. Дженерики не сильно хочу, ибо они усложняют читабельность. А это чуть ли не главная фишка го. На го 2.0 можно будет легко перейти, если сделают gofmt, который предыдущий код переписывает на 2.0. Недавно надо было читать код на питоне. Было больно, так как, все пишут как хотят, pep это конечно хорошо, но он не обязательный, поэтому gofmt лучше. Плюс даже с pycharm сложно было посмотреть, что функции давать в аргументы. </ Нести бред>

почему усложняют?

Привет, я тут немного подумал. Дженерики не сильно хочу, ибо они усложняют читабельность. А это чуть ли не главная фишка го. На го 2.0 можно будет легко перейти, если сделают gofmt, который предыдущий код переписывает на 2.0. Недавно надо было читать код на питоне. Было больно, так как, все пишут как хотят, pep это конечно хорошо, но он не обязательный, поэтому gofmt лучше. Плюс даже с pycharm сложно было посмотреть, что функции давать в аргументы. </ Нести бред>

Не видел, чтобы кто-то такое мнение писал, поэтому держите.

почему усложняют?

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

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

а по каким языкам судите?

Java, кресты.

Мы можем перейти в ЛС, так как это было альтернативное мнение, срач в чате не очень любят

Особенно про дженерики

Привет, я тут немного подумал. Дженерики не сильно хочу, ибо они усложняют читабельность. А это чуть ли не главная фишка го. На го 2.0 можно будет легко перейти, если сделают gofmt, который предыдущий код переписывает на 2.0. Недавно надо было читать код на питоне. Было больно, так как, все пишут как хотят, pep это конечно хорошо, но он не обязательный, поэтому gofmt лучше. Плюс даже с pycharm сложно было посмотреть, что функции давать в аргументы. </ Нести бред>

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

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

Проблем в том, что не все люди адекватные и не весь код написан после 3.6

В го это жёстко обрубается

Проблем в том, что не все люди адекватные и не весь код написан после 3.6

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

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

Боюсь, чтобы это не было так долго как переход со 2 питона на 3.

Привет, я тут немного подумал. Дженерики не сильно хочу, ибо они усложняют читабельность. А это чуть ли не главная фишка го. На го 2.0 можно будет легко перейти, если сделают gofmt, который предыдущий код переписывает на 2.0. Недавно надо было читать код на питоне. Было больно, так как, все пишут как хотят, pep это конечно хорошо, но он не обязательный, поэтому gofmt лучше. Плюс даже с pycharm сложно было посмотреть, что функции давать в аргументы. </ Нести бред>

2.0 не будет, по большой фиче за патч будут вводить + есть не gofmt, a go fix

2.0 не будет, по большой фиче за патч будут вводить + есть не gofmt, a go fix

пруфани-ка

2017 год доклад рас кокса про общение с комьюнити

он там еще показывал их схемку внедрения фич

с гоферкона вроде доклад

2017 год доклад рас кокса про общение с комьюнити

я про 2.0

ну вот он там и говорил, что они не хотят 2.0 делать

2.0 = несовместимость = разделение комьюнити как в питоне

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

а фитц тогда о чем рассказывал пару месяцев назад?

на русском гоферконе?

на русском гоферконе?

да, навреное

это он там еще фотки своего ребенка показывал

плохо помню этот доклад, если честно

там мало что было по делу

а пропозалы то к 2.0 ты должен помнить?

я еще помню комментарии к исходникам //fix this in go2

да, но пропозалы опубликовали вот-вот

так а что это меняет

на гите дофига других с тегами 2.0 просто потому что ломают совместимость

отменяет категоричное "2.0 не будет". кажется так

на гите дофига других с тегами 2.0 просто потому что ломают совместимость

я не говорю про гит. я говорю пропозалы есть на 2.0. значит ли это что 2.0 не будет?

пропозалы типо официальные пропозалы?

а не этих там, контрибуторов

да

2.0 = несовместимость = разделение комьюнити как в питоне

А почему "= несовместимость"? Ничего не мешает делать совместимое, иначе они будут как Java, обрастать новым говном поверх старого, а совместимость всё равно в итоге сломается

А почему "= несовместимость"? Ничего не мешает делать совместимое, иначе они будут как Java, обрастать новым говном поверх старого, а совместимость всё равно в итоге сломается

так они "semver one love" ребята, если 2.0 то нужно ломать, а если не ломает, то это маркетинг

да

ладно, остановимся на том, что я высказал личное мнение, основанное на словах с докладов и простыней текстов про версионирование

Я начинающий знаю PHP html css javascript я хочу поменить бэкенд язык на Go есть перспектива или дальше заниматься изучение php? Спасибо

Я начинающий знаю PHP html css javascript я хочу поменить бэкенд язык на Go есть перспектива или дальше заниматься изучение php? Спасибо

Перспектива есть, go прекрасный язык

Я начинающий знаю PHP html css javascript я хочу поменить бэкенд язык на Go есть перспектива или дальше заниматься изучение php? Спасибо

если php на хорошем уровне, перспектива есть

Найти работу для гошника походу трудно будет так?

Найти работу для гошника походу трудно будет так?

чистым гошником да, если не сеньор

Найти работу для гошника походу трудно будет так?

не будь хорошим гошником, будь хорошим разработчиком

Найти работу для гошника походу трудно будет так?

на текущем месте переписывайте старый функционал и пишите новый на го. а руководству скажите что это новая версия пхп такая

на текущем месте переписывайте старый функционал и пишите новый на го. а руководству скажите что это новая версия пхп такая

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

БЛ можно и на пыхе оставить

на текущем месте переписывайте старый функционал и пишите новый на го. а руководству скажите что это новая версия пхп такая

сейчас сругнусь, простите. 1C-BITRIX!

А гоу тогда для чего? Микросервисы?

А гоу тогда для чего? Микросервисы?

ага.

Ну если только так. Хотя чем больше узлов в системе, тем сложнее ее содержать

Ибо много чего может упасть

Ну если только так. Хотя чем больше узлов в системе, тем сложнее ее содержать

ну понятно что монолит проще всего до определенного момента. а выгода от микросервисов не всегда есть. это капитанство.

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

простите за тупой вопрос, а как бизнес логика связана с ооп или яп?

простите за тупой вопрос, а как бизнес логика связана с ооп или яп?

Ну если вы процедурами бл пишите то никак

простите за тупой вопрос, а как бизнес логика связана с ооп или яп?

люди вон вообще как-то на кложер все пишут

ERROR: S client not available

кложура отличный язык

Ну если вы процедурами бл пишите то никак

так, а при чем тут функции и бизнес логика? я пока не очень понимаю)

кложура отличный язык

Я вот его учу, пока больно)

и на ооп яп можно писать в функциональном стиле - это так просто, если что

так, а при чем тут функции и бизнес логика? я пока не очень понимаю)

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

но бизнес логика то тут при чем

Я вот его учу, пока больно)

смотря зачем учите. так-то если на jvm-based ориентируетесь, то лучше с джявы было начать коненчо.

А структуры меньше

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

привидите пример пожалуйста?) где ооп яп решает более просто вопрос реализации бизнес логики в отличие от фп яп?

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

*для сложной реализации

привидите пример пожалуйста?) где ооп яп решает более просто вопрос реализации бизнес логики в отличие от фп яп?

Наследование например

Наследование например

это бизнес логика? ?

Как реализовать наследование в не ооп языке?

Нужен пример бл с использованием насоедования?

Нужен пример бл с использованием насоедования?

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

собственно это и был мой вопрос

Как реализовать наследование в не ооп языке?

в ООП не принято использовать наследование, если что. Если человек под ООП понимает наследование, то человек не в курсе про ООП. если нужен пример того, что трудно будет сделать - система скидок в интернет магазине. Да, тот же rules engine можно без всяких ООП сделать, но стоит ли - другой вопрос.

Я не говорю что нельзя. Можно вообще инструкции бизнес логики на процессор подавать, но зачем? Вы не согласны, это ваше право. Я реализовывал бл и на гоу и на ооп языках. На последних это было куда быстрее и поддерживаемее.

в ООП не принято использовать наследование, если что. Если человек под ООП понимает наследование, то человек не в курсе про ООП. если нужен пример того, что трудно будет сделать - система скидок в интернет магазине. Да, тот же rules engine можно без всяких ООП сделать, но стоит ли - другой вопрос.

Макс, за трудность реализации системы скидок в ИМ на го, поясняй)

Макс, за трудность реализации системы скидок в ИМ на го, поясняй)

простой rules engine

в ООП не принято использовать наследование, если что. Если человек под ООП понимает наследование, то человек не в курсе про ООП. если нужен пример того, что трудно будет сделать - система скидок в интернет магазине. Да, тот же rules engine можно без всяких ООП сделать, но стоит ли - другой вопрос.

поясните про ооп и нет наследованию

поясните про ооп и нет наследованию

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

Composition over inheritance -> google

"три кита ООП" - это выдумка

в ООП не принято использовать наследование, если что. Если человек под ООП понимает наследование, то человек не в курсе про ООП. если нужен пример того, что трудно будет сделать - система скидок в интернет магазине. Да, тот же rules engine можно без всяких ООП сделать, но стоит ли - другой вопрос.

Если я не упомянул другие 2 столба ооп то это уже значит что я под ооп понимаю только наследование? Это был как пример того, чем удобен оо подход

Сильное заявление

в ООП не принято использовать наследование, если что. Если человек под ООП понимает наследование, то человек не в курсе про ООП. если нужен пример того, что трудно будет сделать - система скидок в интернет магазине. Да, тот же rules engine можно без всяких ООП сделать, но стоит ли - другой вопрос.

Ну вообще как раз таки наследование - это один из столпов в общепринятом понимании ООП. В "изначальном" ООП в Smalltalk по Алану Кею тоже наследование использовалось.

но сам Кей понимал под ООП не наследование)

ООП не нужно

ООП не нужно

/thread

Да и в большинстве ООП языков наследование очень даже используется.