И существенная

Ответ на вопрос - в 99% значением, даже, если собираетесь изменять.

Вот например

Влияет на производительность и связано это со сборщиком

Влияет на производительность и связано это со сборщиком

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

Нет в том то и дело, если пару Гб то по указателю

Это ясно

Правильно ли понимаю, что в голанг структуру передавать и возвращать предпочтительно не по ссылке? По ссылке вообще никогда не стоит. Даже если нужно изменять лучше копию возвращать. Так это или существует альтернативные точки зрения?

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

Щас попробую видос найти полезный по этой теме

Возвращаем указатель, значение или зависит от ситуации?

Щас попробую видос найти полезный по этой теме

Спасибо, очень жду

Возвращаем указатель, значение или зависит от ситуации?

именно

А пример ситуации для указателя? Любой самый банальный

Спасибо, очень жду

https://youtu.be/ZMZpH4yT7M0

А пример ситуации для указателя? Любой самый банальный

Указатель как аргумент или как возвращаемое значение?

Как возвращаемое значение, про аргумент я усвоил - 99% по значению

Там прям очень подробно описаны ситуации что будет если в функцию передавать ссылки или возвращать, как лучше и т д

https://youtu.be/ZMZpH4yT7M0

Спасибо

Как возвращаемое значение, про аргумент я усвоил - 99% по значению

Создал структуру, вернул ссылку

Да вродь не плохо

ток я раньше там ковырялся, вроде за бесплатно, ток шляпа была, норм курс норм денег стоил) Ну из зп джуна повеселила)))

Как же я старался

Как же я старался

Судя по описанию POST и PUT делают одно и тоже, вставляют новую запись

Я до этой строчки доколупался)

что и там и там new record

Да но в в пут бд запрос INSERT, в другой UPDATE

Судя по описанию POST и PUT делают одно и тоже, вставляют новую запись

наркоман?

Я до этой строчки доколупался)

Ааа

Правильно ли понимаю, что в голанг структуру передавать и возвращать предпочтительно не по ссылке? По ссылке вообще никогда не стоит. Даже если нужно изменять лучше копию возвращать. Так это или существует альтернативные точки зрения?

Да, предпочтительно не по ссылке (указателю). Нет. Иногда есть смысл передавать по указателю, когда занимаешься оптимизацией, но в ней не все так очевидно. Сперва надо измерить, потом поменять и опять измерить. Не надо передавать значение в функцию по указателю только по той причине, чтобы его менять. Это нечистый код, он плохо читается, мы пишем не на си, где это делается, а на го. возвращать по указателю тоже лучше не надо. Только в случае, если надо оптимизировать и только в случае, если доказано, что так реально быстрее, а оно так не всегда.

эти знания про кучу и стек в го не нужны опять же для большинства ситуаций. Если ты только начинаешь то просто по значению передавай и будет это и правильно и красиво

Да, предпочтительно не по ссылке (указателю). Нет. Иногда есть смысл передавать по указателю, когда занимаешься оптимизацией, но в ней не все так очевидно. Сперва надо измерить, потом поменять и опять измерить. Не надо передавать значение в функцию по указателю только по той причине, чтобы его менять. Это нечистый код, он плохо читается, мы пишем не на си, где это делается, а на го. возвращать по указателю тоже лучше не надо. Только в случае, если надо оптимизировать и только в случае, если доказано, что так реально быстрее, а оно так не всегда.

"возвращать по указателю тоже лучше не надо. " А если у нас возвращается вторым параетром ошибка, не удобнее ли использовать указатель для возврата основной переменной, чтобы иметь возможность вернуть nil? Типо: val, err := getResult() *Test, error При этом в теле getResult избавляемся от обработчика if err != nil { val := Test{} } return val, err

"возвращать по указателю тоже лучше не надо. " А если у нас возвращается вторым параетром ошибка, не удобнее ли использовать указатель для возврата основной переменной, чтобы иметь возможность вернуть nil? Типо: val, err := getResult() *Test, error При этом в теле getResult избавляемся от обработчика if err != nil { val := Test{} } return val, err

а как тогда тело getResult будет выглядеть?

