Оригиналът е на Преслав Рачев от неговия великолепен блог Даниел

Оригиналът е на Преслав Рачев от неговия превъзходен блог

Даниел Десподов преди 9 секунди 2 Сподели

Най-четени

НаукаЕмил Василев - 16:16 | 06.12.2023

Арабски учени са изобретили слънчева кула, която ще обезпечава чиста сила през деня и нощем

КосмосЕмил Василев - 20:26 | 06.12.2023

Космическият телескоп ‘Джеймс Уеб “ видя „ галактически фантом “, който безусловно се крие пред очите ни

IT НовиниДаниел Десподов - 15:15 | 05.12.2023

Китай разгласи, че е разкрил голям непокътнат петролен запас от 100 милиона тона

Даниел Десподовhttps://www.kaldata.com/Новинар. Увличам се от модерни технологии, осведомителна сигурност, спорт, просвета и изкуствен интелект.

Python и Go имат разнообразни свойства и по тази причина могат доста добре да се допълват взаимно.

Съществува постоянно срещано неправилно разбиране, че елементарното и лесното са едно и също нещо. В края на краищата, в случай че един инструмент е елементарен за потребление, вътрешното му устройство би трябвало да е елементарно за схващане, нали? А противоположното също е правилно, нали по този начин? Всъщност е тъкмо противоположното. Макар че по дух двете понятия указват едно и също нещо (отстрани крайният резултат наподобява лесен), на процедура тази повърхностна лекост се реализира с голяма трудност „ под капака “.

Да разгледаме Python. Добре знае се какъв брой невисок е прагът за нахлуване в този програмен език; точно по тази причина Python е любимец като първи език за програмиране. В учебните заведения, университетите, изследователските институти и многочислените компании по света Python е желан точно тъй като всеки може да го разбере, без значение от равнището си на обучение, а академична подготовка нормално въобще не се изисква. За да работите с Python, рядко се постанова да прибягвате до теорията на видовете или да разбирате къде, какво и по какъв начин се съхранява в паметта, в кои влакна се извършва този или оня откъс от кода и така нататък Освен това посредством Python можете да се запознаете с някои от най-обширните библиотеки, предопределени за научни калкулации и редовно програмиране. Когато се окаже, че разполагате с такава мощност, даже един-единствен ред сорс код безапелационно показва за какво Python се е трансформирал в един от най-популярните езици за програмиране на планетата.

Ето тук се появяват нюансите – става известно, че лекотата, с която можете да изразите всичко на Python, си има цена. Под капака на Python се крие тежък тълковник и даже с цел да се извърши един ред код, би трябвало да се извършат доста интервенции. Ако в миналото сте чували да се споделя, че Python е „ муден “ програмен език, то знаете, че тази привидна „ бавност “ се дължи на редица решения, които интерпретаторът би трябвало да вземе по време на осъществяването. Но съгласно мен даже и това не е главният проблем. Сложността на цялата среда за осъществяване на Python и неговата екосистема, дружно с някои случайно взети решения за ръководството на пакетите в този език, са аргументите за изключителната чупливост на тази среда. Поради тази чупливост постоянно пораждат случаи на несъответственост и отводи по време на осъществяване. Често се случва да се оттеглите от някое приложение на Python за известно време, да се върнете към него след няколко месеца и да установите, че екосистемата се е трансформирала толкоз доста, че остарялото ви приложение към този момент даже не може да се извършва.

Разбира се, това е жестоко, даже прекомерно огромно опростяване: през днешния ден даже децата знаят, че контейнерите могат да вземат решение сходни проблеми. Наистина, с Docker и другите сходни принадлежности е допустимо да се „ заключат “ трайно зависимостите в кодовата база на Python, тъй че тя да работи на практика постоянно. Но на процедура това е просто прекачване на отговорността и изхвърляне на цялата трудност върху инфраструктурния пласт на операционната система. Не е краят на света, само че не можете да гледате на този проблем през просото и да го подценявате.

От лекотата към простотата

Ако се заемем с проблемите, които съществуват в Python, ще получим нещо сходно на Rust – език, който е извънредно работлив, само че е прочут с високия си предел за нахлуване. По мое мнение Rust напълно не е елементарен за потребление и даже освен това – въобще не е елементарен. Макар че през днешния ден Rust е на най-високата вълна на известност, аз с целия си опит (програмирам от 20 години, като първите ми стъпки бяха направени на C и C++) не мога да погледна фрагмент от код на Rust и да го плана с лекост и убеденост.

Но преди към пет години открих Go, тъкмо когато работех със система, основана на Python. Въпреки че не съумях да се оправя със синтаксиса на Go от първия път, незабавно ми стана ясно какъв брой семпли са концепциите зад него. Go е планиран по този начин, че да бъде елементарен за схващане от всеки в организацията, без значение дали става въпрос за младши, преди малко излязъл от института, или за върховен софтуерен управител, който просто е хвърлил един взор върху сорс кода. Ще ви кажа още, че при цялата елементарност на езика Go, неговият синтаксис доста рядко се актуализира. Последната огромна смяна беше генериците, добавени във версия 1.18, и то след десетилетие на съществени полемики. В множеството случаи, в случай че погледнете на код на Go, написан даже преди пет дни или пет години, той ще наподобява доста различим и би трябвало просто да работи.

