রোডরানার: পিএইচপি মারা যাওয়ার জন্য তৈরি নয়, বা উদ্ধারের জন্য গোলং নয়

হে হাবর! আমরা Badoo এ সক্রিয় পিএইচপি কর্মক্ষমতা কাজ, যেহেতু আমাদের এই ভাষায় একটি মোটামুটি বড় সিস্টেম রয়েছে এবং কর্মক্ষমতা সমস্যাটি একটি অর্থ সাশ্রয়ের সমস্যা। দশ বছরেরও বেশি আগে, আমরা এর জন্য PHP-FPM তৈরি করেছি, যা প্রথমে PHP-এর জন্য প্যাচগুলির একটি সেট ছিল এবং পরে অফিসিয়াল বিতরণে প্রবেশ করেছিল।

সাম্প্রতিক বছরগুলিতে, পিএইচপি দুর্দান্ত অগ্রগতি করেছে: আবর্জনা সংগ্রহকারীর উন্নতি হয়েছে, স্থিতিশীলতার স্তর বেড়েছে - আজ আপনি কোনও সমস্যা ছাড়াই পিএইচপি-তে ডেমন এবং দীর্ঘস্থায়ী স্ক্রিপ্ট লিখতে পারেন। এটি স্পাইরাল স্কাউটকে আরও এগিয়ে যাওয়ার অনুমতি দেয়: রোডরানার, পিএইচপি-এফপিএমের বিপরীতে, অনুরোধগুলির মধ্যে মেমরি পরিষ্কার করে না, যা একটি অতিরিক্ত কর্মক্ষমতা লাভ করে (যদিও এই পদ্ধতিটি বিকাশ প্রক্রিয়াকে জটিল করে তোলে)। আমরা বর্তমানে এই টুলটি নিয়ে পরীক্ষা-নিরীক্ষা করছি, কিন্তু শেয়ার করার জন্য আমাদের কাছে এখনও কোনো ফলাফল নেই। তাদের জন্য অপেক্ষা আরও মজাদার করতে, আমরা স্পাইরাল স্কাউট থেকে রোডরানার ঘোষণার অনুবাদ প্রকাশ করি।

নিবন্ধের পদ্ধতিটি আমাদের কাছাকাছি: আমাদের সমস্যাগুলি সমাধান করার সময়, আমরা প্রায়শই একগুচ্ছ পিএইচপি এবং গো ব্যবহার করি, উভয় ভাষার সুবিধা পাচ্ছি এবং একটিকে অন্যের পক্ষে ত্যাগ করি না।

উপভোগ করুন!

গত দশ বছরে, আমরা তালিকা থেকে কোম্পানিগুলির জন্য অ্যাপ্লিকেশন তৈরি করেছি ফরচুন 500, এবং 500 জনের বেশি ব্যবহারকারী নয় এমন ব্যবসার জন্য। এই সমস্ত সময়, আমাদের প্রকৌশলীরা মূলত পিএইচপি-তে ব্যাকএন্ড বিকাশ করছে। কিন্তু দুই বছর আগে, কিছু একটা বড় প্রভাব ফেলেছিল শুধু আমাদের পণ্যের পারফরম্যান্সের উপরই নয়, তাদের স্কেলেবিলিটির উপরও - আমরা আমাদের প্রযুক্তি স্ট্যাকের মধ্যে Golang (Go) চালু করেছি।

প্রায় অবিলম্বে, আমরা আবিষ্কার করেছি যে Go আমাদের 40x পারফরম্যান্সের উন্নতি সহ আরও বড় অ্যাপ্লিকেশন তৈরি করতে দেয়। এটির সাহায্যে, আমরা আমাদের বিদ্যমান পিএইচপি পণ্যগুলিকে প্রসারিত করতে সক্ষম হয়েছি, উভয় ভাষার সুবিধাগুলিকে একত্রিত করে তাদের উন্নতি করতে পেরেছি।

