N>б) GoLang будет не нужен, когда дооптимизируют АОТ и зеленые потоки в JVM/.NET. Скоро
Даже когда дооптимизируют, ничего не изменится, т.к. сила GoLang не в "зеленых потоках", а в компании, которая за ним стоит. И в том количестве alumni этой компании, что тараканами расползается везде и всюду. Но писать ни на чем кроме Go они не умеют. Поэтому очень многим компаниям приходится использовать Go. Ибо с точки зрения бизнеса технология значения не имеет, важно лишь то, как быстро и как много программистов можно найти. Ровно по этой причине хорошие технологии, но с некоторым барьером входа, редко получают популярность. А полное г...о (да, JavaScript, и да, Python) — получает.
No dynamic loading, for example, Assembly.LoadFile.
No run-time code generation, for example, System.Reflection.Emit.
No C++/CLI.
Windows: No built-in COM.
Requires trimming, which has limitations.
Implies compilation into a single file, which has known incompatibilities.
Apps include required runtime libraries (just like self-contained apps, increasing their size as compared to framework-dependent apps).
System.Linq.Expressions always use their interpreted form, which is slower than run-time generated compiled code.
Not all the runtime libraries are fully annotated to be Native AOT compatible. That is, some warnings in the runtime libraries aren't actionable by end developers.
Чем больше когда, тем больше шансов, что не будет что-нибудь работать.
Конечно, со временем будет больше совместимости если тренд нативности разработчики будут активно поддерживать, а не сбегут на Rust
Вон в Microsoft Office
Здравствуйте, Разраб, Вы писали:
Р>Здравствуйте, Mihal9, Вы писали:
M>>Собственно сабж.
Р>Будущее за https://oberon.org/ru
Решил сравнить (наивно, конечно) зиг и оберон(https://free.oberon.org/en/) по убунтой.
просто вывод 1млн чисел в консоль. зиг в режиме фаст релизил. в оберон просто скомпилил по дефолту.
мерял при помощи /usr/bin/time
оберон стабильно на 100-200 мс быстрей(~ 3.5 секунды весь вывод).
пик памяти правда меньше у зига(ровно в 10 раз).
Здравствуйте, Pzz, Вы писали:
Pzz> wl.>Это же тёплое с мягким. Rust — системное ПО, Go — сайты. Они не конкуренты
Pzz> Докер — это системное ПО или сайты? Написан на Go...
Здравствуйте, Serginio1, Вы писали:
S> Ну а что касается замены .Net на Rust лучше бы сосредоточились на Native AOT. S> Наверное проще довести до ума Native AOT чем переписывать все на Rust.
Один забугорный коллега поделился. Лет пять назад, контора, где у него был контракт, решила переписать дельфийский софт на шарпе (насколько мне известно, там и гуй, и веб-сервисы). Наняли штат, он до окончания контракта эту работу наблюдал, потом из конторы ушел. Сейчас эта контора зовет его назад Оказывается, решили продолжать разработку на дельфях
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, wraithik, Вы писали:
SD>>>Ровно по этой причине хорошие технологии, но с некоторым барьером входа, редко получают популярность. А полное г...о (да, JavaScript, и да, Python) — получает.
W>>1С забыл S> Ну я бы не был столь категоричен. Я в свое время перешел на 1С ибо не было конкурентов. S> Ценность 1С не только в языке, формах, но и готовых конфигурациях. В том числе и бухгалтерии. S>Хорошие технологии должны давать не только язык, но и инструменты для быстрого создания отчетов и отчетности. S>Готовые конфигурацию с простой и недорогой возможностью адаптации под себя.
У меня была шутка. Язык конечно говно, но сама платформа и готовые конфы — это вне конкуренции в своей области.
Здравствуйте, Разраб, Вы писали:
Р>Решил сравнить (наивно, конечно) зиг и оберон(https://free.oberon.org/en/) по убунтой. Р>просто вывод 1млн чисел в консоль. зиг в режиме фаст релизил. в оберон просто скомпилил по дефолту.
Серьезно сравниваете языки по скорости вывода в консоль?
Здравствуйте, T4r4sB, Вы писали:
V>>Оба слабенькие. TB>Ощущение что ты не в теме.
Хорошее начало, заранее слился. ))
TB>Они очень сильныы по инфраструкиуое как минимум.
Вопрос стоял — за кем будущее?
Вопрос забавный, бо спросили о двух языках с разным позиционированием.
(хотя, сравнение именно этих языков обнажает текущие проблемы в языковом мейнстриме)
Golang имеет довольно-таки узконишевое позиционирование и показывает себя в этой нише удачно.
Это ниша быстрого прототипирования с довылизыванием прототипа до реального продукта.
По этой причине в вебе пришёлся весьма кстате.
И по этой причине кое-какие ограничения в дизайне — простоты и безопасности прототипирования ради (например, встроенная в язык прикладная функциональность каналов, где можно передавать данные лишь указанного типа — это не дотягивает до классической реализации мейл-боксов из модели акторов, то бишь является классичесской dog-food полуреализацией изначально мощной концепции).
TB>А Раст силён как средствами отлова ошибок
Обсуждаемо.
Раст пытается переосмыслить наработанные практики по отлову ошибок.
Ну как "переосмыслить"...
Тупо взять для императивного языка имеющиеся практики из функциональных языков. ))
Попытка пока в процессе осмысления, бо сам язык и его стандартные либы активно развиваются (и обсуждаются) в сторону функциональности, предоставляемой обычными исключениями, бгг...
Я тут запасся большой порцией попокорна и ехидно (не без этого) наблюдаю. ))
Аналогично у них в корутинах и прочей асинхронщине — принятые изначально решения в плане дизайна языка и принципа работы низлежащей вычислительной модели мешают оформлять корутины и асинхронщину в Расте удобоваримым образом, в отличие от того же Go, в котором корутины/асинхронщина — часть языка, и даже во многом цель его разработки.
TB>так и средствами обобщённого программирования
Это не есть достижение в текущую эпоху языков программирования.
А вот асинхронщина востребована, бо интенсивное развитие выч.мощностей практически остановилось к середине нулевых, сейчас идёт эпоха экстенсивного развития.
И что мы видим?
Пригодный для асинхронщины Go хорошо себя показывает только рядом с JS и прочими полуязыками, сливая вчистую "взрослым" языкам в числодроблении и бизнес-логике.
А изначально задуманный как "взрослый" язык Rust выглядит в асинхронщине недееспособным полупридурком, хотя асинхронщина является основным сегодня подходом к разработке как минимум серверных приложений.
Это эпик фейл для Rust, как ни крути...
Изначально позиционируемый как универсальный и мультипарадигменный Rust испытывает в некоторых задачах сложности, то бишь проявляет свои ограничения по нишам, бгг... ))
===============
Поэтому, вопрос ТС на сегодня более чем бессмысленен.
К нему надо вернуться лет через 15-20...
Лично мне тоже любопытно, что случится быстрее — разработчики Rust-а одумаются, наконец, и перестанут валять дурака в своей упоротости или Golang обзаведётся шикарными оптимизирующими компиляторами + ср-вами низкого уровня (иначе зачем оптимизация)?
Согласен. Погорячился.
А как ты хочешь без CLR? Можно подумать ты в Go и Rust что то там в рантайме компилишь?
C++/CLI, а он в Core то есть?
Ну до Com доберутся. Интерфейсы то нативные поддерживаются. Подсчет ссылок нужно организовать. Но это не критично.
Проблемы конечно есть, но многое переписывается.
С усечением например проблемы для .Net 8 из .Net 7 поубирали.
А так по твоей же статье, многое переписывается под оптимальное использование Native AOT. _NN>Вон в Microsoft Office
Ну а что касается замены .Net на Rust лучше бы сосредоточились на Native AOT.
Наверное проще довести до ума Native AOT чем переписывать все на Rust.
Было бы интересно сравнить производительность Rust и AOT
Кстати в свое время Блазор работал как интерпретатор. То есть многие проблемы можно решать через интерпретацию кода.
Хотя выражения могут использоваться в собственных приложениях AOT, когда вы Lambda.Compile() создаете выражение, оно использует интерпретатор для вычисления выражения. Это не идеально и может привести к снижению производительности. Если возможно, рекомендуется удалить Expression.Compile() использование в собственных приложениях AOT.
Здравствуйте, pagid_, Вы писали:
M>>А синтаксис у Го поприятнее, да? _>Синтаксис Go как раз его паршивая сторона. Но в целом по теме разговора это не особо значимая мелочь.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Mihal9, Вы писали:
M>>Собственно сабж.
V>Оба слабенькие.
Ощущение что ты не в теме. Они очень сильныы по инфраструкиуое как минимум. А Раст силён как средствами отлова ошибок так и средствами обобщённого программирования
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
Здравствуйте, SkyDance, Вы писали:
SD>Ровно по этой причине хорошие технологии, но с некоторым барьером входа, редко получают популярность. А полное г...о (да, JavaScript, и да, Python) — получает.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, wraithik, Вы писали:
W>>Здравствуйте, SkyDance, Вы писали:
SD>>>Ровно по этой причине хорошие технологии, но с некоторым барьером входа, редко получают популярность. А полное г...о (да, JavaScript, и да, Python) — получает.
W>>1С забыл
G>Я вам открою тайну: у 1С очень высокий порог входа. G>Все что там просто делать: таблички\формочки\отчеты в конструкторе. G>Как только ты доходишь до ручного написания кода и использования сложных объектов (документы, регистры, бизнес-процессы, интеграции), то становится все очень непросто. Документация совсем неочень, очень плохой нейминг. Архитектура непонятная. Стандартная бибилиотека слабая. Средств создания абстракций почти нет. Стандартные средства коллективной разработки не подходят, а 1Сные через жопу работают.
Я сам 1С-ник. Знаю. Но большая часть задач простая.
У обоих языков есть будущее. На Go написали столько важного софта, что он точно никуда не денется. На Rust, конечно, поменьше, но тоже дофига, плюс у Rust есть очень хорошие признаки стабильного языка: независимая организация, финансируемая кучей гигантов и любовь сообщества.
Здравствуйте, SkyDance, Вы писали:
SD>Даже когда дооптимизируют, ничего не изменится, т.к. сила GoLang не в "зеленых потоках", а в компании, которая за ним стоит.
Обсуждать будущую социологию = гадать на кофейной гуще.
SD>А полное г...о (да, JavaScript, и да, Python) — получает.
А почему Ерланг забыл?
Здравствуйте, wl., Вы писали:
wl.>Здравствуйте, Mihal9, Вы писали:
wl.>>>Это же тёплое с мягким. Rust — системное ПО, Go — сайты. Они не конкуренты M>>Rust и на вебе применяется. wl.>И что? На с++ тоже можно сайты писать, однако я не уверен, что туда сишников набирают.
У раста есть взрослые web-фрейморки, у плюсов похожего нет.
Здравствуйте, vsb, Вы писали:
vsb>У обоих языков есть будущее. На Go написали столько важного софта, что он точно никуда не денется. На Rust, конечно, поменьше, но тоже дофига, плюс у Rust есть очень хорошие признаки стабильного языка: независимая организация, финансируемая кучей гигантов и любовь сообщества.
Здравствуйте, Mihal9, Вы писали:
vsb>>У обоих языков есть будущее. На Go написали столько важного софта, что он точно никуда не денется. На Rust, конечно, поменьше, но тоже дофига, плюс у Rust есть очень хорошие признаки стабильного языка: независимая организация, финансируемая кучей гигантов и любовь сообщества.
M>А синтаксис у Го поприятнее, да?
Мне кажется, сравнивать их нельзя, очень разные языки с очень разными целями и подходами. Go сделан для того, чтобы быть максимально простым, сложный синтаксис там и не нужен. А Rust это очень сложный язык, решающий сложные задачи, тут без сложного синтаксиса, вероятно, было не обойтись.
Здравствуйте, Mihal9, Вы писали:
M>А синтаксис у Го поприятнее, да?
Синтаксис Go как раз его паршивая сторона. Но в целом по теме разговора это не особо значимая мелочь.
Здравствуйте, Privalov, Вы писали:
P>Здравствуйте, Разраб, Вы писали:
Р>>Будущее за https://oberon.org/ru
P>Не нужен. Есть Фортран и Кобол. А что в них не хватает, можно Сями прикрыть.
Здравствуйте, Pzz, Вы писали:
Pzz>Тебе ж сказали, Фортран и Кобол. Еще PL/1 забыли упомянуть.
PL/1 как раз для замены Фортрана и Кобола был придуман. Туда бред, совершенно не нужный сейчас и из того, и из другого притащен. И еще много всего, что в 60-е казалось интересным.
Pzz>А clojure — это новомодная хрень для хипстеров.
+1
Здравствуйте, pagid_, Вы писали:
Pzz>>Тебе ж сказали, Фортран и Кобол. Еще PL/1 забыли упомянуть. _>PL/1 как раз для замены Фортрана и Кобола был придуман. Туда бред, совершенно не нужный сейчас и из того, и из другого притащен. И еще много всего, что в 60-е казалось интересным.
Не было еще такого в истории, чтобы новый и лучший язык, придуманный для замены, вытеснил заменяемое, а не начал с ним мирно сосуществовать.
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Mihal9, Вы писали:
M>>Собственно сабж. S> Native AOT
Это конечно хорошо но вопрос сколько есть библиотек, которые поддерживают NativeAOT ?
Шаг в лево, шаг вправо и уже что-то отвалится.
А в Go/Rust у нас любая библиотека будет работать.
Здравствуйте, _NN_, Вы писали:
S>> Native AOT _NN>Это конечно хорошо но вопрос сколько есть библиотек, которые поддерживают NativeAOT ? _NN>Шаг в лево, шаг вправо и уже что-то отвалится.
_NN>А в Go/Rust у нас любая библиотека будет работать.
Все под .Net 8! Там же JIT работает. А в Native AOT так еще и тримятся.
Не уж то в том же Rust больше библиотек чем для .Net. Чего то я сомневаюсь.
Просто IL код компилируется с помощью компилятора С++, можно и Rust с использованием сборщика мусора!
Например в Unity давно используют Введение в IL2CPP
Pzz>> Докер — это системное ПО или сайты? Написан на Go... R>В таком случае, и bash инструмент разработки системного ПО: https://github.com/p8952/bocker
А как же!
Обязательно!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
_NN>Чем больше когда, тем больше шансов, что не будет что-нибудь работать.
Еще бы с крипто библиотеками решить. У меня есть на .NET8 проект, и я было уже раскатал губу про нативный запуск, ан нет, что-то не срастается с libsodium (там нативный unsafe код).
Здравствуйте, SkyDance, Вы писали:
_NN>>Чем больше когда, тем больше шансов, что не будет что-нибудь работать.
SD>Еще бы с крипто библиотеками решить. У меня есть на .NET8 проект, и я было уже раскатал губу про нативный запуск, ан нет, что-то не срастается с libsodium (там нативный unsafe код).
Здравствуйте, vdimas, Вы писали:
V>Обсуждаемо. V>Раст пытается переосмыслить наработанные практики по отлову ошибок. V>Ну как "переосмыслить"... V>Тупо взять для императивного языка имеющиеся практики из функциональных языков. ))
Ок, вижу, что ты в теме
V>Попытка пока в процессе осмысления, бо сам язык и его стандартные либы активно развиваются (и обсуждаются) в сторону функциональности, предоставляемой обычными исключениями, бгг... V>Я тут запасся большой порцией попокорна и ехидно (не без этого) наблюдаю. ))
Надеюсь, что никто не продавит панику как штатный способ написания логики программ.
TB>>так и средствами обобщённого программирования
V>Это не есть достижение в текущую эпоху языков программирования.
В целом да, сейчас скорее вызывает недоумение отсутствие таких средств.
Вопрос ещё в их реализации, насколько они сделаны дружелюбно к инкрементальной сборке? В крестах всё крайне ужасно, шаблоны порождют копии одного и того же хедер-онли кода на каждый cpp-файл.
V>А изначально задуманный как "взрослый" язык Rust выглядит в асинхронщине недееспособным полупридурком, хотя асинхронщина является основным сегодня подходом к разработке как минимум серверных приложений. V>Это эпик фейл для Rust, как ни крути...
Ну а у кого с этим лучше? Вот ты говоришь, что Раст слабоват, а по сравнению с кем? Основной его конкурент — это кресты. А как там с асинхронщиной? Не, всё ок, но за дедлоками и расовыми условиями следить надо самостоятельно, и никак иначе. Чёто как-то тоже слабовато.
Нет такой подлости и мерзости, на которую бы не пошёл gcc ради бессмысленных 5% скорости в никому не нужном синтетическом тесте
M>>>Собственно сабж. S>> Native AOT _NN>Это конечно хорошо но вопрос сколько есть библиотек, которые поддерживают NativeAOT ? _NN>Шаг в лево, шаг вправо и уже что-то отвалится.
_NN>А в Go/Rust у нас любая библиотека будет работать.
Я помню переход фреймворка на Core. Первый стндарт был 1.6
В Core помню раздробили библиотеки на множество частей. Что то решили через расширение. Но не все.
Многие разработчики библиотек стали переводить под стандарт 1.6, а потом и 2.0, а затем и 2.1
Так что, это все дело времени. По сути проблемы только с Emit и обрезкой.
Emit это вообще древность заменена деревьями выражений которые могут выполняться без компиляции в натив.
Интерпретируются.
Рефлексия работает, но лучше заменять через кодогенерацию.
А библиотек поддерживают NativeAOT думаю вполне достаточно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, wraithik, Вы писали:
SD>>Ровно по этой причине хорошие технологии, но с некоторым барьером входа, редко получают популярность. А полное г...о (да, JavaScript, и да, Python) — получает.
W>1С забыл
Ну я бы не был столь категоричен. Я в свое время перешел на 1С ибо не было конкурентов.
Ценность 1С не только в языке, формах, но и готовых конфигурациях. В том числе и бухгалтерии.
Хорошие технологии должны давать не только язык, но и инструменты для быстрого создания отчетов и отчетности.
Готовые конфигурацию с простой и недорогой возможностью адаптации под себя.
и солнце б утром не вставало, когда бы не было меня
В 1С очень ограничен сам язык запросов .Я использовал те же Merge при обновлении регистров сведений.
Ну и прочее.
И проблема в том, что интерпретатор и ограничен язык.
Там где скоростей хватало не было смысла и заморачиваться.
В 1С еще и события при записи в те же регистры на каждую запись тормоза.
Ну и я в итоге применяя C# в 1С в итоге отказался от 1С и программирую на C#. Хотя 1С посвятил лет 20.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, wraithik, Вы писали:
W>Здравствуйте, SkyDance, Вы писали:
SD>>Ровно по этой причине хорошие технологии, но с некоторым барьером входа, редко получают популярность. А полное г...о (да, JavaScript, и да, Python) — получает.
W>1С забыл
Я вам открою тайну: у 1С очень высокий порог входа.
Все что там просто делать: таблички\формочки\отчеты в конструкторе.
Как только ты доходишь до ручного написания кода и использования сложных объектов (документы, регистры, бизнес-процессы, интеграции), то становится все очень непросто. Документация совсем неочень, очень плохой нейминг. Архитектура непонятная. Стандартная бибилиотека слабая. Средств создания абстракций почти нет. Стандартные средства коллективной разработки не подходят, а 1Сные через жопу работают.
Здравствуйте, _NN_, Вы писали:
M>>>Собственно сабж. S>> Native AOT _NN>Это конечно хорошо но вопрос сколько есть библиотек, которые поддерживают NativeAOT ? _NN>Шаг в лево, шаг вправо и уже что-то отвалится.
_NN>А в Go/Rust у нас любая библиотека будет работать.
Мы ожидаем добиться прогресса в изучении поддержки Native AOT для MVC и Blazor в сроки .NET 9, но мы не ожидаем предоставления готовой к использованию поддержки Native AOT для .NET 9, учитывая большой объем работы.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, Разраб, Вы писали:
Р>>Решил сравнить (наивно, конечно) зиг и оберон(https://free.oberon.org/en/) по убунтой. Р>>просто вывод 1млн чисел в консоль. зиг в режиме фаст релизил. в оберон просто скомпилил по дефолту.
G>Серьезно сравниваете языки по скорости вывода в консоль?
Нет конечно, просто поржать,
но с другой стороны, а почему такая большая разница?
И это только такая неважная фигня как вывод в консоль.
Здравствуйте, Разраб, Вы писали:
Р>но с другой стороны, а почему такая большая разница? Р> И это только такая неважная фигня как вывод в консоль.
В консоль можно ой как по разному выводить с точки зрения производительности
... << RSDN@Home 1.3.110 alpha 5 rev. 62>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока