Як почати робити свій внесок у Erlang/OTP сьогодні. Інструкція та поради

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

«In real open source, you have the right to control your own destiny» — Linus Torvalds

Усім привіти! З Вами ​Ukrainian Erlanger 🤘 У цій статті я хочу поговорити про те, як зробити свій внесок у відкритий код Erlang. І ні, я не кажу про якийсь проєкт Erlang, я кажу про внески, які можуть надходити безпосередньо до самого Erlang/OTP.

Мабуть, тут варто зазначити, що спочатку я не думав, що ця стаття вийде настільки великою. Фактично стаття розділена на два основні розділи, кожен із яких має свої підрозділи. Отже, якщо ви не хочете знати, яка за цим стояла історія, і ви просто хочете вивчити команди, які потрібно використовувати для створення та тестування Erlang/OTP, перейдіть прямо до розділу «Побудувати та встановити відкритий вихідний код Erlang». В іншому разі дозвольте мені розповісти вам історію, яка може надихнути вас.

8 жовтня 2021 року ми (Erlang Community) відзначили річницю Open Source Erlang — йому виповнилося 23 роки, про що повідомляє Франческо Чезаріні у Twitter. Erlang пройшов через багато змін і випробувань, і як наслідок, він розрісся до неймовірних масштабів, багато в чому завдяки своїм учасникам з відкритим кодом. Але незважаючи на його розвиток до сьогодні, Erlang досі вимагає більше любові та більшого внеску: вашої любові та вашого внеску ❤️

Не знаю, як у вас, а я з перших днів знайомства з мовою подумав, що хочу бути корисним як для Erlang-мови, так і для Erlang-спільноти. Я міг би підсумувати основні перешкоди для мене в цих двох питаннях:

  • Що саме потрібно для Erlang/OTP?
  • Як саме я можу зробити свій внесок у Erlang/OTP?

Ці питання також є перешкодою для більшості розробників, у яких є геніальні ідеї, але оскільки вони не знають, з чого почати, вони тримають ці ідеї при собі. Я опишу, як я зрозумів, як я можу безпечно зробити свій внесок до Erlang/OTP. Сподіваюся, ця інформація буде корисною іншим розробникам, які також хочуть зробити свій внесок у Erlang/OTP.

So, let’s rock 🤘

Що саме потрібно для Erlang/OTP

Перш за все, вам потрібно виявити сфери, де ви можете допомогти, і ви повинні мати можливість знайти існуючі ідеї чи проблеми. Це необхідно, оскільки основна команда Erlang вже обговорила, погодила або відхилила деякі ідеї. Тому, як правило, не варто їх продовжувати. Щоб зібрати цю інформацію, вам потрібно звернутися до кількох джерел:

Ваш мозок та уява

Звичайно, ви можете взяти перші ідеї прямо зі свого мозку та своєї уяви. Якщо ви вже маєте досвід роботи з деякими мовами та/або з Erlang, вам не складе труднощів винайти неймовірні речі та інтеграції, яких ще не існувало в мові Erlang. Також не забуваймо про покращення: величезна кількість функцій, які ми щодня використовуємо у своїх проєктах, в результаті перетворюються на утиліти, а потім на бібліотеки. Якщо вони досить широко використовуються, вони можуть стати частиною стандартної бібліотеки Erlang. Крім того, не забувайте про наявні функції, підтримувані протоколи, інструменти, загальні та модульні тести, ведення журналів та багато інших моментів в Erlang, де є потреба в більшій любові, яку ви можете надати, якщо захочете, звичайно.

erlangforums.com

Як я згадував раніше, багато чудових ідей постійно обговорюються з основною командою Erlang та зі спільнотою Erlang. Щоб знайти подібні теми, ви повинні принаймні звернути свою увагу на цю тему на форумі: що, на вашу думку, має бути в OTP?

В цій темі люди активно обговорюють майбутній розвиток Erlang, і ви можете знайти там деяких видатних та відомих розробників з різних організацій та Erlang Core Team.

Ще одна тема, на яку слід звернути увагу: чого, на вашу думку, не повинно бути в OTP?

У цій темі також йде жвава дискусія про покращення Erlang, але в дещо іншому напрямку. За словами спільноти, основний репозиторій Erlang потрібно очистити та покращити, видаливши всі непотрібні речі, які розробники не використовують регулярно, або можуть бути винесені в окремі бібліотеки. Мета полягає у тому, щоб значно пришвидшити та полегшити підтримку мови та її бібліотек у майбутньому.

