компилишь на хосте или в докере?

гопаф кривой

компилишь на хосте или в докере?

На хосте

там есть Parse и формат по которому парсить

гопаф кривой

GOPATH="/home/user/go" GOROOT="/usr/local/go"

GOPATH="/home/user/go" GOROOT="/usr/local/go"

т.е. код примерно такой package khcp import ( "net/http" "github.com/gin-gonic/gin" ) func main() { //blablabla }?

go build -o http http.go

Вот код: package khcp import ( "net/http" "github.com/gin-gonic/gin" ) func main() { r := gin.New() r.GET("/", func(c *gin.Context) { c.String(http.StatusOK, "Hello World!") }) r.GET("/ping", func(c *gin.Context) { c.String(http.StatusOK, "pong") }) http.Handle("/", r) }

исправьте и будет вам щастье

исправьте и будет вам щастье

Заработало. Спасибо.

иначе придется слать на сервер всю сущность и на сервере вычислять дельту с вариантами 1) запоминать все версии сущностей, вычислять дельту по сравнению с нужной версией 2) придумывать блокировки на время редактирования 3) не придумывать блокировки и слать клиента лесом если он пытается изменить устаревшую версию.

Есть REST API, в нем метод для частичного обновления сущности PATCH. Он может быть реализован как: 1) https://tools.ietf.org/html/rfc7386 2) https://tools.ietf.org/html/rfc6902 3) пересылать полностью состояние сущности, при этом запоминать все версии сущностей, вычислять дельту по сравнению с нужной версией 4) пересылать полностью состояние сущности, при этом придумывать блокировки на время редактирования 5) пересылать полностью состояние сущности, при этом слать клиента лесом если он пытается изменить устаревшую версию сущности. Что из этого кто использует, что проще, как реализовывать на golang?

А в пятом варианте есть необходимость хранить старые версии?

Есть REST API, в нем метод для частичного обновления сущности PATCH. Он может быть реализован как: 1) https://tools.ietf.org/html/rfc7386 2) https://tools.ietf.org/html/rfc6902 3) пересылать полностью состояние сущности, при этом запоминать все версии сущностей, вычислять дельту по сравнению с нужной версией 4) пересылать полностью состояние сущности, при этом придумывать блокировки на время редактирования 5) пересылать полностью состояние сущности, при этом слать клиента лесом если он пытается изменить устаревшую версию сущности. Что из этого кто использует, что проще, как реализовывать на golang?

я бы сделал так 1) Шлется некий GET запрос, на ендпоинт, которым мы показываем, что хотим отредактировать некую сущность. Сервер делает лок на сущность и в ответ на клиента передается некий токен 2) На клиенте происходит какое-то редактирование сущности и потом вся сущность передается на сервер, вместе с полученным токеном 3) Сервер проверяет что сущность открыта на редактирование клиентом именно с таким токеном и производит обновление сущности 4) Все время, пока кто-то уже открыл сущность на редактирование, все остальные такие запросы отбиваются с ошибкой "юзер такой-то уже редактирует такую сущность". 5) У всех запросов на редактирование есть определенный таймаут, во избежание перманентного лока на редактирование

а мы просто завели /lock/unlock/update :)

я бы сделал так 1) Шлется некий GET запрос, на ендпоинт, которым мы показываем, что хотим отредактировать некую сущность. Сервер делает лок на сущность и в ответ на клиента передается некий токен 2) На клиенте происходит какое-то редактирование сущности и потом вся сущность передается на сервер, вместе с полученным токеном 3) Сервер проверяет что сущность открыта на редактирование клиентом именно с таким токеном и производит обновление сущности 4) Все время, пока кто-то уже открыл сущность на редактирование, все остальные такие запросы отбиваются с ошибкой "юзер такой-то уже редактирует такую сущность". 5) У всех запросов на редактирование есть определенный таймаут, во избежание перманентного лока на редактирование

это pessimistic lock. Зависит от бизнес задач, но зачастую слишком жирновато эксклюзивно локать. Лучше оптимистик лок

ну даже если дельту, нужно как-то связывать значение новый старый, например по ID, а дальше кодогенерацией создать if newEntity.Name != "" && newEntity.Name != oldEntity.Name { // добавляем в update значение }

а мы просто завели /lock/unlock/update :)

Гайз, не очень понимаю куда вопрос лучше задать, поэтому сюда. Есть задачка. Дано много (миллиарлды) многомерных векторов с одинаковой размерностью. На вход подается новый вектор и нужно найти N ближайших к нему по метрике косиносного расстояния (или евлидова). На чем такое можно построить? Или лучше свой велосипедик писать на гошечке?

О, стейтфул протокол поверх стейтлес. Это мы любим...

На какой архитектуре хочется запускаться?

это вопрос про железо?

Железом не обделены. Что-то вроде интелов E5-2620 и много памяти

На arm/mips и прочих странных архитектурах неинтересно запускаться, да?

а это даст какой-то существенный прирост?

скорее существенные проблемы

Гайз, не очень понимаю куда вопрос лучше задать, поэтому сюда. Есть задачка. Дано много (миллиарлды) многомерных векторов с одинаковой размерностью. На вход подается новый вектор и нужно найти N ближайших к нему по метрике косиносного расстояния (или евлидова). На чем такое можно построить? Или лучше свой велосипедик писать на гошечке?

rtree? а дальше spatial базы данных. я бы начал с postgis смотреть

Гайз, не очень понимаю куда вопрос лучше задать, поэтому сюда. Есть задачка. Дано много (миллиарлды) многомерных векторов с одинаковой размерностью. На вход подается новый вектор и нужно найти N ближайших к нему по метрике косиносного расстояния (или евлидова). На чем такое можно построить? Или лучше свой велосипедик писать на гошечке?

но хорошо не будет - там, очевидно, полный перебор