Внезапно большинство десктопных приложений пишутся именно на языках "системного программирования", ибо микролаги из-за GC

GUI renderer = systems programming GUI application = application programming я не говорю что на Go нужно рендерить, нет, ни в коем случае! (мы об этом уже здесь говорили почему писать рендер на Go это очень плохая идея) а вот для самой логики приложения, для работы с сетью, для работы с файловой системой, с базами данных, с поверхностным number crunchung'ом и т.д. Go довольно хорош в идеале у нас рендер на Rust вызывающий Go код. Никаких микролагов, стабильные 60 фпс, но и относительно простое написание логики приложения. https://github.com/therecipe/qt это как-раз про C++/Qt рендер с Go логикой

GUI renderer = systems programming GUI application = application programming я не говорю что на Go нужно рендерить, нет, ни в коем случае! (мы об этом уже здесь говорили почему писать рендер на Go это очень плохая идея) а вот для самой логики приложения, для работы с сетью, для работы с файловой системой, с базами данных, с поверхностным number crunchung'ом и т.д. Go довольно хорош в идеале у нас рендер на Rust вызывающий Go код. Никаких микролагов, стабильные 60 фпс, но и относительно простое написание логики приложения. https://github.com/therecipe/qt это как-раз про C++/Qt рендер с Go логикой

То есть при вводе текста лагов в такой схеме не будет замечено? Сомневаюсь.

А что думаете на счёт Elixir? Discord его активно использует

эликсир хорош

В том же VS Code если быстро печатать, то можно заметить инпут лаг.

внешне по крайне мере

Хотя рендер у него на цпп.

хотя я у нашего эрлангиста спросил, он сказал, что нах*й не нужОн

Проблема в том, что не легаси работает так плохо, что аж терпеть невозможно.

проблема веб-аппликух обёрнутых в аппликухи типа Electron в устаревшем DOM'е (HTML/CSS это вообще про статические документы, а не динамические приложения) QML это как раз замена HTML/CSS/DOM, но пока-что только в C++/Qt

проблема веб-аппликух обёрнутых в аппликухи типа Electron в устаревшем DOM'е (HTML/CSS это вообще про статические документы, а не динамические приложения) QML это как раз замена HTML/CSS/DOM, но пока-что только в C++/Qt

Проблема в том, что надо не только рисовать быстро, но и обрабатывать пользовательский ввод без задержек

То есть при вводе текста лагов в такой схеме не будет замечено? Сомневаюсь.

ты пойми, рендер и логика/данные должны оперировать в разных потоках независимо друг от друга. Единственно лаги могут возникать когда рендер не может отрисовать картинку из-за того что логика его блокирует, но этого можно и нужно избегать

а как думаете, чем плох swift по сравнению с go для бэкэнда?

Проблема в том, что надо не только рисовать быстро, но и обрабатывать пользовательский ввод без задержек

Go в этом плане в тысячи раз лучше JavaScript

а как думаете, чем плох swift по сравнению с go для бэкэнда?

goroutines например?

ты пойми, рендер и логика/данные должны оперировать в разных потоках независимо друг от друга. Единственно лаги могут возникать когда рендер не может отрисовать картинку из-за того что логика его блокирует, но этого можно и нужно избегать

Ну вот допустим у нас текстовый редактор. Там, чтобы символ появился на экране рендер должен отдать событие апликэйшн части, а апп должен рассказать рендеру что рисовать. Как в такой схеме избежать лагов? Только переписывать логику на языке без GC

Скорее десктопные приложения нужно писать с архитектурой frontend-backend, где на бэкенде вся медленная бизнес логика, а на фронте быстрые обработчики событий.

а как думаете, чем плох swift по сравнению с go для бэкэнда?

всем хорош, кроме одного - его помимо apple никто не юзает

а как думаете, чем плох swift по сравнению с go для бэкэнда?

Там атомарный счётчик ссылок через атомарный счётчик ссылок ехал и треды нативные.

