ну вот... уже слова старику сказать нельзя... Молодые тут все, злые какие-то... Вот уйду я от вас :)

У меня кстати тоже недавно была утечка горутин

да просто ассемблер то причем тут

да просто ассемблер то причем тут

Да я уже сто лет на нем ничего не делал. Но если уж так приперло поработать с памятью - лучше ассемблера хуже нет, как говорится. :) Это точно!

разговор то не об этом

Почему все так боятся ручного управления памятью?

разговор был такой

А если не так сильно приперло - Go хороший язык, так мне кажется.

а кто что-то плохое про го сказал?

Здесь нельзя говорить плохо о Go!

а кто что-то плохое про го сказал?

Забей. Кажется, ты влез посередине и стал обсуждать то, что тебе показалось, а не то, о чем была речь.

ну мб, хорошо

извини если обидел

А вобще, нельзя говорить плохо о Go - это плохая идея. Надо говорить похо о Go, если, действительно, есть что сказать!

всё уже сказано

Обязательно надо! И тут два варианта: или тебе объяснят что-то недопонятое, или, может быть, и правда ничего идеального в мире не существует и надо уметь правиьно выбирать инструменты...

http://devs.cloudimmunity.com/gotchas-and-common-mistakes-in-go-golang/

Слава, я читал. И, кажется, твой перевод был на хабре? Как-то не вполне сторго и убедительно.

нет, не мой =)

Тут вот вчера запостили: https://github.com/Konstantin8105/Effective_Go_RU

Переводчику, конечно, респект, но редактура нужна явно! Не такой хороший текст получился, как в оригинале

Необходимость перевода технической литературы вообще весьма сомнительна.

И вобще, с языком как-то чем даьше, тем больше косноязычия. Самый печальный вариант - публичные выступления на наших конференциях. Люди не только говорить не умеют, но даже, зная, что придется лезть перед камеру/микрофон, даже и учиться не хотят :(

Необходимость перевода технической литературы вообще весьма сомнительна.

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

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

Да и пока сам переводишь, хоть поймешь, наконец, что там написано=то хотя бы :)

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

Слава, надо как-то все равно на это внимание обращать. Если выступающий сподобился выступить, то пусть хотя бы нескоько вещей учтет:

Необходимость перевода технической литературы вообще весьма сомнительна.

я бы сказал что вообще отсутсвует

1. Надо иметь что сказать. 2. Надо заранее снать план выступления, какие темы будут, в каком объеме, а каких не будет. 3. Заранее продумать, как ты преподнесешь то, о чем речь таки будет. 4. Научи ться слышать свое следующее слово до того, как ты его скажешь. Если следующее слово - это междометие "как бы" и ему подобные - лучше просто его не сказать, а набычась поглядеть в зал четверть секунды 5. Научиться не сидеть на шее у зала. Все вопросы типа "а кто знает, в какой версии ядра Linux появились CGroup" - это просто до свидания. Вышел выступать - выступай, а не еби людям моск

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

москва не сразу строилась =) надо же и интернам практиковаться на ком-то

Ну, пипл хавает пока что, так что никаких проблем. :) И есть прекрасные ораторы, не побоюсь этого слова. :) Это, в первую очередь те, кому есть таки что сказать, у кого глаза горят это донести. А полно и такого убожетва - мама не горюй. Хоть и специалист, вроде, и дело знает... Его что туда пистолетом загоняли выступать, блин???