Но простотата изисква дисциплинираност. На пръв взор езикът Go може да наподобява ограничителен и даже леко назадничав. Особено в случай че сравните кода на Go с къси изрази като описи или речници в Python:

temperatures = [ { " city ": " City1 ", " temp ": 19}, { " city ": " City2 ", " temp ": 22}, { " city ": " City3 ", " temp ": 21}, ] filtered_temps = { entry[ " city " ]: entry[ " temp " ] for entry in temperatures if entry[ " temp " ] > 20 }

За написването на същия код на Go са нужни доста повече натискания на клавиатурата, само че в идеалния случай той ще има едно равнище на абстракция по-малко от Python, който зависи от своя тълковник под капака:

type CityTemperature struct { City string Temp float64 } //... temperatures:= []CityTemperature{ { " City1 ", 19}, { " City2 ", 22}, { " City3 ", 21}, } filteredTemps:= make(map[string]float64) for _, ct:= range temperatures { if ct.Temp > 20 { filteredTemps[ct.City] = ct.Temp } }

Въпреки че можете да напишете сходен код на Python, в програмирането има едно мълчешком предписание: в случай че даден език предлага по-лесен (разбирай по-кратък, по-елегантен) вид, програмистите са склонни да го употребяват. Но „ лекотата “ е субективно разбиране, а „ простотата “ би трябвало да е лесна за всеки. Когато едно и също деяние може да бъде осъществено по няколко метода, това води до развиването на разнообразни стилове на програмиране, а неведнъж многото стилове могат да бъдат комбинирани в една и съща кодова база.

Да, Go може да бъде разказан като отегчителен и „ отегчителен “, само че когато се работи с него, има още един плюс: компилаторът на Go би трябвало да свърши доста малко работа при съставянето на изпълнимия файл. Компилирането и стартирането на приложенията на Go постоянно е толкоз бързо, колкото и в Python (където въпреки всичко би трябвало да се започва интерпретатор) или Java (където би трябвало да се започва виртуална машина), или даже по-бързо от тях. Никак не е изненадващо, че най-бързият осъществим файл е нативният осъществим файл. Той не е толкоз бърз, колкото неговите аналози на C/C++ или Rust, само че е няколко пъти по-опростен на равнище първоначален код. Готов съм да подцени този дребен „ минус “ на Go. И като предястие: двоичните файлове на Go са статично свързани. Това значи, че можете да ги компилирате където и да било и да ги стартирате на машината, която желаете. Няма да има никакви зависимости, свързани със средата за осъществяване или библиотеките. За по-голямо улеснение към момента опаковаме нашите приложения, написани на Go, в Docker контейнери. Тези приложения обаче са дребни и употребяват единствено дребна част от паметта и процесорното време спрямо аналогичните приложения, написани на Python или Java.

Как да комбинираме Python и Go в наша изгода

Най-прагматичното решение, до което стигнахме в нашата работа, е да съвместим най-хубавите характерности на лекотата на Python и простотата на Go. Считаме, че Python е превъзходен полигон за експериментиране на прототипи. Това е мястото, където се раждат концепциите, където се одобряват или отхвърлят научните хипотези. Python е основан за науката за данните и машинното образование и защото в работата си непрекъснато се сблъскваме с тези области, надали има смисъл да изобретяваме колелото на различен език за програмиране. Освен това Python е в основата на фреймуърка Django, чийто лозунг е бързата разработка на приложения (едва ли има равни на него, само че с цел да е цялостна картината, несъмнено, ще загатна Ruby on Rails и Phoenix for Elixir).

Да предположим, че даден план се нуждае от най-малък потребителски надзор, а администрирането на данните би трябвало да бъде проведено вътре в приложението ( при нас множеството планове са точно такива). В този случай вършим скелетно приложение в Django, тъй като то има вграден Admin, фантастично потребно нещо. След като един жестоко квалифициран експериментален модел на Django стартира да наподобява на артикул, преглеждаме каква част от този модел се поддава на пренаписване на Go. Тъй като в приложението на Django към този момент има дефинирана конструкция въз основата данни и се схваща по какъв начин наподобяват моделите на данните, е много елементарно да се напише код на Go, който да размени Django. След няколко итерации доближаваме до симбиоза, при която двете половини съжителстват спокойно върху една и съща база данни, а връзката сред тях се реализира посредством най-опростената система за известия. В последна сметка „ шелът “ на Django се трансформира в оркестратор – т.е. той дава отговор за администрирането и извършва тези задания, които по-късно отиват за обработка в региона на приложението, написано на Go. Частта, написана на Go, дава отговор за всичко останало – от потребителските API и крайни точки до бизнес логиката и дилемите за обработка, зараждащи в машинния интерфейс.

Тази симбиоза към момента не ни е подвела и се надяваме, че няма да ни подведе и в бъдеще. Някой ден ще напиша публикация, в която ще обсъдя по-подробно обрисуваната тук архитектура.

Благодаря ви за вниманието!