Ну вот допустим у нас текстовый редактор. Там, чтобы символ появился на экране рендер должен отдать событие апликэйшн части, а апп должен рассказать рендеру что рисовать. Как в такой схеме избежать лагов? Только переписывать логику на языке без GC

shared memory. рендер в отдельном потоке работает с повышенным приоритетом грубо говоря 60 раз в секунду наблюдая за изменениями в data model которая в shared memory. application logic может пропустить пару кадров например из-за GC, но не заблокирует этим render. Когда AL завершит свою обработку данных он просто разлочит новую модель и рендер среагирует на это читая новую модель

shared memory. рендер в отдельном потоке работает с повышенным приоритетом грубо говоря 60 раз в секунду наблюдая за изменениями в data model которая в shared memory. application logic может пропустить пару кадров например из-за GC, но не заблокирует этим render. Когда AL завершит свою обработку данных он просто разлочит новую модель и рендер среагирует на это читая новую модель

Ну вот ты описал сценарий, где инпут лаг 2 кадра. Ну и нахера такие приложения нужны?

Ну вот ты описал сценарий, где инпут лаг 2 кадра. Ну и нахера такие приложения нужны?

А это много? ?

Скорее десктопные приложения нужно писать с архитектурой frontend-backend, где на бэкенде вся медленная бизнес логика, а на фронте быстрые обработчики событий.

я именно это и предлагаю, просто и backend и frontend в одном бинаре, но в разных потоках на разных платформах (Rust, Go) деля меж собой память процесса в качестве коммуникации

А это много? ?

Для 60к/с - очень

Ну вот ты описал сценарий, где инпут лаг 2 кадра. Ну и нахера такие приложения нужны?

за отображение символов в текстовом поле может отвечать render, не обязательно бизнес-логика

сам Пайк об этом трубил во все стороны, хотя это конечно бред)

нужно быть фантастически смелым человеком, чтобы утверждать, что Пайк не знает, что он делает, да.

в C++ разве умные указатели не решают проблем хотя бы частично?

Умные указатели - это вообще ортогональная тема.

Умные указатели - это вообще ортогональная тема.

почему? вроде про new\delete имелось в виду про опасности?

почему? вроде про new\delete имелось в виду про опасности?

Это единственная проблема, которую умные указатели решают, и то, если не забываешь их мувать при передаче кому-нибудь (unique_ptr).

Владение и заимствование же решают эти проблемы фундаментально.

И ещё кучу других.

Это единственная проблема, которую умные указатели решают, и то, если не забываешь их мувать при передаче кому-нибудь (unique_ptr).

вроде умные указатели решают проблемы с утечкой памяти+проблемы с concurrency?

вроде умные указатели решают проблемы с утечкой памяти+проблемы с concurrency?

Они решают только проблему своевременного удаления объектов. О каких проблемах с concurrency вы говорите?

Они решают только проблему своевременного удаления объектов. О каких проблемах с concurrency вы говорите?

гонки по данным?

гонки по данным?

Не решают.

Не решают.

зачем тогда нужен shared_ptr и unique_ptr?

зачем тогда нужен shared_ptr и unique_ptr?

shared_ptr решает проблему своевременного очищения "общих" объектов, unique_ptr решает проблему своевременного очищения объектов, на которые есть одна уникальная ссылка. При этом unique_ptr никак не гарантирует, что на объект есть только одна ссылка.

shared_ptr решает проблему своевременного очищения "общих" объектов, unique_ptr решает проблему своевременного очищения объектов, на которые есть одна уникальная ссылка. При этом unique_ptr никак не гарантирует, что на объект есть только одна ссылка.

тогда странно, что unique_ptr назван так

тогда странно, что unique_ptr назван так

Ничего странного, он создан ДЛЯ объектов на которые должна быть только одна уникальная ссылка, при этом за исполнением контракта в C++ традиционно должен следить программист

нужно быть фантастически смелым человеком, чтобы утверждать, что Пайк не знает, что он делает, да.

я лишь его цитирую, он сам утвердил что Go это не про systems programming а про „cloud infrastructure“

смотря что понимать под systems programming

Владение и заимствование же решают эти проблемы фундаментально.

