...пока косметику не смоет

JS же ужасен

В том и дело, что это хреновая идея. Сборщик мусора в ядре... кхм...

Сборщик мусора свойство рантайма все же. Были какие то товарищи которые хотели ось на го писать даже

JS же ужасен

Есть сильные стороны

Я оппонента как раз убеждаю, что для узкого круга задач граф.представление - очень норм, а он хочет "визуально программировать", и намекает, что идея нарисовать схему, оттранслировать ее в го, а потом получившееся собрать - это норм идея, так выглядит, мол, программирование будущего. Только я в ТАКОЕ будущее не хочу...

Такое пытались делать во всяких embedded штуках

Есть сильные стороны

Отвращение например

@CheshireKot были системы которые пока ты тыкаешь код в визуальном редакторе генерировали сишные код который проще вереыицировать с формальной точки зрения. Тока это феерически медленно и все равно нужно писать нормальный код

Сборщик мусора свойство рантайма все же. Были какие то товарищи которые хотели ось на го писать даже

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

Отвращение например

Субъективно

А так без косметики

Есть сильные стороны

Вобще-то нету. Особенно если взять его неявное поведение со всякими NaN 0 и т.д.

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

Ну раст, как раз, подходит для написания осей.

Субъективно

Само собой. Но js один из языков в котором я не вижу ничего красивого

Вобще-то нету. Особенно если взять его неявное поведение со всякими NaN 0 и т.д.

Вообще-то есть

Вообще-то есть

Субъективно

Ну раст, как раз, подходит для написания осей.

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

Вообще-то есть

Ну приведи, как бы не хейтеры - обсудим

Сборщик мусора свойство рантайма все же. Были какие то товарищи которые хотели ось на го писать даже

В качестве пет-проджекта, или извращения для... Мало ли какие цели люди себе ставят. В качестве эзотерических развлечений, вероятно, и на брейнфаке можно. Только зачем...

Субъективно

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

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

Для каких сфер подходит Брейнфак или перл?

Для каких сфер подходит Брейнфак или перл?

Ты бы ещё про ептаскрипт спросил. На перле уже никто не пишет, раньше был популярен в вебе, скрипты для линукса на нем тоже писали, и пишут. Почта мэйлру на нем кстати. Лучше в тематических чатах спроси, там лучше расскажут

Ты бы ещё про ептаскрипт спросил. На перле уже никто не пишет, раньше был популярен в вебе, скрипты для линукса на нем тоже писали, и пишут. Почта мэйлру на нем кстати. Лучше в тематических чатах спроси, там лучше расскажут

Ну ты не ответил для чего он лучше

На языке ada до сих пор пишут авиационное ПО, а специалисты получают хорошие зп

Ты сказал у любого языка есть место где он лучше

Ну ты не ответил для чего он лучше

Я привёл промеры, я на нем не пишу. Спроси в тематическом чете

На языке ada до сих пор пишут авиационное ПО, а специалисты получают хорошие зп

То что на языке пишут, не значит что он лучше подходит вообще куда либо

На коболе тоже пишут

Или мумпсе

Я почти уверен что есть места где до сих пор на Делфи пишут или даже на старом добром паскале

Госпаде

Я почти уверен что есть места где до сих пор на Делфи пишут или даже на старом добром паскале

Вполне пишут: https://www.auslogics.com/ru/career/vacancy/

Вполне пишут: https://www.auslogics.com/ru/career/vacancy/

Хампер :D?

Хампер :D?

Да.

Люди помогите. Что то у меня ступор. Как красиво зачитать бинарный файл в в массив uint32? Не читать же по 4 байта и сдвигать их в Uint32?

Но ровно так и придется

Но ровно так и придется

значит я не туплю.

Только ридер нужен буферизованный

Только ридер нужен буферизованный

Мне не обязательно. Я один раз должен файл в память считать

Можно еще выделить массив нужного размера, и через unsafe подсунуть его в качестве буфера читателю

Можно еще выделить массив нужного размера, и через unsafe подсунуть его в качестве буфера читателю

нехотелось бы на аля С прееходить

хотя так наврено быстрее всгео будет

От размера и требуемой скорости зависит

У меня так и не случилось ни разу необходимости в ансейфе

У меня так и не случилось ни разу необходимости в ансейфе

до этого момента у меная как то тоже обходилось

Для каких сфер подходит Брейнфак или перл?

авиационное ПО, очевидно же ?

Народ, а кто как организовывает работу с ошибками в REST сервисе, который по канонам Clean Architecture написан? Смысл в том, чтобы внутренняя логика может порождать разные ошибки и выплевывать наружу их нужно с разными кодами. + ошибки могут быть специфичные для инфраструктуры (ошибка "Invalid User-Agent"), так и специфичные для use case