🖥 26 основных паттернов микросервисной разработки Несмотря на достоинства микросервисов, при их внедрении можно столкнуться с множеством проблем. Изучение общих закономерностей в решении этих проблем привело к появлению паттернов микросервисной разработки (Microservices Patterns), или шаблонов проектирования микросервисов. Основная цель — предоставить проверенные временем решения для таких задач, как разработка микросервисной архитектуры, организация взаимодействия микросервисов друг с другом, клиентскими приложениями, базами данных, обеспечение их отказоустойчивости. Рассмотрим несколько основных паттернов, разделив их на условные группы в зависимости от решаемой задачи. ➡️ Читать дальше @Golang_google

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

никак

сколько раз тут уже был этот вопрос

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

да тут мидлов-то не берут (единороги нужны), какие еще джуны🤣

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

работать джуном

но если ты работаешь джуном, разве ты сам не станешь мидлом?

нет

можно 5 лет перекладывать джейсоны

сам по себе не становишься

мидлом от этого не станешь

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

а как же джун в убыток компании

Вообще все это деление очень странная вещь. Человек нарабатывает опыт в одно стеке, решая определённые задачи и становится типо мидлом.сеньером. Но если его перекинуть на другую область то он он опять станет дужном. Даже не меняя язык.

Вообще все это деление очень странная вещь. Человек нарабатывает опыт в одно стеке, решая определённые задачи и становится типо мидлом.сеньером. Но если его перекинуть на другую область то он он опять станет дужном. Даже не меняя язык.

Сеньор джуном не станет при смене проекта / стека (в рамках разумного). Мидлом - да, может вполне. Джун решает простые задачи, как правило, не может работать БЕЗ контроля и помощи. Сеньор, перешедший на другой стек, МОЖЕТ работать без помощи, может решать не только легкие задачи. Другое дело, что будет это делать сильно медленнее, чем с привычными инструментами.

Вообще все это деление очень странная вещь. Человек нарабатывает опыт в одно стеке, решая определённые задачи и становится типо мидлом.сеньером. Но если его перекинуть на другую область то он он опять станет дужном. Даже не меняя язык.

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

язык это инструмент

также как и технологии

"возвращать по указателю тоже лучше не надо. " А если у нас возвращается вторым параетром ошибка, не удобнее ли использовать указатель для возврата основной переменной, чтобы иметь возможность вернуть nil? Типо: val, err := getResult() *Test, error При этом в теле getResult избавляемся от обработчика if err != nil { val := Test{} } return val, err

м?

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

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

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

Вот с этим согласен.

Поэтому я вот не понимаю эти всякие попытки использовать некоторые языки там, где им не совсем место только потому что "я кроме этого языка ничего не знаю, я в нём 15 лет сижу". Когда JS какой-нибудь нетипизированный тащат в бэкенд, или когда Python толкают в обработку высоконагруженных систем реального времени.

Сеньор джуном не станет при смене проекта / стека (в рамках разумного). Мидлом - да, может вполне. Джун решает простые задачи, как правило, не может работать БЕЗ контроля и помощи. Сеньор, перешедший на другой стек, МОЖЕТ работать без помощи, может решать не только легкие задачи. Другое дело, что будет это делать сильно медленнее, чем с привычными инструментами.

Речь не о стеке, а о здачах. Я например перекинул сеньора который писал сеть, на задачи по обработки изображений. Прошёл уже месяц, результат - просраные сроки.

Речь не о стеке, а о здачах. Я например перекинул сеньора который писал сеть, на задачи по обработки изображений. Прошёл уже месяц, результат - просраные сроки.

Ну, здесь нужно учитывать, что ему нужно время на адаптацию к новой предметной области. Мне пришлось в одно время допиливать приложение на Swift+Rx со всякими конструкциями типа $0.$1.$0 и прочими ништяками, которые я до этого в глаза не видел. Потратил около трёх недель, но теперь могу в Swift.

Сеньор джуном не станет при смене проекта / стека (в рамках разумного). Мидлом - да, может вполне. Джун решает простые задачи, как правило, не может работать БЕЗ контроля и помощи. Сеньор, перешедший на другой стек, МОЖЕТ работать без помощи, может решать не только легкие задачи. Другое дело, что будет это делать сильно медленнее, чем с привычными инструментами.