проблема в C++ в том, что можно этим good practice’ам следовать, а можно и нет… в Rust такого выбора нет (однако он всё-же есть в виде unsafe для работы с C, но его в обычном коде не используют, только в связном) Rust заставляет тебя думать правильно, C++’ам на тебя и твои баги н@срать))

вроде умные указатели решают проблемы с утечкой памяти+проблемы с concurrency?

частично.

гонки по данным?

а вот гонки никак не решают

Вот вам не лень...

shared_ptr решает проблему своевременного очищения "общих" объектов, unique_ptr решает проблему своевременного очищения объектов, на которые есть одна уникальная ссылка. При этом unique_ptr никак не гарантирует, что на объект есть только одна ссылка.

unique_ptr же вроде deprecated?

смотря что понимать под systems programming

чуть выше писал

Вот вам не лень...

+1!

application programming = software for users systems programming = software for software applications prog. = ttm (time-to-market), features, security systems programming = performance, resource-usage, safety Rust = systems programming Go = application programming

@aadz69

@aadz69

Угу. Скрипты на Bash - это тоже приложения для приложений, я даже иногда такие системные скрипты пописываю

нужно быть фантастически смелым человеком, чтобы утверждать, что Пайк не знает, что он делает, да.

Ну что там, когда в лик святых Пайка уже добавляем?

Угу. Скрипты на Bash - это тоже приложения для приложений, я даже иногда такие системные скрипты пописываю

скрипты это отдельная тема

да любая тема отдельная

особенно хорошо, если она в теме и в правильном месте

вот например можно ли рассматривать Go как systems programming language? можно ли написать библиотеку на Go, которую можно вызвать из другого языка (не посредством сети)?

C/C++/Rust этим могут похвастаться, Go не особо

ты решил поменять определение понятия языка для системного программирования? Ну, OK!

Просто иногда даже и задумаешься - сколько можно толочь воду в ступе?

ты решил поменять определение понятия языка для системного программирования? Ну, OK!

это понятие размытое, нет конкретного определения, с этим согласны и Stroustrup, и Пайк и… кто там D проектировал?

Привет всем! Я пишу клиентский метод для вот этого метода API: https://api.bitfinex.com/v2/tickers?symbols=ALL Подскажите как лучше всего распарсить ответ данного API в структуру type TickerResponse struct { Symbol string `json:"symbol"` Bid float64 `json:"bid"` BidSize float64 `json:"bid_size"` Ask float64 `json:"ask"` AskSize float64 `json:"ask_size"` DailyChange float64 `json:"daily_change"` DailyChangePerc float64 `json:"daily_change_perc"` LastPrice float64 `json:"last_price"` Volume float64 `json:"volume"` High float64 `json:"high"` Low float64 `json:"low"` } В данный момент я распарсил ответ вот таким образом var response []interface{} err = json.Unmarshal(body, &response) if err != nil { return response, err } Теперь мне нужно смапить response в структуру, но возникает сложность с преобразованием типов.

а почему нельзя сразу в структуру распарсить?

зачем этот []interface{}

а почему нельзя сразу в структуру распарсить?

Сразу в структуры не получается, API возвращет ответ посто в виде массива

Я правда на всякий случай попытался))

плохо попытались

ERROR: S client not available

в массив структур почему нельзя распарсить?

плохо попытались

Я сделал вот так var tickersResponse []structures.TickerResponse err = json.Unmarshal(body, &tickersResponse) if err != nil { return tickersResponse, err } но получил вот такую ошибку json: cannot unmarshal array into Go value of type structures.TickerResponse

так там массив массивов

к вашей структуре надо приписать кастомный анмаршалер

который будет сначала массив парсить, а потом структуры заполнять

о, да там в одном массиве строки и числа

это прямо праздник!

к вашей структуре надо приписать кастомный анмаршалер

Ну то есть получается что по итогу будет нужно присваивать эллементы массива к полям структуры? Я попробовал сделать это посто в цикле, но у меня возникла сложность с типами. В массиве у меня тип данных интерфейс, а нужно присвоить к полю с типом стринг или float64, я так и не нагуглил как это сделать лучше всего

