Пишут, что в Go 1.24 мапы будут переключены на алгоритм SwissTable

https://github.com/golang/go/issues/43930#issuecomment-2458068992

Пора заводить рубрику "слоупок".

Бесит, когда запускаешь терминал, в терминале набираешь что-то частое, например docker, жмешь стрелку вверх (zsh), а там в истории какой-то мусор от других проектов, которые ты недавно пощупал.

Ну так вот, нашёл классный плагин для zsh - per-directory-history. Он запоминает команды отдельно для каждой папки.

Ctrl+G переключает между локальной и глобальной историей.

Включается просто - добавить в список плагинов per-directory-history

Чума просто

ахаха, сегодня я узнал, что в JavaScript обдумывают завезти оператор ?=, который делает обработку ошибок в Гошном стиле. Т.е. натурально, проверку ошибки на nil null

const [error, result] ?= await fetch("https://example.com/data");

if (error) {
   // do something
}

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

Это интересно. Пишут, что кончаются данные для обучения AI, т.е. похоже достигнут предел качества. Конечно, если не придумают, как добывать больше данных

https://habr.com/ru/articles/857784/

Gemini посоветовал пользователю умереть. "Умри , пожалуйста", говорит

Лог чата пока еще доступен по ссылке

Я вот чего не понимаю.

Сейчас в мире продолжается тема с заталкиванием людей обратно в офисы. Окей, менеджерам легче, когда они видят людей лично, кто-то считает, что люди в офисах будут работать эффективнее. Допустим, хотя никаких внятных подтверждений этому пока нет, исследования противоречивы. (Если знаете такие - скиньте.) Ну, допустим, даже так.

Но ведь это же всё не бесплатно. Я даже не говорю про косвенные потери от того, что лояльность людей падает, если им насильно меняют образ жизни.

Это просто напрямую стоит денег: люди, готовые работать в офисе стоят в среднем дороже, чем люди, которым дают выбор. Цена - это баланс спроса и предложения. Если предложение состоит только из людей одного города (где стоит офис), да еще и работающих только в офисе, а не дома - это прям существенно меньше чем "любые люди".

Особенно странно это выглядит у бигтехов, которые сначала делают массовые сокращения, чтобы сэкономить на ФОТ, а потом загоняют людей в офисы, что в конце концов увеличит ФОТ.

И вдвойне странно, если офисов много в разных частях страны/мира, и команда всё равно общается друг с другом через интернет.

Hewlett Packard Enterprise запустила новый суперкомпьютер El Capitan

Hewlett Packard Enterprise поставила рекорд - компания создала самый мощный суперкомпьютер в мире. El Capitan, установленный в Ливерморской лаборатории США, способен выполнять более 1.7 квинтиллиона вычислений в секунду.
Одна из самых интересных особенностей El Capitan - его система охлаждения. Компания полностью отказалась от вентиляторов в пользу жидкостного охлаждения. Это не только делает систему тихой, но и невероятно энергоэффективной - на каждый ватт потребляемой энергии приходится почти 59 миллиардов вычислений.

El Capitan будет решать масштабные задачи: от вопросов национальной безопасности до исследования климатических изменений и создания новых лекарств. Значительная часть его мощностей будет направлена на работу с искусственным интеллектом, причем как для закрытых государственных проектов, так и для открытых научных исследований.

В основе суперкомпьютера лежат новейшие процессоры AMD Instinct MI300A, объединяющие в себе возможности обычных и графических процессоров с быстрой памятью. Вся система состоит из более чем 11000 таких вычислительных узлов, связанных между собой сверхбыстрой сетью HPE Slingshot.

Если вдруг кто не знал, слово "Javanoscript" является торговой маркой, принадлежащей компании Oracle. Т.е. вы не можете просто взять и назвать свою библиотеку MyCoolJavanoscriptLibrary, по идее нужно получить явное согласие компании.

Поэтому все используют слово-заменитель js.

Ну так вот, Райан Даль (создатель Node.js) и Брендан Эйх (создатель самого JavaScript) сейчас пытаются бороться с Oracle из-за торговой марки, потому что слово Javanoscript давно ушло в массы и стало таким же общеупотребительным, как «эскалатор» или «термос». В общем, они подали официальную петицию по отмене торговой марки.

