Информация об изменениях

Сообщение Re[3]: Rust или Golang - за кем будущее? от 05.02.2024 14:50

Изменено 13.02.2024 9:27 vdimas

Re[3]: Rust или Golang - за кем будущее?
Здравствуйте, T4r4sB, Вы писали:

V>>Оба слабенькие.

TB>Ощущение что ты не в теме.

Хорошее начало, заранее слился. ))


TB>Они очень сильныы по инфраструкиуое как минимум.


Вопрос стоят — за кем будущее?
Вопрос забавный, бо спросили о двух языках с разным позиционированием.
(хотя, сравнение именно этих языков обнажает текущие проблемы в языковом мейнстриме)

Golang имеет довольно-таки узконишевое позиционирование и показывает себя в этой нише удачно.
Это ниша быстрого прототипирования с довылизыванием прототипа до реального продукта.
По этой причине в вебе пришёлся весьма кстате.
И по этой причине кое-какие ограничения в дизайне — простоты и безопасности прототипирования ради (например, встроенная в язык прикладная функциональность каналов, где можно передавать данные лишь указанного типа — это не дотягивает до классической реализации мейл-боксов из модели акторов, то бишь является классичесской dog-food полуреализацией изначально мощной концепции).


TB>А Раст силён как средствами отлова ошибок


Обсуждаемо.
Раст пытается переосмыслить наработанные практики по отлову ошибок.
Ну как "переосмыслить"...
Тупо взять для императивного языка имеющиеся практики из функциональных языков. ))

Попытка пока в процессе осмысления, бо сам язык и его стандартные либы активно развиваются (и обсуждаются) в сторону функциональности, предоставляемой обычными исключениями, бгг...
Я тут запасся большой порцией попокорна и ехидно (не без этого) наблюдаю. ))

Аналогично у них в корутинах и прочей асинхронщине — принятые изначально решения в плане дизайна языка и принципа работы низлежащей вычислительной модели мешают оформлять корутины и асинхронщину в Расте удобоваримым образом, в отличие от того же Go, в котором корутины/асинхронщина — часть языка, и даже во многом цель его разработки.


TB>так и средствами обобщённого программирования


Это не есть достижение в текущую эпоху языков программирования.
А вот асинхронщина востребована, бо интенсивное развитие выч.мощностей практически остановилось к середине нулевых, сейчас идёт эпоха экстенсивного развития.

И что мы видим?
Пригодный для асинхронщины Go хорошо себя показывает только рядом с JS и прочими полуязыками, сливая вчистую "взрослым" языкам в числодроблении и бизнес-логике.

А изначально задуманный как "взрослый" язык Rust выглядит в асинхронщине недееспособным полупридурком, хотя асинхронщина является основным сегодня подходом к разработке как минимум серверных приложений.
Это эпик фейл для Rust, как ни крути...
Изначально позиционируемый как универсальный и мультипарадигменный Rust испытывает в некоторых задачах сложности, то бишь проявляет свои ограничения по нишам, бгг... ))

===============
Поэтому, вопрос ТС на сегодня более чем бессмысленен.
К нему надо вернуться лет через 15-20...
Лично мне тоже любопытно, что случится быстрее — разработчики Rust-а одумаются, наконец, и перестанут валять дурака в своей упоротости или Golang обзаведётся шикарными оптимизирующими компиляторами + ср-вами низкого уровня (иначе зачем оптимизация)?
Re[3]: Rust или Golang - за кем будущее?
Здравствуйте, T4r4sB, Вы писали:

V>>Оба слабенькие.

TB>Ощущение что ты не в теме.

Хорошее начало, заранее слился. ))


TB>Они очень сильныы по инфраструкиуое как минимум.


Вопрос стоял — за кем будущее?
Вопрос забавный, бо спросили о двух языках с разным позиционированием.
(хотя, сравнение именно этих языков обнажает текущие проблемы в языковом мейнстриме)

Golang имеет довольно-таки узконишевое позиционирование и показывает себя в этой нише удачно.
Это ниша быстрого прототипирования с довылизыванием прототипа до реального продукта.
По этой причине в вебе пришёлся весьма кстате.
И по этой причине кое-какие ограничения в дизайне — простоты и безопасности прототипирования ради (например, встроенная в язык прикладная функциональность каналов, где можно передавать данные лишь указанного типа — это не дотягивает до классической реализации мейл-боксов из модели акторов, то бишь является классичесской dog-food полуреализацией изначально мощной концепции).


TB>А Раст силён как средствами отлова ошибок


Обсуждаемо.
Раст пытается переосмыслить наработанные практики по отлову ошибок.
Ну как "переосмыслить"...
Тупо взять для императивного языка имеющиеся практики из функциональных языков. ))

Попытка пока в процессе осмысления, бо сам язык и его стандартные либы активно развиваются (и обсуждаются) в сторону функциональности, предоставляемой обычными исключениями, бгг...
Я тут запасся большой порцией попокорна и ехидно (не без этого) наблюдаю. ))

Аналогично у них в корутинах и прочей асинхронщине — принятые изначально решения в плане дизайна языка и принципа работы низлежащей вычислительной модели мешают оформлять корутины и асинхронщину в Расте удобоваримым образом, в отличие от того же Go, в котором корутины/асинхронщина — часть языка, и даже во многом цель его разработки.


TB>так и средствами обобщённого программирования


Это не есть достижение в текущую эпоху языков программирования.
А вот асинхронщина востребована, бо интенсивное развитие выч.мощностей практически остановилось к середине нулевых, сейчас идёт эпоха экстенсивного развития.

И что мы видим?
Пригодный для асинхронщины Go хорошо себя показывает только рядом с JS и прочими полуязыками, сливая вчистую "взрослым" языкам в числодроблении и бизнес-логике.

А изначально задуманный как "взрослый" язык Rust выглядит в асинхронщине недееспособным полупридурком, хотя асинхронщина является основным сегодня подходом к разработке как минимум серверных приложений.
Это эпик фейл для Rust, как ни крути...
Изначально позиционируемый как универсальный и мультипарадигменный Rust испытывает в некоторых задачах сложности, то бишь проявляет свои ограничения по нишам, бгг... ))

===============
Поэтому, вопрос ТС на сегодня более чем бессмысленен.
К нему надо вернуться лет через 15-20...
Лично мне тоже любопытно, что случится быстрее — разработчики Rust-а одумаются, наконец, и перестанут валять дурака в своей упоротости или Golang обзаведётся шикарными оптимизирующими компиляторами + ср-вами низкого уровня (иначе зачем оптимизация)?