Wpis z mikrobloga

protip: jakbyście chcieli pisać kiedyś CLI w #python to nie róbcie tego. Rozwijałem kiedyś takie CLI i przyglądałem się innym projektom open source i mam jeden wniosek: czasy importowania potrafią tak mocno wpłynąć na czas startu, że używanie staje się niewygodne. Zwłaszcza, gdy eksplorujemy narzędzie za pomocą --help albo spamując ``
#programowanie
  • 11
@papugatotwardziel: @Lunatik: przykładowo porównuje aws help (mean 364.8 ms) vs gh help (mean 11 ms), który jest napisany w go . Env PYTHONPROFILEIMPORTTIME=1 pozwala sprawdzić, co trwa długo. Jak dla mnie to duży narzut, inaczej nie pisałbym tego posta.
nie zauwazylem tego problemu, o jakiej skali w przyblizeniu mówisz i co zamiast tego polecasz?


@Lunatik: co do polecania to pewnie Go lub Rust, oba języki bardzo szybko startują i są dobre do CLI: statyczne binarki, mały rozmiar, duża wydajność
@Saly: ja tam lubię. MAŁE cli. Bydlaki są zawsze problematyczne. Chociaż np cli dla opensracka niby małe nie jest a nie bardzo zamula. I mowie tu o openstack i neurlink czy jak mu tam
@papugatotwardziel: pierwszy commit aws-cli jest z 2012 roku: wtedy go a tym bardziej rust nie były popularnymi wyborami, więc wcale się nie dziwie. No i oczywiście nikt nie przepisze tak ogromnego projektu, bo jakiś random z internetu narzeka. Chodzi mi tylko o to, że jakby ktoś planował pisać coś nowego w pythonie to niech się zastanowi dwa razy, bo panuje taka wiedza ogólna, że "python wstaje szybko" a to niestety kłamstwo