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

Parseconfig по-моему такая штука есть

Вот простая задача: при разработке, во время игры надо что-то быстренько поменять небольшим количеством кода без рестарта этой самой игры

Вот простая задача: при разработке, во время игры надо что-то быстренько поменять небольшим количеством кода без рестарта этой самой игры

Lua

Если вопрос чисто гипотетический и звучит как "можно ли использовать go в роли скриптового языка" - однозначно да. Но есть более простые решения... Сами по себе "скриптовые" языки имеют главное достоинство перед языками низкого уровня - скорость разработки. И если мы говорим о пунктах выше, уверены ли Вы что они описывают требование к скриптовому языку?

дак вот моё утверждение было именно в том, что когда не 10 строчек нужно написать а весчь чуть более сложнее - Go возможно обгонет по скорости разработки тот-же Lua и JS

Interactions & local logic = JS / Lua / Visual Scripting [> / Go?] Game world logic = Go > C++ Repetitive time consuming logic = C++ Engine = C++

а помимо ответов услышать 100500 мнений о том что нет генериков, что Go говно, что надо писать на Rust, что "ты дурак?!", что ты ничего не понимаешь... это ничто иное как засирание истории чата и с этим нужно бороться! есть чего толкового сказать? Говори - обосновывай, аргументируй, это только приветствуется. Срачь никому не полезен

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

Rust вообще всех сделал за 26 миллисекунд (про память не в курсе, но очевидно меньше Go)

дак вот моё утверждение было именно в том, что когда не 10 строчек нужно написать а весчь чуть более сложнее - Go возможно обгонет по скорости разработки тот-же Lua и JS

А можно подробнее

Но на Rust не так приятно писать, как на Go. К тому же, собственно, го для таких вычислений не очень подходит, если нужна именно скорость вычисления. Меня вполне устраивает то, что го проигрывает расту и си++, но на нем легко и удобно писать в микросервисы и простенькие программы. Я бы не стала выбирать язык по критериям скорости и объемам памяти, ну такое себе это.

спасибо кэп)) ну мы же это уже сотню раз обсуждали, что каждый языки имеют своё место)

в том то и дело, что я не хочу делать из этого чата академический форум. Я просто хочу сохранить в нём приятную и полезную атмосферу общения, разве вы это не приветствуете?

где то был отдельный специальный чатик для людей не осиливших го тур, но, по моему, он загнулся, т.к. все всё равно сразу шли сюда

Не, вобще, чтобы связываться со форнтэндом - это надо быть дизайнером и любителем красоты, а не ремесленником. Go - больше для ремесленников, Так я думаю

В прошлом чате меня добила дискуссия имени дениса, который пишет на го месяц,поспорившего с жавистом двух летним опытом, что его уделает, что вылилось в сравнение жавы и го на примере хттп сервера получающего два числа и делящего их. Что бы выяснить что лучше работает с числами с плавающей точкой.

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

Именно по скорости разработки, наврятли, ибо скорость разработки на скриптовых языках очень велика. Говнища при этом конечно получается много и зачастую такие скрипты могут быстро портится и протухать и сделать на них макаронный код проще чем на go, но разработка точно выше. Есть ещё один момент, он тоже не мало важен... способ доставки скриптов... Вы собираетесь компились все скрипты отдельно или после правки Вы будете пересобирать весь проект? Скриптовые языки инторпритируемы и все что Вам надо что бы проверить их работу - перезапустить приложение...

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

го справился за 7 сек (16 сек если в 1 горутине) потребив при этом 13,7 мб, JS за ~460 с чем-то и сожрал при этом ~260mb озу

лол. накладные расходы на http стэк много больше деления двух чисел

В прошлом чате меня добила дискуссия имени дениса, который пишет на го месяц,поспорившего с жавистом двух летним опытом, что его уделает, что вылилось в сравнение жавы и го на примере хттп сервера получающего два числа и делящего их. Что бы выяснить что лучше работает с числами с плавающей точкой.

если учитывать изначальное написание кода то однозначно да - написать скрипт на JS/Lua гораздо проще. если учитывать maintainance, refactoring, bug fixing, adding of new feature то всё это быстро превратится в кашу

го справился за 7 сек (16 сек если в 1 горутине) потребив при этом 13,7 мб, JS за ~460 с чем-то и сожрал при этом ~260mb озу

https://paste.ubuntu.com/p/9j5j49RW4Z/ https://paste.ubuntu.com/p/PS8Q9RSMYd/

если учитывать изначальное написание кода то однозначно да - написать скрипт на JS/Lua гораздо проще. если учитывать maintainance, refactoring, bug fixing, adding of new feature то всё это быстро превратится в кашу

собственно еще раз: Есть пакет responce: type v1ApiResponce struct { } func (res *v1ApiResponce) Success(data interface{}) *Response { return &Response{ data: data, status: "success" } } ---- type Response struct { status string data string } func (r *Response) WriteJson(w http.ResponseWriter) error { .... } есть пакет handlers: type ResponseInterface interface { Success(data interface{}) *Response } тут то мы и ловим циклическую зависимость

LimitedReader или LimitReader в io пакете

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

Если перд Вами стоит цель сделать круто, чисто, что бы быстро работало и тратило мало памяти - может Вам и не обвязка в виде скриптового языка нужна...

Так я смогу ограничить размер стрима. Тоесть если я загружаю стримом картинку то она просто обрежется и все? А как проверить она была больше или нет?

https://paste.ubuntu.com/p/9j5j49RW4Z/ https://paste.ubuntu.com/p/PS8Q9RSMYd/

Хочу чтобы вы знали, когда вы говорите плохо про Node.js вы задеваете мои нежные чувства.

закон об оскорблении чувств верующих не распространяется на территорию государства Telegram 🙂

закон об оскорблении чувств верующих не распространяется на территорию государства Telegram 🙂

Node.js - не существует!

Пришел или не пришел EOF

эт луа?

эт луа?

смысл в том, что на больших степенях go становится в разы медленнее lua

это ещё надо доказать, пока-что я не уверен одинаковы ли алгоритмы

https://paste.ubuntu.com/p/4nCFXzK8mG/ https://paste.ubuntu.com/p/qqFxhcTd2Q/ поправленные варианты. считают сумму i^24 от 0 до 10^9. root@wks:~/bench# time ./bench 4.0000000500001234e+223 real 0m7,744s user 0m7,723s sys 0m0,003s root@wks:~/bench# time luajit f.lua 4.0000000500001e+223 real 0m1,754s user 0m1,738s sys 0m0,001s

Jit. Ну ясно) ноду тоже с jit надо потестить

Jit. Ну ясно) ноду тоже с jit надо потестить

нода разве не JIT?!

Не по дефолту)

как так, V8 же по дефолту JIT компилит?!

@Romshark ну jit jit'у рознь. Какой-то делает лучше код, какой-то нет

да но что-то мне не верится что Node.js по умолчанию работает в режиме интерпретатора без JIT

@Romshark а как ты предлагаешь скриптинг на go куда-то встраивать?

насчёт склеивания модулей движка кстати очень верно подмечено. Вот тут я даже немного затрудняюсь ответить как именно обращаться к движку из Go. Можно неким runtime интерфейсом и биндингами в продакшне, но это уже реально вопрос по сложнее.

для джунов все плохо