JavaScript

ข้อจำกัดประการสำคัญของ JavaScript คือการไม่กำหนดชนิดของตัวแปร (type) แบบตายตัว (static typing) เมื่อ JavaScript ได้รับความนิยมเพิ่มขึ้นเรื่อยๆ จึงมีคนพยายามแก้ปัญหานี้ด้วยการประดิษฐ์ภาษาหรือเครื่องมือใหม่ๆ ที่เป็น JavaScript แบบมี type เข้ามา (เช่น TypeScript, Closure Compiler หรือ Flow) เพื่อจัดระเบียบการเขียนโค้ดให้มีโครงสร้างมากขึ้น

แนวทางของภาษาแบบ TypeScript คือให้มนุษย์เขียนโค้ดด้วยภาษาใหม่ที่มีระเบียบขึ้น จากนั้นใช้เครื่องมือ "แปลง" (ในที่นี้คือ transpiler) ภาษาใหม่กลับมาเป็น JavaScript อีกทีหนึ่ง

กรณีของ TypeScript ที่มีตัวแปรแบบ static type จึงต้องแปลงมาเป็น JavaScript ที่ไม่มี type ซึ่งวิธีการแปลงมักอยู่ในรูปการเปลี่ยนชนิดตัวแปรเป็นคอมเมนต์

ถึงแม้แนวทางนี้ในปัจจุบันมีเครื่องมือรองรับมากมาย แต่ก็ยังมีความไม่สะดวกของการแปลงโค้ด และความไม่ตรงไปตรงมาของการเขียนโค้ดอยู่บ้าง

ไมโครซอฟท์ในฐานะผู้สร้างภาษา TypeScript จึงมีไอเดียใหม่ เสนอแก้สเปกของ JavaScript ให้ "มองข้าม" การกำหนดชนิดของตัวแปรของ TypeScript เพื่อจะได้ไม่ต้องมีกระบวนการแปลงโค้ดอีกต่อไป!

ตัวอย่างการแปลง TypeScript เป็น JavaScript ในปัจจุบัน ที่นำข้อมูลชนิดตัวแปรมาใส่ไว้ในคอมเมนต์ (ภาพบน) และข้อเสนอใหม่คือ เราสามารถระบุ type ลงไปใน JavaScript ได้เลย (ภาพล่าง)

สิ่งที่เกิดขึ้นคือ โปรแกรมเมอร์สามารถเขียนโค้ดด้วย syntax แบบ TypeScript เหมือนเดิม รันด้วยคอมไพเลอร์ TypeScript ก็ทำงานได้เหมือนเดิม แต่สามารถนำโค้ดเดียวกันไปคอมไพล์ด้วยรันไทม์/คอมไพเลอร์ของ JavaScript (เช่น เบราว์เซอร์หรือ V8 engine) ได้ทันที โดยรันไทม์ JavaScript จะมองข้าม syntax เหล่านี้ไป

ข้อเสนอนี้จำเป็นต้องปรับแก้ syntax ของ JavaScript เล็กน้อย เช่น เพิ่ม modifier ตัว "?" เข้ามาด้วย (รายละเอียดข้อเสนอ) ซึ่งทีมของไมโครซอฟท์จะต้องเสนอไปยังคณะกรรมการ ECMAScript ในฐานะผู้กำหนดสเปกของ JavaScript ในที่ประชุมกรรมการเดือนมีนาคมนี้

ข้อเสนอของไมโครซอฟท์สร้างการถกเถียงอย่างมากในโลก JavaScript (รายละเอียด) มีทั้งฝ่ายที่สนับสนุนและคัดค้าน และตอนนี้ยังไม่มีข้อสรุปว่าคณะกรรมการ ECMAScript มีแนวโน้มจะตอบรับแค่ไหน

ที่มา - Microsoft

Hiring! บริษัทที่น่าสนใจ

Carmen Software company cover
Carmen Software
Hotel Financial Solutions
Next Innovation (Thailand) Co., Ltd. company cover
Next Innovation (Thailand) Co., Ltd.
We are web design with consulting & engineering services driven the future stronger and flexibility.
KKP Dime company cover
KKP Dime
KKP Dime บริษัทในเครือเกียรตินาคินภัทร
Kiatnakin Phatra Financial Group company cover
Kiatnakin Phatra Financial Group
Financial Service
Fastwork Technologies company cover
Fastwork Technologies
Fastwork.co เว็บไซต์ที่รวบรวม ฟรีแลนซ์ มืออาชีพจากหลากหลายสายงานไว้ในที่เดียวกัน
Thoughtworks Thailand company cover
Thoughtworks Thailand
Thoughtworks เป็นบริษัทที่ปรึกษาด้านเทคโนโยลีระดับโลกที่คว้า Great Place to Work 3 ปีซ้อน
Iron Software company cover
Iron Software
Iron Software is an American company providing a suite of .NET libraries by engineer for engineers.
CLEVERSE company cover
CLEVERSE
Cleverse is a Venture Builder. Our team builds several tech companies.
Nipa Cloud company cover
Nipa Cloud
#1 OpenStack cloud provider in Thailand with our own data center and software platform.
Bangmod Enterprise company cover
Bangmod Enterprise
The leader in Cloud Server and Hosting in Thailand.
CIMB THAI Bank company cover
CIMB THAI Bank
MOVING FORWARD WITH YOU - CIMB is the leading ASEAN Bank
Bangkok Bank company cover
Bangkok Bank
Bangkok Bank is one of Southeast Asia's largest regional banks, a market leader in business banking
MuvMi (Urban Mobility Tech Co.,Ltd.) company cover
MuvMi (Urban Mobility Tech Co.,Ltd.)
Shape the future of urban mobility towards affordable, clean, and safe solutions
T.N. Digital Solution Co., Ltd. company cover
T.N. Digital Solution Co., Ltd.
TNDS has been involving in every first move of banking’s major digital transformation.
KBTG - KASIKORN Business-Technology Group company cover
KBTG - KASIKORN Business-Technology Group
KBTG - "The Technology Company for Digital Business Innovation"
Siam Commercial Bank Public Company Limited company cover
Siam Commercial Bank Public Company Limited
"Let's start a brighter career future together"
Icon Framework co.,Ltd. company cover
Icon Framework co.,Ltd.
Global Standard Platform for Real Estate แพลตฟอร์มสำหรับธุรกิจอสังหาริมทรัพย์ครบวงจร มาตรฐานระดับโลก
REFINITIV company cover
REFINITIV
The Financial and Risk business of Thomson Reuters is now Refinitiv
H LAB company cover
H LAB
Re-engineering healthcare systems through intelligent platforms and system design.
The Gang Technology Co., Ltd. company cover
The Gang Technology Co., Ltd.
We're a Digital Agency that helps our customers transform their business into digital with ease.
LTMH company cover
LTMH
LTMH มุ่งเน้นการพัฒนาผลิตภัณฑ์ที่สามารถช่วยพันธมิตรของเราให้บรรลุเป้าหมาย
Seven Peaks company cover
Seven Peaks
We Drive Digital Transformation
Wisesight (Thailand) Co., Ltd. company cover
Wisesight (Thailand) Co., Ltd.
The Best Choice For Handling Social Media · High Expertise in Social Data · Most Advanced and Secure
MOLOG Tech company cover
MOLOG Tech
We are Modern Logistic Platform, Specialize in WMS, OMS and TMS.
Data Wow Co.,Ltd company cover
Data Wow Co.,Ltd
We enable our clients to realize increased productivity by solving their most complex issues by Data
LINE Company Thailand company cover
LINE Company Thailand
LINE, the world's hottest mobile messaging platform, offers free text and voice messaging + Call
LINE MAN Wongnai company cover
LINE MAN Wongnai
Join our journey to becoming No.1 food platform in Thailand

อยากรู้ว่า "ฝ่ายที่สนับสนุนและคัดค้าน" มีมุมมองแตกต่างกันอย่างไร พอจะมีใครสรุปให้สักเล็กน้อยได้ไหมครับ

เอาคหสต. ผมไปแทนแล้วกันนะครับ ?

สนับสนุน

  • รันง่ายดี ไม่เสียเวลา build เวลา dev คงสะดวกขึ้นเยอะมาก

คัดค้าน

  • คือเหมือนบอกให้ยอมรับว่ามีอะไรใส่ไปตรงนั้นตรงนี้ได้แต่อย่าไปสนใจว่ามันคืออะไรและไม่มีผลอะไรเลยต่อการรัน แปลกมากครับ

Type hint ใน Python ก็มีลักษณะคล้าย ๆ กัน คือ แทบไม่มีผลกับการเขียนโปรแกรม ถึงไม่มี type hint ใน Python ก็มี duck type คอยตรวจสอบอีกที เป็นเหมือนเอกสารที่ฝังไว้ในโค้ดเสียมากกว่า

ถ้าตามแนวทาง คือจะทำให้มัน ignore type ครับ

ไมโครซอฟท์ในฐานะผู้สร้างภาษา TypeScript จึงมีไอเดียใหม่ เสนอแก้สเปกของ JavaScript ให้ "มองข้าม" การกำหนดชนิดของตัวแปรของ TypeScript เพื่อจะได้ไม่ต้องมีกระบวนการแปลงโค้ดอีกต่อไป!

ผมอาจจะคิดมากไป คือ ประมาณว่า พฤติกรรมบางเคส
โค้ดเดียวกันอาจทำงานไม่เหมือนกันถ้ามีการ ignore type หนะครับ

เรื่องพวกนี้ก็ต้องมาโต้เถียงกันตอนเขียนสเปกครับ เขียนอย่างไรให้รัดกุม ทดสอบให้ครบก่อนยอมรับเข้าเป็นสเปกกลาง

ที่ผมหายไปเพราะโควต้าหมดครับ เพิ่งได้โควต้ากลับมา

ที่คิดมากไปว่าพฤติกรรมจากการ ignore type อาจเปลี่ยนไปหรือต่างกัน ทำไมถึงคิดแบบนั้นล่ะครับ ไม่ได้ถามจี้นะ แต่ผมอยากฟังเพราะอาจมีมุมที่ผมคิดไม่ถึง

ที่ผมเข้าใจคือ JS มันก็ ignore type ในระดับ core อยู่แล้วนะ เพราะตัวแปรเดียวกันจะ assign type ต่างกันไปมากี่รอบก็ได้ เพียงแค่ว่าในปัจจุบันไม่รองรับการ ignore type ในระดับ syntax แค่นั้นเอง

Code ทำงานไม่เหมือนกันของ js เป็นที่น่าปวดหัวจริงๆแหละ
เช่น if(var_a) true else false บางคนเขียนอย่างนี้ไว้เช็คค่าว่าง แต่ เลข 0 คือโดนด้วย ทำให้เกิดบั๊ค

rattananen Mon, 14/03/2022 - 12:55

คือ explicit type นี้เป็นสิ่งดี
แต่มีแล้วตนไม่ได้ใช้ นี้มันประหลาดไปหน่อย

ใส่ static type ใน javascript ไปเลยดีกว่า

พอรู้เหตุที่ไม่ชอบ static type กันไหมครับ ผมว่ามันไม่มีเหตุให้ไม่ชอบนะครับ

คือผมเขียนโปรแกรมนานมากพอตัว ประมาณ 90% ผมใช้เป็น dynamic type
3 ปีที่แล้วมาลองใช้ static type ของ Typescript ผลคือ

  • มันลด error ได้เยอะมาก ไม่ต้องกลับมาแก้ bug บ่อยๆ
  • ใช้ร่วมกับ intellisense ของ editor ได้ดีทำให้ coding เร็วขึ้น
  • ได้เรียนรู้อะไรเยอะจาก type-hint
    ตั้งแต่นั้นมา ไม่ว่าผมเขียน Python หรือ PHP นี้ผมก็พยายามใช้ static type ตลอด

static typed ต้องดูว่า strong typed แค่ไหนครับ บางทีใช้เป็น any ใช้เป็น unknown ไม่ได้เลยก็หงุดหงิดอยู่ เพราะตอน dev กำลัง prototype ก็จะลวกๆ หน่อย บางที http response ก็ยังไม่แม่น แถมมี field ที่ลักปิดลักเปิดอีก จะทำให้การ dev ช้าลง แล้วต้องมาคอย debug จนกว่าจะ declare type ได้ครอบคลุมทุก scenario ซึ่งการ prototype บางทีความคิดมันมาแล้วมันก็ไปตอนมานั่งแก้ type declaration นี่แหละครับ

typescript มันแปลกอย่างนึง ถ้าไม่ได้ประกาศว่าจะเป็น null ได้ มันก็จะไม่ยอมให้รันเลย ต้องไปแก้ tsconfig หรือไม่ก็ต้องไปประกาศให้ชัดๆ ไปเลย