Речь не о стеке. Если ты писал веб код на питоне, на го перейти не проблема.

Ну, здесь нужно учитывать, что ему нужно время на адаптацию к новой предметной области. Мне пришлось в одно время допиливать приложение на Swift+Rx со всякими конструкциями типа $0.$1.$0 и прочими ништяками, которые я до этого в глаза не видел. Потратил около трёх недель, но теперь могу в Swift.

Вот об этом и речь. И иногда это требует далеко не 1 месяц

15 лет он работает по 40 часов в неделю. Как можно не набраться при этом опыта и знаний? Это же количество, которое перейдёт в качество, грубо говоря. Иначе не понятно как его 15 лет содержат

15 лет он работает по 40 часов в неделю. Как можно не набраться при этом опыта и знаний? Это же количество, которое перейдёт в качество, грубо говоря. Иначе не понятно как его 15 лет содержат

Может он формочки пилил за большие бабки? =)

Вот об этом и речь. И иногда это требует далеко не 1 месяц

Зависит от задач и от человека.

15 лет он работает по 40 часов в неделю. Как можно не набраться при этом опыта и знаний? Это же количество, которое перейдёт в качество, грубо говоря. Иначе не понятно как его 15 лет содержат

Я работал человеком, который много лет пилил сайты на Wordpress, и кроме этого ничего его не интересовало в принципе. И его это устраивало. И наверняка до сих пор устраивает. Можно ли его считать Senior? Ну и да, на нём веб-студия эта висела считай, т.к. компания занималась как раз сайтами на WP :)

Зависит от задач и от человека.

Задача например написать алгоритм non-local means на го

тогда странно претендовать на сеньора с таким стажем

тогда странно претендовать на сеньора с таким стажем

Ну он же синьор фактически, но только в своей области

Задача например написать алгоритм non-local means на го

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

тогда странно претендовать на сеньора с таким стажем

Часто под "сеньором" понимают "этот парень лучше всех знаком с проектом". + в разных конторах различные понятия о грейдах. Поэтому, не стоит через чур серьезно относиться к этим лычкам. Главное понять на собесе, насколько эффективно человек в нужной перспективе будет решать конкретно ваши задачи или нет. А именовать ли при этом мидлом, сеньором, staff engineer или L4, или космическим десантником - вообще все-равно.

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

Оно есть готовое, но на питоне. И из-за этого оно работает крайне медленно

Оно есть готовое, но на питоне. И из-за этого оно работает крайне медленно

Ну вот. Можно наверное переписать.

Ну вот. Можно наверное переписать.

Так я то не против. Проблема в том, что у современных сеньеров проблема с операциями над матрицами

Так я то не против. Проблема в том, что у современных сеньеров проблема с операциями над матрицами

А в чем проблема то?

А в чем проблема то?

В том, что большинство сеньеров приходящих на собеседование не могут найти детерминант матрицы.

В том, что большинство сеньеров приходящих на собеседование не могут найти детерминант матрицы.

А в чем проблема?

А в чем проблема?

Не знаю. Даешь задание а они сидят и тупят

Не знаю. Даешь задание а они сидят и тупят

Его задачи связаны постоянно с определением детерминанта матрицы? Если да, то доеб засчитан, иначе звучит, как "Можешь вывести эту формулу сейчас, так как я математику учил в университете"

Его задачи связаны постоянно с определением детерминанта матрицы? Если да, то доеб засчитан, иначе звучит, как "Можешь вывести эту формулу сейчас, так как я математику учил в университете"

Его задача связана с операциями над матрицами, умножение сложение и тд и тп, в том числе и нахождение детерминанта.

Его задача связана с операциями над матрицами, умножение сложение и тд и тп, в том числе и нахождение детерминанта.

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

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

Не спорю)

Ну так под эти матричные операции тоже есть скорее всего куча библиотек. Алгоритмы описаны уже все.

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

Просто многие наверное уже привыкли что в вакансиях указаны завышенные требования