Народ, а кто как организовывает работу с ошибками в REST сервисе, который по канонам Clean Architecture написан? Смысл в том, чтобы внутренняя логика может порождать разные ошибки и выплевывать наружу их нужно с разными кодами. + ошибки могут быть специфичные для инфраструктуры (ошибка "Invalid User-Agent"), так и специфичные для use case

Ну я логирую ещё и название функции, в которой возникла ошибка

Я не про логирование, а про то, как иметь сквозные ошибки, которые будут апихой отстреливаться с соответствующим сообщением, кодом приложения и http кодом, да так, чтобы это не ломало всю структуру Clean. Пример, у меня есть бизнес правило на слое use case и оно порождает message, а мне нужно ответить апихой с кодом 1022 и http кододом 400

Сейчас я имплементировал на уровне use case интерфейс, который отдает сообщение ошибки и код, а хэндлер уже знает какой код какой http code должен иметь, но что-то меня данная схема смущает

Сейчас я имплементировал на уровне use case интерфейс, который отдает сообщение ошибки и код, а хэндлер уже знает какой код какой http code должен иметь, но что-то меня данная схема смущает

механизма исключений нет, все ручками. Я реализовал свои хендлеры, который имплементирует http.Handler, ServeHTTP вызывает мою функцию, которая принимает контекст, а он имеет доступы к ридеру и врайтеру. И оттуда очень удобно делать всякие ctx.WithError(HttpResponseErrorWriter), где HttpResponseErrorWriter штука, которая пишет в ответ: - статус HTTP - коды по API (jsonapi) - и метаинформацию Удобство в том, что можно подготовить базовые структуры, и выбрасывать их, с разными кодами и прочим. Правда, везде придется return return return...

но честно говоря, в некоторых местах все равно больно

Я почти уверен что есть места где до сих пор на Делфи пишут или даже на старом добром паскале

На прежней работе кое какой софт был написан на дельфях. Хотя написан был хреново.

Ну если можно быстро и легко шлепать интерфейсы. Особенно, если необходимые компонеты наделаны.

Народ, а кто как организовывает работу с ошибками в REST сервисе, который по канонам Clean Architecture написан? Смысл в том, чтобы внутренняя логика может порождать разные ошибки и выплевывать наружу их нужно с разными кодами. + ошибки могут быть специфичные для инфраструктуры (ошибка "Invalid User-Agent"), так и специфичные для use case

если ошибка не со стороны клиента а внутреняя то я бы её не выплёвывал клиенту а писал в лог, а клиенту говорил бы internal error: %id% где id это уникальный идентификатор именно этой ошибки в логе

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

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

Эмм

Наоборот же слишком много

Слишком мало лайков чтобы покончить с собой Шта?

Это абстрактный пример. К сути не относится

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

{ "err": { "type": "internal", "msg": "Couldn't process request: couldn't generate password: password generator failed, string too long, processing timed out" } }

ERROR: S client not available

{ "err": { "type": "internal", "msg": "Couldn't process request: couldn't activate profile: couldn't connect to service X using password 1234: service temporarily unavailable" } }

Ты вообще про другое

я говорю про каноны Clean Architecture. У меня есть ошибки на уровне сценариев, которые нужно отгрузить из апи клиенту с соответствующим кодом и статусом. Как сделать так, чтобы бы модель клин не ломался и при этом, при генерации ошибки она была такой, чтобы можно было ее с учетом требований отстреливать из API

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

Честно говоря, не понятно о чем ты

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

что есть коды в твоем случае?

http status?

или какие-то твои внутренние коды ошибок?

Внутренние коды

ну так Error это интерфейс, его реализовывать могут любые структуры, со всеми вытекающими

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

Ну сделай себе пакет errors Потом тип InternalError struct{}, BusinessLogicError struct{} А в своем обработчике switch v := err.(type) { case InternalError: ... case BusinessLogicError: ... }

я говорю про каноны Clean Architecture. У меня есть ошибки на уровне сценариев, которые нужно отгрузить из апи клиенту с соответствующим кодом и статусом. Как сделать так, чтобы бы модель клин не ломался и при этом, при генерации ошибки она была такой, чтобы можно было ее с учетом требований отстреливать из API

Добрый совет: держись подальше от всяких clean architecture и тому подобных solid

Подскажите, где можно хранить данные для подключения к MySQL БД? В самом приложении задать логин и пароль - не подходит

Dotenv

Dotenv

Спасибо

Подскажите, где можно хранить данные для подключения к MySQL БД? В самом приложении задать логин и пароль - не подходит

в конфиг файле

почему так выводит?

кодировка неверная

как исрпавить?

ты проекты хранишь в AppData/Local/Temp ?)

как исрпавить?

поставить юникод

в ide

а что за ось?

winda

стоит utf-8

а что за ось?

кек там же скрин

Странная ось

Однако

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