আমরা আপনাকে বলব কিভাবে Go এবং PHP এর সংমিশ্রণ প্রকৃত উন্নয়ন সমস্যা সমাধানে সাহায্য করে এবং কীভাবে এটি আমাদের জন্য একটি টুলে পরিণত হয়েছে যা এর সাথে সম্পর্কিত কিছু সমস্যা থেকে মুক্তি পেতে পারে। পিএইচপি মৃতপ্রায় মডেল.

আপনার দৈনন্দিন পিএইচপি উন্নয়ন পরিবেশ

পিএইচপি ডাইং মডেলটিকে পুনরুজ্জীবিত করতে আপনি কীভাবে গো ব্যবহার করতে পারেন সে সম্পর্কে কথা বলার আগে, আসুন আপনার ডিফল্ট পিএইচপি বিকাশের পরিবেশটি একবার দেখে নেওয়া যাক।

বেশিরভাগ ক্ষেত্রে, আপনি nginx ওয়েব সার্ভার এবং PHP-FPM সার্ভারের সংমিশ্রণ ব্যবহার করে আপনার অ্যাপ্লিকেশনটি চালান। প্রাক্তনটি স্ট্যাটিক ফাইলগুলি পরিবেশন করে এবং নির্দিষ্ট অনুরোধগুলি PHP-FPM-এ পুনঃনির্দেশ করে, যখন PHP-FPM নিজেই PHP কোড নির্বাহ করে। আপনি হয়তো Apache এবং mod_php এর কম জনপ্রিয় সমন্বয় ব্যবহার করছেন। কিন্তু যদিও এটি একটু ভিন্নভাবে কাজ করে, নীতিগুলি একই।

পিএইচপি-এফপিএম কীভাবে অ্যাপ্লিকেশন কোড নির্বাহ করে তা দেখে নেওয়া যাক। যখন একটি অনুরোধ আসে, PHP-FPM একটি PHP চাইল্ড প্রক্রিয়া শুরু করে এবং অনুরোধটির বিশদ বিবরণ তার অবস্থার অংশ হিসাবে পাস করে (_GET, _POST, _SERVER, ইত্যাদি)।

একটি পিএইচপি স্ক্রিপ্ট কার্যকর করার সময় রাষ্ট্র পরিবর্তন করতে পারে না, তাই ইনপুট ডেটার একটি নতুন সেট পাওয়ার একমাত্র উপায় হল প্রক্রিয়া মেমরি পরিষ্কার করা এবং এটি আবার শুরু করা।

এই মৃত্যুদন্ড মডেল অনেক সুবিধা আছে. আপনাকে মেমরি খরচ সম্পর্কে খুব বেশি চিন্তা করতে হবে না, সমস্ত প্রক্রিয়া সম্পূর্ণরূপে বিচ্ছিন্ন, এবং যদি তাদের মধ্যে একটি "মৃত্যু" হয় তবে এটি স্বয়ংক্রিয়ভাবে পুনরায় তৈরি হবে এবং এটি বাকি প্রক্রিয়াগুলিকে প্রভাবিত করবে না। কিন্তু এই পদ্ধতির অসুবিধাও রয়েছে যা অ্যাপ্লিকেশন স্কেল করার চেষ্টা করার সময় উপস্থিত হয়।

একটি নিয়মিত পিএইচপি পরিবেশের অসুবিধা এবং অদক্ষতা

আপনি যদি একজন পেশাদার পিএইচপি ডেভেলপার হন, তাহলে আপনি জানেন কোথায় একটি নতুন প্রকল্প শুরু করবেন - একটি কাঠামোর পছন্দের সাথে। এটি নির্ভরতা ইনজেকশন লাইব্রেরি, ORM, অনুবাদ এবং টেমপ্লেট নিয়ে গঠিত। এবং, অবশ্যই, সমস্ত ব্যবহারকারীর ইনপুট সুবিধামত একটি বস্তুতে রাখা যেতে পারে (Symfony/HttpFoundation বা PSR-7)। ফ্রেমওয়ার্ক শান্ত!

কিন্তু সবকিছুরই দাম আছে। যেকোনো এন্টারপ্রাইজ-লেভেল ফ্রেমওয়ার্কে, একটি সাধারণ ব্যবহারকারীর অনুরোধ বা একটি ডাটাবেসে অ্যাক্সেস প্রক্রিয়া করার জন্য, আপনাকে কমপক্ষে ডজন ডজন ফাইল লোড করতে হবে, অসংখ্য ক্লাস তৈরি করতে হবে এবং বেশ কয়েকটি কনফিগারেশন পার্স করতে হবে। কিন্তু সবচেয়ে খারাপ বিষয় হল যে প্রতিটি কাজ শেষ করার পরে, আপনাকে সবকিছু পুনরায় সেট করতে হবে এবং আবার শুরু করতে হবে: আপনি যে সমস্ত কোড শুরু করেছেন তা অকেজো হয়ে যায়, এর সাহায্যে আপনি আর অন্য অনুরোধ প্রক্রিয়া করতে পারবেন না। অন্য কোন ভাষায় লেখা যে কোন প্রোগ্রামারকে এটি বলুন, এবং আপনি তার মুখে বিভ্রান্তি দেখতে পাবেন।

পিএইচপি ইঞ্জিনিয়াররা চতুর অলস-লোডিং কৌশল, মাইক্রোফ্রেমওয়ার্ক, অপ্টিমাইজড লাইব্রেরি, ক্যাশে ইত্যাদি ব্যবহার করে বছরের পর বছর ধরে এই সমস্যাটি সমাধানের উপায় খুঁজছেন। কিন্তু শেষ পর্যন্ত, আপনাকে এখনও সম্পূর্ণ অ্যাপ্লিকেশন রিসেট করতে হবে এবং আবার শুরু করতে হবে। . (অনুবাদকের দ্রষ্টব্য: এর আবির্ভাবের সাথে এই সমস্যাটি আংশিকভাবে সমাধান করা হবে লোড পিএইচপি 7.4-এ)

গো সহ পিএইচপি কি একাধিক অনুরোধ টিকে থাকতে পারে?

পিএইচপি স্ক্রিপ্টগুলি লেখা সম্ভব যা কয়েক মিনিটের (ঘণ্টা বা দিন পর্যন্ত) বেশি থাকে: উদাহরণস্বরূপ, ক্রোন টাস্ক, CSV পার্সার, কিউ ব্রেকার। তারা সবাই একই দৃশ্যে কাজ করে: তারা একটি কাজ পুনরুদ্ধার করে, এটি কার্যকর করে এবং পরবর্তীটির জন্য অপেক্ষা করে। কোডটি সর্বদা মেমরিতে থাকে, মূল্যবান মিলিসেকেন্ড সংরক্ষণ করে কারণ ফ্রেমওয়ার্ক এবং অ্যাপ্লিকেশন লোড করার জন্য প্রয়োজনীয় অনেক অতিরিক্ত পদক্ষেপ রয়েছে।

কিন্তু দীর্ঘজীবী স্ক্রিপ্ট তৈরি করা সহজ নয়। যেকোন ত্রুটি প্রক্রিয়াটিকে সম্পূর্ণরূপে মেরে ফেলে, মেমরি লিক নির্ণয় করা বিরক্তিকর, এবং F5 ডিবাগিং আর সম্ভব নয়।

পিএইচপি 7 প্রকাশের সাথে পরিস্থিতির উন্নতি হয়েছে: একটি নির্ভরযোগ্য আবর্জনা সংগ্রহকারী উপস্থিত হয়েছে, এটি ত্রুটিগুলি পরিচালনা করা সহজ হয়ে উঠেছে এবং কার্নেল এক্সটেনশনগুলি এখন লিক-প্রুফ। সত্য, ইঞ্জিনিয়ারদের এখনও মেমরির বিষয়ে সতর্ক থাকতে হবে এবং কোডে রাষ্ট্রীয় সমস্যা সম্পর্কে সচেতন হতে হবে (এই জিনিসগুলিকে উপেক্ষা করতে পারে এমন কোন ভাষা আছে কি?)। তবুও, পিএইচপি 7 আমাদের জন্য কম চমক রয়েছে।

