ພາສາການຂຽນໂປຣແກຣມ

ສາລະບານ:

• ບົດສະຫຼຸບ
  • ບັນຫາ
  • ການຕັດສິນໃຈ
  • ສະຖານະ
• ລາຍລະອຽດ
  • ສົມມຸດຕິຖານ
  • ຂໍ້ຈຳກັດ
  • ຈຸດຢືນ
  • ຂໍ້ໂຕ້ແຍ້ງ
  • ຜົນໄດ້ຮັບ
• ທີ່ກ່ຽວຂ້ອງ
  • ການຕັດສິນໃຈທີ່ກ່ຽວຂ້ອງ
  • ຄວາມຕ້ອງການທີ່ກ່ຽວຂ້ອງ
  • ຜະລິດຕະພັນທີ່ກ່ຽວຂ້ອງ
  • ຫຼັກການທີ່ກ່ຽວຂ້ອງ
• ໝາຍເຫດ

ບົດສະຫຼຸບ

ບັນຫາ

ພວກເຮົາຕ້ອງເລືອກພາສາການຂຽນໂປຣແກຣມສຳລັບຊອບແວຂອງພວກເຮົາ. ພວກເຮົາມີສອງຄວາມຕ້ອງການຫຼັກ: ພາສາການຂຽນໂປຣແກຣມຝັ່ງໜ້າທີ່ເໝາະສຳລັບເວັບແອັບພລິເຄຊັນ ແລະ ພາສາການຂຽນໂປຣແກຣມຝັ່ງຫຼັງທີ່ເໝາະສຳລັບແອັບພລິເຄຊັນເຊີບເວີ.

ການຕັດສິນໃຈ

ພວກເຮົາເລືອກ TypeScript ສຳລັບຝັ່ງໜ້າ.

ພວກເຮົາເລືອກ Rust ສຳລັບຝັ່ງຫຼັງ.

ສະຖານະ

ຕັດສິນໃຈແລ້ວ. ພວກເຮົາເປີດຮັບທາງເລືອກໃໝ່ເມື່ອມີອອກມາ.

ລາຍລະອຽດ

ສົມມຸດຕິຖານ

ແອັບພລິເຄຊັນຝັ່ງໜ້າເປັນແບບທົ່ວໄປ:

• ຜູ້ໃຊ້ ແລະ ການໂຕ້ຕອບທົ່ວໄປ

• ບຣາວເຊີ ແລະ ລະບົບທົ່ວໄປ

• ການພັດທະນາ ແລະ ການຕິດຕັ້ງທົ່ວໄປ

ແອັບພລິເຄຊັນຝັ່ງໜ້າມີແນວໂນ້ມພັດທະນາຢ່າງວ່ອງໄວ:

• ພວກເຮົາຢາກຮັບປະກັນການພັດທະນາ, ການຕິດຕັ້ງ, ການວົນຊ້ຳ ແລະ ອື່ນໆ ທີ່ໄວ ແລະ ງ່າຍ.

• ພວກເຮົາໃຫ້ຄຸນຄ່າກັບການພິສູດໄດ້ ເຊັ່ນ ຄວາມປອດໄພຂອງປະເພດ ແລະ ພວກເຮົາຍອມເຮັດວຽກເພີ່ມເລັກນ້ອຍເພື່ອບັນລຸມັນ.

• ພວກເຮົາບໍ່ຕ້ອງການຄວາມເຂົ້າກັນໄດ້ກັບລະບົບເກົ່າ.

ແອັບພລິເຄຊັນຝັ່ງຫຼັງມີມາດຕະຖານສູງກວ່າທົ່ວໄປ:

• ເປົ້າໝາຍສູງກວ່າທົ່ວໄປດ້ານຄຸນນະພາບ ໂດຍສະເພາະການພິສູດໄດ້, ຄວາມເຊື່ອຖືໄດ້, ຄວາມປອດໄພ ແລະ ອື່ນໆ.

