@krokietowy jeśli już na tym etapie jest trudno testować, to ja naprawdę mocno bym przemyślał to portowanie. Było wiele firm, które (pod)upadły przez nieumiejętnie przeprowadzone migracje tego typu, które są (jak słusznie zauważyłeś) bardzo kosztowne i czasochłonne, a ostatecznie może się okazać że zwyczajnie nie realizują tego co powinny. Pokrycie testów to must have przy portowaniu i zmniejszanie tego pokrycia to nie jest dobry prognostyk. Mimo wszystko trzymam kciuki za powodzenie, ale z doświadczenia radzę Wam to dobrze zweryfikować, możecie uniknąć dużych problemów za chwilę.

@krokietowy dzieki za odpowiedz. lubie takie opowiesci z pierwszej, maja najwieksza wartosc.

Jesli to nie tajemnica to jaki to ARM? nie ma problemu z kompilacja rusta? Hobbistycznie przysiadlem do bare metal C dla prockow stm32 i jak patrzylem Rusta pod embeded to nie ma podjazdu do C

@Giblet5280 Na początku myśleliśmy żeby zrobić jedną aplikację z dwoma językami, jednak to by komplikowało proces budowania i oprócz błędów z rusta i pythona, dodawało błędy z warstwy pośredniej, więc obecnie mamy dwa osobne serwisy o bardzo podobnej odpowiedzialności.

Najprawdopodobniej byśmy użyli PyO3 - https://github.com/PyO3/pyo3, gdybyśmy szli w tę stronę.

@Astro Podwyżka była, ale przed ostateczną decyzją o przepisaniu i raczej była związana z rosnącym moim stażem pracy i odejściem jednego ze współpracowników.

W sumie, nawet gdyby nie było podwyżki, to i tak bym został tam dłuższą chwilę, bo pracuje mi się tam po prostu dobrze, w fajnej atmosferze, robię w miarę ciekawe projekty i się dużo uczę(przyszedłem jako junior i od początku cisnęli mnie, bym się uczył robić dobry software, a nie że dali mi klawiaturę i kazali po prostu robić taski, by po prostu działały).

@krokietowy no to powinieneś poprosić o podwyżkę w związku z projektem.

Po pierwsze żeby doceniali wagę pracownika.

Po drugie żebyś ty nie czuł sie wydymany gdy pracy i komplikacji będzie przybywało wraz ze zmianami.

A po trzecie żeby nie psuć rynku :)

@rm-rf Pythonową wersję robiłem w dużej części sam i to była moja pierwsza styczność z pythonem, ale niemal każdy MR był czujnie sprawdzany przez bardziej obeznanych programistów i ostatecznie, mimo że nie jest to ósmy cud świata, to kod jest w miarę czytelny i wystarczająco łatwy do modernizacji i gdyby nie problemy wydajnościowe, to by został na miejscu.

Z rustową wersją powinno być dużo łatwiej, bo mam więcej doświadczenia, zarówno w rust jak i pisaniu aplikacji, a oczy które sprawdzają MR się nie zmieniły, więc nie sądzę by został stworzony program który trzeba by było później przepisywać

@krokietowy a kompilowaliscie to do jakiejś implementacji c Pythona tak z ciekawości?

@rm-rf Myśleliśmy by użyć pypy albo nuitika, ale docelowy sprzęt ma 32 bitowy procesor arm, więc pewnie byłoby z tym trochę problemów i w końcu nawet nie spróbowaliśmy zrobić żadnych testów(nie jestem pewien czy wszystkie paczki których używaliśmy wspierały coś innego niż Cpython).

Mieliśmy jeszcze nadzieję na Cpythona >3.12 i kilkunastoprocentowe przyspieszenie, ale najwcześniej nową wersję moglibyśmy użyć pod koniec roku, a potrzebowaliśmy przyspieszania już teraz.

@krokietowy spoko rozumiem o czym mówisz bo u nas była potrzeba przyspieszyć z obrabiałem jednego requestu tylko, że w lambda i zmuszeni byliśmy zrobić to i w python i w node I w Java dla porównania. Koniec końców najwolniejszy był node, python dawał sobie radę i na przykład dla 10k requestow był najszybszy ale dla 150k Java wygrywała po rozgrzaniu jvm.