দীর্ঘস্থায়ী পিএইচপি স্ক্রিপ্টগুলির সাথে কাজ করার মডেলটি নেওয়া, HTTP অনুরোধগুলি প্রক্রিয়াকরণের মতো আরও তুচ্ছ কাজের সাথে মানিয়ে নেওয়া এবং এর ফলে প্রতিটি অনুরোধের সাথে স্ক্র্যাচ থেকে সবকিছু লোড করার প্রয়োজন থেকে মুক্তি পাওয়া কি সম্ভব?

এই সমস্যাটি সমাধান করার জন্য, আমাদের প্রথমে একটি সার্ভার অ্যাপ্লিকেশন প্রয়োগ করতে হবে যা HTTP অনুরোধগুলি গ্রহণ করতে পারে এবং প্রতিবার এটিকে হত্যা না করে একে একে পিএইচপি কর্মীকে পুনঃনির্দেশ করতে পারে।

আমরা জানতাম যে আমরা বিশুদ্ধ PHP (PHP-PM) বা একটি C এক্সটেনশন (Swoole) ব্যবহার করে একটি ওয়েব সার্ভার লিখতে পারি। এবং যদিও প্রতিটি পদ্ধতির নিজস্ব যোগ্যতা রয়েছে, উভয় বিকল্পই আমাদের জন্য উপযুক্ত নয় - আমরা আরও কিছু চেয়েছিলাম। আমাদের শুধু একটি ওয়েব সার্ভারের চেয়ে বেশি প্রয়োজন ছিল - আমরা এমন একটি সমাধান পাওয়ার আশা করেছিলাম যা আমাদের পিএইচপি-তে একটি "হার্ড স্টার্ট" এর সাথে সম্পর্কিত সমস্যাগুলি থেকে বাঁচাতে পারে, যা একই সময়ে নির্দিষ্ট অ্যাপ্লিকেশনের জন্য সহজেই অভিযোজিত এবং প্রসারিত হতে পারে। অর্থাৎ, আমাদের একটি অ্যাপ্লিকেশন সার্ভার দরকার ছিল।

এই সঙ্গে সাহায্য করতে পারেন? আমরা জানতাম যে এটি হতে পারে কারণ ভাষাটি অ্যাপ্লিকেশনগুলিকে একক বাইনারিতে কম্পাইল করে; এটা ক্রস-প্ল্যাটফর্ম; HTTP এর সাথে কাজ করার জন্য নিজস্ব, খুব মার্জিত, সমান্তরাল প্রসেসিং মডেল (একসঙ্গে) এবং একটি লাইব্রেরি ব্যবহার করে; এবং অবশেষে, হাজার হাজার ওপেন-সোর্স লাইব্রেরি এবং ইন্টিগ্রেশন আমাদের কাছে উপলব্ধ হবে।

দুটি প্রোগ্রামিং ভাষা একত্রিত করার অসুবিধা

প্রথমত, দুই বা ততোধিক অ্যাপ্লিকেশন একে অপরের সাথে কীভাবে যোগাযোগ করবে তা নির্ধারণ করা প্রয়োজন ছিল।

উদাহরণস্বরূপ, ব্যবহার করে চমৎকার লাইব্রেরি অ্যালেক্স প্যালেস্ট্রাসের মতে, পিএইচপি এবং গো প্রসেসের মধ্যে মেমরি ভাগ করা সম্ভব ছিল (অ্যাপাচিতে mod_php এর মতো)। কিন্তু এই লাইব্রেরির বৈশিষ্ট্য রয়েছে যা আমাদের সমস্যা সমাধানের জন্য এর ব্যবহার সীমিত করে।

আমরা একটি ভিন্ন, আরও সাধারণ পদ্ধতি ব্যবহার করার সিদ্ধান্ত নিয়েছি: সকেট/পাইপলাইনের মাধ্যমে প্রক্রিয়াগুলির মধ্যে মিথস্ক্রিয়া তৈরি করতে। এই পদ্ধতিটি গত কয়েক দশক ধরে নির্ভরযোগ্য বলে প্রমাণিত হয়েছে এবং অপারেটিং সিস্টেম স্তরে ভালভাবে অপ্টিমাইজ করা হয়েছে।

শুরু করার জন্য, আমরা প্রক্রিয়াগুলির মধ্যে ডেটা বিনিময় এবং সংক্রমণ ত্রুটিগুলি পরিচালনা করার জন্য একটি সাধারণ বাইনারি প্রোটোকল তৈরি করেছি। তার সহজতম আকারে, এই ধরনের প্রোটোকল অনুরূপ নেটস্ট্রিং с নির্দিষ্ট আকারের প্যাকেট হেডার (আমাদের ক্ষেত্রে 17 বাইট), এতে প্যাকেটের ধরন, এর আকার এবং ডেটার অখণ্ডতা পরীক্ষা করার জন্য একটি বাইনারি মাস্ক সম্পর্কে তথ্য রয়েছে।

পিএইচপি দিকে আমরা ব্যবহার করেছি প্যাক ফাংশন, এবং গো পাশে, লাইব্রেরি এনকোডিং/বাইনারী.

এটি আমাদের কাছে মনে হয়েছিল যে একটি প্রোটোকল যথেষ্ট নয় - এবং আমরা কল করার ক্ষমতা যুক্ত করেছি পিএইচপি থেকে সরাসরি নেট/আরপিসি গো পরিষেবা. পরবর্তীতে, এটি আমাদের উন্নয়নে অনেক সাহায্য করেছে, যেহেতু আমরা সহজেই পিএইচপি অ্যাপ্লিকেশনগুলিতে গো লাইব্রেরিগুলিকে একীভূত করতে পারি। এই কাজের ফলাফল দেখা যেতে পারে, উদাহরণস্বরূপ, আমাদের অন্যান্য ওপেন সোর্স পণ্যে গরিজ.

একাধিক পিএইচপি কর্মীদের মধ্যে কাজ বিতরণ করা

ইন্টারঅ্যাকশন মেকানিজম বাস্তবায়নের পর, আমরা পিএইচপি প্রসেসে কাজ স্থানান্তর করার সবচেয়ে কার্যকর উপায় সম্পর্কে ভাবতে শুরু করি। যখন একটি টাস্ক আসে, অ্যাপ্লিকেশন সার্ভারকে অবশ্যই এটি চালানোর জন্য একটি বিনামূল্যে কর্মী বেছে নিতে হবে। যদি কোনো কর্মী/প্রক্রিয়া কোনো ত্রুটি সহ প্রস্থান করে বা "মৃত্যু" করে, তাহলে আমরা এটি থেকে পরিত্রাণ পাই এবং এটি প্রতিস্থাপন করার জন্য একটি নতুন তৈরি করি। এবং যদি কর্মী/প্রক্রিয়াটি সফলভাবে সম্পন্ন হয়, আমরা তা কাজ সম্পাদনের জন্য উপলব্ধ কর্মীদের পুলে ফিরিয়ে দিই।

সক্রিয় কর্মীদের পুল সংরক্ষণ করতে, আমরা ব্যবহার করি বাফার চ্যানেল, পুল থেকে অপ্রত্যাশিতভাবে "মৃত" কর্মীদের অপসারণ করতে, আমরা ত্রুটিগুলি এবং শ্রমিকদের অবস্থা ট্র্যাক করার জন্য একটি প্রক্রিয়া যুক্ত করেছি৷

ফলস্বরূপ, আমরা একটি কার্যকরী পিএইচপি সার্ভার পেয়েছি যা বাইনারি আকারে উপস্থাপিত যেকোনো অনুরোধ প্রক্রিয়া করতে সক্ষম।