เดี๋ยวต้องมีคนมาเถียง ก็ต้องหัดจดสิ่งที่คิด ต้องหัดเขียนโปรแกรมให้ถูกต้องในครั้งแรก ฯลฯ เบี่ย (เพลีย + เบื่อ)

ถ้าใช้ JS + Typescript งานมันก็เพิ่มสิครับ
ผมใช้ Typescript 100% เลยน่ะ ไม่ต้องมา declare อยู่

สังเกตดีๆ package หลายเจ้าเขาเปลี่ยน จาก .js + .d.ts เป็น .ts
เพราะใช้ .ts 100% เลยมันง่ายกว่าน่ะ

ส่วน http response นี้ใช้ TS ยิ่งง่ายเลยครับ
เพราะเรารู้อยู่แล้วว่า shape/type ของ response เป็นอย่างไร
ทำให้ไป declare shape/type ไว้ก่อนได้ ไม่ต้องใช้ any/unknown ด้วยซ้ำ

ผมก็ typescript 100% เลยครับ แต่ต้อง declare type นะ เขียน microservice ข้อมูลที่รับส่งไม่ใช่ primitive type ก็ต้อง declare ทั้งหมด

แปลกดีครับที่บอกว่าใช้ typescript 100% แต่ไม่ต้อง declare

  1. Type script debug+ edit ใน chrome ลำบาก เราแก้งานผ่าน chrome บ่อย js บางจุดแก้โค้ดแล้วรันต่อได้เลย ไม่ต้อง refresh ใหม่

  2. อย่าที่ท่านบนว่า บางที request response ไม่นิ่ง เสียเวลาแก้
    บางทีก็แก้ requirement ขอเพิ่ม field ที่แสดง dynamic มันสะดวกกว่า
    แก้ ที่ store procedure กับ html เอา ไม่ต้อง restart service หรือ ต้อง build งานกันใหม่

ผมขอเสริม คำว่าลักปิดลักเปิด เพราะ 3rd party service บางเจ้าจะมี field ที่มีบ้างไม่มีบ้าง

เช่น ใน document บอกว่า { error: string } แต่เวลาใช้จริงกลายเป็น { error?: string } หนักสุดที่เคยเจอคือเป็น { error?: string | interface of something }

ผมไม่ถึงกับไม่ชอบ แต่ไม่ค่อยอยากเขียนเพราะขี้เกียจ เหตุผลคือ ผมเชื่อใน convention & test มากกว่า หากเรากำหนด convention ดี ๆ มันจะนำทางเราไปเรื่อย ๆ โอกาสผิดพลาดน้อย ส่วนการทดสอบ ยังไงก็เลี่ยงไม่ได้ จะมีหรือไม่มีประเภทตัวแปร ก็ต้องทดสอบ

เท่าที่สังเกตเวลาไป consult คนอื่น ประเภทตัวแปรจะจำเป็นมาก หากโค้ดที่เขียนมีความซับซ้อนสูง ข้อแนะนำของผมคือ refactoring เถอะ ทำทีเดียว โค้ดหลักพันบรรทัด ชม. เดียวก็เสร็จ ที่ผ่านมาแก้ปัญหากันเป็นเดือนแล้วก็ยังไม่เสร็จ พอมาถึงตรงนี้ประเภทตัวแปรก็จะช่วยได้อีกรอบ แต่ก็ไม่ถึงกับจำเป็น

จุดเริ่มต้นมันก็เรื่องนึง ปัจจุบันมันก็เรื่องนึงเนอะ อะไรไม่ดีก็ต้องแก้ไขปรับปรุงกันไป

ก็เหมือน JavaScript จุดเริ่มต้นมันก็ใช้แค่บน client side แต่ก็ถูกนำไปใช้ใน server side ในคราวต่อมาเหมือนกัน

ภาษา JavaScript ตัวมันเองเนื้อๆ แล้วชวนสับสนและมีปัญหาหลายๆ อย่าง การมาของ TypeScript ก็ช่วยได้มากเช่นกัน ของมันก็ต้องปรับปรุงกันไปเรื่อยๆ

จนตอนนี้ PHP ยังไม่รองรับ async เลย

edit เพิ่มหน่อยเผื่อเดี๋ยวจะดราม่ากันมากขึ้น (แล้วเราจะสุมไฟเพิ่ม) ส่วนตัวไม่ได้มีปัญหากับตัวภาษาโปรแกรมอยู่ละ เพราะมันก็แค่ข้อความที่รอเอาไปแปลงเป็นรหัสเครื่อง หรือให้คอมพิวเตอร์ทำตาม แต่ไม่ค่อยโอเคเท่าไรกับการที่ห้ามแซะ ห้ามวิจารณ์ภาษานั้นภาษานี้ ประหนึ่งเป็นสิ่งศักดิ์สิทธิ์ หรือย้อนบอกว่าหลัง ๆ เดี๋ยวก็ปรับปรุง ซึ่ง... จนตอนนี้ยังไม่เห็นภาษา C ปรับปรุงจนเอามาแทนภาษาสำหรับเว็บเลย มีแต่สร้างภาษาใหม่กันไปเรื่อย ๆ เอามารองรับงานต่าง ๆ ที่ต่างออกไป แล้ว PHP มันแทบจะไม่ตอบโจทย์อะไรเลยสำหรับเว็บยุคใหม่ แล้วปรับปรุง API กันน้อยมากในแต่ละเวอร์ชัน ฟีเจอร์ที่ควรจะเพิ่มก็ไม่เพิ่ม อย่าง async ที่พูดถึง จริงอยู่ที่มันไม่ต้องมีก็ได้/มี workaround แต่นั่นไม่ใช่ข้อแก้ตัวที่จะไม่เพิ่มความสามารถที่ภาษาเว็บอื่น ๆ เขามีกันมาแทบจะทศวรรษแล้ว

สำหรับ server-side JS ก็เหมือนกับข้างบน จริง ๆ JS มันก็ไม่ได้เหมาะเอามาใช้กับ server เลยแม้แต่นิดเดียว แค่ V8 มันเร็วผิดผีในช่วงนั้นจนคนเห่อใช้มันก็แค่นั้น แล้วพยายามซ่อมจุดบกพร่องในงาน server-side ของมันไปเรื่อย ๆ (ทั้งที่ไม่ควรทำ) จนมาตรฐานมันมั่วไปหมดแล้ว

ในโลกนี้ไม่ได้มีภาษาไหนดีที่สุด เอาจริง ๆ ไม่มีภาษาไหนดีไปกว่ากันเลย (ยกเว้น C ที่สมบูรณ์แบบในตัวอยู่แล้ว) และการวิจารณ์ถึงจุดอ่อนของภาษาในงานที่มันควรจะทำได้ ก็ควรจะเป็นเรื่องปกติ จะได้ปรับปรุงพัฒนากันไปเรื่อย ๆ

พอจะบอกได้ไหมครับ ว่า จุดบกพร่องในงาน server-side ของ nodejs คืออะไร แล้วทำไม ไม่ควรพยายามซ่อม อันนี้อยากรู้เพราะว่าใช้ nodejs เป็นหลักอยู่

ขั้นแรกเลย อย่างที่ทุกคนรู้กัน คือ Node.JS เป็นภาษา dynamic-typed แล้ว lint ส่วนใหญ่ก็ไม่เก่งพอที่จะทำนายการเปลี่ยนแปลงของ data type ฉะนั้นเป็นหน้าที่ของผู้เขียนโปรแกรมที่จะต้องระมัดระวังเรื่องนี้ไม่ให้มันพัง (ตรงนี้แก้ได้ด้วย TypeScript)

ขั้นที่สอง ECMAScript มาตรฐานมันไม่เคยอยู่นิ่ง ดัดแปลงได้เยอะมาก ซึ่งมันก็อาจจะดี แต่ปัญหาคือ พฤติกรรมของแต่ละวิธีการเขียนโค้ดที่ออกมามันไม่เหมือนกันเลย ทำให้รู้ได้ยากว่าวิธีการเขียนโค้ดของเรานั้นเหมาะสมที่สุดแล้วหรือไม่ ผมเคยเขียนโค้ดสองตัวที่ทำงานแบบเดียวกันแต่ใช้วิธีการต่างกัน ผลที่ได้คือ ทั้งสองโค้ดนั้นให้ประสิทธิภาพที่ต่างกันอย่างสิ้นเชิง (ซึ่งก็นี้ก็แก้ด้วย TypeScript อีกนั่นแหละ)

ขั้นที่สาม ตัว V8 ให้ประสิทธิภาพสูงก็จริง แต่ memory management จัดว่าแย่ เพราะต้องใช้เพื่อการทำนายและคอมไพล์โค้ดไปเป็นรหัสเครื่อง โปรแกรมเดียวกันที่เขียนบน tool ต่างกัน ตัว Node ใช้ความจำค่อนข้างสูงกว่าชาวบ้าน ถ้าใครมี resource ที่จำกัด Node.JS จะไม่ค่อยตอบโจทย์

ยังมีปัญหาเรื่องโครงสร้างระดับลึกเช่น event loop ที่ block main thread ซึ่งแก้โคตรยาก และต่อให้แก้ได้โค๊ดก็อ่านโคตรยาก ซึ่งเอาจริงๆก็อย่างที่ท่านว่า V8 ที่ทำงานแบบโคตรๆๆไว เลยหาเคสที่ต้อง optimize ขนาดนั้นในชีวิตจริงยาก

เรื่อง thread ผมว่าอยู่ที่ทำงานอะไร แล้วมันอ่านยากยังไง อย่างการทำ cluster ไม่น่ามีอะไรง่ายกว่านี้แล้วมั้ง หรือ worker thread ตัวโค้ดก็ไม่ได้ยุ่งยากอะไร ง่ายกว่าหลายๆ ภาษาด้วยซ้ำ

พูดถึงคนละเรื่องเลย เจ้าของคอมเมนต์กำลังพูดถึง event loop ที่มีโอกาสบล็อก main thread จนประสิทธิภาพตก ไม่ได้เกี่ยวกับ parallel computing เลย

แต่ถ้าอยากจะพูดถึงมันจริง ๆ การ implement parallel computing ของ V8 ในความคิดเห็นของผมนี่เกือบจะเรียกได้ว่าน่าสมเพชที่สุดแล้วในบรรดาของภาษาโปรแกรมที่เคลมว่ารองรับ parallel computing เพราะต้อง spawn ทั้ง process ใหม่ที่ใช้โค้ดชุดเดิม ทำให้ใช้ทั้งหน่วยความจำและ OS ต้องจัดการ scheduling ของ worker ด้วย แถมใช้ memory pool เดียวกันไม่ได้อีก อย่าเรียกมันว่า parallel computing เลย

7elven Tue, 15/03/2022 - 16:16

In reply to by big50000

1, 2 มันคือเรื่องปกติของการเขียนโปรแกรมไหมครับ ภาษาอื่นไม่เป็นหรอ ส่วน 3 ผมไม่เคยเจอปัญหา memory management ก็ no comment ครับ

น่าจะอ่านไม่ครบ อย่างที่บอกไป นอกจาก ECMAScript มาตรฐานมันจะมั่วและพลิกแพลงได้มากแล้ว พฤติกรรมในแต่ละ JS Engine ยังต่างกันด้วย ในครั้งนี้จะนับเฉพาะ Node.JS ตัวอย่างง่าย ๆ ก็อย่างเช่น prototype และ class ที่ทำงานอย่างเดียวกันได้

var proto = function() {}
var obj = new proto();

และ

var Proto = class {}
var obj = new Proto();

ทั้งสองตัวอย่างทำงานที่เหมือนกันได้ แต่ prototype pattern บน V8 ใช้งานหน่วยความจำมากกว่า 2 เท่าตัว

หรือ null vs undefined ทั้งสองอย่างนี้สามารถทำงานอย่างเดียวกันได้ แต่ไม่ใช่อย่างเดียวกัน และไม่ควรจะเอาไปปนกันด้วย

ทั้งสองเรื่องนี้คุณอาจไม่ได้ประสบปัญหาเพราะเขียน TS ซึ่ง Babel มันจะแปลงให้เข้ากับแต่ละเวอร์ชันของ ES อยู่แล้ว แต่นั่นก็ไม่ได้หมายความว่าทุกอย่างจะเหมือนกันนอกเสียจากผลลัพธ์ของงานเท่านั้น (นอกเสียจากว่าคุณจะเอาเฉพาะผลลัพธ์อย่างเดียวและไม่ได้สนใจเรื่องอื่น ๆ ก็สุดแล้วแต่จะคิด)