Задачі Erlang в Github

Так, це чудове джерело, щоб знайти існуючі задачі в Erlang. Як ви вже могли помітити, задачі в GitHub позначені мітками. Їх є кілька, але варто звернути увагу на bug, enhancement та help wanted. Ці мітки чітко вказують, для чого були створені ці завдання та як їх обробляє основна команда Erlang. Звичайно, перш ніж братися за будь-яке завдання, ви повинні переконатися, що над ним ще ніхто не працює, і ви чітко розумієте, що вам потрібно зробити для реалізації. Якщо у вас виникли запитання чи сумніви, спільнота Erlang допоможе вам їх вирішити.

Спільнота Erlang

Спільнота Erlang — це фантастична група людей, де ви можете черпати свої ідеї, знаходити нових друзів і наставників, покращувати себе як розробника та багато іншого. У спільноті вас завжди приймуть тепло, і ви завжди знайдете когось, хто готовий допомогти вам із будь-яким питанням. Тут ніхто не буде судити вас за погані ідеї або невдалі спроби щось покращити.

Ось невеликий приклад того, що сталося зі мною. Деякий час тому я почав думати про створення CLI для Mnesia (після того, коли я зможу запустити мінімальну версію, я зроблю все можливе, щоб описати цей інструмент, але це буде в іншій статті). Я зрозумів, що мені потрібна допомога, навіть щоб завершити свою загальну ідею щодо цього проєкту. Тому я розповів Брухо про те, наскільки маленькою, на мою думку, була моя мережа Erlang (тобто я не знав, хто міг би мені допомогти з цим проєктом), і подякував йому за те, що він приділяв свій час для наставництва щодо мене. Він пояснив мені, що «якщо ти шукаєш досить добре, ти завжди знайдеш когось, хто тобі допоможе».

Це правда, бачите: зовсім недавно я не мав уявлення про те, як створювати плагіни для rebar3, не знав, як працювати з AST в Erlang, чи як працювати з yecc та leex, чи як будувати та тестувати Erlang/OTP для локальної розробки. Усе це та ще багато інших речей допомогли мені розширити мій внутрішній світ Erlang/OTP. Різноманітні та екстраординарні зустрічі в спільноті, з людьми, начебто не пов’язаними між собою, допомогли мені знайти правильне рішення, правильний шлях для реалізації певних речей. Як я вже казав раніше, поганих ідей не буває, тому що кожна ідея створює початок наступної. Пам’ятайте: краще мати дурну ідею, ніж не мати ідей взагалі — сміливо діліться ними, розповідайте про них, намагайтеся втілити їх у життя! Ви однозначно знайдете когось, хто захоче принаймні обговорити їх з вами.

Отже, якщо ви досі не є частиною спільноти Erlang, якщо ви досі не приєдналися до Erlang Slack, або якщо ви досі не приєдналися до erlangforums.com, вам варто зробити це якнайшвидше. Ми завжди раді новим людям, і ми готові підтримати вас у будь-якій ситуації. Будь ласка, не соромтеся приєднатися до нас, відрекомендуйтесь, розкажіть нам, що ви думаєте, які проблеми ви відчуваєте у своїх проєктах, що б ви хотіли зробити, і ми зможемо вам допомогти.

Як саме я можу зробити свій внесок у Erlang/OTP

Деякий час тому я створив Pull Request для Erlang/OTP. Цей PR був відносно невеликим і включав виправлення досить старої помилки. Оскільки я чітко розумів, які дані ми отримуємо як вхідні дані, і яку інформацію ми повинні видавати на виході, я вирішив відтворити проблему в окремому файлі локально. Не найкращий підхід. У моєму випадку я б сказав, що це була дещо дурна ідея на перший погляд, але ця ідея насправді привела мене до правильного напрямку.

Після успішного тестування я почувався впевнено, тому вирішив оновити вихідний код Erlang безпосередньо. Я вніс свої зміни до свого fork-репозиторію, потім перевірив, що GitHub Actions пройшли успішно, а вже потім набрався мужності відкрити PR.

Зауважте, що на самому початку я не мав уявлення про те, як локально збирати Erlang/OTP для розробки, про запуск тестів, налагодження тощо. Іншими словами, спочатку я покладався виключно на GitHub Actions, які запускаються на моєму fork після кожних внесених змін.