আমাদের অ্যাপ্লিকেশন একটি ওয়েব সার্ভার হিসাবে কাজ শুরু করার জন্য, আমাদের যেকোন আগত HTTP অনুরোধের প্রতিনিধিত্ব করার জন্য একটি নির্ভরযোগ্য PHP মান নির্বাচন করতে হয়েছিল। আমাদের ক্ষেত্রে, আমরা শুধু রূপান্তর ফরম্যাটে যান থেকে net/http অনুরোধ PSR-7যাতে এটি আজ উপলব্ধ বেশিরভাগ পিএইচপি ফ্রেমওয়ার্কের সাথে সামঞ্জস্যপূর্ণ।

যেহেতু PSR-7 অপরিবর্তনীয় বলে বিবেচিত হয় (কেউ কেউ টেকনিক্যালি বলতে পারে এটা নয়), ডেভেলপারদের এমন অ্যাপ্লিকেশন লিখতে হবে যেগুলো নীতিগতভাবে একটি বৈশ্বিক সত্তা হিসাবে অনুরোধটিকে বিবেচনা করে না। এটি দীর্ঘস্থায়ী পিএইচপি প্রক্রিয়ার ধারণার সাথে সুন্দরভাবে ফিট করে। আমাদের চূড়ান্ত বাস্তবায়ন, যা এখনও নামকরণ করা হয়নি, দেখতে এইরকম:

রোডরানারের সাথে পরিচয় উচ্চ কর্মক্ষমতা পিএইচপি অ্যাপ্লিকেশন সার্ভার

আমাদের প্রথম পরীক্ষার কাজটি ছিল একটি API ব্যাকএন্ড, যা পর্যায়ক্রমে অপ্রত্যাশিতভাবে ফেটে যায় (স্বাভাবিকের চেয়ে অনেক বেশি)। যদিও বেশিরভাগ ক্ষেত্রে nginx যথেষ্ট ছিল, আমরা নিয়মিত 502টি ত্রুটির সম্মুখীন হতাম কারণ আমরা লোডের প্রত্যাশিত বৃদ্ধির জন্য যথেষ্ট দ্রুত সিস্টেমে ভারসাম্য রাখতে পারিনি।

এই সমাধানটি প্রতিস্থাপন করতে, আমরা 2018 সালের প্রথম দিকে আমাদের প্রথম PHP/Go অ্যাপ্লিকেশন সার্ভার স্থাপন করেছি। এবং অবিলম্বে একটি অবিশ্বাস্য প্রভাব পেয়েছিলাম! আমরা কেবলমাত্র 502 ত্রুটি থেকে সম্পূর্ণরূপে পরিত্রাণ পাইনি, তবে আমরা সার্ভারের সংখ্যা দুই-তৃতীয়াংশ কমাতে সক্ষম হয়েছি, প্রকৌশলী এবং পণ্য পরিচালকদের জন্য প্রচুর অর্থ এবং মাথাব্যথার ওষুধ বাঁচিয়েছি।

বছরের মাঝামাঝি নাগাদ, আমরা আমাদের সমাধানটি উন্নত করেছি, এটিকে এমআইটি লাইসেন্সের অধীনে গিটহাবে প্রকাশ করেছি এবং এটির নামকরণ করেছি RoadRunner, এইভাবে তার অবিশ্বাস্য গতি এবং দক্ষতা জোর দেওয়া.

কিভাবে RoadRunner আপনার ডেভেলপমেন্ট স্ট্যাক উন্নত করতে পারে

আবেদন RoadRunner অনুরোধটি PHP-এ পৌঁছানোর আগে JWT যাচাইকরণের জন্য Go-এর দিকে মিডলওয়্যার নেট/http ব্যবহার করার অনুমতি দিয়েছে, সেইসাথে প্রমিথিউসে বিশ্বব্যাপী ওয়েবসকেট এবং সামগ্রিক অবস্থা পরিচালনা করার অনুমতি দিয়েছে।

