ты смотришь в рамках малого количества операций

высоконагруженный бэкэнд пишут на плюсах

либо на go каком-нибудь

Высоконагруженный бекенд пишут горизонтально

высоконагруженный это сколько чего?

тебе цифрами? ок я не знаю

Вот серьезно, какой бекенд пишут на плюсах?

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

Сколько ты видел таких беков?

Вот серьезно, какой бекенд пишут на плюсах?

яндекс

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

Хуяндекс

Знаешь сколько там написано на перле питоне и джаве

это как-то меняет то что c++ быстрее c#? я что-то не пойму что вы вообще всем этим сказать хотет

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

я говорю, что он быстрее, а вы мне ДА КТО НА НЁМ ПИШЕТ

Быстрее это как?

тебе конкретику? я не изучал конретику и всех тестов не смотрел

некоторые модули в проекте на плюсах это нормально

тюлень быстрее медведя в воде, а медведь быстрее тюленя на суше

отдельная тима для этого

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

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

медведь тяжелее

если это не оранжевая панда

А тюлень обтекамый

мех не мешает полету

тебе конкретику? я не изучал конретику и всех тестов не смотрел

тогда как ты можешь говорить, что что-то быстрее?

мб даже наоборот

медведь тяжелее

сударь, да вы даже физику не знаете

школьную*

тогда как ты можешь говорить, что что-то быстрее?

а мне прежде чем что-то заявить надо дисер на эту тему писать?

сударь, да вы даже физику не знаете

Не забывай про трение

сударь, да вы даже физику не знаете

докажи, сударь куксенок

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

Не забывай про трение

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

ну без материала

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

Ты про JIT слышал хоть?

а почему вы спрашиваете?

что меняет присутствие JIT в процессе трансляции кода?

докажи, сударь куксенок

https://www.youtube.com/watch?v=e2Fd64B9FeU

на тебе видосик, станет интересно - погуглишь

что меняет присутствие JIT в процессе трансляции кода?

Нейтив код ты собираешь один раз, джит может перегенерироваться в зависимости от данных

https://www.youtube.com/watch?v=e2Fd64B9FeU

https://www.youtube.com/watch?v=E43-CfukEgs более глобальные масштабы

https://www.youtube.com/watch?v=E43-CfukEgs более глобальные масштабы

о, видел кусок этого видоса в стограмме

Оптимизатор JIT-компилятора благодаря подробнейшей "живой" статистике о вашем коде запросто может обгонять по эффективности оптимизатор С/С++, который строит предположения только по исходному код

что меняет присутствие JIT в процессе трансляции кода?

То что код компилируется на лету в инструкции проца с оптимизацие и под конкретное железо. В итоге горячий код (где как раз важен перформанс) может почти не отличаться от того что сделает c++.

Оптимизатор JIT-компилятора благодаря подробнейшей "живой" статистике о вашем коде запросто может обгонять по эффективности оптимизатор С/С++, который строит предположения только по исходному код

насколько я знаю, это происходит только на определенных тестах

я не верю в гениальную супер-оптимизацию от майкрософт :)

у них всю жизнь все через еп-твою-мать работало

конечно только на определённых

очередной бессмылсенный срач :)

насколько я знаю, это происходит только на определенных тестах

ну и вот суть этого спора. где-то плюсы быстрее, где-то шарп.

C# не очень умеет в динамической перекомпиляции

Другое дело GC в .NET (и Java) - остановки программы на сборку мусора - это главная проблема (особенно когда все хотят иммутабельности).

Другое дело GC в .NET (и Java) - остановки программы на сборку мусора - это главная проблема (особенно когда все хотят иммутабельности).

Подобная штука тоже решается, OOM киллер, выводим из балансера, запускаем, вводим в балансер

очередной бессмылсенный срач :)

все как мы любим

C# не очень умеет в динамической перекомпиляции

Ну да, тут http://razbor-poletov.com/2016/11/episode-121.html в очередной раз разжували

все как мы любим

лучше бы посрались что лучше, сиськи или жопа

на тебе видосик, станет интересно - погуглишь

это твое доказательство того, что я не знаю физику? как-то алогично

с пруфами

Ну да, тут http://razbor-poletov.com/2016/11/episode-121.html в очередной раз разжували

Слушал, жаль что не было срачика

мягко говоря

это твое доказательство того, что я не знаю физику? как-то алогично

ну ты же пизданул что медведь тяжелее

хотя в данном случае похуй

тем более что тюлень обтекаемее

Слушал, жаль что не было срачика

Надо было пригласить школьников из этого чата ?

ну ты же пизданул что медведь тяжелее

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

ERROR: S client not available

мм.. окаy

Кто о чем, а кто то о медведях...

лан. пидон ждет

покеда

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

Вот так мы потеряли нового сишарписат...

это еще не известно!

надеюсь нового ильи (или как там его) не получится

Через все надо пройти

напомните мне, доступ к ДБ лееру должен иметь только Кор леер?

или там можно сразу чтоб несколько слоёв имели доступ к дб лееру

как по канону?

У меня работа с дб через ДИ и сервисы

Делай слой Repository

Но вообще конечно все зависит от задач

Пруфы не нужны тут

В теории jit компиляция .net может дать лучший результат чем скопиленные плюсы

Его на плюсах наговнокодить

Валидно ли в репозитории иметь методы типо IncrementSomeProp(id) ?

как по канону?

Dal слой имеет доступ к бд а business layer юзает репозитории из него

?

Dal слой имеет доступ к бд а business layer юзает репозитории из него

спс

Валидно ли в репозитории иметь методы типо IncrementSomeProp(id) ?

Смотря что ты этим сделать хочешь. Есть плюсы и минусы

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

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

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

Что значит не вляет на логику?

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

ну все от задачи и реализации зависит

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

не бывает одного решения правильного