[Перевод] История IDE в Google

В предыдущей статье я говорил о том, что основная кодовая база Google обязывает использовать строгий инструментарий и стандарты для обеспечения её масштабирования. В течение многих лет единственным исключением оставались IDE. Контекст: я работал в Google в 2011 по 2024 год. Часть информации может быть приблизительной, и я буду дополнять её, если мне сообщат об ошибках. В этом посте речь пойдёт об основном монорепозитории Google (google3). Фрагментированная экосистема Как и во многих компаниях, в Google разработчики имели возможность самостоятельно выбирать IDE, и из-за этого возникла высокая степень фрагментированности. В 2011 году одним из самых опытных разработчиков-сениоров задали вопрос: «Можно ли как-то сделать так, чтобы все гуглеры пользовались одной хорошей IDE?». Если вкратце, они ответили «Нет». Джефф Дин ответил так: «Попытки достичь компромисса в выборе общего редактора для группы разработчиков приведут к недовольству. У каждого есть собственное мнение о том, что здесь важно, а плюсы и минусы разных систем имеют для разных разработчиков различный вес. Да и в конечном итоге, это не так уж важно.» И такое мнение долгие годы оставалось доминирующим. В конце концов, не важно, какими IDE пользуются коллеги, если их код остаётся качественным. Но я двенадцать лет занимался в Google инструментами разработчика, поэтому время от времени задумывался над этим вопросом.

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

#cider #code_completion #language_server_protocol #vscode #ide

История IDE в Google

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

Хабр

Тестируем новый TypeScript-Go в OpenIDE: что на самом деле даёт порт компилятора

Недавно команда TypeScript представила TypeScript 7 — новую версию, переписанную на Go. Главные обещания: до 10× ускорения компиляции и до 8× более быстрый старт анализа проекта . Но самое интересное спрятано чуть глубже: вместе с TS-Go появляется полноценный LSP-сервер , встроенный прямо в компилятор. Для многих IDE это шаг вперёд. Для нас, команды OpenIDE , — это ещё и освобождение от ограничений, с которыми TypeScript приходилось поддерживать долгие годы. В статье делимся контекстом, собственными экспериментами и наблюдениями — что уже работает, что нет и как новый сервер ощущается в реальной IDE.

https://habr.com/ru/companies/haulmont/articles/973534/

#typescript #language_server_protocol #golang #ide #javascript #webразработка #nodejs

Тестируем новый TypeScript-Go в OpenIDE: что на самом деле даёт порт компилятора

Недавно команда TypeScript представила TypeScript 7 — новую версию, переписанную на Go. Главные обещания: до 10× ускорения компиляции и до 8× более быстрый старт анализа проекта . Но самое интересное...

Хабр

@GeanyIDE
I saw a few web articles since the 2.1 release of Geany. They more or less rephrased the release notes we published. Which is totally fine.

But I guess it was missed that the Geany-Plugins collection was also released and beside nice small additions in there, there was a whole new plugin:

Geany-LSP

This plugin integrates any (or least almost) LSP server into Geany and enriches Geany's functionality a lot. From my point of view, this is a great addition which lots of useful additional features.
So, if you wrote and will write an article about Geany, please notice the Geany-LSP plugin and tell other Geany users about.

The plugin is distributed as part of the Geany-Plugins collection, see https://github.com/geany/geany-plugins.

It's development and issue tracker can be found at its project page: https://github.com/techee/geany-lsp

The plugin developer did a great job in writing the plugin and also extending the Geany core to work with the plugin. This was a hard bit of work.

#Geany #LSP #language_server_protocol

[Перевод] MCP и будущее AI: что стоит знать сегодня, чтобы не отстать завтра

С тех пор как OpenAI внедрила функцию function calling в 2023 году, я всё чаще задумываюсь о том, что потребуется, чтобы по-настоящему разблокировать экосистему агентов и инструментов. По мере того как базовые модели становятся всё более интеллектуальными, возможности агентов взаимодействовать с внешними инструментами, данными и API всё больше фрагментируются: разработчики вынуждены реализовывать агентов с индивидуальной бизнес-логикой под каждую отдельную систему, в которой агент работает или с которой интегрируется. Очевидно, что необходим единый стандартный интерфейс для исполнения, извлечения данных и вызова инструментов. API стали первым универсальным стандартом для Интернета — общим языком, с помощью которого взаимодействуют программные системы. Но у AI-моделей до сих пор нет эквивалента такого унифицированного протокола. Model Context Protocol (MCP), представленный в ноябре 2024 года, привлек большое внимание в сообществе разработчиков и AI-энтузиастов как потенциальное решение этой проблемы. В этой статье мы разберем, что такое MCP, как он меняет способ взаимодействия AI с инструментами, что уже создают разработчики на его основе и какие задачи еще предстоит решить. Поехали.

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

#mcp #mcpserver #model_context_protocol #ai #ии #llm #lsp #language_server_protocol #ai_агенты #ииагенты

MCP и будущее AI: что стоит знать сегодня, чтобы не отстать завтра

С тех пор как OpenAI внедрила функцию function calling в 2023 году, я всё чаще задумываюсь о том, что потребуется, чтобы по-настоящему разблокировать экосистему агентов и инструментов. По мере того...

Хабр

And now there's also a watch system integrated. I think it's now ready enough to test in our next project and then release it for the public.

#ink #vscode #lsp #languageServerProtocol #language_server_protocol

How the RLS works

The Rust Language Server (RLS) is an important part of the plan to provide IDE support for Rust developers. In this blog post I'll try to explain how the RLS works. The language server architecture for IDEs is a client/server architecture. It separates the concerns of editing and understanding

featherweight musings