অন্তর্নির্মিত RPC-এর জন্য ধন্যবাদ, আপনি এক্সটেনশন র‌্যাপার না লিখে PHP-এর জন্য যে কোনও Go লাইব্রেরির API খুলতে পারেন। আরও গুরুত্বপূর্ণ, RoadRunner দিয়ে আপনি নতুন নন-HTTP সার্ভার স্থাপন করতে পারেন। উদাহরণ PHP-এ চলমান হ্যান্ডলার অন্তর্ভুক্ত এডাব্লুএস ল্যাম্বদা, নির্ভরযোগ্য কিউ ব্রেকার তৈরি করা এবং এমনকি যোগ করা gRPC আমাদের অ্যাপ্লিকেশনগুলিতে।

PHP এবং Go সম্প্রদায়ের সাহায্যে, আমরা সমাধানের স্থায়িত্ব উন্নত করেছি, কিছু পরীক্ষায় অ্যাপ্লিকেশন কর্মক্ষমতা 40 গুণ পর্যন্ত বাড়িয়েছি, উন্নত ডিবাগিং টুলস, সিমফনি ফ্রেমওয়ার্কের সাথে ইন্টিগ্রেশন বাস্তবায়িত করেছি এবং HTTPS, HTTP/2 এর জন্য সমর্থন যোগ করেছি। প্লাগইন, এবং PSR-17।

উপসংহার

কিছু লোক এখনও PHP-এর পুরানো ধারণার মধ্যে আটকে আছে একটি ধীর, দুর্বোধ্য ভাষা যা শুধুমাত্র ওয়ার্ডপ্রেসের জন্য প্লাগইন লেখার জন্য ভাল। এই লোকেরা এমনকি বলতে পারে যে পিএইচপি-র এমন একটি সীমাবদ্ধতা রয়েছে: যখন অ্যাপ্লিকেশনটি যথেষ্ট বড় হয়ে যায়, তখন আপনাকে আরও একটি "পরিপক্ক" ভাষা বেছে নিতে হবে এবং বহু বছর ধরে জমে থাকা কোড বেসটি পুনরায় লিখতে হবে।

এই সবের জন্য আমি উত্তর দিতে চাই: আবার চিন্তা করুন। আমরা বিশ্বাস করি যে শুধুমাত্র আপনি PHP এর জন্য কোনো সীমাবদ্ধতা সেট করেন। আপনি একটি ভাষা থেকে অন্য ভাষাতে রূপান্তরিত করতে আপনার পুরো জীবন ব্যয় করতে পারেন, আপনার প্রয়োজনের জন্য নিখুঁত মিল খুঁজে বের করার চেষ্টা করতে পারেন, অথবা আপনি ভাষাকে হাতিয়ার হিসাবে ভাবতে শুরু করতে পারেন। পিএইচপি-র মতো ভাষার অনুমিত ত্রুটিগুলি আসলে এর সাফল্যের কারণ হতে পারে। এবং যদি আপনি এটিকে Go এর মতো অন্য ভাষার সাথে একত্রিত করেন, তাহলে আপনি যে কোনও একটি ভাষা ব্যবহার করার জন্য সীমাবদ্ধ থাকলে তার চেয়ে অনেক বেশি শক্তিশালী পণ্য তৈরি করবেন।

Go এবং PHP এর একগুচ্ছ সাথে কাজ করার পরে, আমরা বলতে পারি যে আমরা তাদের ভালবাসি। আমরা অন্যের জন্য একটিকে উৎসর্গ করার পরিকল্পনা করি না - বিপরীতে, আমরা এই দ্বৈত স্ট্যাক থেকে আরও বেশি মূল্য পাওয়ার উপায়গুলি সন্ধান করব।

UPD: আমরা RoadRunner এর নির্মাতা এবং মূল নিবন্ধের সহ-লেখককে স্বাগত জানাই - ল্যাচেসিস

উত্স: www.habr.com