Перший коментар у запиті на витяг надійшов від Бьорна Густавссона:

«Я думаю, що вам потрібно буде додати тестовий приклад...»

Я не продовжував читати коментар, оскільки мій мозок вже був у колапсі після цих кількох слів 😅 Саме цього я боявся з самого початку. Я не знав, як оновити тести локально, і я міг покладатися виключно на дії GitHub Actions — у свою чергу це означало, що мені доводилося чекати кожного проходу тестів у CI і виправляти проблеми, якщо вони були знайдені ним. Це неймовірно величезна кількість часу, яку я не міг дозволити собі витратити під час розробки чи дослідження якихось невідомих мені областей...

Отже, я пішов у Erlang Slack. Брухо сказав мені попросити допомоги у Лукаса Ларссона.

Оскільки в мене вже була змога познайомитися з Лукасом, коли я співпрацював з Erlang Solutions деякий час тому щодо надання консалтингових послуг з розробки месенджерів на Erlang/OTP, а саме щодо MongooseIM та Ejabberd для кількох клієнтів з різних країн, я написав Лукасу і запитав його про наставництво у цій справі. Він досить швидко відповів і погодився мені допомогти. Як виявилося, Лукас вже працював над новим посібником з розробки, але ще не публікував його у Open Source. Після нашого обговорення та читання додаткової документації виявилося, що побудувати та запустити тести Erlang/OTP локально дуже просто, як ви зможете побачити нижче. Зауважте, що всі приклади виконано на Linux Mint.

Побудувати та встановити відкритий вихідний код Erlang

Ось, як я це зробив:

# Clone created fork
$ git clone https://github.com/vkatsuba/otp.git
# Go to "otp" folder
$ cd otp
# Add upstream of original Erlang source repository
$ git remote add upstream https://github.com/erlang/otp.git
# Create your working branch
$ git checkout -b my-develop-branch

Для того, щоб побудувати вихідний код Erlang/OTP для розробки, вам потрібно переконатися, що у вас вже встановлені такі інструменти:

Тепер вам потрібно буде налаштувати змінні ERL_TOP і PATH у вашому терміналі:

$ export ERL_TOP=$PWD
$ export PATH=$ERL_TOP/bin:$PAT

А потім ви можете запустити команди для будування вихідного коду Erlang/OTP та побудування тестів (це може зайняти деякий час 😉):

$ ./otp_build setup -a --prefix=$PWD/tests_install
$ make install
% ./otp_build tests
$ export PATH=$PWD/tests_install/bin:$PATH

На цьому етапі ви вже можете запустити вихідний код Erlang/OTP, як вказано нижче:

$ $ERL_TOP/tests_install/bin/erl

Гарна робота! Тепер ви можете запустити останню версію відкритого вихідного коду Erlang на своєму комп’ютері (зверніть свою увагу на те, що під час написання цієї статті остання офіційна версія Erlang/OTP була 24, тоді коли ми бачимо у терміналі OTP 25, який досі знаходиться у стадії розробки).

Додавання нового модуля та запуск модульних тестів

Тоді давайте спробуємо створити простий модульний тест. Наприклад, я створю модуль у GitHub папці за шляхом otp/lib/eunit/src/contribution_tests.erl:

%%% @doc Unit test for a contribution to Erlang Open Source code

-module(contribution_tests).

-include("eunit.hrl").

simple_test() ->
   ?assertEqual(2, 1 + 1).simple_two_test() ->
   ?assertEqual(3, 1 + 2).

Та додайте шлях до нового модуля в /otp/lib/eunit/src/Makefile:

...
SOURCES= \
   contribution_tests.erl \
   eunit_striptests.erl  \
   ...
…

Тепер давайте спробуємо створити вихідний код, завантажимо оболонку Erlang і запустимо наші нові модульні тести:

$ make install
$ $ERL_TOP/tests_install/bin/erl
Erlang/OTP 25 [DEVELOPMENT] [erts-12.1.5] [source-32d401265d] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]Eshell V12.1.5  (abort with ^G)
1> eunit:test(contribution_tests).
 2 tests passed.
ok

Тепер ми знаємо, як додавати нові модулі, створювати та запускати для них модульні тести.

Git commit & Git push зміни коду

Давайте подивимося на статус git нашого репо:

$ git status
...
Changed:      lib/eunit/src/Makefile
...
Added:
...
erts/test/otp_SUITE_data/otp_version_tickets
erts/test/otp_SUITE_data/otp_versions.table
lib/compiler/test/bs_bincomp_r24_SUITE.erl
lib/compiler/test/bs_construct_r24_SUITE.erl
lib/compiler/test/bs_utf_r24_SUITE.erl
lib/compiler/test/fun_r23_SUITE.erl
lib/eunit/src/contribution_tests.erl
tests_install/

Цього разу ми повинні додати лише lib/eunit/src/Makefile і lib/eunit/src/contribution_tests.erl, зафіксувати, а потім опублікувати наші зміни!

Але що, якщо ваша зміна була не просто додаванням нового модуля, а замість цього ви застосували зміни до багатьох існуючих файлів? У такому разі ви можете застосувати таку команду. Потрібно лише звернути увагу на таке попередження: ця команда скине всі додані файли, зберігаючи лише змінені вами файли.

$ git clean -xfdq
$ git status
$ git add .

Перш ніж створювати коміти, я рекомендую прочитати Erlang Wiki: Написання хороших повідомлень про коміти. Ця вікі-сторінка надає корисну інформацію про створення видатного коміту, а також про те, чого саме очікує команда Erlang Core у повідомленнях комітів і чому.

Загальні тести

Подібно до попередньої частини, де ми працювали з eunit, давайте спробуємо додати новий модуль, створити для нього загальні тести, побудувати та запустити усе це.

Давайте додамо модуль у /otp/lib/dialyzer/src/contribution_example.erl:

%% Module for a new contribution to Erlang Open Source code

-module(contribution_example).

-export([plus/2]).

-spec plus(integer(), integer()) -> integer().
plus(X, Y) ->
   X + Y.

Як і в попередньому розділі, нам також потрібно оновити Makefile, але зараз це треба зробити вже у otp/lib/dialyzer/src/Makefile:

....
MODULES = \
   contribution_example \
   cerl_prettypr \
   ...
...

Потім нам потрібно додати нові загальні тести для нашого нового модуля. Давайте додамо новий набір за шляхом otp/lib/dialyzer/test/contribution_example_SUITE.erl:

%% Module for Common Test for contribution Erlang Open Source code

-module(contribution_example_SUITE).

-include_lib("common_test/include/ct.hrl").

%% Test server specific exports

-export([all/0, groups/0,init_per_suite/1, end_per_suite/1,
  init_per_group/2,end_per_group/2]).

-export([init_per_testcase/2, end_per_testcase/2]).

%% Test cases must be exported.

-export([test_new_module/1]).

all() ->
	[test_new_module].

groups() ->
	[].

init_per_suite(Config) ->
	Config.

end_per_suite(_Config) ->
	ok.

init_per_group(_GroupName, Config) ->
	Config.

end_per_group(_GroupName, Config) ->
	Config.

init_per_testcase(_Case, Config) ->
	Config.

end_per_testcase(_Case, _Config) ->
	ok.

%%%
%%% Test cases start here.
%%%

test_new_module(doc) ->
	["Test new module"];
test_new_module(Config) when is_list(Config) ->
	2 = contribution_example:plus(1, 1).

І, звичайно, нам потрібно додати шлях до цього нового загального набору тестів, але цього разу у папці самих тестів otp/lib/dialyzer/test/Makefile:

...
AUXILIARY_FILES=\
   ...
   erl_types_SUITE.erl \
   contribution_example_SUITE.erl \
   ...
...

Вам потрібно знати дещо про common-тести: щоб запустити їх правильно, вам потрібно буде встановити фреймворк ts, який вже знаходиться у Erlang/OTP. Цей фреймворк допоможе запустити тести. Щоб підготувати, встановити ts фреймворк та запустити нові common-тести, вам потрібно виконати наступні команди у вашому терміналі:

$ export ERL_TOP=$PWD
$ export PATH=$ERL_TOP/bin:$PATH
$ ./otp_build setup -a --prefix=$PWD/tests_install
$ make install
$ ./otp_build tests
$ export PATH=$PWD/tests_install/bin:$PATH
$ cd release/tests/test_server
$ $ERL_TOP/tests_install/bin/erl

Остання команда запустить оболонку Erlang. Тепер вам потрібно встановити ts і запустити тестовий модуль:

Erlang/OTP 25 [DEVELOPMENT] [erts-12.1.5] [source-32d401265d] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]

Eshell V12.1.5  (abort with ^G)
1> ts:install().
2> ts:run(dialyzer, contribution_example_SUITE, [batch]).

Результат повинен виглядати так:

....
Common Test starting (cwd is /home/vk/otp/release/tests/dialyzer_test)

Common Test: Running make in test directories...
Recompile: contribution_example_SUITE
...
TEST INFO: 1 test(s), 1 case(s) in 1 suite(s)

Testing tests.dialyzer_test.contribution_example_SUITE: Starting test, 1 test cases
Testing tests.dialyzer_test.contribution_example_SUITE: TEST COMPLETE, 1 ok, 0 failed of 1 test cases

...
done

Наші нові загальні тести пройшли!

Отже, як ви щойно бачили, щоб запустити нові common-тести за допомогою фреймворку ts, вам потрібно виконати: ts:run(Application, CommonTest, [batch]).

Мабуть, ви вже помітили, що недостатньо додати модуль з логікою і модуль з тестами. Вам також потрібно змінити Makefile в src і в папці test. Можливо, варто також зазначити, що Makefile іноді розміщується в кореневих папках деяких Erlang/OTP додатків. Наприклад, для eunit файл Makefile розміщується в lib/eunit/Makefile, але у випадку діалізатора він знаходиться для тестів в otp/lib/dialyzer/test/Makefile, а для основних модулів в otp/lib/dialyzer/src/Makefile. Тому будьте дуже обережні і завжди шукайте Makefile як у кореневій папці, так і у підтеках.

Статичний аналіз

Для ситуації, коли ви захочете виконати запуск статичного аналізу Erlang/OTP, вам потрібно буде знаходитися у корені папки OTP та виконати наступні команди make:

$ make xmllint
$ make dialyzer
$ make format-check

Та якщо вам знадобиться побудувати документацію Erlang/OTP після змін в ній, вам достатньо виконати:

$ make release_docs

Резюме

У цій статті ми дізналися:

  • де ми можемо отримати ідеї про Erlang/OTP;
  • хто може нам допомогти і де знайти цих людей;
  • що робити, якщо застрягли на будь-якому етапі;
  • як створити та запустити нашу власну версію Erlang/OTP;
  • як додати нові модулі в код Erlang/OTP;
  • як створювати та запускати модульні тести та загальні тести в Erlang/OTP;
  • як ми можемо зробити статичний аналіз коду Erlang/OTP.

Тепер ви готові зробити свій перший надзвичайний внесок у саму мову Ерланг з усіма цими знаннями!

Посилання:

Особлива подяка

  • Дякую Вам, Брухо, за Ваше фантастичне наставництво та підтримку! 🚀
  • Дякую, Лукасе, за Ваше чудове наставництво та чудовий посібник із локального будівництва та тестування Erlang/OTP та іншої видатної документації, а також за Ваші чудові комунікативні навички! 🤘
  • Дякую Вам, Бьорн Густавссон, за Ваші неймовірно швидкі реакції та за все те, що Ви робите для спільноти Erlang/OTP! 💪
👍ПодобаєтьсяСподобалось4
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
на акторів

его превосходительство любил весёлых птис и брал под покровительство хорошеньких актрис (к)

5 лет кодил на эрланге. Но сейчас говорю — в сад.
Очень не люблю Go, но любителей эрланга отправляю в первую очередь к нему.
Ибо воистину.

¯\_(ツ)_/¯

А чому?

1. Зріст потужности компʼютерів практично зупинився. За процесорами маємо ~10% на рік. Ціна DRAM ходить в одному вузькому коридорі з 2012, швидкість найгіршого випадку не збільшується. Ще й поточна криза. У таких умовах все що не має хоча б високорівневого JIT має скорочуватись. Erlang за якістю виконання коду на рівні Python, тобто сам по собі в 20-100 раз повільніше компільованого на рівні C, C++. Але він значно складніший, писати в функціональному стилі масово незвично і незручно.

У нього, по суті, є єдина висока перевага — можливість заміни коду на ходу. Але з сучасними підходами у стилі k8s/etc. ціього ніхто не використовує.

