Здравствуйте, night beast, Вы писали:

NB>если нет необходимости генерить картинку из osm файла (очень сомневаюсь что JavaScript этим занимается), то там банальное скачивание по известному адресу.
NB>никакой библиотеки не требуется.

Это очень-очень упрощенное представление

Да, скачиваются растровые изображения, масштабируются, отображаются, анализируется необходимость докачки новых изображений, кешируются старые.
Кроме этого, обеспечивается наличие многих "слоёв_пирога" — layers, при этом, изображения слоя привязываются к широте и долготе объектов на карте.

Альтернативный вариант — работа с векторными изображениями (потребуется скачивать и кешировать намного меньше, чем для растровых).
В этом случае именно происходит "генерация_картинки", но наличие этой "низкоуровневой" задачи, не отменяет высокоуровневый API на JS, Java, C#
C++ как раз интересен тем, что низко- и высоко-уровневые задачи одного проекта, могуь быть закрыты одним ЯП.

Возвращаясь к теме: именно наличие таких библиотек, это то, что так необходимо языку для наличия массовой популярности.
Пока НЕ нужно, не приперло — ты даже не понимаешь, сколько трудозатрат экономит та или иная библиотека...
Именно это (отсутствие библиотек) — фактор замедления при внедрении нового языка.
Как обстоят с этим дела в Go — сказать не берусь, но подозреваю что пока библиотек всё-же мало

Здравствуйте, night beast, Вы писали:

NB>если нет необходимости генерить картинку из osm файла (очень сомневаюсь что JavaScript этим занимается), то там банальное скачивание по известному адресу.
NB>никакой библиотеки не требуется.

Это очень-очень упрощенное представление

Да, скачиваются растровые изображения, масштабируются, отображаются, анализируется необходимость докачки новых изображений, кешируются старые.
Кроме этого, обеспечивается наличие многих "слоёв_пирога" — layers, при этом, изображения слоя привязываются к широте и долготе объектов на карте.

Альтернативный вариант — работа с векторными изображениями (потребуется скачивать и кешировать намного меньше, чем для растровых).
В этом случае именно происходит "генерация_картинки", но наличие этой "низкоуровневой" задачи, не отменяет высокоуровневый API на JS, Java, C#
C++ как раз интересен тем, что низко- и высоко-уровневые задачи одного проекта, могуь быть закрыты одним ЯП.

Возвращаясь к теме: именно наличие таких библиотек, это то, что так необходимо языку для наличия массовой популярности.
Пока НЕ нужно, не приперло — ты даже не понимаешь, сколько трудозатрат экономит та или иная библиотека.
Я ведь и сам не представлял, пока не занялся вплотную — например, теми же GIS системами...

Именно это (отсутствие библиотек) — фактор замедления при внедрении нового языка.
Именно поэтому, весьма часто, разработчик тратит время и силы на изучение актуальных предметных наработок в "старом" языке,
нежели вкладывается в изучение "нового" языка.

Как обстоят с этим дела в Go — сказать не берусь, но подозреваю что пока библиотек всё-же мало