Автор статьи утверждает, что шансы на успех есть. Так как у Оракла нет никаких конкретных планов по монетизации Javanoscript, и вообще, это давно уже не продукт, а общепринятая технология. Аналогично, когда-то AT&T отпустила в свободное плавание "Unix".

Не знаю, откуда видос, но гениально

Удивительно часто попадаются статьи/посты "вопросы для собеседований по [ваш язык программирования]", где задается вопрос "что выведет программа", а дальше дается некая лапша из запутанного кода, смачно сдобренного особенностями языка, которые используются раз в 100 лет при полной луне, когда Марс в доме Меркурия.

Имхо это даже разбирать не надо - правильный ответ на собесе должен быть один: не превращайте код в грёбаную головоломку

По мотивам прослушивания одного подкаста :)

Мысли про AI агентов

Представим себе такую картину: владельцам шоколадной фабрики предложили сделать эксперимент — заменить взрослых сотрудников детьми. В общем, семилеткам дали "порулить" конфетной фабрикой на день. Одного поставили следить за конвейром, второй теперь начальник отдела, следит за первым, командует ему, что делать. Третий — упаковкой занимается. Четвертый — заведующий складом, катается на транспортировщике поддонов. А во главе всего этого стоит самый умный из них, 9-летний, который формирует стратегию развития. Вопрос: через какое время фабрика "встанет колом"? Как мне кажется, достаточно быстро. Захотят ли владельцы повторить эксперимент? Есть сомнение.

Вот примерно насколько же я не разделяю оптимизма людей про AI агентов и их внедрения в реальный бизнес. Рано ещё.

Удивительно, насколько футурологи красочно описывают истории про то, как скоро можно будет "нанимать" приложения, иметь автономных помощников, а вместо фриланс-бирж появятся маркетплейсы агентов и вы сможете объединить их в сеть, и вот они работают за вас, программируют, автоматизируют документооборот, а вы спокойно можете полететь на Бали делать ретрит.
Венчур до сих пор под эти истории отсыпает приличное количество монет, вероятно, в надежде, что ребята должны рано или поздно сделать что-то прорывное, а они будут стоять у истоков этой истории и выйдут из этих историй со множителем "охулион"!
Cтартаперы тоже не против за чужой счёт поэкспериментировать. И вот как будто бы на этих взаимных ожиданиях и "синергии" история про агентов и качается.

При этом можно достаточно быстро стать неприятным собеседником, просто попросив показать реальные кейсы внедрения AI агентов в бизнесе. В последний раз, когда я так сделал, мне прислали кучу ссылок на технологии и агенские фреймворки. Но кейсов внедрения я не увидел. Знаю один, что-то из web3 и мира крипты, где боты создают свои токены и монеты. Но это всё про мешок фантиков, и я от этого далёк. А реально, где бы автономная система заменила человека, и чтобы эта история стала масштабируемой в нескольких компаниях — такого я не слышал.

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

С технической — это оверкил, потому что иногда запилить RPA решение в виде простого скрипта, преобразующего неструктурированные данные в структурированные, а затем отдать человеку на ревью и дальнейшую обработку, в сто раз эффективнее и быстрее, чем пытаться сделать все с помощью агентов. Я за то, чтобы 80% всей рутины может сделать AI ассистент, 20% важных проверок — человек. И планировать пока у человека получается значительно лучше. Несколько месяцев назад я рискнул потестить AutoGen от Microsoft. Оно у меня забуксовало на первой же простой задаче из примеров.

В общем, про AI агентов у меня стакан наполовину пуст. Проверим, что будет через год. Может что-то прорывное ;-)

📊  Оверимплоймент: что это? Примите участие в новом исследовании от NEWHR и получите инсайты рынка

Вы сотрудник и совмещаете несколько мест работы? Или пока только задумываетесь о поиске подработки и взвешиваете «за» и «против»? А может, никогда не смотрели в эту сторону? Или вы — работодатель, который сталкивается с феноменом оверимплоймента среди своих сотрудников? А может, не сталкивались или не знаете наверняка, совмещают ли ваши сотрудники? Расскажите нам о своем опыте и/или отношении к вопросу!

