const std = @import("std");
pub fn main() void {
var arr: [1000_000]i32 = undefined;
for (arr) |*item, i| {
item.* = @intCast(i32, i);
}
var sort = isSort(&arr);
std.debug.print("{!}\n", .{sort});
}
fn isSort(arr: []i32) bool {
var i: usize = 1;
while (i < arr.len) : (i += 1) {
if (arr[i - 1] > arr[i]) return false;
}
return true;
}
Аналог на D2(кстати в планах разрабов — д3 с аст, чтобы это не значило):
import std.stdio;
void main()
{
auto arr = new int[1000_000];
foreach (i, _; arr)
{
arr[i] = i;
}
writeln(arr[10]);
writeln("Array is ", isSort(arr) ? " sorted." : " not sorted.");
}
bool isSort(T)(T[] arr)
{
for (auto i = 1; i < arr.length; i++)
{
if (arr[i - 1] > arr[i])
return false;
}
return true;
}
Очевидно, код на ди в разы проще для восприятия. И вот интересная штука. C# конечно чуточку сложнее синтаксически.
Это удивительно, ведь авторы ди это сишник(Брайт) и плюсовик(Александреску).
Теперь к сути.
Дотнет философия — это компонентный подход к разработке. Но почему-то в крупном проекте продуктовом столкнулся с монолитным репозитарием где в транке все что нужно для жизни.
А ведь гораздо удобнее было бы использовать стабильные версии компонентов в виде dll.
С другой стороны взять ди — только сборщик мусора и исходники — малый размер бинаря(можно импортнуть из модуля только используемые функции).
Зиг и Раст это уже абсолютная категория.
Но стоит ли отказываться от сборщика мусора большой вопрос.
Экономия ресурсов сейчас даже актуальней чем в нулевых. Кол-во вычислений растет. А ди2 как раз проектировался на многопроцессорные вычисления.
По теме: чем все-таки DOTNET убивает(или убьет в ближайшем будущем) такие крутые штуки как java|go|zig|rust|c++?
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Вот когда bing станет самым используемым и популярным поисковиком, тогда поверю.
Облачная платформа не имеет отношения к поисковикам.
Здравствуйте, Эйнсток Файр, Вы писали:
ЭФ>Вот когда bing станет самым используемым и популярным поисковиком, тогда поверю.
Ты же сам облачные платформы упомянул, а теперь спрыгнул на поисковики
Здравствуйте, Разраб, Вы писали:
Р>Экономия ресурсов сейчас даже актуальней чем в нулевых. Кол-во вычислений растет. А ди2 как раз проектировался на многопроцессорные вычисления.
Ничем она не актуальней, это хайп
Р>По теме: чем все-таки DOTNET убивает(или убьет в ближайшем будущем) такие крутые штуки как java|go|zig|rust|c++?
EF + Linq, аналогонет
async\await, в котором не просто удобно использовать асинхронные функции, но и создавать их. еще и быстро работает, по сравнению с аналогами.
Еще в .NET тащат aot и compile-time кодогенерацию, чтобы работало быстрее, бинари были меньше.
Здравствуйте, Разраб, Вы писали:
Р>По теме: чем все-таки DOTNET убивает(или убьет в ближайшем будущем) такие крутые штуки как java|go|zig|rust|c++?
Дотнет уж лет 20 обещает всех убить в ближайшем будущем. Собственно, из перечисленного тобой, только java и c++ существовали до дотнета, остальные потом появились.
Здравствуйте, Farsight, Вы писали:
ЭФ>>Go — платформа от лидера интернета Google. Какой .Net? Microsoft с его Azure не догоняет.
F>Оффтоп, но как раз в облачной платформе MS уделывает Google.
В каком смысле, уделывает?
Для MS облака — основное направление бизнеса. А для Google — отход производства, которым они торгуют заодно, раз уж у них этого добра девать некуда.
G>async\await, в котором не просто удобно использовать асинхронные функции, но и создавать их. еще и быстро работает, по сравнению с аналогами.
вроде же уже развенчивали этот миф.
This is pretty much the Java equivalent to the ASP.NET Core MVC (aka Full) benchmark.
The interesting part is that this completely unoptimised fully fledged Java MVC framework ranks overall 12th in the Fortunes benchmark with an incredible 404k requests/sec. It is essentially more than twice as fast as the ASP.NET Core equivalent, still beats the "Micro" implementation of the ASP.NET Core benchmark (which skips all the expensive I/O operations by using a fake templating engine) and even manages to compete with the infamous /PlatformBenchmarks application which in all honesty due to its differences is not even worth a comparison.
No disrespect to ASP.NET Core (because 184k requests/sec is still an amazing result) but it doesn't come anywhere near this Java framework when it comes to performance. Credit where credit is due.
Всегда можно придумать бенч, который покажет преимущество одной системы над другой. Поэтому вопрос не столько в скорости, сколько в умении и удобстве использования. Вся асинхронщина в .NET гораздо более удобна в использовании, чем в других языках. Другие языки (как js) откровенно копируют то, что сделано в .NET\C#.
Здравствуйте, gandjustas, Вы писали:
Р>>Экономия ресурсов сейчас даже актуальней чем в нулевых. Кол-во вычислений растет. А ди2 как раз проектировался на многопроцессорные вычисления. G>Ничем она не актуальней, это хайп
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
Р>>>Экономия ресурсов сейчас даже актуальней чем в нулевых. Кол-во вычислений растет. А ди2 как раз проектировался на многопроцессорные вычисления. G>>Ничем она не актуальней, это хайп
НС>Нет, это не хайп, это облака.
Да ну, облака появились 10+ лет назад. Беспокоиться за потребляемые ресурсы начали почему-то аккурат после появления go (примерно 2015 год), а после появления rust и анонса zig вообще какая-то истерия пошла. До этого как-то не стеснялись писать ни на js, ни на пайтоне, ни на RoR (прости господи). А сейчас все соревнуются в размерах бинарника, времени старта и размерах потребляемой памяти.
Возможно этот хайп вызван микросервисами, когда 100500 экземпляров JVM\.NET\Пайтона жрут больше, чем все приложение написанное на go. Но никто же не заставляет всюду пихать микросервисы, даже в облаке.
Здравствуйте, gandjustas, Вы писали:
G>Да ну, облака появились 10+ лет назад.
И?
G> Беспокоиться за потребляемые ресурсы начали почему-то аккурат после появления go
Ну как облака начали обретать популярность, так и забеспокоились. Ты глянь на cloud native — там львиная доля проектов — Go.
G>А сейчас все соревнуются в размерах бинарника, времени старта и размерах потребляемой памяти.
Потому что, прикинь, эти параметры напрямую определяют стоимость клауда.
G>Возможно этот хайп вызван микросервисами,
Который, в свою очередь, тоже порожден облаками.
G> Но никто же не заставляет всюду пихать микросервисы, даже в облаке.
А там и без микросервисов перечисленные тобой параметры напрямую влияют на затраты.
Здравствуйте, gandjustas, Вы писали:
G>Всегда можно придумать бенч, который покажет преимущество одной системы над другой. Поэтому вопрос не столько в скорости, сколько в умении и удобстве использования. Вся асинхронщина в .NET гораздо более удобна в использовании, чем в других языках. Другие языки (как js) откровенно копируют то, что сделано в .NET\C#.
Это вот ручное таскание канцелейшн токена через параметры называется удобством?
спасибо не нада
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, gandjustas, Вы писали:
G>>Да ну, облака появились 10+ лет назад. НС>И?
А беспокоиться начали позже.
G>> Беспокоиться за потребляемые ресурсы начали почему-то аккурат после появления go НС>Ну как облака начали обретать популярность, так и забеспокоились. Ты глянь на cloud native — там львиная доля проектов — Go.
Конечно нет, облака были задолго до Go
G>>А сейчас все соревнуются в размерах бинарника, времени старта и размерах потребляемой памяти. НС>Потому что, прикинь, эти параметры напрямую определяют стоимость клауда.
Внезапно нет, стоимость решения в облаке определяется в основном эффективностью работы со стореджом.
А Compute биллится по времени работы инстанса, заметные различия только на очень высокой нагрузке, когда количество инстансов можно сократить в разы переписав на другой язык.
Но как раз .NET и Java не настолько сильно отстают по быстродействию от Go, чтобы было оправдано переписывать. А в некоторых местах и превосходят (ссылка выше есть).
G>>Возможно этот хайп вызван микросервисами, НС>Который, в свою очередь, тоже порожден облаками.
Конечно нет, микросервисы — порождение нетфликса, к облакам не имело отношения изначально.
G>> Но никто же не заставляет всюду пихать микросервисы, даже в облаке. НС>А там и без микросервисов перечисленные тобой параметры напрямую влияют на затраты.
Они не настолько влияют, чтобы имело смысл об этом говорить. А вот размер рантайма реально влияет, если у тебя 100500 микросервисов вместо пары экземпляров монолита.
почему зависит ? в двое большая производительность кушает в двое больше памяти, звучит логично.
G>Всегда можно придумать бенч, который покажет преимущество одной системы над другой. Поэтому вопрос не столько в скорости, сколько в умении и удобстве использования. Вся асинхронщина в .NET гораздо более удобна в использовании, чем в других языках. Другие языки (как js) откровенно копируют то, что сделано в .NET\C#.
но тут то никто не выдумывал под жаву тест. совершенно стандартная задачка, где жава далеко не в лидерах.
по мне майкрсофт просто накидывает фичи, после чего все больше народу валит в жава, потому как все больше понимают, что async/await не не ускорит уже написанный код. я так понимаю результат .net core в TechEmpower как раз от того, что async/await добавили, а переделать весь asp фреймворк не получилось.
Здравствуйте, gandjustas, Вы писали:
НС>>Ну как облака начали обретать популярность, так и забеспокоились. Ты глянь на cloud native — там львиная доля проектов — Go. G>Конечно нет, облака были задолго до Go
Не задолго. И это нормально, когда инструменты появляются с некоторым запаздыванием.
НС>>Потому что, прикинь, эти параметры напрямую определяют стоимость клауда. G>Внезапно нет,
Внезапно да.
G> стоимость решения в облаке определяется в основном эффективностью работы со стореджом.
Смелое заявление. Вот только компьют в облаке намного дороже стораджа.
G>А Compute биллится по времени работы инстанса,
Компьют биллится по разному. Но даже так. Количество инстансов чем, по твоему, определяется?
G> заметные различия только на очень высокой нагрузке,
Ну так go решения тоже обычно про нее родимую.
G>Но как раз .NET и Java не настолько сильно отстают по быстродействию от Go, чтобы было оправдано переписывать.
Не настолько — это не речь инженера, это речь бабки на лавочке. Инженер оперирует цифрами.
G>>>Возможно этот хайп вызван микросервисами, НС>>Который, в свою очередь, тоже порожден облаками. G>Конечно нет, микросервисы — порождение нетфликса, к облакам не имело отношения изначально.
Ох уж эти теоретики.
Что требуют современные микросервисы? Правильно, оркестратор. А кто сегодня главный оркестратор? Правильно, кубер. Где сейчас в основном крутится кубер? Правильно, в облаках. А что и кем там было порождено — пофигу, речь не про историю.
Кубер, кстати, помнишь на чем написан?
НС>>А там и без микросервисов перечисленные тобой параметры напрямую влияют на затраты. G>Они не настолько влияют,
Опять бабки на лавочке.
G>А вот размер рантайма реально влияет, если у тебя 100500 микросервисов вместо пары экземпляров монолита.
Ты про автоскейлинг слышал? Чем определяется его эффективность в первую очередь знаешь?
