короче, не нужно было рестартить сервис когда новыые девайсы подключали

и в конфигах ничо прописывать не нужно было

оно само все делало)

Единственное что нужно было в конфиге прописать - блеклисты по VenID:DevID

чтобы оно случайно к твоему телефону не приконнектилось))

Такие вещи легко пишутся на плюсах и отлично работают.

да, но есть одно небольшое НО!

:))

где есть, где нет...)

точно :)

Ну вот, собрался после длинного перерыва проект с пучком зависимостей собрать, а code.dlang.org не работает.

Типично

нужно переписать его на go :D

Многим тут синтаксис го не нравится

мне тоже

В таком случае, зачем переписывать на го?

типа быстрый, заточеный под хайлоад, и прочие ко-ко-ко

вообще это было сарказмом :)

А, ну если это сарказм, тогда ок

А то как то ненатурально вышло

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

Людвигу, что ли?))

Хочешь наказать дишника - заставь его на Го писать

я не понимаю чо все дрочат на эту композицию в го и горутины :)

в d это было до того как появился го :)

композиция?

ну про горутины я неосторожно выразился канеш

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

да

когда ты описываешь структуру

а в функции уже описываешь ресивер

в ди так тоже можно было :)

Горутины специально заточены под это все. А так всякие корутины и прочие асинхронные шняги естествено не в го появилось

я правда синтаксис этого не помню)

Эх я вот в расте не могу осилить tokio, тупенький

это норма

я тоже тупенький

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

И как так просто передать данные из одного потока в другой? Асинхронно

Разрабы Go походу вообще бошкой поехали. Они директивы компилятора в комментах додумались указывать.

Во всяком случае примеры видел такого

Отсюда можно сделать вывод, что в Go нет полноценных комментариев

Не понял вообще логики

Можно поподробнее?

Сдается мне это все из статьи на хабре пошло )

Видел пару дней назад обсуждение этого там

да именно там видел

А поподробнее нельзя?

Это ещё с турбопаскаля практиковалось, если я понял о чем речь.

Разрабы Go походу вообще бошкой поехали. Они директивы компилятора в комментах додумались указывать.

https://code.dlang.org/advanced_usage (Single-file packages)

https://code.dlang.org/advanced_usage (Single-file packages)

Да, меня это тоже раздражает

Если про это речь, то вы еще документирующиеся комменты вспомни

Зачем???? Ну создай ты отдельный файл

Зачем???? Ну создай ты отдельный файл

Для багрепортов удобно

Для багрепортов удобно

Ну...

Возможно

Но выглядит реально отстойно

хорошо когда коменты есть

плохо когда их нет :)

хорошо когда коменты есть

+1

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

у нас та же херня

типа, самодокументирующийся кот

как по мне - так каменты нужны чтоб не тратить время на "обязан без них разобораться"

Имхо, каменты нужны там где они нужны, и наоборот.

а как определить, где они нужны, а где нет?

ERROR: S client not available

допустим, то же самое описание методов нужно?

а как определить, где они нужны, а где нет?

Если пьяным не можешь свой код понять то нужны

чо за метод, чо делает?

чо за метод, чо делает?

Зависит от удачности выбранного названия

те юе самые пхпдок

а как определить, где они нужны, а где нет?

очень просто. если юзаешь неочевидне решение

тогда писать комменты маст

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

это тупо экономит время

но писать камменты на очевидные вещи имхо странно. код нужно уметь читать. А запутанный код (без причины) нужно заворачивать на код ревью

а как определить, где они нужны, а где нет?

Любое переусложнение логики

Например, магические константы

Вот вам пример:

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

Как об этом донести, что сперва нужно вызвать m1, за ним m6, а уж только потом m53. Плохой код все начнут писать.

Нужно чтобы было понятно.

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

А если прочтете только исходники, вы все равно не поймёте, что нужно сперва биндить, а после слушать.

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

Ф-ция max редко нуждается в описании

НО! Если она принимает не 2 значения, а массив вариантов?

И она рекурсивно проходит по этим вариантам.

Это бы описать...

спасибо! :)

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

https://vk.com/@tproger-how-to-improve-your-programming-style

интересная статья

тыдыщ! https://github.com/Kripth/lighttp/releases

Обратите внимание, что в качестве зависимостей идет https://github.com/huntlabs/kiss от Китайских друзей

по графикам только не понятно, чем выше, тем лучше? или наоборот?

ну хотя да, чем выше, тем лучше

что-то китайцы не супер отзывчивые. сделал им ишью в kiss - молчат уже с неделю