Предмет нового исследования — оверипмлоймент, он же совмещение нескольких работ, он же вторичная занятость, — яркий макро-тренд последних нескольких лет на рынке, распространённый не только в IT.

В рамках исследования узнаем:

- насколько распространены подработки в отрасли и в каких компаниях более, а в каких — менее?
- как к подработкам относятся работодатели? какие видят риски и, напротив, какие это дает им преимущества? и что перевешивает?
- в чём мотивация сотрудников, которые совмещают 2-3 работы? только ли в деньгах дело, и в чем может быть ещё?
- действительно ли запрет на удалёнку и принудительное посещение офиса снижает вероятность совмещений?
- можно ли остановить это явление? а главное — нужно ли?

👉🏻 Пройти опрос 👈🏻

Результаты исследования опубликуем в начале 2025 года.

🎁 Для всех, кто поучаствует в опросе:

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

📎 Для отправки результатов исследования мы попросим вас оставить электронную почту в конце. Это не обязательно, но гарантирует, что вы получите результаты первыми. Вы можете использовать любую комфортную для вас почту.

👉 Расскажите о вашем отношении к совмещению работ и/или поделитесь этим постом с теми, кому может быть интересна эта тема. Опрос займет не больше 6 минут.

Знакомые попросили продвинуть опрос ☝️

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

Не забывайте, что писать неэффективные программы - значит наносить вред окружающей среде

https://pythonspeed.com/articles/co2-emissions-software/

Переписывайте, короче, всё на C и Раст с ваших питонов, а то Грета придёт за вами

Google выпустила новое API для Protocol Buffers в Go

Команда Go представила новое API для работы с Protocol Buffers, получившее название Opaque API. Это важное обновление, которое должно сделать работу с protobuf более эффективной и безопасной.

До сих пор в Go использовалось так называемое Open Struct API, где все поля структур были доступны напрямую. Например, так:

go 
type LogEntry struct {
  BackendServer *string
  RequestSize   *uint32
  IPAddress     *string
}

С новым Opaque API все поля становятся приватными, а доступ к ним осуществляется через методы:

type LogEntry struct {
  xxx_hidden_BackendServer *string
  xxx_hidden_RequestSize   uint32
  xxx_hidden_IPAddress    *string
  // …внутренние поля опущены
}

// Доступ через методы
func (l *LogEntry) GetBackendServer() string
func (l *LogEntry) HasBackendServer() bool
func (l *LogEntry) SetBackendServer(string)
func (l *LogEntry) ClearBackendServer()
//...

Зачем это сделано?

Новый подход значительно экономит память. Вместо использования указателей для хранения информации о наличии значения в поле (presence), теперь используются битовые поля. В некоторых случаях это позволяет сократить количество аллокаций памяти почти на 60%. (речь идет про элементарные типы, такие как целые числа, булевы и т.д)

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

Новое API предотвращает некоторые ошибки. Например, раньше было легко случайно сравнить указатели вместо значений при работе с enum:

/*
message LogEntry {
  enum DeviceType {
    DESKTOP = 0;
    MOBILE = 1;
    VR = 2;
  };
  DeviceType device_type = 1;
}
*/

// Неправильно и незаметно:
if cv.DeviceType == logpb.LogEntry_DESKTOP.Enum()

// Правильно:
if cv.GetDeviceType() == logpb.LogEntry_DESKTOP

С новым API такая ошибка просто невозможна, так как прямого доступа к полям нет.

Еще одно улучшение касается работы с reflection. Раньше разработчики могли случайно использовать стандартный пакет reflect вместо специального protobuf-reflection, что приводило к неожиданным результатам. Теперь такие ошибки исключены.

Google предлагает постепенный путь миграции через "гибридное" API, которое поддерживает оба способа работы. Для новых проектов рекомендуется сразу использовать Opaque API. В 2024 году оно станет стандартным подходом в новой версии Protocol Buffers (Edition 2024).
Старое API никуда не исчезнет – принцип обратной совместимости.

Для перехода на новое API Google предоставляет инструмент open2opaque, который помогает автоматически переписывать код. Внутри самого Google большинство protobuf-файлов уже переведено на новое API, и оно активно используется на проде.

подробнее здесь

Алхимия промпт-инжиниринга

