Там D с его стандартной либой без GC жить научился?

хз)

Там D с его стандартной либой без GC жить научился?

в каком-то виде без гц оно умело уже давно как-то жить

в каком-то виде без гц оно умело уже давно как-то жить

Стандартная либа без GC не жила, точнее жила пока память не кончится :-)

Вроде Александреска там что-то обещал сделать на эту тему.

ну, так лоу мемори - кил энд рестарт процесс)

ну, так лоу мемори - кил энд рестарт процесс)

Сурово :-)

Сурово :-)

лол кек чебурек https://dlang.org/spec/betterc.html

кмк проще уже на чистом Си педалить

или вообще свифтом обмазаться и не париться :-)

или вообще котлином!

в свифте чел из раста уже работает

агентура в действии)

"There is currently work in progress to make the runtime library free of GC heap allocations, to allow its use in scenarios where the use of GC infrastructure is not possible."

то есть в D еще не сделали, чтобы стандартной либой можно было без GC пользоваться

то есть в D еще не сделали, чтобы стандартной либой можно было без GC пользоваться

кмк там пока вкидывают новый функционал вместо доработки старого

мне кажеться, что это не есть хорошоу

это например какой? я, кажется, последний раз на D писал в году эдак 2010-2011. Вообще не в курсе что там происходит сейчас.

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

о! телегогруппа существует таки дишная

упс, уже не существует

https://t.me/dlangru

во. актуальное

хм. а основная идея раста выросла ведь из cyclone?

на тему безопасной работы с памятью

скорее всего тебе это не нужно обычно не рекомендуют выпускать в интернет велосипедные веб-сервера, вместо этого надо фронтэндом делать настоящий веб-сервер, типа nginx или apache httpd (даже для просто http) исключение - если твои сервисы работают поверх изолированной сети или шифрованного VPNа, но там https уже не нужен

причина в том, что в настоящих веб-серверах быстрее чинят уязвимости и другие проблемы

по правильной настройке tls: https://wiki.mozilla.org/Security/Server_Side_TLS

а в каких случаях следует кидать unwinded panic? можно примеры?

эх, и вот так всегда - ты хочешь помочь людям, а тебя обвиняют =/

А можно критерий настоящести «веб-сервера»?

настоящесть = обратное от нележащесть

под "настоящим web-сервером" я понимаю достаточно старый продукт, из которого уже выгребли кучу неочевидных багов, наработали best practices, и у которого хорошая документация и понятно поведение

nginx, apache - вот эти вот, как пример

haproxy - не чисто web-сервер, но близко по смыслу

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

некоторые типы атак могут использовать стандартные возможности HTTP и TCP

например slow HTTP request attack

которая позволяет с минимальными ресурсами заDoSить большую часть самописных синхронных web-серверов

асинхронные положить будет сложнее

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

А ковбой настоящий сервер или нет?)

без понятия

под "настоящим web-сервером" я понимаю достаточно старый продукт, из которого уже выгребли кучу неочевидных багов, наработали best practices, и у которого хорошая документация и понятно поведение

документация врёт. если не врёт, то недоговаривает. если не врёт и не недоговаривает, то будет. прастити. в случае с сищечькой (nginx, apache, haproxy) не вполне понятно, наличию которых багов мы обязаны, скажем так, предметной области, а которых — ковбоям-пидорасам и примитивности языка программирования?

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

короче, если кто-то напишет на расте, на tokio и hyper что-то типа nginx, то это будет очень хорошо

но до продакшена дорога будет очень долгой и тяжёлой

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

каюсь, я опять перепутал чатик с хипсторами и ЛОР =(

ну вы как бы довольно очевидное говорите

под "настоящим web-сервером" я понимаю достаточно старый продукт, из которого уже выгребли кучу неочевидных багов, наработали best practices, и у которого хорошая документация и понятно поведение

как из OpenSSL выгребли?

как из OpenSSL выгребли?

в том числе

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

Кстати про OpenSSL https://lists.zx2c4.com/pipermail/wireguard/2018-January/002304.html — верифицированная крипта из кодогенератора оказалась быстрее ручной

На расте тоже можно наговнокодить

даже с утечкой памяти

На расте тоже можно наговнокодить

и что?

{:.03}

Как нить так

std:fmt глянь

let formatted_number = format!("{:.*}", 2, 1.234567); assert_eq!("1.23", formatted_number)

можно даже точность как аргумент задавать

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

при правильной настройке он неплохо работает

при правильной настройке он неплохо работает

не инженерный термин - «не плохо»

с ним не плохая ебля

а качество утилизации ресурсов vs производительность при аналогичных решениях существенно ниже

согласен с тем, что с производительностью у него плоховато

но "аналогичных решений" у него нет

но "аналогичных решений" у него нет

очень зависит от контекста

насколько я знаю, по функциональности к нему пока никто не подошёл

да, зависит

на самом деле мало кому нужно всё, что апач умеет

обычно только для какого-нибудь очень большого говна на похапе, у которого половина логики на реврайтах сделана 8)

модули опять же...

эм. пхп давно на фпм + nginx перешёл

но в nginx тоже впилили недавно поддержку загружаемых модулей

хотя я не смотрел как там оно

эм. пхп давно на фпм + nginx перешёл

возможно ты недооцениваешь масштаб бедствия, когда что-то пишут на php и сразу под apache

там иногда только конфиг апача на 10 кило строк

лично такое видел в одной ънтерпрайзной хреноте