ในขณะที่ภาษาอื่น ๆ มักมี syntax/pattern ในรูปแบบเดียวกันและไม่ได้พลิกแพลงได้มากมายขนาดนั้น ขนาด Go เองก็ยังไม่มี class ให้ใช้เลยขนาดว่าเป็นภาษายุคใหม่ ถ้าอยากได้ OOP ต้อง implement เอง เพราะมันไม่ได้ออกแบบให้เป็น OOP อยู่แล้ว ในขณะที่ JS มันแทบจะเหยียบเรือทุกแคม พลิกแพลงได้แทบจะทุกรูปแบบ เอาแค่ class ยังประกาศได้ 2 แบบ (class declaration vs. class expression) แถมยังมีข้อถกเถียงกันใน community ว่าแบบไหนดีกว่ากัน ทั้ง ๆ ที่ทั้งคู่ทำงานไม่เหมือนกันเลย (แต่ดันเอาไว้ใช้งานแบบเดียวกันได้)

ขอถามอีกรอบได้ไหมครับ แล้วงานอะไรบ้าง ที่ต้องระวังเรื่องการจัดการ memory กับเรื่อง block main thread อย่างที่ว่า

ปล. เพิ่งสังเกตว่าสมัยนี้ยังมีคนใช้ var กันอยู่

เรื่อง memory นี่ผมก็ระวังทั้งหน้าบ้านหลังบ้านนะครับ ตัวหน้าบ้านผมงานนึงเคยกินแรมไปหลายกิ๊กต้องตามเก็บเพราะรันบน RPi แล้วหนักไปมาก กับอีกงานคือพลาด กดปุ๊บ block main thread ไปห้าวินาทีได้ (บน intel น่าจะ i5 หรือ i7) แก้ให้ไม่ block ก็ UI ขยับได้แบบอืดและช้ามากอยู่ดี สุดท้ายพยายามให้รัน parallel ×4 ด้วย web worker แล้วก็ได้สุดที่ 2 วิอยู่ดีด้วยความง่อยจัดด้าน parallel ของ JS T-T (รอบที่แก้ใช้ web worker นี่คืองานด่วนปัดฝุ่นของเดิมมาขายซ้ำ เวลาน้อยงบน้อย ไม่งั้นคงเล่นใหญ่อยู่ให้มันเร็วด้วยท่าโยนออกนอก JS อยู่ ?)

ถ้าเรื่อง memory กรณีที่ใช้ในการเขียน API ทั่ว ๆ ไปแล้วมักไม่เจอปัญหาอยู่แล้วเพราะมันไม่ได้ใช้ทรัพยากรมากมายอะไรขนาดนั้น แล้วพวก API ก็ไม่ได้มีโค้ดเยอะด้วย แต่ถ้านำไปสร้างอะไรที่ใหญ่ขึ้น มี logic ที่ซับซ้อนขึ้น (เช่น เซิร์ฟเวอร์เกม) จะเริ่มเจอปัญหา โปรแกรมเซิร์ฟเวอร์ตัวหนึ่งที่ผมเคยเขียนไว้เมื่อนานมาแล้ว start เริ่มแรกใช้ memory ไปแล้ว 10 MB ทั้งที่ยังไม่ได้เริ่มทำอะไรเลย ไม่ต้องนึกสภาพถ้าเริ่มมีคน Join เข้ามาจริง ๆ ตัว memory เริ่มต้น 512 MB ไม่พอใช้แน่ ส่วนวิธีเลี่ยงก็ไม่มีหรอก 555 ไปหา solution อื่นลูกเดียว

ส่วนเรื่อง block main thread บอกตามตรงว่า "ไม่รู้" เหมือนกัน พวก lib บน Node.JS ส่วนใหญ่ก็พยายามที่จะ process โดยที่ไม่ block อยู่แล้ว ยกเว้นว่าเราอยากจะ block มัน โดยไม่ใช้ asynchronous เลย หรือโค้ดของเรามีส่วนที่ต้องประมวลผลเป็นเวลานานโดยที่ไม่คิดที่จะ "หาร" มัน หรือ lib ที่ใช้อยู่นั้นเลี่ยงการ block ไม่ได้ก็ "ลาก่อย" ค้างกันไปเลย แต่ส่วนใหญ่แล้วก็ไม่เจออีกนั่นแหละเพราะพวกเกี่ยวกับ API เองก็ไม่ได้ประมวลผลข้อมูลขนาดใหญ่อยู่แล้ว และ Node.JS ก็เร็วมาก

ปล. ที่ใช้ var นี่เผื่อคนอื่น ๆ ที่ใช้ภาษาอื่นเป็นหลักแล้วมาอ่านจะได้พอเข้าใจว่าหมายถึงอะไร (คีย์เวิร์ด let เห็นมีไม่มีภาษาที่ใช้ เช่น Rust, Swift ใครรู้จักมากกว่านี้มาเพิ่มเติมได้จะขอบพระคุณยิ่ง) แต่ผมยอมรับนะว่าไม่ควรใช้ var แล้ว ข้อเสียเยอะเกิน ส่วนตัวผมเองก็ไม่ได้ใช้ในงานจริง

มันมีน่ะครับแแต่ไม่ใช่ keyword async
parallel PHP7.2+
Fibers PHP8.1+
แต่คนใช้น้อยมาก น่าจะเพราะแค่ไม่ใช่ keyword async ทั้งที่หลักการเดียวกัน
และถ้าจะ work around มันก็มี https://symfony.com/doc/current/messenger.html

ขนาดเขาทำ data structure ดีๆ มาให้คนก็ยังใช้ แต่ array
https://www.php.net/manual/en/book.ds.php

คือผมใช้มาตั้งแต่ PHP3 ช่วงปลายๆ จน 8.1 บอกได้เลยว่า PHP เป็นภาษาที่พัฒนาไปเยอะที่สุดในภาษาที่ผมใช้แล้ว
แต่หลายคนยังติดภาพเก่าๆ ช่วง PHP5 เยอะ

ก่อนอื่นเลย Parallel Computing ≠ Coroutine

