J
Строгая типизация и в питоне
там и поинтеры так-то есть. но не все знают и не все умеют правильно
Size: a a a
2020 November 14
EG
ИДЕ не подсвечивает ошибки, не круто
Какие ошибки?
p
А ну хотя это Раст, здесь 60% ошибок не подсвечиваются ИДЕ
EG
Ошибки в темплейте? А для какого движка подсвечивает?
EG
Для динамического темплейта ты это уж точно не сделаешь
p
Ошибки в темплейте? А для какого движка подсвечивает?
В профессиональном пайчарме умеет
EG
В профессиональном пайчарме умеет
Умеет подсвечивать что? Ошибки джинджи?
p
Умеет подсвечивать что? Ошибки джинджи?
Да
EG
Ну так извини, где питон, а где раст
EG
Питон — промязык, а раст — игрушка
MW
Но это ж офигенно
Она получается статически типизированной и быстрой
Она получается статически типизированной и быстрой
а почему на ней GUI не пишут? Типа Apache Wicket , это же было бы отлично
EG
Merlin Wizard
а почему на ней GUI не пишут? Типа Apache Wicket , это же было бы отлично
Потому что это templating engine, а не веб-фреймворк?..
p
Merlin Wizard
а почему на ней GUI не пишут? Типа Apache Wicket , это же было бы отлично
На расте гуй не пишут, игрушка же
YB
На расте гуй не пишут, игрушка же
вроде ж гном какие-то куски на раст портирует
KB
Умные люди, подскажите - а чем концептуально сложно писать какой-нибудь бэкенд на rust? Ведь пишут на go (там бывают утечки, иногда их очень тяжело отлавливать, особенно если были обрёртки над плюсами), пишут на java и scala (тоже типизация, правда с gc). И вроде в rust очень приятный drop, сильные типы, немного фп. Что именно вызывает такую боль, когда говорят про обычные web приложения на rust?
Мои пять копеек: писать обычно приятно и не очень сложно, а вот поддерживать и сопровождать иногда больновато.
Не весь тулинг доведён до ума, не все библиотеки нормально попользованы и вычищены от глупых багов, поэтому иногда, когда что-то ломается, мне, как человеку, избалованному JVM, бывает сложно быстро найти проблему и починить.
Пример: задеплоили приложение, всё, вроде ок.
Начали грузить load тестами — потекла память.
Ну ок, идём смотреть на профайлеры: всё серьёзное только под Linux, анализируют только аллокации, поэтому проблему показывают примерно.
Удалённо подключиться и потрекать память можно, но нужно менять немного сборку проекта, чтобы с кастомным аллокатором запуститься или ставить какие-нибудь доп. профайлеры и запускать ими.
А потом перезапускать тест, ждать и анализировать многогигабайтные дампы.
А в той же Java — подключился удалённо наживую к приложению (порт, конечно, нужно заранее открыть, но ставить или крутить дополнительно ничего не нужно) и сразу видишь всю кучу со всем графом, гуляй по жирным объектами смотри, что они себе в память понаписали, прямо сами данные посмотреть можно.
Хоть дебажь так же, если совсем нужно.
И так примерно со всем: на любой закидон приложения приходится тратить больше времени и сил, чем этого бы хотелось бы.
Но и таких проблемных закидонов сильно меньше, как мне кажется.
Не весь тулинг доведён до ума, не все библиотеки нормально попользованы и вычищены от глупых багов, поэтому иногда, когда что-то ломается, мне, как человеку, избалованному JVM, бывает сложно быстро найти проблему и починить.
Пример: задеплоили приложение, всё, вроде ок.
Начали грузить load тестами — потекла память.
Ну ок, идём смотреть на профайлеры: всё серьёзное только под Linux, анализируют только аллокации, поэтому проблему показывают примерно.
Удалённо подключиться и потрекать память можно, но нужно менять немного сборку проекта, чтобы с кастомным аллокатором запуститься или ставить какие-нибудь доп. профайлеры и запускать ими.
А потом перезапускать тест, ждать и анализировать многогигабайтные дампы.
А в той же Java — подключился удалённо наживую к приложению (порт, конечно, нужно заранее открыть, но ставить или крутить дополнительно ничего не нужно) и сразу видишь всю кучу со всем графом, гуляй по жирным объектами смотри, что они себе в память понаписали, прямо сами данные посмотреть можно.
Хоть дебажь так же, если совсем нужно.
И так примерно со всем: на любой закидон приложения приходится тратить больше времени и сил, чем этого бы хотелось бы.
Но и таких проблемных закидонов сильно меньше, как мне кажется.
YB
Мои пять копеек: писать обычно приятно и не очень сложно, а вот поддерживать и сопровождать иногда больновато.
Не весь тулинг доведён до ума, не все библиотеки нормально попользованы и вычищены от глупых багов, поэтому иногда, когда что-то ломается, мне, как человеку, избалованному JVM, бывает сложно быстро найти проблему и починить.
Пример: задеплоили приложение, всё, вроде ок.
Начали грузить load тестами — потекла память.
Ну ок, идём смотреть на профайлеры: всё серьёзное только под Linux, анализируют только аллокации, поэтому проблему показывают примерно.
Удалённо подключиться и потрекать память можно, но нужно менять немного сборку проекта, чтобы с кастомным аллокатором запуститься или ставить какие-нибудь доп. профайлеры и запускать ими.
А потом перезапускать тест, ждать и анализировать многогигабайтные дампы.
А в той же Java — подключился удалённо наживую к приложению (порт, конечно, нужно заранее открыть, но ставить или крутить дополнительно ничего не нужно) и сразу видишь всю кучу со всем графом, гуляй по жирным объектами смотри, что они себе в память понаписали, прямо сами данные посмотреть можно.
Хоть дебажь так же, если совсем нужно.
И так примерно со всем: на любой закидон приложения приходится тратить больше времени и сил, чем этого бы хотелось бы.
Но и таких проблемных закидонов сильно меньше, как мне кажется.
Не весь тулинг доведён до ума, не все библиотеки нормально попользованы и вычищены от глупых багов, поэтому иногда, когда что-то ломается, мне, как человеку, избалованному JVM, бывает сложно быстро найти проблему и починить.
Пример: задеплоили приложение, всё, вроде ок.
Начали грузить load тестами — потекла память.
Ну ок, идём смотреть на профайлеры: всё серьёзное только под Linux, анализируют только аллокации, поэтому проблему показывают примерно.
Удалённо подключиться и потрекать память можно, но нужно менять немного сборку проекта, чтобы с кастомным аллокатором запуститься или ставить какие-нибудь доп. профайлеры и запускать ими.
А потом перезапускать тест, ждать и анализировать многогигабайтные дампы.
А в той же Java — подключился удалённо наживую к приложению (порт, конечно, нужно заранее открыть, но ставить или крутить дополнительно ничего не нужно) и сразу видишь всю кучу со всем графом, гуляй по жирным объектами смотри, что они себе в память понаписали, прямо сами данные посмотреть можно.
Хоть дебажь так же, если совсем нужно.
И так примерно со всем: на любой закидон приложения приходится тратить больше времени и сил, чем этого бы хотелось бы.
Но и таких проблемных закидонов сильно меньше, как мне кажется.
Дык с го разве не того же свойства проблемы если очень хочется наживую в памяти порыться? Это ж проблема скорее отсутствия виртуалки как таковой, а не отдельно взятого языка.
MB
Ну в принципе начать трассировку аллокаций наживую можно, но вряд ли кто-то таким занимался.
YB
Ну в принципе начать трассировку аллокаций наживую можно, но вряд ли кто-то таким занимался.
Можно, а нужно ли?)
KB
Дык с го разве не того же свойства проблемы если очень хочется наживую в памяти порыться? Это ж проблема скорее отсутствия виртуалки как таковой, а не отдельно взятого языка.
С Го, наверное, так же, я не знаком.
Но решил поделиться чутка наболевшим)
Но решил поделиться чутка наболевшим)
MB
Можно, а нужно ли?)
Ну вот человек хочет :)