Какая скорость разработки серверов для небольших проектов с небольшой нагрузкой .
При небольшом опыте разработки если смысл писать такие сервера ? Будут ли какие-то преимущества по сравнению с той же нодой ?
А о чем вообще был вопрос - эффективность чего?
Создания, эксплуатации?
По сравнению с чем?
На каких проектах? Мелких, больших?
При какой квалификации разработчика? Начинающие, опытные?
G_tost а какие цифры нужны? Мой опыт - 2 дня изучения, 7 микросервисов за неделю, на go + gin-gonic + mgo. О небольшой нагрузке судить не могу, два сервиса нагружены до 7K запросов/сек. Много это или мало - вопрос относительный.
Примерно на одном уровне с ngnix, а иногда даже быстрее, за счет отсутствия проксирования на бэкенд, так как у Вас в одном приложении и сервер и логика
Другой вопрос в том, на сколько оптимально Вы напишите Ваш код и умеете пользоваться Go, ибо даже на асме можно сделать тормоза, что php3+apache будет быстрее ползать
un1t: проблема медленных клиентов решается только одним из двух методов - прокси (внешний или внутренний, я бы выбрал внешний, зачем писать велосивед) и раздувание количества открытых соединений (каждый web-запрос обрабатывается в своей параллельной или псевдопараллельной go-routine, ничего для этого делать не нужно).
go держит тысячи go-routine без заморочек. Но это затраты памяти.
abcyu: стандартный пакет http и так создает горутину на каждый запрос, горутины работают ассинхронно и изменить это в отличии от js к счастью нельзя, тут принцип другой, при любом ассинхронном вызове горутина блокируется, но в это время на том же потоке могут выполняться другие горутины. un1t: Любая программа выполняющаяся более чем в одной горутине будет ассинхронной, и, следовательно, наличие медленных клиентов как-то всеравно, каждый http запрос у нас в отдельной горутине из коробки
un1t: у Go в одной утилите и компилятор и пакет-менеджер и юнит тесты и много чего еще
зависимости прописываются непосредственно в исходниках в операторе import
если хотите распространять свое приложение в исходниках - пишите make файл для сборки
если распространяете пакеты, то go get вполне подтягивает зависимости самостоятельно
Дмитрий Беляев: Из коробки там какой-то геморой с пакетами, нельзя указывать версии пакетов и нужно прописывать GOPATH для каждого проекта. Мне понравился gb, но я не знаю насколько он общепринятый, может имеет смысл посмотреть на другой.
un1t:
встроенный менеджер - качает всегда последние версии
я использую gb, просто и удобно и фиксировано.
начиная с 1.5 встроили какой-то функционал "vendor", еще не разбирался.
un1t:
GOPATH она одна, а не для каждого пакета.
GOPATH указывает каталог где лежат исходники, и там же рядом будут лежать бинарники.
GOPATH может быть один на каждый отдельный проект, а может быть вообще одним на все твое рабочее место (ну тогда, вестимо, библиотеки будут все вместе лежать для всех проектов).
gb настолько помню сам эмулирует GOPATH, ничего делать не нужно.
un1t:
насколько общепринят gb....
удобен, поэтому принят или не принят - неважно. если не требует чего-то специфического можно gb использовать
недавно сдавал работу в исходниках иностранным заказчикам. там нормальный сильный тех. лид, но он не гофер.
отдал в одном абзаце тех. лиду в виде структуры каталогов для gb. описал как ставить gb да как компилировать с ним.
у тех. лида ни одного вопроса по компиляции проекта.
вопросы были только по функционалу.
все приняли, проверили и запустили в продакшн.
никаких проблем с использованием gb
По медленным соединениям вроде была тулза которая их генерирует и проверяет веб-сервер на прочность. Можно провести тесты nginx vs golang
По поводу gb, жаль что не пошли по пути git.
go init создавал бы каталог .golang и от него бы уже всё плесалось....
Средний
