Да, это неплохая идея. Еще слышал идею, что можно делать дерево приглашений — каждый участник приглашает других, те в свою очередь других и так далее. Бан участника автоматически вызвает бан всех, кого он пригласил, и так по дереву вниз.
Что касается организаторов конференций, то с этим сложно — если вы организуете открытое мероприятие (митап, конференцию и т.п.), ссылка на доступ или даже пароль так или иначе шарится через какие-то открытые источники. Даже если регистрация ведется через митап.ком или тимпад, и вы можете отправить пароль по почте участникам, то все равно ничто не мешает злоумышленнику зарегистрироваться и получить пароль.
А вот что реально может предпринять зум и подобные, чтобы с этим бороться? Мне на данный момент видится какой-то удобный инструмент для мьюта и блокирования участников, плюс запрет на подключение к конференции в какой-то момент (например, через 10 минут после начала, когда все собрались). Сам видел, как в середине митапа набегает 50+ человек хулиганов и начинают хулиганить :)
Лучше ничего в голову не приходит, но может есть подходы эффективнее?
Я думаю, что что-то среднее. То есть, например, придумывают какое-то сложное название из слов, которые как-то описывают суть, вроде "Железнодорожный Проект Отдела Администрирования", а потом видят, что можно красиво поменять местами, ну и меняют.
Отсутствие дженериков — это не только ради скорости компиляции, конечно. Это и необходимость расчета размера в хипе, и много чего еще (я не эксперт в этом вопросе). Более того, насколько я слышал, с момента релиза го появились новые подходы к работе с дженериками, которые мы, возможно, увидим в Go 2.
Что же касается времени компиляции — сравните компиляцию большого приложения на Go и на c++ (условно) — разница намного больше, чем 5 секунд против доли секунды. Особенно при кросс-компиляции на несколько платформ, особенно в пайплайне.
Но дабы не вдаваться в холивар — прелесть Go не в скорости компиляции, да и проблем ему хватает. Как и любому другому ЯП.
Да — потому что действительно, обмен знаниями и все такое, важно знать, как это делается у соседей, и брать лучшие практики себе.
Нет — потому что часто другие языки ругают с точки зрения контекста, под который "правильный" язык заточен.
Пример — я работаю с Go и часто вижу обсуждения статей вида "почему Go плох", или "почему мы перешли с Go на X" (впрочем, полно и противоположных статей, но там такого обсуждения не получается, конечно). Из недавнего — переход дискорда с Go на Rust и Elixir.
В итоге ругаемые в том или ином языке (в этом случае в Go) вещи — есть следствия trade-off ради получения выгод где-то еще. Например, GC значительно упрощает работу с памятью с точки зрения программиста (особенно что касается гринтредов), но дает пиковые провалы в производительности, когда этот самый GC отрабатывает. Или там отсутствие дженериков делает возможность компиляции за секунды (очень грубо говоря).
В итоге, большинство критики — это просто "неумение правильно готовить ЯП X". И прийти в питон тусовку и сказать — а вот у нас в Го есть гринтреды, а вы до сих пор кипятите с GIL сидите — неверно, потому что контекст решаемых задач на том и на том обычно разный, и цена этого тоже разная.
В целом, самое главное — взаимоуважение и готовность идти на диалог. Не стоит пытаться впихнуть невпихуемое, но и ругать ЯП за то, что он не подошел для решения задачи, где есть инструмент заточенный под эту задачу — тоже неверно.
Более того, если вы используете редактор чуть лучший, чем блокнот, то визуальной разницы нет что там, что там.
То, что у вас отторжение — это чисто вкусовщина, не более. Питон хорош как раз тем, что возводит оформление кода в стандарт — хочешь не хочешь, а не получится писать код абы как (без отступов). Да, в 2020 это может казаться странным, потому что уже у всех есть IDE, которые все как надо выравнивают, но в свое время мне это показалось очень крутой фичей.
К сравнению, у компилятора Go тоже довольно жестки требования к форматированию кода, несмотря на наличие скобок. И это тоже супер удобно, потому что писать код одинаково что так, что так — IDE сама делает отступы. А вот читать исходник без отступов (в тех ЯП, которые это допускают, и у тех программистов, кому религия не позволяет) — это просто пытка.
Круговорот замкнут во времени, но не в пространстве. Любители го прибегают к любителям питона, любители раста к любителям го, а те, кто прибежит к любителям раста, еще не родились/не стали программировать. Возможно, это будут дети любителей питона.
Давайте будем честны, каждый из этих языков в чем-то лучше, чем остальные. Вот там они и будут применяться еще ой сколько.
И питон, и го, и раст заточены под, в целом, достаточно разные ниши. Конечно, они в целом перекрываются, но для написания веб-сайта я бы взял питон, для дата-интенсив вебсервиса взял бы го, а для плотной работы с железом скорее раст.
Все они хороши по-своему, и по-своему плохи. Каждый берет то, что ближе к его задачам и мировоззрению. Заменит ли что-то из этого друг друга — вряд ли это вообще когда-то произойдет. Появятся ли в ближайшие годы ЯП, делающие то же самое, но лучше — да, возможно.
То, что на картинке — это аккреционный диск вид сбоку.
То есть впереди черной дыры мы видим ближнюю к нам половину диска, а сверху и снизу — две стороны диска, который за черной дырой. Из-за гравитационного линзирования мы видим их одновременно, хотя по факту вторая половина находится ровно с обратной стороны, и закрыта самой черной дырой, как диски у Сатурна, например.
Почему диск? Емнип, не обязательно диск, это может быть просто аккреционный поток (который обычно "стекает" с какого-то соседнего тела, вроде газового гиганта), но в этом случае (и, наверно, чаще всего) закрутился в диск по спирали, то есть отдельная частица подлетает к черной дыре и начинает на нее "падать" по спиральной траектории. При этом частицы летят все плотнее и плотнее, из-за чего начинают люто разогреваться и излучать.
Вот картинка откуда-то из гугла:
Тут еще джеты сверху и снизу видны, но я, если честно, не помню, что нужно для их формирования (скорее всего очень много аккреционного материала в единицу времени).
Блин, пойти чтоли после карантина МРТ сделать
Поменял везде, где мог — Goland, VSCode, DBeaver, iTerm, Chrome, еще где-то. Сижу теперь и балдею. Спасибо!
А вот и нормальная статистика наконец подъехала! А то все вирус, вирус...
Ого, 2К комментов под статьей!
У меня хром уже еле-еле страницей ворочает
Да, это неплохая идея. Еще слышал идею, что можно делать дерево приглашений — каждый участник приглашает других, те в свою очередь других и так далее. Бан участника автоматически вызвает бан всех, кого он пригласил, и так по дереву вниз.
Что касается организаторов конференций, то с этим сложно — если вы организуете открытое мероприятие (митап, конференцию и т.п.), ссылка на доступ или даже пароль так или иначе шарится через какие-то открытые источники. Даже если регистрация ведется через митап.ком или тимпад, и вы можете отправить пароль по почте участникам, то все равно ничто не мешает злоумышленнику зарегистрироваться и получить пароль.
А вот что реально может предпринять зум и подобные, чтобы с этим бороться? Мне на данный момент видится какой-то удобный инструмент для мьюта и блокирования участников, плюс запрет на подключение к конференции в какой-то момент (например, через 10 минут после начала, когда все собрались). Сам видел, как в середине митапа набегает 50+ человек хулиганов и начинают хулиганить :)
Лучше ничего в голову не приходит, но может есть подходы эффективнее?
Мне понравилось, перевел все IDE и терминал на эту тему, пробую
Фримеум. У платных юзеров все те же проблемы
Я думаю, что что-то среднее. То есть, например, придумывают какое-то сложное название из слов, которые как-то описывают суть, вроде "Железнодорожный Проект Отдела Администрирования", а потом видят, что можно красиво поменять местами, ну и меняют.
Отсутствие дженериков — это не только ради скорости компиляции, конечно. Это и необходимость расчета размера в хипе, и много чего еще (я не эксперт в этом вопросе). Более того, насколько я слышал, с момента релиза го появились новые подходы к работе с дженериками, которые мы, возможно, увидим в Go 2.
Что же касается времени компиляции — сравните компиляцию большого приложения на Go и на c++ (условно) — разница намного больше, чем 5 секунд против доли секунды. Особенно при кросс-компиляции на несколько платформ, особенно в пайплайне.
Но дабы не вдаваться в холивар — прелесть Go не в скорости компиляции, да и проблем ему хватает. Как и любому другому ЯП.
И да, и нет.
Да — потому что действительно, обмен знаниями и все такое, важно знать, как это делается у соседей, и брать лучшие практики себе.
Нет — потому что часто другие языки ругают с точки зрения контекста, под который "правильный" язык заточен.
Пример — я работаю с Go и часто вижу обсуждения статей вида "почему Go плох", или "почему мы перешли с Go на X" (впрочем, полно и противоположных статей, но там такого обсуждения не получается, конечно). Из недавнего — переход дискорда с Go на Rust и Elixir.
В итоге ругаемые в том или ином языке (в этом случае в Go) вещи — есть следствия trade-off ради получения выгод где-то еще. Например, GC значительно упрощает работу с памятью с точки зрения программиста (особенно что касается гринтредов), но дает пиковые провалы в производительности, когда этот самый GC отрабатывает. Или там отсутствие дженериков делает возможность компиляции за секунды (очень грубо говоря).
В итоге, большинство критики — это просто "неумение правильно готовить ЯП X". И прийти в питон тусовку и сказать — а вот у нас в Го есть гринтреды, а вы до сих пор
кипятитес GIL сидите — неверно, потому что контекст решаемых задач на том и на том обычно разный, и цена этого тоже разная.В целом, самое главное — взаимоуважение и готовность идти на диалог. Не стоит пытаться впихнуть невпихуемое, но и ругать ЯП за то, что он не подошел для решения задачи, где есть инструмент заточенный под эту задачу — тоже неверно.
Нет ничего сложного ни в том ни в том.
Более того, если вы используете редактор чуть лучший, чем блокнот, то визуальной разницы нет что там, что там.
То, что у вас отторжение — это чисто вкусовщина, не более. Питон хорош как раз тем, что возводит оформление кода в стандарт — хочешь не хочешь, а не получится писать код абы как (без отступов). Да, в 2020 это может казаться странным, потому что уже у всех есть IDE, которые все как надо выравнивают, но в свое время мне это показалось очень крутой фичей.
К сравнению, у компилятора Go тоже довольно жестки требования к форматированию кода, несмотря на наличие скобок. И это тоже супер удобно, потому что писать код одинаково что так, что так — IDE сама делает отступы. А вот читать исходник без отступов (в тех ЯП, которые это допускают, и у тех программистов, кому религия не позволяет) — это просто пытка.
Да, вы правы.
В моем примере было бы правильно сказать, что круговорот как раз замкнут в пространстве, но не во времени, то есть получается спираль вида:
Где
n+m; m=[1,2,3...]— следующий язык, аgen+l; l=[1,2,3...]— поколения языков (или программистов).При этом набегают в направлении, противоположном формированию спирали по времени (то есть
n+m -> n+(m-1)).Круговорот замкнут во времени, но не в пространстве. Любители го прибегают к любителям питона, любители раста к любителям го, а те, кто прибежит к любителям раста, еще не родились/не стали программировать. Возможно, это будут дети любителей питона.
Давайте будем честны, каждый из этих языков в чем-то лучше, чем остальные. Вот там они и будут применяться еще ой сколько.
И питон, и го, и раст заточены под, в целом, достаточно разные ниши. Конечно, они в целом перекрываются, но для написания веб-сайта я бы взял питон, для дата-интенсив вебсервиса взял бы го, а для плотной работы с железом скорее раст.
Все они хороши по-своему, и по-своему плохи. Каждый берет то, что ближе к его задачам и мировоззрению. Заменит ли что-то из этого друг друга — вряд ли это вообще когда-то произойдет. Появятся ли в ближайшие годы ЯП, делающие то же самое, но лучше — да, возможно.
Вот тогда и поговорим.
А на конференции по Go прибегают любители Rust, и так далее. Круговорот любителей в природе, ничего нового.
То, что на картинке — это аккреционный диск вид сбоку.
То есть впереди черной дыры мы видим ближнюю к нам половину диска, а сверху и снизу — две стороны диска, который за черной дырой. Из-за гравитационного линзирования мы видим их одновременно, хотя по факту вторая половина находится ровно с обратной стороны, и закрыта самой черной дырой, как диски у Сатурна, например.
(Вот длинная, но просто офигительная статья на тему "почему это выглядит именно так" и про механизм гравитационного линзирования.)
Почему диск? Емнип, не обязательно диск, это может быть просто аккреционный поток (который обычно "стекает" с какого-то соседнего тела, вроде газового гиганта), но в этом случае (и, наверно, чаще всего) закрутился в диск по спирали, то есть отдельная частица подлетает к черной дыре и начинает на нее "падать" по спиральной траектории. При этом частицы летят все плотнее и плотнее, из-за чего начинают люто разогреваться и излучать.
Вот картинка откуда-то из гугла:
Тут еще джеты сверху и снизу видны, но я, если честно, не помню, что нужно для их формирования (скорее всего очень много аккреционного материала в единицу времени).
Неплохо, мне понравилось. Было бы интересно почитать в виде статьи
Не в футбольных полях, и на том спасибо
Спасибо за перевод, проблема насущная. Теперь буду греть в сковородке, а не в микроволновке