Я это не про конференции Go, а вобще. Те же курсы лекций от Mail.RU или Яндекса. Бывает слушаешь минут 15-20 для начала что-то и просто физически страдаешь, как человеку плохо, так не надо было и лезть в это! А бывают просто суперские лекторы! Но сильно реже :(

вообще-то, все 5 пунктов - чистое капитанство

Да!

то есть, если человек не умеет этого - не надо бы ему - пока? - выступать

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

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

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

а кого не в школе - того в универе

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

ну вот у нас нет специально риторики ни в школе, ни в вузе.

И к лекциям готовился, особенно поначалу! Но то, что я вижу на ютюбе - это просто модой об забор иногда, даже если то под вывеской Яндекса или MRU идет

то есть, ежели кто из наших это умеет - это просто талант, а талантов мало, как известно

Талант талантом, но если нет элеметарных речевых навыков - лучше, наверное, не надо. Хотя опять же, кто хочет выступить и есть о чем - почему нет? Если хочешь, то обычно и можешь, а опыт - дело наживное.

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

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

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

Талант талантом, но если нет элеметарных речевых навыков - лучше, наверное, не надо. Хотя опять же, кто хочет выступить и есть о чем - почему нет? Если хочешь, то обычно и можешь, а опыт - дело наживное.

талант не так работает. талант делает твое обучение эффективным. талант может помочь за одно выступление стать из никакого неплохим оратором.

но, повторюсь, это редкость

Перед зеркалом ничего не надо. Просто если есть план выступления, то уже заранее думаешь, что вот это я расскажу так... Потом думаешь, нет... половина поймет неправильно. Лучше так расскажу... В общем, муки творчества непосредственно в голове. А потом видишь аудиторию и уже как-то само начинает идти, потому что ты уже о разных методиках подачи материала дал себе труд подумать.

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

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

И свои выступления - тоже! Обычно когда свои - то ты и есть самый строгий зритель :)

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

Мы тут не о конкурсе мужской красоты еще? Я про косноязычие на наших конпутерных конференциях и курсах тут разоряюсь. Хотя, я может быть, что-то пропустил?

А вообще , что посоветует, я б научился вытупать

А вообще , что посоветует, я б научился вытупать

А о чем ты хотел бы выступить?

Слава! Не упускай парня! Он выступить хочет!

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

Ваня, вот, послушай хорошего лектора: https://www.youtube.com/watch?v=LcQXXhNT__I

Ж)))

Это вырезки, полностью лкция про Кложуру тоже там есть. Но это - просто чудо природы! :)))

спасибо

обращайся :)

Приветствую товарищи, есть такой вопрос про база данных: Работаю sqlx + postres, использую не http server, а grpc методы, но не суть. Например в 1 секунду одновременно может прийти 50 запросов, но у меня база глобальная, в main я его открыл, и держу в memory: var db *sqlx.DB func AccountFor(db *sqlx.DB) и просто в каждый запрос передаю его в параметрах, так вот у меня крашит на транзакциях, как работать многопоточно с базой? Сильно гуглю, пока стоящее не нашел?

Делай одну транзакцию, если у тебя атомарные запросы и все такие запросы просто делай в ней . Эта транзакция будет идти через один connect. И, разумеется, счетчик времени, или количества атомарных запросов (по ситуации). Периодически ты должен говорить COMMIT

Делай одну транзакцию, если у тебя атомарные запросы и все такие запросы просто делай в ней . Эта транзакция будет идти через один connect. И, разумеется, счетчик времени, или количества атомарных запросов (по ситуации). Периодически ты должен говорить COMMIT

Может есть пример на gist, github, честно, пока не очень понятно. Пример кода чтоли

К сожалению, в библиотеке Go сделано все так, что подразумеваются только транзакции, на каждую он будет открывать новое подключение к базе. Поправьте, если не прав, но я в это утыкался :(

в го есть пул коннектов

Пример кода - звучит слишком по-индийски

Слава, есть пул коннектов и размером даже можно рулить. Но библиотека думает, что любой запрос - это транзакция, а для нее надо открыть соединение с базой :(

Например как эту задачу я решил бы в Swift или Object-C, просто создаю global queue очередь только для database, и все операций по базе, кидаю в block в эту очередь: queue.async{}

Да! И я о том же. Кидаешь все атомарные запросы в функцию, которая умеет их слать, но при этом еще и делает это в одной транзакции с периодическим коммитом.

И эта функция, как можно понять. держит один коннект с базой.

Или я не понял, и ты о чем-то другом?

Да! И я о том же. Кидаешь все атомарные запросы в функцию, которая умеет их слать, но при этом еще и делает это в одной транзакции с периодическим коммитом.

code example pls, примерно хоть, наводку, не догоняю

У меня нет готового примера

У sqlx вроде есть connection pool: http://jmoiron.github.io/sqlx/#connectionPool

не оно?

По сути, я предлагаю тебе сделать на Go функцию, которая обрабатывает очередь запросов, как ты привык. Но она должна периодически говорить Commit