Под tcp кстати я бы не стал

Лучше udp

А как же если пакеты потеряются :(

Недавно только читал историю как упавший сислог уронил сетевую инфраструктуру из-за tcp как раз )

Ну да но что делать с пропадающими пакетами то? Смысл в таком логировании как-то теряется.

Если нельзя доверять тому что видишь.

Логи это такая вещь которая не нужна когда все работает и очень сильно нужна когда что-то начинает работать неправильно

дополнительно можно хранить локально

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

А вообще можно писать локально (быстро и надежно), но раз в какое-то время отсылать логи на удаленный сервер (чтобы место не жрали)

Или писать приложением в локальный файл - (дешево, сердито, ничего не ебанется), а другим каким-нибудь демонком - разгребать этот файл и высылать логи куда надо. Во-первых это МИКРОСЕРВИСНО...

https://www.facebook.com/photo.php?fbid=10215636895216658

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

Это все палки о мультиконцах. Если писать в лог локально то при сгорании сервера важные логи теряются, если все передавать гарантированно по TCP то может полечь сеть, если писать через UDP и без очереди, то логи тоже будут теряться.

Тут видмо какая-то priority queue нужна с локальным кешированием. Чтобы по TCP гарантированно быстро доставлялись важные записи, а неважные по мере сил.

А чего не сделать драйвера под разные нужды и конфигурить по мере необходимости?

Короче писать в сислог в формате json чтобы было как объект, а дальше уже уже какой-то разгребалкой разгребать это дальше, так?

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

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

https://www.facebook.com/photo.php?fbid=10215636895216658

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

@deviator не вижу писали или нет но есть ещё такое: https://capnproto.org/

@deviator не вижу писали или нет но есть ещё такое: https://capnproto.org/

я читал раньше, лично мне не понравилась слишком крикливая самореклама.

удваиваю

вообще не понятно протокол ли это

вопрос стоит типа как "вирус" это живое существо или нет?

Как понять фразу "элементы зранятся сами, а не указателями". Я думал что в стеке при сохранении строки просто создается ссылка (указатель) на кучу.

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

Стек тут вообще не при чём

А почему alias this только один может быть? И как мне тогда определить автоматическое преобразование типов, когда типов более одного. Пример: struct A { int i = 5; float f = 3.14; alias i this; alias f this; } void main() { A a; int i = a; float f = a; } Получаю Error: there can be only one alias this Как быть?

В C++ я мог бы определить operator int () const; и operator float () const; и без проблем сделал бы что мне нужно

opCast?

Он требует явного преобразования

а в D и нет неявного преобразования)

это фишка такая

opCast?

вот так придётся писать: void main() { A a; int i = cast(int) a; float f = cast(float) a; }

Ну да: ./test.d(45): Error: cannot implicitly convert expression a of type A to int ./test.d(46): Error: cannot implicitly convert expression a of type A to float

ну да)

alias this, говорит компилятору, что структура или объект будет вести себя как то, что указано в alias, а нельзя себя вести одновременно как int, float и string

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

как-то так

Хорошо, а есть какой то способ перегрузить преобразование в разные типы без cast?

в D нет неявных преобразований типов

в D нет неявных преобразований типов

Плохо...

наоборот же)

наоборот же)

меньше гибкости

почему?

хочешь что-то во что-то преобразовать, убеди компилятор, что знаешь, что делаешь.

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

int a = 480; byte b = a; Вот как компилятору понять, ты специально это делаешь, или просто не понимаешь, что происходит?)

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

[]+[]

int a = 480; byte b = a; Вот как компилятору понять, ты специально это делаешь, или просто не понимаешь, что происходит?)

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

опыт таких языков как C и C++ говорит, что это слишком дорого обходится)

опыт таких языков как C и C++ говорит, что это слишком дорого обходится)

Очень удобно это в C++. Позволяет делать гибкие интерфейсы

и в день по пальцу на ноге отстреливать)

в D в плане гибкости нет проблем относительно C++, просто тебе нужно дополнительно cast(ololo) писать

Те кто стреляет по пальцам на C++ долго не пишут :) Зато он доверяет пргограммисту и просто предоставляет срадства, ничего не навязывая :)

ну, наверное, просто так во всяких шарпах и ди появились явные преобразования типов)

D в некоторых вопросах гибче С++ Поэтому вызывает недоумение, когда натываешься на такие места, когда компилятор думает, что я стреляю по ногам

разработчикам просто захотелось потроллить других разработчиков)

D в некоторых вопросах гибче С++ Поэтому вызывает недоумение, когда натываешься на такие места, когда компилятор думает, что я стреляю по ногам

это в каких?

Те кто стреляет по пальцам на C++ долго не пишут :) Зато он доверяет пргограммисту и просто предоставляет срадства, ничего не навязывая :)

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

это в каких?

В шаблонах

orly?

А ещё в D миксины без костылей с CRTP есть

В шаблонах

а, блин, не так прочитал)

ERROR: S client not available

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

у js типобезопасности нет. И вообще язык из другой категории совсем. и для других задач

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

у js типобезопасности нет. И вообще язык из другой категории совсем. и для других задач

Зато все гибко)

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

в том что уродливый cast писать надо

каким боком это к гибкости относится?

в том что уродливый cast писать надо

Зато все просто, понятно и очевидно

Зато все гибко)

Да ладно. Хорош тосто тролить. У js много плюсов. Отличный язык. Но гибкость не его конёк

Да ладно. Хорош тосто тролить. У js много плюсов. Отличный язык. Но гибкость не его конёк

Ну тогда у нас разные представления о гибкости

Что значит гибкость в твоем понимании?

каким боком это к гибкости относится?

Вот хочу я определить неявное преобразование, а язык не позволяет. Причём для одного типа позволяет, а для двух нет.

нет в D неявных преобразований

alias this — это эмуляция объектом поведения конкретного поведения

Что значит гибкость в твоем понимании?

В js нет интерфейсов и перегрузки. Для меня этого достаточно. И вообще тяжело поддерживать код без типов. Я на js писал довольно много

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

нет в D неявных преобразований

ок ок. Я уже понял :)

В js нет интерфейсов и перегрузки. Для меня этого достаточно. И вообще тяжело поддерживать код без типов. Я на js писал довольно много

Ок ок, но это не ответ на мой вопрос

Я не понимаю, как гибкость коррелирует с количеством символов

Что значит гибкость в твоем понимании?

В ES6 деструктуризация красиво сделана. А ещё он legacy не ломает. Эт его сильные стороны

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

Блин

Дайте мне уже определение гибкости

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

Я с тобой не согласен. Спорный вопрос. Но не хочу холиварить.

Дайте мне уже определение гибкости

Оно субъективно

спорный вопрос — это какой?)

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

Вот этот

Оно субъективно

Я прошу лично твое определение гибкости, а не описания фишек JS

Я прошу лично твое определение гибкости, а не описания фишек JS

Ух. Можно не буду?

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

Щас опять флуд будет на 5 экранов

Всё. Спасибо за ответ. Уважаю ваше мнение. Не хочу спорить

ну, в общем, нету в D неявных преобразований, и с этим придется жить)