2. Erlang принципово не тримає деякі види задач, як клієнт або проксі під високим навантаженням. Тільки як сервер без якісного контролю потоку. Причина — нескасовний забобон на керування вхідним потоком внутрішнього процесу. Є деякі часткові оптимізації, але нормального рішення нема (хоча просять з ~2008), автори не розуміють. Штатні «євангелісти» на це кажуть «ви не вмієте писати на Erlang» замість щоб визнати ваду. Команда авторів, схоже, ще ментально у XX столітті.

І на чому зараз?

На одній з попередніх робіт був випадок — побачив що нічого не зробити, взяв тестовий код на Python, перегнав 1:1 в C++ за три дні... і всіх задовольнило.

JIT додався в останній версії. Erlang має специфічний синтаксис але це не означає що саме через це погано на ньому писати, можна погано писати будь-якою мовою. Якщо не достатньо потужності на одному сервері, немає жодних проблем взяти N серверів і об’єднати їх в кластер, але найпростіші сервери з 4-х ядрами і 16 гігабайт пам’яті витримували навантаження в 50к запитів на секунду. Так, однозначно все залежить від архітектури та підходу до вирішення, я бачив проекти, які живуть у продакшені більше п’яти років і після першого навантажувального тестування за допомогою Tsung продакшен лягав спати але це була не проблема Erlang/OTP, а була проблема раробників, які не врахували величезну кількість факторів. Я не кажу, що Erlang/OTP це панацея від усіх бід, але він зайняв свою нішу досить давно і досі рівних йому немає — навіть якщо є схожі технології, реалізувати BEAM і перенести OTP — буде неймовірно трудомісткою роботою. Але в будь-якому випадку це обговорення заходить далеко за рамки цієї статті. Мета цієї статті не переконати спільноту DOU писати на Erlang або на іншій мові, а поділитися знаннями з Erlang розробниками з України, щоб вони не були скуті на випадок, якщо їм потрібно буде внести якісь зміни в ядро Erlang.

JIT додався в останній версії.

Чув про плани. Значить, до нормального стану років 5. Якщо повезе.
І принципово динамічний характер мови не дасть використати багато оптимізацій.

Erlang має специфічний синтаксис але це не означає що саме через це погано на ньому писати, можна погано писати будь-якою мовою.

До чого тут синтаксис? Синтаксис якраз нормальний. Семантика дає невиліковну специфіку.

Якщо не достатньо потужності на одному сервері, немає жодних проблем взяти N серверів і об’єднати їх в кластер

Як починають казати про «жодних проблем взяти N серверів», все зрозуміло. Не в гарному сенсі.

але найпростіші сервери з 4-х ядрами і 16 гігабайт пам’яті витримували навантаження в 50к запитів на секунду.

Я не просто так казав про різницю між ролями сервера і іншого.

навіть якщо є схожі технології, реалізувати BEAM і перенести OTP — буде неймовірно трудомісткою роботою.

І не треба таке переносити.

а поділитися знаннями з Erlang розробниками з України, щоб вони не були скуті на випадок, якщо їм потрібно буде внести якісь зміни в ядро Erlang.

Хто з них коли і для чого буде вносити зміни в ядро??

Навіть у найбільш дивному випадку максимум що я вважаю реальним це написати свої NIF. Інше — імовірність як падіння метеоріту.

Значить, до нормального стану років 5

Я не думаю, що це можна оцінити так при цьому ніколи не використавши його.

Як починають казати про «жодних проблем взяти N серверів», все зрозуміло. Не в гарному сенсі.

Будь-який сервіс рано чи пізно потребує масштабованості. Знов-таки незалежно від мови програмування та технології.

І не треба таке переносити.

У такому разі не скоро з’явиться технологія, яка зможе змагатися з Erlang/OTP у його ніші.

Хто з них коли і для чого буде вносити зміни в ядро??

Це залежить від того, чи поверхово використовується Erlang в проекті або на більш глибокому рівні. Команди WhatsApp, Klarna і багато інших, включаючи мою команду, вносять час від часу зміни пов’язані як з усуненням багів так і з поліпшенням існуючого функціоналу. Невеликий приклад прояви подібної проблеми у проекті як github.com/...​ker-erlang-otp/issues/332 розробники з наявністю цих знань зможуть без особливих проблем та з упевненістю як надати виправлення для розгляду до Erlang Core Team так і зможуть використати свій fork для будь-яких цілей при цьому не чекаючи нової версії з їх виправленням.