PHP::Fibers เป็นหนึ่งในรูปแบบของ Coroutine ที่เกือบจะเรียกได้ว่า "ง่อย" เพราะมันไม่ต่างจากการเขียนฟังก์ชันแยกแล้วให้มันรันทีหลังสักเท่าไร (ประมาณว่าเป็น sweet syntax) เพราะตัวฟังก์ชันต้องรันขึ้นมาก่อนสักที่ แล้วมันไม่ fulfill/resume อัตโนมัติเมื่อเสร็จสิ้น ฉะนั้นต้องรอบคอบเมื่อใช้งาน ถ้าไม่ระมัดระวังมากพอ คือคุณทำ procedure ตรงนั้นล็อกตายไปเรียบร้อยแล้ว แถมตัวมันเองยังก่อปัญหาเรื่อง readability/maintainability มากกว่าที่จะช่วย คนเขียนโปรแกรมก็ต้องมีความรู้ด้าน Coroutine พอสมควรจึงจะสามารถใช้งานได้อย่างถูกต้อง ในขณะที่ภาษาอื่น ๆ แค่เติม async/await ก็จบแล้ว โปรแกรมเมอร์มือสมัครเล่นก็ใช้งานได้

เท่าที่รู้คือ PHP::Fibers ไม่ได้ออกแบบมาให้ผู้พัฒนา PHP สามัญใช้ แต่เอาไว้สำหรับผู้พัฒนาเครื่องมือ / library นำไปใช้งานเสียมากกว่า ถ้าให้เดาเล่น ๆ เนื่องด้วยตัวภาษาเองก็มีอายุ ทีมผู้พัฒนาเองก็มีขนาดเล็ก แล้วไม่น่าจะอยากลงแรงพัฒนา compiler/runtime ใหม่ให้รองรับ async จริง ๆ จึงลงเลยแบบที่เห็น

ปล. ถ้าให้แฟร์ async/await ก็ไม่ได้ perfect เหมือนกันในตอน await ที่ยังเป็น synchronous อยู่ แต่มันก็ไม่ใช่เหตุผลที่จะไม่นำมาใช้อยู่ดี สำหรับภาษาที่ดีที่สุดตอนนี้ในเรื่อง Coroutine เท่าที่ผมรู้ น่าจะเป็น Go เพราะผสานทั้ง threading และ coroutine เข้าด้วยกันได้ดีมาก

ถ้าแยกตามลำดับการ execute code การเขียนโปรแกรมมันมีแค่ 2 แบบน่ะครับ

  • synchronous
  • asynchronous

coroutine
promise
thread
subprocess

ร่วนเป็น asynchronous แค่มันไม่ได้ใช้ keyword async
สำหรับผมเหล่านี้มันใช้แทนกันได้ อยู่ที่ว่าเราอยากให้ CPU มัน priority ระดับไหน

------------ อาจจะจำผิด -------------
อยากจะแยก core CPU ก็ใช้ subprocess
อยากให้ CPU priority ไม่แยก core ก็ thread
asynchronous handmake ก็ promise
ใช้อะไรก็ได้ไม่ว่ากัน coroutine

ปกติผมไม่พยายามเขียนแบบ asynchronous เท่าไร เพราะมันงง ออกแบบไม่ดีมี race condition

ตายแล้ว คิดแบบนี้ Godot, Node.JS ไปร้องไห้อยู่มุมห้องแล้ว

อยากจะแยก core CPU ก็ใช้ subprocess

เคยเจอ process เดียวแต่เปอร์เซนต์การใช้งานโพรเซสโปรแกรมเกิน 1 / Threads ไหม แต่นั่นแหละ เห็นว่าพูดถึงการเพิ่ม CPU priority โดยใช้ Thread แต่มันไม่ใช่เลย คนละเรื่องด้วยซ้ำ นั่นแหละที่เขาเรียกว่า multi-threaded ถ้าเห็นซีพียูใช้เกิน 1 / Threads เมื่อไรนั่นแปลว่ามันใช้เกินกว่า 1 thread ไปแล้ว และทั่วไปแล้ว CPU core จะทำงานแบบ 1 thread แต่บางครั้งเราสามารถจำลอง thread เพิ่มขึ้นมาอีกได้ ทั้งทาง hardware (อย่างพวกซีพียูคอมฯ x86 ต่าง ๆ ทั้งหลาย) และ software (emulation) ถ้าเป็นทาง hardware เอง ซึ่งจะได้ benefit จากการออกแบบสถาปัตยกรรมค่อนข้างเยอะ แล้วทำให้เราได้ข้อดีของ multi-thread ได้พอสมควรโดยที่ไม่ต้องเพิ่ม CPU core อีกตัว

Sub-process เป็นศัพท์สวยงามสำหรับอีก process ที่ทำงานร่วมกันกับ process หลัก แต่มันทำงานแทบจะ independent และต้องสื่อสารผ่านช่องทางกำหนดเอง ไม่สามารถแชร์ memory pool ได้เหมือนกับการโปรแกรมแบบ threaded ซึ่ง sub-process มันก็มีทั้งข้อดีข้อเสียของมันเอง และเป็นคนละอย่างกับ multi-threaded (แต่ถือว่าอยู่ในกลุ่มของ parallel computing ได้ด้วยหน้าที่ของมัน)

Coroutine นี่ไม่เกี่ยวอะไรเลยกับพวก core/thread มันทำงานบน thread เดียวได้ เพียงแต่ว่าเราสามารถเขียน core/thread ร่วมกับ Coroutine ได้ก็เท่านั้นเอง ความหมายมันก็ตรงตัวอยู่แล้ว Coroutine เป็นการพักกระบวนการย่อยในโปรแกรมไว้ แล้วไปทำอย่างอื่นก่อน จากนั้นกลับมาทำงานอย่างเดิมทีหลัง เรื่องแบบนี้ไม่ใช่เรื่องใหม่ มันมีมาตั้งแต่สมัยคอมพิวเตอร์บ้านยุคแรก ๆ เลย เพียงแต่ว่าในภาษายุคใหม่มีวิธีการเขียน coroutine ใหม่ ๆ มี sweet syntax ที่ใช้ง่ายมาให้ใช้เรื่อย ๆ อย่าง async ก็เป็นรูปแบบหนึ่งของ Coroutine ที่ใช้งานง่ายที่สุด (แต่ก็ทำให้มีประสิทธิภาพยากที่สุด)

ที่คุณงงกับ Coroutine มันก็ไม่แปลกเท่าไร เพราะ syntax มันประหลาดจริงถ้าใครเคยผ่านการเขียน Coroutine ในรูปแบบอื่น ๆ มาก่อน แต่ถ้าหยุดคิดเรื่อง Coroutine แล้วใช้มันเหมือน synchronous เมื่อไรจะหายงงทันที เพราะตัว keyword เองมันก็แค่ใช้หยุดกระบวนการแล้วเตะไปอยู่ที่ awaiting state จากนั้นไปทำงานอย่างอื่นต่อ แล้วกลับมาดูใหม่อีกครั้งไปเรื่อย ๆ จนกว่าสถานะ await จะ fulfill แล้วจีงรันโค้ดที่เหลือต่อไปก็แค่นั้น