пожалуй, действительно, с interface{} это разобрать будет проще всего

я прошу прощения

Ну то есть получается что по итогу будет нужно присваивать эллементы массива к полям структуры? Я попробовал сделать это посто в цикле, но у меня возникла сложность с типами. В массиве у меня тип данных интерфейс, а нужно присвоить к полю с типом стринг или float64, я так и не нагуглил как это сделать лучше всего

будем считать, что у вас там два типа

string и float64

это прямо праздник!

Да) В этом то всё веселье, не будь в массиве смешанных типов данных, всё было бы проще)

про цикл я не понял - вы в цикле поля структуры перебираете? рефлексией?

это я бы делать не советовал

я бы советовал руками прописать все 11 присваиваний

типа Symbol : res[0].(string) Bid: res[1].(float64)

про цикл я не понял - вы в цикле поля структуры перебираете? рефлексией?

Не совсем, я перебираю response типа []interface{} и хочу присваивать руками все поля структуры, но не знаю как преобразовать тип, так как не могу присваить к строковому полю тип interface{}

Увидел ответ

ага

Сейчас попробую, большое спасибо за помощь

И ещё, если не сложно, могли бы вы проконсультировать меня по такому вопорсу: В корне моего проекта лежит файл server.go который отвечает за обработку HTTP запосов, но мне так же нужны различные мелкие утилитки для операций над БД, сбора аналитики по крону, они лежат в папке cmd в корне поекта. В связи с этим у меня возникает порблема с пописыванием путей к файлам конфигов, к файлам логов так как точкой отсчёта является папка в которой лежит бинарник. Бодскажите как правильно организовывать доступ к файлам?

Я скорее всего объяснил не очень понятно, поэтому если нужны уточнения, я их предоставлю

И ещё, если не сложно, могли бы вы проконсультировать меня по такому вопорсу: В корне моего проекта лежит файл server.go который отвечает за обработку HTTP запосов, но мне так же нужны различные мелкие утилитки для операций над БД, сбора аналитики по крону, они лежат в папке cmd в корне поекта. В связи с этим у меня возникает порблема с пописыванием путей к файлам конфигов, к файлам логов так как точкой отсчёта является папка в которой лежит бинарник. Бодскажите как правильно организовывать доступ к файлам?

передавайте все пути через флаги при запуске сервера

конфиг через флаг, лог пути в конфиге ну или кординально ваулт

Привет всем! Я пишу клиентский метод для вот этого метода API: https://api.bitfinex.com/v2/tickers?symbols=ALL Подскажите как лучше всего распарсить ответ данного API в структуру type TickerResponse struct { Symbol string `json:"symbol"` Bid float64 `json:"bid"` BidSize float64 `json:"bid_size"` Ask float64 `json:"ask"` AskSize float64 `json:"ask_size"` DailyChange float64 `json:"daily_change"` DailyChangePerc float64 `json:"daily_change_perc"` LastPrice float64 `json:"last_price"` Volume float64 `json:"volume"` High float64 `json:"high"` Low float64 `json:"low"` } В данный момент я распарсил ответ вот таким образом var response []interface{} err = json.Unmarshal(body, &response) if err != nil { return response, err } Теперь мне нужно смапить response в структуру, но возникает сложность с преобразованием типов.

https://github.com/bitfinexcom/bitfinex-api-go/pull/84/files

а еще можно, что бы все было одним бинарем, режим выбирался флагом и соответсвенно, небольшая обертка на баше в нужном месте

передавайте все пути через флаги при запуске сервера

Мне пути к конфигам нужны и в небольших утилитках, будет не очень удобно для каждой передавать пути. Или я не правльно понял что нужно сделать?

мне вот непонятен вопрос

1. конечно, отсчет идет не от того места, где лежит исходник, а от того, где лежит скомпилированный бинарник

2. путь к конфигу придется передавать так или иначе. или захардкодив путь в утилитку, или сделав в ней флаг, или еще как