Дуже хороша доповідь від компанії CISCO www.youtube.com/watch?v=qmtpszspEaI про те як за допомогою Erlang/OTP вони контролюють 90% інтернет трафіку і не тільки — рекомендую подивитися.

за допомогою Erlang/OTP вони контролюють 90% інтернет трафіку і не тільки

А NVIDIA (Mellanox) — за допомогою С, ніби. Та й домашні роутери на OpenWRT здебільшого.

Звичайно, я і не кажу, що інших рішень по контролю інтернет трафіку не існує 🙃. Це просто був один із багатьох прикладів про те як відома компанія використовує технологію за призначенням і які плюси від цього отримує.

То ж питання — які саме там плюси. Бо інші (та усі мабуть інші) використовують інакші технології з інакшими плюсами. І якось успішні на ринку. Себто, Ваші плюси не такі вже й плюси, коли порівнювати з чужими плюсами.

Це залежить від того, хто переслідує які цілі. Багато компаній у тому числі виробники машин використовують продукти написані на Erlang саме для мобільних інтернет мереж та IoT — компанія CISCO не єдина компанія у своєму роді хто це вже робить. У разі питання — які саме плюси? Це залежить від того, які проблеми необхідно вирішити. Давайте наприклад візьмемо реалізацію ААА(Authentication, Authorization, Accounting) — для її реалізації необхідно використовувати або RADIUS або Diameter або оба протоколи. Також не забуватимемо про ASN.1 який також добре та активно використовують у подібних проектах(в даному контексті я не говорю про 5G 🙃). І так, якщо ми подивимося на кожен з пунктів окремо, ми можемо звернути увагу на те, що Diameter та ASN.1 вже доступний з-під коробки Erlang/OTP і звичайно підтримується Erlang Core Team — тобто для ААА нам уже не потрібно винаходити велосипед і переживати про підтримку, тому що це вже є і добре протестовано, а також потенційному клієнту не потрібно буде витрачати додатковий бюджет на реалізацію того, що вже є і працює роками. Давайте подивимося на RADIUS протокол — цей протокол не реалізовано у Erlang/OTP — але це не завадило моїй команді протягом тижня реалізувати бібліотеку яка повністю його підтримає. Іншими словами я б сказав що основною перевагою для інтернет мереж є те, що багато речей вже підтримуються з коробки, а якщо немає підтримки, дуже швидко можна реалізувати підтримку того чи іншого протоколу або іншого функціоналу у стислі строки(про що і розповідається у поточній статті). Звичайно для інтернет мереж ми не всюди використовуємо Erlang/OTP. Є ряд речей, які написані на С або на С++ або на Golang. Якщо стоїть завдання реалізувати sidecar для k8s — звичайно потрібно вибирати Golang. Іншими словами я б сказав, що все залежить від поставлених завдань і цілей, сроків та бюджету і не варто шукати завдання для технології, я б сказав, що потрібно шукати технологію в залежності від поставленого завдання.

У такому разі не скоро з’явиться технологія, яка зможе змагатися з Erlang/OTP у його ніші.

Akka?

Так Akka — я мав наувазі что якщо не думати про перенос BEAM та OTP аналогу не буде. У своєму інтерв’ю Франческо Чизаріні gotopia.tech/...​-solving-scaling-30-years розповідає про те як він відчув почуття дежавю коли познайомився з © original Java white paper:

It’s almost like, you know when I was reading your original Java white paper, I had a sense of deja vu, which was a virtual machine and a concurrency model built-in memory management and a garbage collector. So this was in JVM, and I was working on the Erlang virtual machine at the time. But I think there’s still a big difference between the Java Virtual Machine and the BEAM today because to bring Akka, you know, to the JVM, you wanna had to emulate a lot of the semantics and a lot of the functionality which exists in the BEAM, which a BEAM is highly optimized for, which doesn’t exist in the JVM.

Але так — свого роду саме Akka може бути конкурентом.

s.dou.ua/...​626289121642761808766.png

омг там русский гит сирёзно штоле а что так тоже можно было?

Это же линукс минт, там когда установил на русском, очень сложно потом всё переделать на английский.

В мене колись був український.

Але наразі з метою уніфікації в межах команди на всіх ноутбуках англійська убунта.

А Namdak Tonpa в камєнти вийде?

Якщо йому буде також цікава стаття як і Вам — все можливо 🙃.

Підписатись на коментарі