Совсем сторонние, не на Go написанные — в общем случае нет, у них могут быть свои динамические зависимости. Тут надо отдельно на каждую либу внимательно смотреть.
И сама go-программа тоже не абсолютно автономна, для некоторых функций она обращается к системным библиотекам. Самая заметная такая функция — резолвинг DNS (см. коммент к тому посту blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/#comment-1719377745). Но в данном случае это не мешает, т. к. системные либы в лямбда-окружении доступны.
Хотя формально поддерживается только Node.js, но вместе с JS-файлами туда можно загружать произвольные ресурсы, в том числе и исполнимые файлы, написанные на других языках. И вызывать их потом из JS.
Я общался с Яндексом по поводу п. 1 для Я.Картинок. Ему это не интересно. Большинство картинок, которые есть на стоках, есть и где-то ещё, а значит, выгоднее показать большую чистую картинку из этого «где-то ещё», а не маленькую с водяными знаками картинку со стока, да ещё и с кнопкой «Купить». Люди, скажем уж честно, идут в Я.Картинки не для того, чтобы покупать, а для того, чтобы скачать на халяву. Не смогут тут — уйдут к конкуренту (Гуглу).
А возможная прибыль от нескольких честных покупателей, очевидно, несравнимо меньше прибыли от рекламы на страницах, где пасутся миллионы халявщиков.
Например, в PostgreSQL есть тип JSON. В него можно класть произвольные JSON-данные, а кроме того, делать из поля этого типа выборки ('{«a»:1,«b»:2}'::json->'b') и строить индексы по полям этих данных (с версии 9.3). Кажется, при таких возможностях, нет смысла параллельно держать Монгу?
Столь строгое совпадение времени ресайза libNthumbIppOnly и libNthumb даже афинными преобразованиями не объяснить. Я бы вообще предположил, что они и там и там использовали предварительное 8-кратное уменьшение. Ну а что, всё равно никто не проверит…
Ага, тоже недавно (как пояса обновлял) открыл для себя смещение в +14 часов:)
Нет, дата рождения — это, к сожалению, именно дата, просто дата. Без таймзоны, без ничего. И каждый раз, когда её надо сделать временем, вокруг неё надо плясать с бубном…
Сорри, пример плох тем, что List пересекается с тем, что предлагает 'gen'. Там действительно генерится один файл, и нет проблем со встраиванием в пакет.
Но если List (или какая-то другая нетривиальная структура) требует не одного файла, а целого пакета, возможно, с подпакетами и импортами снаружи — вот как в таком случае генерировать код, я не знаю…
(сорри, в первом варианте комментария парсер съел угловые скобки)
…Простой пример: есть некая библиотека list, реализующая, скажем, типизированный список: list.List[T] (просто для примера). Пусть теперь в _нашем_ пакете user есть тип user.User и мы хотим в нём же использовать user.List[user.User]. Кодогенерацией это сделать невозможно — чтобы сгенерировать код для List[User], нам надо в сгенерированный пакет импортировать пакет user, а потом то что получилось импортировать в user же. Получится циклический импорт.
Да, есть много вариантов кодогенерации (я этим вопросом интересовался). Есть даже крутая идея генериков-как-веб-вервиса:) — bouk.co/blog/idiomatic-generics-in-go/
К сожалению, это очень ограниченное решение. Простой пример: есть некая библиотека list, реализующая, скажем, типизированный список: list.List (просто для примера). Пусть теперь в _нашем_ пакете user есть тип user.User и мы хотим в нём же использовать user.List. Кодогенерацией это сделать невозможно — чтобы сгенерировать код для List, нам надо в сгенерированный пакет импортировать пакет user, а потом то что получилось импортировать в user же. Получится циклический импорт.
Одной из идеоматических бест-практик Го являются каналы каналов — когда мы передаём канал Б в канал А и слушаем из канала Б результат. Если внимательно посмотреть на этот паттерн, то можно увидеть обыкновенный Promise. Но нам ведь обычно не интересно передавать _только_ каналы. Нам интересно передать данные какого-то типа, и получить через обратный канал данные какого-то другого типа. А ещё и ошибки хорошо было бы получать. Сейчас это всё можно делать только через interface{} или через копипаст. Хотя передавать в канал канал для результата — это то, чем начинается каждый учебник Го, идеоматичнее паттерна и быть не может.
На PubSub Алексей там тоже сослался — о нём рассказывается непосредственно в пайковском “Advanced Go Concurrency Patterns” (http://blog.golang.org/advanced-go-concurrency-patterns). Если это не best practice, то и не знаю, что тогда best practice.
Я давно пишу на Го, и он мне очень нравится и без генериков (я без них не «страдаю»). Однако я вижу, что с генериками мы могли бы получить более мощные библиотеки.
Они действительно нужны не всегда. Но, на мой взгляд, их отсутствие уже начинает подтормаживать развитие языка. Без генериков трудно делать достаточно сложные универсальные библиотеки, а сила языка в том числе и в богатстве библиотек.
А во что ещё? Можно интерпретировать, но даже с JIT-ом интерпретация медленна (хотя вот Lua неплохо справляется). Можно создавать код для вирт. машины (Java и вся её семья), но это требует поддержки собственно виртуальной машины, нетривиальной её настройки и обычно большого кол-ва памяти. И можно компилить в бинарники, которые запускаешь, и они работают. Особенно удобны Go-бинарники в силу статической линковки — деплой сводится к копированию ровно одного файла.
Разумеется, можно убрать требование компиляции, и тогда спектр языков станет гораздо шире. Но тем, кто выбирает Go, обычно компиляция важна.
Не так много на рынке статически типизированных, компилируемых в нативные бинарники, кроссплатформенных, да ещё и сколько-нибудь распространённых языков. Если не брать си с плюсами, то останется, по сути, только OCaml, Go и Rust.
Но она, к сожалению, тоже не актуальна — отсутствуют новые зоны Asia/Chita и Asia/Srednekolymsk, а значит, недавняя перетасовка поясов в России там не учтена…
Хм, а что там написано, опровергающее Ваши слова?) Да, Постгрес понимает названия и аббревиатуры таймзон. Но тип timestamp with time zone всё равно хранит только UTC-время + смещение, а не название таймзоны. Хотя его, конечно, можно рядом положить, как строку…
Я, правда, сам на своём сайте использую именно постгресовый timestamptz, но у меня нет дат в будущем, так что пока более-менее всё нормально.
Спасибо, кстати, за статью. Хранить город (координаты) пользователя — это классная идея. Но поделитесь, как вы потом переводите эту точку в таймзону? Где-то есть актуальные границы таймзон? Я знаю только efele.net/maps/tz/, но там последнее обновление было год назад…
У нас (lori.ru) некоторое количество мелких сервисов на Го. В частности, сервисы, обрабатывающие картинки. Правда, к сожалению, родная картиночная библиотека Го очень медленная, приходится использовать биндинг к ImageMagick.
Думаю, его много где используют, просто в России не очень принято делиться/хвастаться внутренними разработками.
Вообще, язык классный, очень легко на нём писать, и результат получается весьма надёжным. Хотя генериков и не хватает:)
И сама go-программа тоже не абсолютно автономна, для некоторых функций она обращается к системным библиотекам. Самая заметная такая функция — резолвинг DNS (см. коммент к тому посту blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/#comment-1719377745). Но в данном случае это не мешает, т. к. системные либы в лямбда-окружении доступны.
Вот тут пишут об успешном запуске Go-программы: blog.0x82.com/2014/11/24/aws-lambda-functions-in-go/
Go тут удобен тем, что он компилирует всё в один статический экзешник, поэтому неважно, в каком окружении его запустит Лямбда.
А возможная прибыль от нескольких честных покупателей, очевидно, несравнимо меньше прибыли от рекламы на страницах, где пасутся миллионы халявщиков.
1) В чём новизна работы?
2) Каковы критерии качества результата?
Нет, дата рождения — это, к сожалению, именно дата, просто дата. Без таймзоны, без ничего. И каждый раз, когда её надо сделать временем, вокруг неё надо плясать с бубном…
Но если List (или какая-то другая нетривиальная структура) требует не одного файла, а целого пакета, возможно, с подпакетами и импортами снаружи — вот как в таком случае генерировать код, я не знаю…
…Простой пример: есть некая библиотека list, реализующая, скажем, типизированный список: list.List[T] (просто для примера). Пусть теперь в _нашем_ пакете user есть тип user.User и мы хотим в нём же использовать user.List[user.User]. Кодогенерацией это сделать невозможно — чтобы сгенерировать код для List[User], нам надо в сгенерированный пакет импортировать пакет user, а потом то что получилось импортировать в user же. Получится циклический импорт.
К сожалению, это очень ограниченное решение. Простой пример: есть некая библиотека list, реализующая, скажем, типизированный список: list.List (просто для примера). Пусть теперь в _нашем_ пакете user есть тип user.User и мы хотим в нём же использовать user.List. Кодогенерацией это сделать невозможно — чтобы сгенерировать код для List, нам надо в сгенерированный пакет импортировать пакет user, а потом то что получилось импортировать в user же. Получится циклический импорт.
На PubSub Алексей там тоже сослался — о нём рассказывается непосредственно в пайковском “Advanced Go Concurrency Patterns” (http://blog.golang.org/advanced-go-concurrency-patterns). Если это не best practice, то и не знаю, что тогда best practice.
Я давно пишу на Го, и он мне очень нравится и без генериков (я без них не «страдаю»). Однако я вижу, что с генериками мы могли бы получить более мощные библиотеки.
Они действительно нужны не всегда. Но, на мой взгляд, их отсутствие уже начинает подтормаживать развитие языка. Без генериков трудно делать достаточно сложные универсальные библиотеки, а сила языка в том числе и в богатстве библиотек.
Разумеется, можно убрать требование компиляции, и тогда спектр языков станет гораздо шире. Но тем, кто выбирает Go, обычно компиляция важна.
Но она, к сожалению, тоже не актуальна — отсутствуют новые зоны Asia/Chita и Asia/Srednekolymsk, а значит, недавняя перетасовка поясов в России там не учтена…
Я, правда, сам на своём сайте использую именно постгресовый timestamptz, но у меня нет дат в будущем, так что пока более-менее всё нормально.
Спасибо, кстати, за статью. Хранить город (координаты) пользователя — это классная идея. Но поделитесь, как вы потом переводите эту точку в таймзону? Где-то есть актуальные границы таймзон? Я знаю только efele.net/maps/tz/, но там последнее обновление было год назад…
Думаю, его много где используют, просто в России не очень принято делиться/хвастаться внутренними разработками.
Вообще, язык классный, очень легко на нём писать, и результат получается весьма надёжным. Хотя генериков и не хватает:)