• ເປົ້າໝາຍສູງກວ່າທົ່ວໄປດ້ານເກືອບເວລາຈິງ ນັ້ນຄື ພວກເຮົາບໍ່ຕ້ອງການການຢຸດຊົ່ວຄາວຍ້ອນ 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.

ພວກເຮົາຕັດສິນໃຈວ່າ VM ມີຊຸດຂໍ້ແລກປ່ຽນທີ່ພວກເຮົາບໍ່ຕ້ອງການໃນຕອນນີ້ ເຊັ່ນ ຄວາມຊັບຊ້ອນເພີ່ມເຕີມທີ່ໃຫ້ຄວາມສາມາດໃນເວລາດຳເນີນງານ.

ພວກເຮົາເຊື່ອວ່າການຕັດສິນໃຈຫຼັກຂອງພວກເຮົາຖືກຂັບເຄື່ອນດ້ວຍສອງຄວາມກັງວົນທີ່ຂ້າມຫຼາຍສ່ວນ:

• ສຳລັບຄວາມໄວໃນເວລາດຳເນີນງານທີ່ໄວທີ່ສຸດ ແລະ ການເຂົ້າເຖິງລະບົບທີ່ແໜ້ນທີ່ສຸດ ພວກເຮົາຈະເລືອກ JavaScript ແລະ C.

• ສຳລັບຄວາມໄວໃນເວລາດຳເນີນງານທີ່ເກືອບໄວທີ່ສຸດ ແລະ ການເຂົ້າເຖິງລະບົບທີ່ເກືອບແໜ້ນທີ່ສຸດ ພວກເຮົາເລືອກ TypeScript ແລະ Rust.

ການກ່າວເຖິງກຽດຕິຍົດໄປຫາພາສາ VM ແລະ ເຟຣມເວີກເວັບທີ່ພວກເຮົາຈະເລືອກຖ້າພວກເຮົາຕ້ອງການພາສາ VM:

• Clojure ແລະ Luminus

• Java ແລະ Spring

• Elixir ແລະ Phoenix

ຜົນໄດ້ຮັບ

ນັກພັດທະນາຝັ່ງໜ້າຈະຕ້ອງຮຽນ TypeScript. ນີ້ອາດເປັນເສັ້ນໂຄ້ງການຮຽນຮູ້ທີ່ງ່າຍ ຖ້າປະສົບການຫຼັກຂອງນັກພັດທະນາແມ່ນການໃຊ້ JavaScript.

ນັກພັດທະນາຝັ່ງຫຼັງຈະຕ້ອງຮຽນ Rust. ນີ້ອາດເປັນເສັ້ນໂຄ້ງການຮຽນຮູ້ປານກາງ ຖ້າປະສົບການຫຼັກຂອງນັກພັດທະນາແມ່ນການໃຊ້ C/C++ ແລະ ເປັນເສັ້ນໂຄ້ງການຮຽນຮູ້ທີ່ຍາກ ຖ້າປະສົບການຫຼັກຂອງນັກພັດທະນາແມ່ນການໃຊ້ Java, Python, Ruby ຫຼື ພາສາທີ່ມີການຈັດການໜ່ວຍຄວາມຈຳທີ່ຄ້າຍກັນ.

TypeScript ແລະ Rust ທັງສອງຄ່ອນຂ້າງໃໝ່. ນັ້ນໝາຍຄວາມວ່າເຄື່ອງມືຫຼາຍຢ່າງຍັງບໍ່ມີເອກະສານສຳລັບພາສາເຫຼົ່ານີ້. ຕົວຢ່າງ ທໍ່ devops ຈະຕ້ອງຖືກຕັ້ງຄ່າສຳລັບພາສາເຫຼົ່ານີ້ ແລະ ມາຮອດຕອນນີ້ ບໍ່ມີເຄື່ອງມື devops ໃດທີ່ພວກເຮົາກຳລັງປະເມີນມີຕົວຢ່າງເລີ່ມຕົ້ນສຳລັບພາສາເຫຼົ່ານີ້.