Race condition นี่ก็ไม่เกี่ยวอะไรเลยกับ Coroutine (นอกจากเขียนผูกกันแบบโคตรแน่นแบบบางภาษา เช่น C#, Go) มันเป็นเรื่องของ thread ที่ประมวลผลเสร็จในเวลาไม่เท่ากันแล้วดันต้อง access data pool ชุดเดียวกัน ถ้ารู้ว่าเราจัดการกับอะไรอยู่จะรู้ได้เลยว่า งานส่วนใหญ่มันไม่ต้องการ thread เลยเสียด้วยซ้ำ เขาเอาไว้ใช้กับ parallel computing

สิ่งผมต้องการจะสื่อคือ

  1. คุณบอกว่า PHP ไม่มี async > ผมตอบ มี
  2. คุณบอก นั้นมันไม่ใช่ > ผมตอบ มันใช้แทนกันได้เพราะมันเป็น asynchronous เหมือนกัน

ถ้าจะเปลี่ยนประเด็นมันก็ discuss กันไม่จบสักทีนะครับ

เดี๋ยว ใครเปลี่ยนประเด็น คุณเปิดมาเรื่อง parallel/thread ก่อนเลยนะ ผมเลยแก้ความเข้าใจผิดให้ก็เท่านั้นเอง อีกอย่าง async มันเป็น subset ของ Coroutine แม้ว่าจะใช้เขียนแทนได้ แต่ยังไงมันไม่ใช่ async เพราะวิธีการใช้งาน/ความสะดวกมันต่างกันมาก

C ที่สมบูรณ์แบบในตัวอยู่แล้ว

ภาษา C เองก็มีพัฒนามาเรื่อยๆ นะครับไม่ได้อยู่นิ่ง อย่างล่าสุดก็ออกมาถึง C17 (ปรับปรุงเมื่อปี 2017 แต่ประกาศใช้ปี 2018) https://en.wikipedia.org/wiki/C17_(C_standard_revision) แถมกำลังทำ C2X อยู่ด้วย

ผมเข้าใจว่าภาษา C เองก็มีการพัฒนาขึ้นมาเรื่อย ๆ แต่ syntax ของ C ดั้งเดิมยังคงตอบโจทย์ทุกงานเหมือนเดิมถ้าเราขยันจะสร้างมันขึ้นมา อีกอย่างมาตรฐานพวกนี้ไม่ได้เป็น public เสียทีเดียว ใครอยากจะใช้ก็ใช้

+1 ครับ จริง ๆ ผมเห็นด้วยกับคุณหลายความเห็นในข่าวนี้เลยนะ ดังนั้นผมเลยมองว่าสุดท้ายแล้วภาษามันก็คงเป็นเรื่องที่คนเขียนถนัดหรือคนเขียนอยากใช้จริง ๆ อย่างที่ nodejs เกิดขึ้นมาได้ผมก็ว่าเพราะมันมาจากความนิยมของ JS ล้วน ๆ

เขียนอธิบายได้เห็นภาพดีมากเลยครับ มือสมัครเล่นที่ลองศึกษาไปเรื่อยอย่างผมอ่านแล้วเข้าใจเลยครับ

ความเร็ว
JavaScript > PHP -> Python

ความมั่ว
JavaScript > PHP > Python

จะเห็นว่า PHP ก็กลางๆ และมีที่ทางความเหมาะสมของมันอยู่

แต่เวลาโดนแซะเรื่องความเร็วและความมั่ว PHP จะโดนตลอด

เคยฟัง Clubhouse ที่หมอจิมจัด หัวข้อ WordPress โดยมีคุณเม่นเป็นผู้บรรยายหลัก ช่วงถามตอบมีแม่ค้าออนไลน์มาปรึกษาว่าเว็บอีคอมเมิร์ซ (เดาว่าเป็น PHP) ช้า จะแก้ปัญหาอย่างไรได้บ้าง ทุกคนก็ช่วยแนะนำไป

แต่มีกลุ่มโปรแกรมเมอร์ที่น่าจะเกลียด PHP เข้าไส้ ให้ความเห็นและย้ำว่า PHP ไม่ใช่ภาษาโปรแกรมมิ่ง แต่เป็น template engine จนหมอจิมต้องเบรค ผมที่ฟังอยู่ก็งงว่ามันเกี่ยวกับปัญหาและหัวข้อที่เค้ากำลังคุยกันตรงไหน

ยังไม่หยุด โปรแกรมเมอร์ในกลุ่มนั้นเล่าต่อว่าเคยไป support ลูกค้าที่ระบบเป็น PHP ลองเทสต์พบว่ารับรีเควสได้ 1 transaction per sec

ผมรู้ว่า PHP ไม่ใช่ภาษาที่เร็ว แต่ก็ไม่ได้อืดขนาดจะรันได้ 1 tps ถ้าช้าขนาดนั้นมันต้องมีคอขวดที่ไหนสักที่แล้วล่ะ (เดาว่า database)

ทุกวันนี้ยังไม่เข้าใจว่าทำไมหลายคนจงเกลียดจงชัง PHP กันเหลือเกิน

ถ้าความเร็วให้ 3 ภาษานี่ผมให้เท่ากันน่ะครับเพราะมัน interpreter language เหมือนกัน
ที่จริงควรจะให้ nodejs ช้าสุดเพราะ nodejs ไม่มี cache byte code (หรือมีแต่ผมไม่รู้)

ที่ทำให้ช้าส่วนนึงเลย ก็ 3rd party package นี่ล่ะ
ผมเห็นบาง package ที่นิยมกันเขียนค่อนข้างแย่ แต่คนก็ใช้กันเพราะไม่มีตัวเลิอก

และสาเหตุอันดับ 1 สำหรับผมคือ database ครับ
บางคนเขียน query โดนไม่คำนึง process ใน database (ซึ่งมันเป็นเรื่องของ database ไม่เกี่ยวกับภาษาที่ใช้ coding)
และไม่คำนึงถึง memory allocation ชอบ fetch all row dump to memory

คือต่อให้ภาษามันดีเลิศอย่างไร แต่ถ้าคนเขียนไม่เข้าใจพื้นฐาน computer science
มันก็ไม่สามารถใช้ภาษานั้นให้มีประสิทธิภาพอยู่ดี

หลายคนยังไม่รู้ว่า ฐานข้อมูลในหลาย ๆ การออกแบบมันไม่ต้องยืนยันข้อมูลล่าสุดก็ได้ หรือบางทีก็ไม่ได้คิดถึงเรื่องนั้น จะ query กันในทุก ๆ request เลย ทั้งที่มันสามารถ cache ไว้ใช้ทีหลังได้ ถ้าเป็นคนที่พึ่งเริ่มเรียนรู้ก็จะไม่ว่าอะไรเพราะคนเก่งก็เคยเป็นคนไม่เก่งมาก่อนนั่นแหละ

ปล. Node.JS เร็วที่สุดต่างหาก เพราะมันไม่ใช่แค่แปลงเป็น bytecode แต่มันแปลงเป็น machine code แล้ว branch ไว้ล่วงหน้าเลย ซึ่งก็มี side-effect ของการใช้ memory ที่สูง (แต่น้อยกว่า Java หลายขุมอยู่) แต่ถ้านับเฉพาะงานที่ทำแบบ sequential ตัว PHP จะเร็วกว่าหน่อย และที่ช้าที่สุดคือ Python (เจาะจงหน่อยคือ CPython) เพราะมันไม่แม้แต่จะใช้ JIT ด้วยซ้ำ

ถ้าเขียนโปรแกรมให้ทำงานที่ 1 transaction per sec ได้นี่ต้องเชิญไปเป็นวิทยากรในงาน "เขียนโค้ดอย่างไรให้ไร้คุณภาพ" อ่ะครับ

big50000 Thu, 17/03/2022 - 14:07

In reply to by crucifier

ความเร็ว
JavaScriptNode.JS > PHP -> Python

JavaScript ใครจะสร้าง Engine ขึ้นมาก็ได้ เพียงแต่ว่าเราติดภาพจำมาจาก Node.JS ที่เร็วมากแค่นั้นเอง

ถ้าให้แฟร์ PHP เวอร์ชันหลัง ๆ นี่เรียบร้อยยิ่งกว่า Python สำหรับโปรแกรมเมอร์สาย Java ไม่ถือว่าแย่เลยล่ะ แต่ถ้าจะบอกว่าเกลียดนั่นนี่แบบไร้เหตุผล เอาจริง ๆ มันก็มีเหตุผลของมัน เพราะ PHP มันไม่ได้ออกแบบมาให้รองรับงานที่มี concurrency สูงมาตั้งแต่แรก (แทบทุกอย่างใน PHP ทำงานแบบ sequential) ทำให้มัน optimise ได้ยากมากถ้าไม่หวังพึ่งเครื่องมืออื่น ๆ ช่วย แล้ว cost ก็สูงกว่า solution อื่น ๆ มากใน scale เดียวกัน แต่ก็โทษอะไรไม่ได้นั่นแหละ PHP มันอยู่มานานแล้ว โดยเฉพาะ WordPress ที่เป็นมาตรฐานของ CMS และเติบโตมานาน จะไปจี้ให้ใช้งานของที่คุยว่าดีกว่าอย่างนั้นอย่างนี้โดยที่ไม่คำนึงถึงความต้องการจริง ๆ มันก็กะไรอยู่ และตอนนี้วิธีการแก้ปัญหาความช้าของ PHP นอกเหนือจากการเขียนโค้ดก็มีเพียบ สรุปง่าย ๆ PHP มันแค่ช้าในทางทฤษฎี แต่ใน real-world มันมีคนเห็นปัญหาแล้วแก้ไขให้ได้อยู่แล้ว แต่ถึงกระนั้น ถ้าเลี่ยง PHP ได้่ก็เลี่ยง จะได้ไม่ต้องไปคิดหา solution ซ้อนเข้าไป

ปล. กลุ่มโปรแกรมเมอร์ที่เกลียด PHP เข้าไส้นี่ทำไมผมรู้สึกคุ้น ๆ

ผมคิดเดาเอาเองว่าในอนาคต engine ของ PHP คงเร็วขึ้นอีกมาก ก็ถ้ามีคนทำ engine ให้รัน JavaScript ให้เร็วได้ ฝั่ง PHP ก็คงทำได้เช่นกัน อย่างน้อยตอนนี้ PHP เวอร์ชัน 7 -> 8 ก็ดูมีพัฒนาการขึ้นมากจนมีความหวังว่าในอนาคตมันจะเร็วขึ้นได้อีก

เสียแต่ว่าทีมงานที่ดูแลโครงการ PHP นั้นน้อยเหลือเกิน คุ้นๆ ว่า maintainer หลักจะมีแค่ 2-3 คนนี่แหละ

พูดให้ถูก (แต่ไร้ประโยชน์) ความเร็วขึ้นอยู่กับว่าเอาไปใช้ทำอะไร

ความเร็วของ JS ได้จาก JIT ของ PHP ได้จาก optimized hash ทำให้ความเร็วของ PHP predictable และ consistence กว่า แต่ JS จะเร็วกว่าเมื่อทำงานซ้ำ ๆ กันหลายรอบ

แต่พอเป็น string processing ทั้ง 3 ภาษาแทบไม่ต่างกัน และแทบไม่ต่างจาก static type มากนัก เพราะต่างถูก optimized กันมาตั้งแต่แรก

แต่! ในชีวิตจริง ความเร็วไม่ได้ขึ้นกับภาษา แต่ขึ้นกับ data structure และ algorithm

ทั้ง 3 ภาษาใช้พัฒนาโปรแกรมได้ดีแทบไม่ต่างกัน Python จะได้เปรียบบ้างในเรื่องดีไซน์ สำหรับผมคุณภาพซอฟท์แวร์ที่พัฒนาด้วย 3 ภาษานี้แทบไม่ต่างกัน

ตั้งแต่ PHP 8 ก็มี JIT แล้ว และเร็วกว่า Node.JS มากในบางกรณีด้วย แต่ก็ยังติดเรื่อง concurrency ที่ทำให้มันช้าใน real-world มีคนแก้ปัญหาไปแล้วส่วนหนึ่งแต่ยังไงก็ยังเข็นลำบากกว่าเจ้าอื่นที่รองรับ concurrent มาตั้งแต่ต้น

เรื่องความเร็วผมเห็นด้วยนะ ส่วนใหญ่มันไม่ได้ช้าเพราะภาษาแต่เป็นเพราะ code ห่วย + จัดการฐานข้อมูลไม่เป็น