Если код получается слишком сложным, значит что-то в нём не так. Проблема моков в том, что при тестировании, тестируешь не нужный сервис, а свои моки, в которых тоже может быть ошибка.
Do_Error — тоже совсем не гошное имя переменной.
Думаю, нужно пересмотреть алгоритм. Наверняка всё можно сильно упростить.
А зачем вообще гошный проект компилировать на машине клиента? Почему программу не распространять в виде бинарника и рядом конфиг? И пусть кладут куда хотят потом.
Далее, если юзер будет править конфиг, то он вполне может его положить в нужное место. Например, рядом с бинарником или в ~/.myapp/, или в /usr/local/etc/myapp/. Можно и там и сям, с приоритетом конфига в директории бинаря. А ключ, всё-таки, сделать для того, если юзер хочет конкретно в другом месте разместить конфиг.
Если редактирование конфига опционально – зашить умолчательные настройки в саму программу.
А на этапе копиляции прописывать путь до кофига — это как-то странно. Если захочется переместить конфиг – программу перекомпилировать?
Парень серьёзными вещами заняться решил, а вы ему PHP советуете :).
Но на самом деле верно. Тут или шашечки, или ехать. На PHP пока ещё спрос есть и не малый, но это от того, что не смотря на огромное количество "кодеров", вменяемых из них несколько процентов.
Да не агитирую за свои велосипеды, ни в коем случае. Я просто пытался понять мотивацию ТС.
Лично моё мнение – нужно решать проблемы по мере их возникновения. Если видно, где можно оптимизировать по-пути и это не займёт много времени, то можно и на месте сделать. Но лучше не делать, пока не возникнут проблемы. Как показывает практика, чаще проблемы не возникают :)
А что, такая большая необходимость в поддержке старых браузеров? Websocket уже несколько лет работает в браузерах. Socket.io и подобные штуки больше не актуальны. Ну и реализация его на Go хромает (смотрел пару лет назад, правда).
Ошибка здесь в использовании go-curl. Нафига тащить сишную либу, в которой ничего не понимаешь, когда есть отличный пакет net/http, который позволяет делать всё?
Хочется более высокого уровня либу, т.к. лень (или просто некогда) написать самому? Есть и такие.
Go – язык с открытыми исходниками. Если что-то, по вашему мнению, работает не так, то правильно было бы докопаться до сути и запостить проблему на гитхаб. Либо даже найти решение и запостить пул реквест.
Но по опыту скажу, что в 90% искать проблему нужно в своем коде.
Владимир Грабко: у него хэндлер так написан был (который он не показал, но скорее всего так), не нужно на инструмент валить. Различие при компилляции под другой ОС тоже, вероятно, связана с использованием cgo (т.е. сишной части, го тут не причем).
Си – простой язык, но в простоте и есть его проблема. В поставке нет стандартных средств для реализации каких-либо более-менее сложных сервисов.
Го – простой и современный язык, в комплекте с которым идёт обширная стандартная библиотека на все случаи жизни.
В общем, если ТС написал, что не хочет заниматься профессионально, то с какой целью мучить себя, когда можно изучить простой и эффективный язык? Я не говорю, что Си – это плохо и его не нужно учить. Си – отличный язык, очень производительный, но, скажем так, не самый эффективный с точки зрения разработки (да и изучения).
Зачем учить Си? С памятью в современных условиях проблем нет, производительности тоже достаточно. Не систему реального времени же создают. Го отлично подходит для этих целей.
Конкретно нужный пункт:
https://golang.org/doc/effective_go.html#for