ເວລາຄອມໄພລ໌ຂອງ TypeScript ແລະ Rust ຊ້າຫຼາຍ. ສ່ວນໜຶ່ງຂອງສິ່ງນີ້ອາດເປັນຍ້ອນຄວາມໃໝ່ຂອງພາສາ. ພວກເຮົາອາດຕ້ອງເບິ່ງວິທີບັນເທົາເວລາຄອມໄພລ໌ທີ່ຊ້າ ເຊັ່ນ ໂດຍການຄອມໄພລ໌ຕາມຄວາມຕ້ອງການ, ການຄອມໄພລ໌ພ້ອມກັນ ແລະ ອື່ນໆ.

ການສະໜັບສະໜູນ IDE ສຳລັບພາສາເຫຼົ່ານີ້ຍັງບໍ່ແຜ່ຫຼາຍ ແລະ ຍັງບໍ່ເປັນຊັ້ນໜຶ່ງ. ຕົວຢ່າງ JetBrains ຂາຍ IDE PyCharm ເພື່ອການສະໜັບສະໜູນ Python ຊັ້ນໜຶ່ງ ແຕ່ບໍ່ຂາຍ IDE ທີ່ມີການສະໜັບສະໜູນ Rust ຊັ້ນໜຶ່ງ; ແທນທີ່ຈະເປັນແນວນັ້ນ JetBrains ສາມາດໃຊ້ປລັກອິນ Rust ທີ່ໃຫ້ການສະໜັບສະໜູນພາສາ Rust ປະມານ 80% ເມື່ອທຽບກັບການສະໜັບສະໜູນພາສາ Python.

ທີ່ກ່ຽວຂ້ອງ

ການຕັດສິນໃຈທີ່ກ່ຽວຂ້ອງ

ພວກເຮົາຈະມຸ່ງໄປສູ່ທາງເລືອກລະບົບນິເວດທີ່ສອດຄ່ອງກັບພາສາເຫຼົ່ານີ້.

ຕົວຢ່າງ ພວກເຮົາຢາກເລືອກ IDE ທີ່ມີຄວາມສາມາດດີສຳລັບພາສາເຫຼົ່ານີ້.

ຕົວຢ່າງ ສຳລັບເຟຣມເວີກເວັບຝັ່ງໜ້າຂອງພວກເຮົາ ພວກເຮົາມີແນວໂນ້ມຈະຕັດສິນໃຈເລືອກເຟຣມເວີກທີ່ມຸ່ງໄປທາງ TypeScript (ເຊັ່ນ Vue) ຫຼາຍກວ່າເຟຣມເວີກທີ່ມຸ່ງໄປທາງ JavaScript ທຳມະດາ (ເຊັ່ນ React).

ຄວາມຕ້ອງການທີ່ກ່ຽວຂ້ອງ

ຊຸດເຄື່ອງມືທັງໝົດຂອງພວກເຮົາຕ້ອງຮອງຮັບພາສາເຫຼົ່ານີ້.

ຜະລິດຕະພັນທີ່ກ່ຽວຂ້ອງ

ພວກເຮົາຄາດວ່າພວກເຮົາອາດສົ່ງອອກຂໍ້ມູນລັບບາງຢ່າງໄປເປັນຕົວແປສະພາບແວດລ້ອມ.

ຫຼັກການທີ່ກ່ຽວຂ້ອງ

ວັດສອງເທື່ອ ຕັດເທື່ອດຽວ. ພວກເຮົາໃຫ້ບູລິມະສິດກັບຄວາມປອດໄພບາງຢ່າງຫຼາຍກວ່າຄວາມໄວບາງຢ່າງ.

ເວລາດຳເນີນງານມີຄ່າກວ່າເວລາຄອມໄພລ໌. ພວກເຮົາໃຫ້ບູລິມະສິດກັບການໃຊ້ງານຂອງລູກຄ້າຫຼາຍກວ່າການໃຊ້ງານຂອງນັກພັດທະນາ.

ໝາຍເຫດ

ໝາຍເຫດໃດໆໃສ່ຢູ່ນີ້.