Езици за програмиране

Съдържание:

• Резюме
  • Проблем
  • Решение
  • Състояние
• Подробности
  • Допускания
  • Ограничения
  • Позиции
  • Аргумент
  • Последици
• Свързани
  • Свързани решения
  • Свързани изисквания
  • Свързани артефакти
  • Свързани принципи
• Бележки

Резюме

Проблем

Трябва да изберем езици за програмиране за нашия софтуер. Имаме две основни нужди: front-end език за програмиране, подходящ за уеб приложения, и back-end език за програмиране, подходящ за сървърни приложения.

Решение

Избираме TypeScript за front-end.

Избираме Rust за back-end.

Състояние

Взето. Открити сме за нови алтернативи, когато се появят.

Подробности

Допускания

Front-end приложенията са типични:

• Типични потребители и взаимодействия

• Типични браузъри и системи

• Типична разработка и внедряване

Front-end приложенията вероятно ще се развиват бързо:

• Искаме да осигурим бърза и лесна разработка, внедряване, итерации и т.н.

• Ценим доказуемостта, като типовата безопасност, и сме съгласни да вложим малко повече работа, за да я постигнем.

• Не се нуждаем от съвместимост с наследени системи.

Back-end приложенията са над типичното:

• Над типичните цели за качество, особено доказуемост, надеждност, сигурност и т.н.

• Над типичните цели за близо до реално време, т.е. не искаме паузи поради garbage collection на виртуалната машина.

• Над типичните цели за функционално програмиране, особено за паралелизация, многоядрена обработка и безопасност на паметта.

Приемаме по-ниска скорост на компилация в полза на безопасност при компилация и скорост по време на изпълнение.

Ограничения

Имаме силно ограничение към езици, използваеми с услугите на основните доставчици на облачни услуги за функции, като Amazon Lambda.

Позиции

Разгледахме тези езици:

• C

• C++

• Clojure

• Elixir

• Erlang

• Elm

• Flow

• Go

• Haskell

• Java

• JavaScript

• Kotlin

• Python

• Ruby

• Rust

• TypeScript

Аргумент

Резюме по език:

• C: отхвърлен заради ниската безопасност; Rust може да направи почти всичко по-добре.

• C++: отхвърлен, защото е бъркотия; Rust може да направи почти всичко по-добре.

• Clojure: отлично моделиране; най-доброто приближение на Lisp; страхотна среда за изпълнение на JVM.

• Elixir: отлична среда за изпълнение, включително внедряемост и паралелизъм; отличен опит за разработчика; относително малка екосистема.

• Erlang: отлична среда за изпълнение, включително внедряемост и паралелизъм; труден опит за разработчика; относително малка екосистема.

• Elm: изглежда много обещаващ; IBM публикува значими казуси с добри резултати; по-малка екосистема.

• Flow: интересно подобрение спрямо JavaScript; разработчиците обаче се отдалечават от него.

• Go: отличен опит за разработчика; отличен паралелизъм; но история от лоши решения, които осакатяват езика.

• Haskell: най-добрият функционален език; по-малка общност от разработчици; не е постигнал достатъчно публикувани успехи в производство.

• Java: отлична среда за изпълнение; отлична екосистема; под средния опит за разработчика.

• JavaScript: най-популярният език досега; най-разпространената екосистема.

• Kotlin: поправя толкова много от Java; отлична подкрепа от JetBrains; добри публикувани случаи на пренасяне от Java към Kotlin.

• Python: най-популярният език за системна администрация; страхотни инструменти за анализи; добри уеб рамки; но изоставен от Google в полза на Go.

• Ruby: най-добрият опит за разработчика досега; най-добрите уеб рамки; най-приятната общност; но много бавен; донякъде труден за пакетиране.

• Rust: най-добрият нов език; акцент върху нулева абстракция; акцент върху паралелизма; има обаче относително малка екосистема; и умишлени ограничения върху някои видове ускорения на компилатора, напр. директният достъп до паметта трябва да е изрично unsafe.

• TypeScript: добавя типове към JavaScript; страхотен транспилатор; нарастващ акцент сред разработчиците върху пренасянето от JavaScript към TypeScript; силна подкрепа от Microsoft.

Решихме, че виртуалните машини имат набор от компромиси, от които не се нуждаем в момента, като допълнителна сложност, която предоставя възможности по време на изпълнение.

Вярваме, че основното ни решение се определя от две междусекторни съображения:

• За най-бърза скорост по време на изпълнение и най-тесен достъп до системата бихме избрали JavaScript и C.

• За почти най-бърза скорост по време на изпълнение и почти най-тесен достъп до системата избираме TypeScript и Rust.

Почетни споменавания заслужават езиците с виртуална машина и уеб рамките, които бихме избрали, ако искахме език с виртуална машина:

• Clojure и Luminus

• Java и Spring

• Elixir и Phoenix

Последици

Front-end разработчиците ще трябва да научат TypeScript. Това вероятно е лесна крива на учене, ако основният опит на разработчика е с JavaScript.

Back-end разработчиците ще трябва да научат Rust. Това вероятно е умерена крива на учене, ако основният опит на разработчика е с C/C++, и трудна крива на учене, ако основният опит на разработчика е с Java, Python, Ruby или подобни езици с управление на паметта.

TypeScript и Rust са относително нови. Това означава, че много инструменти все още нямат документация за тези езици. Например devops конвейерът ще трябва да бъде настроен за тези езици и засега нито един от devops инструментите, които оценяваме, няма примери по подразбиране за тези езици.

Времената за компилация на TypeScript и Rust са доста бавни. Част от това може да се дължи на новостта на езиците. Може да искаме да разгледаме как да смекчим бавните компилации, например чрез компилация при поискване, паралелна компилация и т.н.

Поддръжката на IDE за тези езици все още не е всеобща и все още не е първокласна. Например JetBrains продава IDE PyCharm с първокласна поддръжка за Python, но не продава IDE с първокласна поддръжка за Rust; вместо това JetBrains може да използва добавка за Rust, която осигурява може би 80% от поддръжката на езика Rust спрямо поддръжката на езика Python.

Свързани

Свързани решения

Ще се стремим към избори на екосистемата, които съответстват на тези езици.

Например искаме да изберем IDE, което има добри възможности за тези езици.

Например за нашата front-end уеб рамка по-вероятно е да изберем рамка, която клони към TypeScript (напр. Vue), отколкото рамка, която клони към обикновен JavaScript (напр. React).

Свързани изисквания

Цялата ни верига от инструменти трябва да поддържа тези езици.

Свързани артефакти

Очакваме, че може да експортираме някои тайни в променливи на средата.

Свързани принципи

Мери два пъти, режи веднъж. Даваме приоритет на известна безопасност пред известна скорост.

Времето за изпълнение е по-ценно от времето за компилация. Даваме приоритет на използването от клиентите пред използването от разработчиците.

Бележки

Всякакви бележки тук.