но я, конечно, обвиню тебя в недостаточном знаии AWK в итоге :)

1. если не большой - берите что хотите 2. в json нет строк 3. откуда вообще взялся этот вопрос? есть стандартная реализация json, ее и берите

Доброго времени суток. Плюсы Вы выделили верные, только вот немного о том что такое скриптование в компьютерных играх... по сути это обвязка вокруг двигла задачей которой является описание повидения мира (игрового в данном случае), перед скриптовым языком не ставят те цели которые вы описали, перед скриптовым языком ставят цель - быстрая разработка (быстрое получение получени результат)... и вот тут го проигрывает python/lua и подобных им... и к слову, многие студии пишут свои собственные языки скриптования игры...

моё утверждение заключалось в том, что не смотря на то что нафигачить 10 строчный JS для описания поведения двери - всегда будет легче чем Go, на Go можно описать более сложную логику в более безопасном и производительном виде не притрагиваясь к C++. когда речь идёт о симуляции эконимики, взаимодействий большого колва объектов и т.д. JS/Lua быстро теряют свою актуальность.

Доброго времени суток. Плюсы Вы выделили верные, только вот немного о том что такое скриптование в компьютерных играх... по сути это обвязка вокруг двигла задачей которой является описание повидения мира (игрового в данном случае), перед скриптовым языком не ставят те цели которые вы описали, перед скриптовым языком ставят цель - быстрая разработка (быстрое получение получени результат)... и вот тут го проигрывает python/lua и подобных им... и к слову, многие студии пишут свои собственные языки скриптования игры...

ладно, поспорили и хватит

ладно, поспорили и хватит

ладно, поспорили и хватит

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

Всем привет. Кто знает как можно ограничить размер изображения если оно загружается через multipart/form-data, multipartreader?

А в Питере улица Зеленина - не твоим именем названа?

слушай, я люблю шутки, но примитивные бесят

Всем привет. Кто знает как можно ограничить размер изображения если оно загружается через multipart/form-data, multipartreader?

на 90% вопросов в этом чате гугл дает ответ первой же ссылкой на первой странице выдачи, так что более научным этот чат не сделать никак

https://github.com/golang/go/issues/23165

моё утверждение заключалось в том, что не смотря на то что нафигачить 10 строчный JS для описания поведения двери - всегда будет легче чем Go, на Go можно описать более сложную логику в более безопасном и производительном виде не притрагиваясь к C++. когда речь идёт о симуляции эконимики, взаимодействий большого колва объектов и т.д. JS/Lua быстро теряют свою актуальность.

слушай, я люблю шутки, но примитивные бесят

моё утверждение заключалось в том, что не смотря на то что нафигачить 10 строчный JS для описания поведения двери - всегда будет легче чем Go, на Go можно описать более сложную логику в более безопасном и производительном виде не притрагиваясь к C++. когда речь идёт о симуляции эконимики, взаимодействий большого колва объектов и т.д. JS/Lua быстро теряют свою актуальность.

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

>когда речь идёт о симуляции эконимики, взаимодействий большого колва объектов и т.д. JS/Lua быстро теряют свою актуальность. почему?

Parse подразумевает считывание в память, мне через стримы

runtime производительность, память, многопоточность, отсутствие compile-time гарантий.

вот про скорость, предлагаю простой бенч: сумма квадратов всех чисел от 0 до n

сделать, давать людям RO на часик за необоснованное обсирание и экспоненциально растить период RO за повторение

да вот вчера только сравнивали V8 JavaScript с Go, разница в скорости около 6000%, разница в памяти около 1600% https://github.com/xrei/prime-numbers-benchmark

а зачем нам еще один мертвый чат по го? один уже умер, слившись с данным чатом

в чью пользу?

в чью пользу?

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

да вот вчера только сравнивали V8 JavaScript с Go, разница в скорости около 6000%, разница в памяти около 1600% https://github.com/xrei/prime-numbers-benchmark

а на чем сравнивали? На чем надо, как обычно?

конечно это зависит от размера команды и проекта. Обсуждалась лишь чисто гипотетическая возможность использования Go для описания игровой логики по перечисленным выше причинам.

Читаю чат и вижу одни только мнения, необоснованные мнения.. Go в качестве скриптового языка интересен следующим: 1. Он относительно прост и прагматичен (надеюсь это пояснять не нужно). На C++ ведь никто скрипты игрового мира не пишет? (максимум повторяющееся поведение, где JS/Lua etc. недостаточно быстрые). 2. Одновременно он значительно производительнее и менее затратный по памяти таких языков как JavaScript и Lua, нужно объяснять в чём выгода? 3. Он быстро компилируется, вам нужно объяснять почему это хорошо для скриптинга? 4. Система актовор и вычисления AI хорошо укладывается на горутины, можно управлять большим колвом объкетов игрового мира используя весь потенциал CPU. 5. Модель памяти с GC отлично подходит для написания логики поведения. Без GC скрипты писать адово и опасно. что ещё... пока что всё, может что-то забыл упомянуть

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

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/