Здравствуйте, pagid_, Вы писали:
M>>А синтаксис у Го поприятнее, да? _>Синтаксис Go как раз его паршивая сторона. Но в целом по теме разговора это не особо значимая мелочь.
Здравствуйте, Pzz, Вы писали:
Pzz>Тебе ж сказали, Фортран и Кобол. Еще PL/1 забыли упомянуть.
PL/1 как раз для замены Фортрана и Кобола был придуман. Туда бред, совершенно не нужный сейчас и из того, и из другого притащен. И еще много всего, что в 60-е казалось интересным.
Pzz>А clojure — это новомодная хрень для хипстеров.
+1
Здравствуйте, pagid_, Вы писали:
Pzz>>Тебе ж сказали, Фортран и Кобол. Еще PL/1 забыли упомянуть. _>PL/1 как раз для замены Фортрана и Кобола был придуман. Туда бред, совершенно не нужный сейчас и из того, и из другого притащен. И еще много всего, что в 60-е казалось интересным.
Не было еще такого в истории, чтобы новый и лучший язык, придуманный для замены, вытеснил заменяемое, а не начал с ним мирно сосуществовать.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Mihal9, Вы писали:
M>>Собственно сабж.
V>Оба слабенькие.
Ощущение что ты не в теме. Они очень сильныы по инфраструкиуое как минимум. А Раст силён как средствами отлова ошибок так и средствами обобщённого программирования
Здравствуйте, 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
А как же!
Обязательно!
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
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
Согласен. Погорячился.
А как ты хочешь без 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.
Здравствуйте, T4r4sB, Вы писали:
V>>Оба слабенькие. TB>Ощущение что ты не в теме.
Хорошее начало, заранее слился. ))
TB>Они очень сильныы по инфраструкиуое как минимум.
Вопрос стоял — за кем будущее?
Вопрос забавный, бо спросили о двух языках с разным позиционированием.
(хотя, сравнение именно этих языков обнажает текущие проблемы в языковом мейнстриме)
Golang имеет довольно-таки узконишевое позиционирование и показывает себя в этой нише удачно.
Это ниша быстрого прототипирования с довылизыванием прототипа до реального продукта.
По этой причине в вебе пришёлся весьма кстате.
И по этой причине кое-какие ограничения в дизайне — простоты и безопасности прототипирования ради (например, встроенная в язык прикладная функциональность каналов, где можно передавать данные лишь указанного типа — это не дотягивает до классической реализации мейл-боксов из модели акторов, то бишь является классичесской dog-food полуреализацией изначально мощной концепции).
TB>А Раст силён как средствами отлова ошибок
Обсуждаемо.
Раст пытается переосмыслить наработанные практики по отлову ошибок.
Ну как "переосмыслить"...
Тупо взять для императивного языка имеющиеся практики из функциональных языков. ))
Попытка пока в процессе осмысления, бо сам язык и его стандартные либы активно развиваются (и обсуждаются) в сторону функциональности, предоставляемой обычными исключениями, бгг...
Я тут запасся большой порцией попокорна и ехидно (не без этого) наблюдаю. ))
Аналогично у них в корутинах и прочей асинхронщине — принятые изначально решения в плане дизайна языка и принципа работы низлежащей вычислительной модели мешают оформлять корутины и асинхронщину в Расте удобоваримым образом, в отличие от того же Go, в котором корутины/асинхронщина — часть языка, и даже во многом цель его разработки.
TB>так и средствами обобщённого программирования
Это не есть достижение в текущую эпоху языков программирования.
А вот асинхронщина востребована, бо интенсивное развитие выч.мощностей практически остановилось к середине нулевых, сейчас идёт эпоха экстенсивного развития.
И что мы видим?
Пригодный для асинхронщины Go хорошо себя показывает только рядом с JS и прочими полуязыками, сливая вчистую "взрослым" языкам в числодроблении и бизнес-логике.
А изначально задуманный как "взрослый" язык Rust выглядит в асинхронщине недееспособным полупридурком, хотя асинхронщина является основным сегодня подходом к разработке как минимум серверных приложений.
Это эпик фейл для Rust, как ни крути...
Изначально позиционируемый как универсальный и мультипарадигменный Rust испытывает в некоторых задачах сложности, то бишь проявляет свои ограничения по нишам, бгг... ))
===============
Поэтому, вопрос ТС на сегодня более чем бессмысленен.
К нему надо вернуться лет через 15-20...
Лично мне тоже любопытно, что случится быстрее — разработчики Rust-а одумаются, наконец, и перестанут валять дурака в своей упоротости или Golang обзаведётся шикарными оптимизирующими компиляторами + ср-вами низкого уровня (иначе зачем оптимизация)?
_NN>Чем больше когда, тем больше шансов, что не будет что-нибудь работать.
Еще бы с крипто библиотеками решить. У меня есть на .NET8 проект, и я было уже раскатал губу про нативный запуск, ан нет, что-то не срастается с libsodium (там нативный unsafe код).
Здравствуйте, SkyDance, Вы писали:
_NN>>Чем больше когда, тем больше шансов, что не будет что-нибудь работать.
SD>Еще бы с крипто библиотеками решить. У меня есть на .NET8 проект, и я было уже раскатал губу про нативный запуск, ан нет, что-то не срастается с libsodium (там нативный unsafe код).
Здравствуйте, Serginio1, Вы писали:
S> Ну а что касается замены .Net на Rust лучше бы сосредоточились на Native AOT. S> Наверное проще довести до ума Native AOT чем переписывать все на Rust.
Один забугорный коллега поделился. Лет пять назад, контора, где у него был контракт, решила переписать дельфийский софт на шарпе (насколько мне известно, там и гуй, и веб-сервисы). Наняли штат, он до окончания контракта эту работу наблюдал, потом из конторы ушел. Сейчас эта контора зовет его назад Оказывается, решили продолжать разработку на дельфях
Здравствуйте, vdimas, Вы писали:
V>Обсуждаемо. V>Раст пытается переосмыслить наработанные практики по отлову ошибок. V>Ну как "переосмыслить"... V>Тупо взять для императивного языка имеющиеся практики из функциональных языков. ))
Ок, вижу, что ты в теме
V>Попытка пока в процессе осмысления, бо сам язык и его стандартные либы активно развиваются (и обсуждаются) в сторону функциональности, предоставляемой обычными исключениями, бгг... V>Я тут запасся большой порцией попокорна и ехидно (не без этого) наблюдаю. ))
Надеюсь, что никто не продавит панику как штатный способ написания логики программ.
TB>>так и средствами обобщённого программирования
V>Это не есть достижение в текущую эпоху языков программирования.
В целом да, сейчас скорее вызывает недоумение отсутствие таких средств.
Вопрос ещё в их реализации, насколько они сделаны дружелюбно к инкрементальной сборке? В крестах всё крайне ужасно, шаблоны порождют копии одного и того же хедер-онли кода на каждый cpp-файл.
V>А изначально задуманный как "взрослый" язык Rust выглядит в асинхронщине недееспособным полупридурком, хотя асинхронщина является основным сегодня подходом к разработке как минимум серверных приложений. V>Это эпик фейл для Rust, как ни крути...
Ну а у кого с этим лучше? Вот ты говоришь, что Раст слабоват, а по сравнению с кем? Основной его конкурент — это кресты. А как там с асинхронщиной? Не, всё ок, но за дедлоками и расовыми условиями следить надо самостоятельно, и никак иначе. Чёто как-то тоже слабовато.
M>>>Собственно сабж. S>> Native AOT _NN>Это конечно хорошо но вопрос сколько есть библиотек, которые поддерживают NativeAOT ? _NN>Шаг в лево, шаг вправо и уже что-то отвалится.
_NN>А в Go/Rust у нас любая библиотека будет работать.
Я помню переход фреймворка на Core. Первый стндарт был 1.6
В Core помню раздробили библиотеки на множество частей. Что то решили через расширение. Но не все.
Многие разработчики библиотек стали переводить под стандарт 1.6, а потом и 2.0, а затем и 2.1
Так что, это все дело времени. По сути проблемы только с Emit и обрезкой.
Emit это вообще древность заменена деревьями выражений которые могут выполняться без компиляции в натив.
Интерпретируются.
Рефлексия работает, но лучше заменять через кодогенерацию.
А библиотек поддерживают NativeAOT думаю вполне достаточно.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, SkyDance, Вы писали:
SD>Ровно по этой причине хорошие технологии, но с некоторым барьером входа, редко получают популярность. А полное г...о (да, JavaScript, и да, Python) — получает.
Здравствуйте, wraithik, Вы писали:
SD>>Ровно по этой причине хорошие технологии, но с некоторым барьером входа, редко получают популярность. А полное г...о (да, JavaScript, и да, Python) — получает.
W>1С забыл
Ну я бы не был столь категоричен. Я в свое время перешел на 1С ибо не было конкурентов.
Ценность 1С не только в языке, формах, но и готовых конфигурациях. В том числе и бухгалтерии.
Хорошие технологии должны давать не только язык, но и инструменты для быстрого создания отчетов и отчетности.
Готовые конфигурацию с простой и недорогой возможностью адаптации под себя.
и солнце б утром не вставало, когда бы не было меня
Оказывается, решили продолжать разработку на дельфях 