Если рассматривать GenAI решения с точки зрения детерминизма результатов (а именно стабильности результатов нам и хочется в большинстве случаев), то
1) В общем случае детерминизм в LLM/LVM не достижим.
2) Всегда стоит рассматривать промпт и языковую модель как одно целое.

Про недетерминизм:

100% точности и воспроизводимости результатов инференса не будет даже при нулевой температуре, фиксированном seed параметре и других рандомных параметрах ввиду особенностей работы GPU вычислений (операции с плавающей точкой и квантизации). Тем не менее, обеспечить точность в три девятки можно. А это уже что-то.

Про систему "промпт + модель":

Prompt Engineering — это алхимия. А LLM — "черный ящик". С этим важно свыкнуться, особенно если вы любите one-shot prompting для принятия сложных логических решений внутри одного запроса. Одно небольшое изменение в промпте или изменение модели (даже простой переход с неквантизованной на квантизованную версию) приводит к тому, что отлаженная функциональность перестаёт работать и нужно начинать всё сначала. А уж если использовать облачные версии типа ChatGPT и Claude, то там вообще под капотом целые подсистемы роутеров и всяких "улучшайзеров ваших промптов", после которых даже сами разработчики этих решений, скорее всего, не угадают, какой будет результат. И они постоянно что-то в этих подсистемах подкручивают.

Какие выводы я сделал к текущему моменту для себя:

🔹 Выбор языковой модели для прода — это как выбор жены. Тестить как можно на большем кол-ве моделей до релиза, а в релиз выбирать и фиксироваться на какой-то конкретной, лучшей. На ней и "жениться" ;) Потом поменять уже сложнее.

🔹 Облачным моделям доверять нельзя, они имеют неприятное свойство меняться, ухудшаться. Кажется, что каждый новый релиз ChatGPT должен быть только лучше, но для конкретных задач может оказаться совсем наоборот. Например, в одном моём решении gpt-4 (которая уже почти на пенсии) работает в плане генерации кода по инструкции значительно лучше gpt-4o-2024-11-20. Значит ли это, что модели становятся в целом хуже? Нет. Но мне не нужно "в целом", мне нужно решать конкретные задачи.

🔹 Принимать решения или делать обработку нужно как можно больше в коде, и как можно меньше в LLM. Если есть возможность что-то сделать без LLM, нужно делать без LLM, так достигается детерминизм. Если вытаскиваются ключевые сущности: максимально очистите данные до LLM, и всякие операции сортировки, ранжирования, нормализации делайте уже в python, а модели оставьте только работу с неструктурированными данными. У меня есть решение по отслеживанию трендов, там вытаскивают определенные классы тегов, имен компаний и продуктов из текста. Эти сущности извлекаются как получится, а нормализуются по словарю уже в коде, потому что модель это делает плохо.

🔹 Большой и сложный промпт — скорее зло. Простой промпт позволяет мигрировать между моделями без особой деградации качества. А сложный промпт приколочен гвоздями к конкретной модели, для которой писался и тестился. Эффективнее делать мелкие, несложные запросы.

🔹 У меня лучше работает серия простых промптов + объединение результатов в коде, чем один огромный промпт со всеми агрегациями и принятиями финальных решений внутри LLM. Такой большой и сложный промпт невозможно дебажить. Внутри что-то "решилось", а вы гадаете, почему. Папример, как один абзац инструкций повлиял на другой абзац. Меняете что-то вверху, а оно аффектит то, что внизу. Получается этакая игра Wack-A-Mole (из рандомных дырок вылазит крот, а вы ему по голове стучите молотком).

🔹 Structured Output — не панацея. Иногда он делает хуже вывод или дороже решение. Например, я никогда не использую его в задачах генерации кода или там, где нужны "плоские" одноуровневые тексты, или где нужно обрабатывать большой массив данных. В последнем случае это просто экономически не выгодно. При большом числе запросов оцените, насколько увеличивается число токенов в OpenAI либе при structured output и сделайте вывод (можно включить logger.DEBUG и увидеть это в консоли). А ещё json универсальнее Pydantic.

Конец.

Если раньше у ИИ были галлюцинации, то теперь еще и раздвоение личности

https://habr.com/ru/companies/bothub/news/870510/

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