История изменений

В целом, есть плюсы и минусы, растущие из разной истории(кто-то зарелизился в девяностых, кто-то в 2015-ом году).

Но мне лично нравится то, как разрабы языка, по сути, сели и крепко подумали «А как мы можем улучшить то, что уже существует?». К примеру, взяли pcre, написали длинный список их недостатков и того, что делает их нечитабельным месивом и подумали «А как мы можем сделать лучше?». Придумали и сделали. При этом понятно, что тот же Ларри это явно не последний человек, который работал с pcre.

Или вот взяли проблему типа канкаренси и подумали «Вот есть какой-нибудь rxjava, но пользоваться им больно и страшно и неудобно. Как мы можем сделать удобней?». Придумали и сделали. «Гонки трудно искать». Обычно дизайнеры языков отвечают в стиле «Сам дурак», но здесь люди задаются вопросом «А что мы можем как разработчики языка с этим сделать? Можем ли мы помочь пользователям?». Девиз «Пытай разработчика компилятора ради удобства пользователей» это же чудесно (для пользователей, для разработчиков это не весело). Но многие делают наоборот, «пусть пользователи сами парятся с проблемами, потому что я не хочу придумывать, как можно решить проблему, едет и едет».

Будет очень печально, если язык, как многие тут хотят, умрёт, потому что это та штука, где действительно есть изменения на фоне относительного застоя в дизайне ЯП.

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

В целом, есть плюсы и минусы, растущие из разной истории(кто-то зарелизился в девяностых, кто-то в 2015-ом году).

Но мне лично нравится то, как разрабы языка, по сути, сели и крепко подумали «А как мы можем улучшить то, что уже существует?». К примеру, взяли pcre, написали длинный список их недостатков и того, что делает их нечитабельным месивом и подумали «А как мы можем сделать лучше?». Придумали и сделали. При этом понятно, что тот же Ларри это явно не последний человек, который работал с pcre.

Или вот взяли проблему типа канкаренси и подумали «Вот есть какой-нибудь javarx, но пользоваться им больно и страшно и неудобно. Как мы можем сделать удобней?». Придумали и сделали. «Гонки трудно искать». Обычно дизайнеры языков отвечают в стиле «Сам дурак», но здесь люди задаются вопросом «А что мы можем как разработчики языка с этим сделать? Можем ли мы помочь пользователям?». Девиз «Пытай разработчика компилятора ради удобства пользователей» это же чудесно (для пользователей, для разработчиков это не весело). Но многие делают наоборот, «пусть пользователи сами парятся с проблемами, потому что я не хочу придумывать, как можно решить проблему, едет и едет».

Будет очень печально, если язык, как многие тут хотят, умрёт, потому что это та штука, где действительно есть изменения на фоне относительного застоя в дизайне ЯП.

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