গ্রেডন হোয়ার এবং রাস্ট: মেমরি-নিরাপদ সিস্টেম প্রগতির রূপান্তর

এই কাহিনি কী ব্যাখ্যা করে (এবং কী করে না)

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

আমরা “সিস্টেম প্রোগ্রামিং” বলতে কী বুঝি

“সিস্টেম প্রোগ্রামিং” মেশিনের কাছাকাছি থাকে—এবং আপনার প্রডাক্টের ঝুঁকিরও কাছাকাছি। এটি ব্রাউজার, গেম ইঞ্জিন, অপারেটিং সিস্টেম কম্পোনেন্ট, ডেটাবেস, নেটওয়ার্কিং, এবং এমবেডেড সফটওয়্যারে দেখা যায়—এসব জায়গায় সাধারণত আপনি চান:

• উচ্চ কর্মক্ষমতা (কাজ দ্রুত ও পূর্বানুমেয় হতে হবে)
• নিম্ন-স্তরের নিয়ন্ত্রণ (মেমরি বরাদ্দ, থ্রেডিং, ডেটা বিন্যাস)
• নির্ভরযোগ্যতা (ক্র্যাশ এবং সিকিউরিটি বাগের দায় খুবই বেশি)

ঐতিহ্যগতভাবে, এই সম্মিলন দলগুলিকে C ও C++-এর দিকে নিয়ে যেত—সঙ্গে বিস্তর বিধি, রিভিউ, এবং টুলিং যাতে মেমরি-সংক্রান্ত বাগ কমে।

আমরা কোন মূল প্রতিশ্রুতি খোলাসা করব

রাস্টের প্রধান প্রতিশ্রুতি বলা সহজ কিন্তু বাস্তবে ডেলিভার করা কঠিন:

গারবেজ কালেক্টর ছাড়া মেমরি নিরাপত্তা।

রাস্ট নির্দিষ্ট ভাবে use-after-free, double-free, এবং অনেক ধরনের ডাটা রেস প্রতিরোধ করতে চায়—কিন্তু একটি রানটাইম-ভিত্তিক GC-এ নির্ভর না করে। পরিবর্তে, রাস্ট মালিকানা এবং বোরোইংয়ের মাধ্যমে অনেক কাজ কম্পাইল টাইমে সরিয়ে দেয়।

কী অন্তর্ভুক্ত—এবং কী নয়

আপনি ইতিহাস পাবেন (প্রাথমিক ধারনা থেকে Mozilla-র অন্তর্ভুক্তি পর্যন্ত) এবং মূল ধারণাগুলো (মালিকানা, বোরোইং, লাইফটাইম, safe বনাম unsafe) সহজ ভাষায় ব্যাখ্যা করা।

যা আপনি পাবেন না তা হলো সম্পূর্ণ রাস্ট টিউটোরিয়াল, সব সিনট্যাক্সের ট্যুর, বা ধাপে ধাপে প্রজেক্ট সেটআপ। এটিকে ধরা যেতে পারে রাস্ট ডিজাইনের “কেন” হিসেবে—পর্যাপ্ত উদাহরণসহ যাতে ধারণাগুলো স্পষ্ট হয়।

লেখকের নোট: পুরো পিসি লক্ষ্য ~৩,০০০ শব্দ—সংক্ষিপ্ত উদাহরণ রাখার জায়গা রেখে, কিন্তু রেফারেন্স ম্যানুয়াল হয়ে না যেতে।

গ্রেডন হোয়ার-এর প্রাথমিক পরীক্ষা যা রাস্টে পরিণত হয়

রাস্ট কোনো কেমিটির নকশাধীন “পরবর্তী C++” হিসেবে শুরু করে নি। এটি ২০০৬ সালে গ্রেডন হোয়ার-এর একটি ব্যক্তিগত পরীক্ষায় শুরু হয়েছিল—প্রথমে তিনি স্বাধীনভাবে কাজ করেছিলেন, পরে এটি আরও বিস্তৃত মনোযোগ টুল। ওই উত্সটি গুরুত্বপূর্ণ: অনেক প্রাথমিক নকশা সিদ্ধান্তই প্রতিদিনের কষ্ট কমানোর প্রচেষ্টা হিসেবে পড়ে, ভাষা তত্ত্ব জিতে নেওয়ার চেষ্টা হিসেবে না।

প্রারম্ভিক অনুপ্রেরণা: নিম্ন-স্তরের ক্ষমতা, কম ফুট-গান

হোয়ার ছিল ঠিক কীভাবে নিম্ন-স্তরের, উচ্চ-পারফরম্যান্স সফটওয়্যার লিখবেন যা গারবেজ কালেক্টরের উপর নির্ভর না করে—তার সাথেই C ও C++-এ ক্র্যাশ ও সিকিউরিটি বাগের সাধারণ কারণগুলোও এড়াতে চেয়েছিলেন। টেনশনটি সিস্টেম প্রোগ্রামারদের কাছে পরিচিত:

• আপনি গতি ও বিন্যাসের জন্য মেমরি ও লেআউটের সরাসরি নিয়ন্ত্রণ চান।
• আপনি কার্যকরী নিরাপত্তা চান যেন ভুলগুলো চুপচাপ ভঙ্গুরতায় পরিণত না হয়।
• আপনিConcurrency এমনভাবে চান যে তা ব্যবহারযোগ্য হয়, কারণ আধুনিক পারফরম্যান্স প্রায়শই বহু থ্রেড মানে।

রাস্টের “GC ছাড়া মেমরি নিরাপত্তা” দিকটি প্রথমে মার্কেটিং ট্যাগলাইন ছিল না। এটি ছিল ডিজাইনের লক্ষ্য: সিস্টেম কাজে উপযুক্ত পারফরম্যান্স বজায় রেখে অনেক মেমরি বাগ প্রকাশ করা কঠিন করে তোলা।

কেন একটি নতুন ভাষা (শুধু উন্নত টুল নয়)

প্রশ্ন করা যুক্তিযুক্ত: কেন এটা “শুধু C/C++-এর জন্য একটি ভালো কম্পাইলার” ছিল না? স্ট্যাটিক অ্যানালাইসিস, স্যানিটাইজার, এবং নিরাপদ লাইব্রেরি অনেক সমস্যা রোধ করে, কিন্তু সাধারণত তারা গ্যারান্টি দিতে পারে না। মূল ভাষাগুলো এমন প্যাটার্ন অনুমতি দেয় যেগুলো সম্পূর্ণরূপে বাইরের থেকে নিয়ন্ত্রন করা কঠিন বা অসম্ভব।

রাস্টের বাজি ছিল মূল নিয়মগুলো ভাষা ও টাইপ সিস্টেমে সরিয়ে দেওয়া যাতে নিরাপত্তা হয়ে ওঠে ডিফল্ট আউটকাম, আবার স্পষ্টভাবে চিহ্নিত এস্কেপ হ্যাচে ম্যানুয়াল কন্ট্রোল রাখে।

গল্পকে ভিত্তিতে রাখা: তথ্য বনাম লোককথা

রাস্টের প্রাথমিক দিনগুলো সম্পর্কে কিছু বিবরণ বিস্তারিত ভ্রম হিসেবে ঘোরে (প্রায়ই টক ও ইন্টারভিউতে পুনরাবৃত্তি হয়)। এই উদ্ভব কাহিনি বলার সময়, ব্যাপকভাবে দলিলভিত্তিক মাইলফলকগুলো—যেমন ২০০৬ শুরু তারিখ এবং রাস্ট পরে Mozilla Research-এ গৃহীত হওয়া—কে ব্যক্তিগত স্মৃতি ও মাধ্যমিক পুনরবর্তনের থেকে আলাদা করা ভালো।

প্রাইমারি সোর্স হিসেবে খুঁজুন: প্রাথমিক রাস্ট ডকুমেন্টেশন ও ডিজাইন নোট, গ্রেডন হোয়ার-এর টক/ইন্টারভিউ, এবং Mozilla/Servo-যুগের পোস্টগুলো যা ব্যাখ্যা করে কেন প্রজেক্টটি নেওয়া হয়েছিল এবং কীভাবে লক্ষ্যগুলো ফ্রেম করা হয়েছিল। একটি ভালো “আরও পড়ুন” অংশ পাঠকদের ঐ অরিজিনালগুলোর দিকে ইঙ্গিত করতে পারে (দেখুন /blog সম্পর্কিত লিংকগুলো)।

সিস্টেম প্রোগ্রামিং সমস্যা: দ্রুত কোড, ভঙ্গুর মেমরি

সিস্টেম প্রোগ্রামিং প্রায়শই হার্ডওয়্যারের কাছাকাছি কাজ করা মানে। এই কাছাকাছি থাকা কোডকে দ্রুত ও রিসোর্স-কার্যকর করে—কিন্তু একই কারণে মেমরি ভুলগুলো এত কষ্টদায়ক।

সাধারণ অপরাধীরা: মেমরি বাগ

কয়েকটি ক্লাসিক বাগ বারবার দেখা যায়:

• Use-after-free: প্রোগ্রাম মেমরি মুক্ত করার পরে সেটি ব্যবহার চালিয়ে যায়, যেমন আপনি ফেলে দেওয়া নোটপ্যাডে লেখা চালিয়ে যাচ্ছেন।
• Double free: একই মেমরি দুটি বার মুক্ত করা হয়, যা আলোকেটরকে বিভ্রান্ত করে এবং শোষণের সুযোগ দিতে পারে।
• Buffer overflow: ডেটা বরাদ্দ করা স্থানের বাইরে ছড়িয়ে পড়ে, পার্শ্ববর্তী ডেটা বা কন্ট্রোল ফ্লো দূষিত করতে পারে।

এই ত্রুটিগুলো সবসময় স্পষ্ট নয়। একটি প্রোগ্রাম সপ্তাহ ধরে “চলতে” পারে, তারপর একটি বিরল টাইমিং বা ইনপুট প্যাটার্নে ক্র্যাশ করে।

কেন টেস্টিং আপনাকে বাঁচায় না

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

প্রকৃত খরচ: সিকিউরিটি, স্থিতিশীলতা, সময়

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

গতি বনাম নিরাপত্তা: মূল টেনশন

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

কেন “গারবেজ কালেক্টর ছাড়া মেমরি নিরাপত্তা” বড় ব্যাপার ছিল

গারবেজ কালেক্টর (GC) হলো ভাষাগুলোর একটি সাধারণ উপায় মেমরি বাগ প্রতিরোধ করার: রানটাইম ট্র্যাক করে কোন অবজেক্টগুলো প্রাপ্য এবং অবশিষ্টগুলো পুনরুদ্ধার করে দেয়। এতে use-after-free, double-free, এবং অনেক লিক ধরণ অদৃüşt হয়—কারণ প্রোগ্রাম সাধারণত “ভোলা” উপলব্ধি করে না একইভাবে।

সিস্টেম-ধাঁচা কোডে GC-র ট্রেডঅফ

GC নিজে “খারাপ” নয়, কিন্তু এটি প্রোগ্রামের পারফরম্যান্স প্রোফাইল বদলে দেয়। অধিকাংশ কালেক্টর কিছু মিলিয়ে দেয়:

• পজ টাইমস (যদিও ছোট বা ইনক্রিমেন্টাল হোক), যা স্টাটার হিসেবে দেখা দিতে পারে
• রানটাইম ওভারহেড বরাদ্দ ট্র্যাকিং ও রিচেবলিটি হিসাবের জন্য
• কম পূর্বানুমেয় লেটেন্সি, কারণ সংগ্রহ কাজ তখন হয় যখন রানটাইম ঠিক করে

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

কোথায় পূর্বানুমেয়তা জরুরি

সিস্টেম প্রোগ্রামিং-এ worst-case প্রায়ই সবচেয়ে গুরুত্বপূর্ণ। একটি ব্রাউজার ইঞ্জিনকে মসৃণ রেন্ডারিং দরকার; একটি এমবেডেড কন্ট্রোলারের কড়া টাইমিং বাধ্যতা থাকতে পারে; একটি নিম্ন-লেটেন্সি সার্ভার লোডের অধীনে টেইল লেটেন্সি শক্তভাবে ধরে রাখতে চায়। এই পরিবেশে “সাধারণত দ্রুত” এর চেয়ে “গড়ে পূর্বানুমেয়” বেশি মূল্যবান।

রাস্টের প্রস্তাব: নিয়ন্ত্রণ সহ নিরাপত্তা

রাস্টের বড় প্রতিশ্রুতি ছিল: মেমরি ও ডেটা লেআউটের ওপর C/C++-সদৃশ নিয়ন্ত্রণ রাখুন, কিন্তু গারবেজ কালেক্টরের ওপর নির্ভর না করে মেমরি নিরাপত্তা প্রদান করুন। লক্ষ্য ছিল পূর্বানুমেয় পারফরম্যান্স ব্যাবহার—একই সঙ্গে নিরাপদ কোডকে ডিফল্ট করা।

এটি GC-কে নিম্নমান দাবি করা নয়। এটা বাজি ছিল যে একটি বড় ও গুরুত্বপূর্ণ মাঝামাঝি জমি আছে: সফটওয়্যার যা নিম্ন-স্তরের নিয়ন্ত্রণ এবং আধুনিক নিরাপত্তা চায়।

মালিকানা: রাস্টের নিরাপত্তার কেন্দ্রীয় ধারণা

Ownership রাস্টের সহজ কিন্তু বড় ধারণা: প্রতিটি মানের একটি একক মালিক থাকে, যে সেটি আর প্রয়োজন নেই বুঝলে পরিষ্কার করে ফেলে।

এই এক নিয়ম অনেক ম্যানুয়াল “কে এই মেমরিটি ফ্রি করবে?”-র হিসাব বদলে দেয় যা C ও C++ প্রোগ্রামাররা মাথায় রেখে চলেন। শৃঙ্খলার উপর নির্ভর করার পরিবর্তে রাস্ট ক্লিনআপকে পূর্বানুমেয় করে তোলে।

মুভ বনাম কপি (সরল ভাষায়)

যখন আপনি কপি করেন, আপনি দুইটি স্বাধীন কপি পান। যখন আপনি মুভ করেন, আপনি মূলটি হস্তান্তর করে দিচ্ছেন—মুভের পরে পুরনো ভেরিয়েবলটি সেটি ব্যবহার করতে পারে না।

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

নিচে একটি ক্ষুদ্র ছদ্ম-কোডে ধারণা:

buffer = make_buffer()
ownerA = buffer      // ownerA owns it
ownerB = ownerA      // move ownership to ownerB
use(ownerA)          // not allowed: ownerA no longer owns anything
use(ownerB)          // ok
// when ownerB ends, buffer is cleaned up automatically

লাভ: গারবেজ কালেক্টর ছাড়া ক্লিনআপ

একটি মানের সবসময় ঠিক একটি মালিক থাকার কারণে, রাস্ট জানে কখন একটি মান পরিষ্কার করতে হবে: যখন তার মালিক স্কোপ থেকে বের হয়। তার মানে স্বয়ংক্রিয় মেমরি ম্যানেজমেন্ট (আপনি প্রতিটি জায়গায় free() কল করবেন না) কিন্তু একটি গারবেজ কালেক্টরের প্রয়োজন ছাড়াই।

বাস্তবে এটি কী প্রতিরোধ করে

এই মালিকানা নিয়ম অনেক ক্লাসিক সমস্যা ব্লক করে:

• Double-free: দুই “মালিক” একই মেমরি দুবার মুক্ত করার চেষ্টা করে।
• Use-after-free: কোড একটি পয়েন্টার ব্যবহার করে যখন মেমরি ইতিমধ্যেই মুক্ত।

রাস্টের মালিকানা মডেল কেবল সুরক্ষিত অভ্যাস উত্সাহ দেয় না—এটি অনেক ঝুঁকিপূর্ণ অবস্থাকে অনুপস্থিত করবে, যা বাকী রস্ট নিরাপত্তা বৈশিষ্ট্যের ভিত্তি।

বোরোইং, লাইফটাইম, এবং বোরো চেকার

মালিকানা ব্যাখ্যা করে কে মানের “মালিক”। বোরোইং ব্যাখ্যা করে প্রোগ্রামের অন্য অংশগুলো কীভাবে অস্থায়ীভাবে সেই মান ব্যবহার করতে পারে মালিকানা নেয়া ছাড়াই।

বোরোইং: মালিকানা ছাড়া প্রবেশাধিকার

যখন আপনি রাস্টে কিছু বোরো করেন, আপনি সেটির একটি রেফারেন্স পান। আসল মালিক মেমরি ক্লিয়ানে দায়ী থাকে; বোরোয়ার কেবল একটি সময়ের জন্য ব্যবহার করার অনুমতি পায়।

রাস্টে দুটি ধরণের বোরো আছে:

• শেয়ার্ড বোরো (&T): কেবল রিড-অনলি অ্যাক্সেস।
• মিউটেবল বোরো (&mut T): রিড-রাইট অ্যাক্সেস।

মূল নিয়ম: অনেক পাঠক বা এক লেখক

রাস্টের কেন্দ্রীয় বোরো নিয়ম বলতে সহজ এবং ব্যবহারিকভাবে শক্তিশালী:

• আপনি একই সময়ে অনেক শেয়ার্ড রেফারেন্স রাখতে পারেন, অথবা
• আপনি একটি মিউটেবল রেফারেন্স রাখতে পারেন,\n- কিন্তু একসাথে দুটিই নয়।

এই নিয়মটি এমন একটি সাধারণ বাগ প্রতিরোধ করে: প্রোগ্রামের এক অংশ ডেটা পড়ছে যখন অন্য অংশ তা পরিবর্তন করে নিচ্ছে।

লাইফটাইম: “এই রেফারেন্সটি কতক্ষণ বৈধ?”

একটি রেফারেন্স কেবল তখনই নিরাপদ যখন তা কখনও সেই ডেটার মৃত্যুর চেয়ে দীর্ঘজীবী না হয়—রাস্ট এটিকে লাইফটাইম বলে।

আপনাকে ফরমালিটি জানার প্রয়োজন নেই: একটি রেফারেন্স তার মালিকের মেয়াদ শেষ হওয়ার পরে টিকে থাকতে পারবে না।

বোরো চেকার: প্রোগ্রাম চলার আগেই নিরাপত্তা

রাস্ট এই নিয়মগুলোকে কম্পাইল টাইমে বোরো চেকার-এর মাধ্যমে জোরদার করে। একটি খারাপ রেফারেন্স বা ঝুঁকিপূর্ণ মিউটেশন ধরা না পাওয়ার আশায় না রেখে, রাস্ট এমন কোড কম্পাইল হতে দেবে না যা মেমরি ভুলভাবে ব্যবহার করতে পারে।

একটি পরিচিত উদাহরণ

একটি শেয়ার্ড ডকুমেন্ট ভাবুন:

• যদি অনেক মানুষ দেখছে, সেটি শেয়ার্ড বোরোর মতো—নিরাপদ, কারণ কেউ টেক্সট বদলাচ্ছে না।
• যদি একজন সম্পাদনা করছে, এটি মিউটেবল বোরোর মতো—নিরাপদ, কারণ একটি একক সত্যিই আছে।
• কাউকে সম্পাদনা করার সময় অন্যরা পড়তে দিলে পাঠকরা অর্ধ-সম্পাদিত পরিবর্তন দেখতে পারে—রাস্ট সেই পরিস্থিতি ডিজাইন করে প্রতিরোধ করে।

সমান্তরালতার জন্য নিরাপত্তা: ডাটা রেস ডিজাইন করে প্রতিরোধ

Concurrency হলো সেই জায়গা যেখানে “আমার মেশিনে এটা কাজ করে” বাগগুলো লুকাতে যায়। যখন দুইটি থ্রেড একই সময়ে চলে, সেগুলো আচরণে বিস্ময়কর ইন্টারঅ্যাকশন করতে পারে—বিশেষ করে যখন তারা ডেটা শেয়ার করে।

ডাটা রেস কী (এবং কেন এটা বিপজ্জনক)

একটি ডাটা রেস ঘটে যখন:

• একাধিক থ্রেড একই মেমরিতে একই সময়ে অ্যাক্সেস করে,
• অন্তত একটি অ্যাক্সেস লেখালেখি করে, এবং
• কোনো সমন্বয় নেই।

ফলাফল শুধু “ভুল আউটপুট” নয়। ডাটা রেস রাষ্ট্রকে দূষিত করতে, প্রোগ্রাম ক্র্যাশ করাতে, বা সিকিউরিটি ঝুঁকি তৈরি করতে পারে। আরও খারাপ, এগুলো অনিয়মিত—লগ যোগ করলে বা ডিবাগ করলে বাগটি অদৃশ্য হয়ে যেতে পারে।

রাস্টের বাজি: ঝুঁকিপূর্ণ জিনিসকে ডিফল্টভাবে কঠিন করে দেওয়া

রাস্ট একটি অস্বাভাবিক অবস্থান নেয়: প্রতি প্রোগ্রামারকে সবসময় নিয়ম মনে রাখার উপর বিশ্বাস না করে, এটি বহু অনিরাপদ সমান্তরাল প্যাটার্নকে safe code-এ প্রকাশ করা অসম্ভব করার চেষ্টা করে।

উচ্চ স্তরে, রাস্টের মালিকানা-ও-বোরো নিয়ম এক থ্রেড কোডের বাইরে পৌঁছায়—এগুলো যা আপনি থ্রেডের মধ্যে শেয়ার করতে চান তা নিয়ন্ত্রণ করে। যদি কম্পাইলার প্রমাণ করতে না পারে যে শেয়ার করা অ্যাক্সেস সমন্বিত, তাহলে কোড কম্পাইল হবে না।

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

উদাহরণ: দুই থ্রেড একই ডেটা আপডেট করছে

ধরা যাক দুই থ্রেড কাউন্টার বাড়াচ্ছে:

• অনেক ভাষায় আপনি একই রেফারেন্স/পয়েন্টার দুই থ্রেডে দিতে পারেন।
• যদি দুটো থ্রেড একই সময়ে লিখে, কাউন্টারে লস্ট আপডেট বা অবস্থা দুর্নীতিগ্রস্ত হতে পারে।

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

নিম্ন-স্তরের নিয়ন্ত্রণ এখনও আছে—পরিষ্কারভাবে চিহ্নিত

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

রাস্ট কোথায় রেখা টেনে দেয়: Safe বনাম Unsafe কোড

রাস্টের সুরক্ষার খ্যাতি সম্পূর্ণরূপে অভেদ্য শোনালেও, সঠিকভাবে বলা উচিত—রাস্ট সেই সীমানা স্পষ্ট করে দেয় safe এবং unsafe প্রোগ্রামিংয়ের মধ্যে—এবং তা সহজে অডিটযোগ্য করে তোলে।

Safe Rust: ডিফল্ট

অধিকাংশ রাস্ট কোডই “safe Rust।” এখানে কম্পাইলার এমন নিয়ম জোরদার করে যা সাধারণ মেমরি বাগ প্রতিরোধ করে: use-after-free, double free, dangling pointers, এবং ডাটা রেস। আপনি এখনও লজিকগত ভুল করতে পারেন, কিন্তু সাধারণ ভাষা ফিচার দ্বারা সহজে মেমরি-নিরাপত্তা লঙ্ঘন করা যায় না।

একটি গুরুত্বপূর্ণ দিক: safe Rust মানে “ধীর গতি” নয়। অনেক উচ্চ-পারফরম্যান্স প্রোগ্রাম সম্পূর্ণভাবে safe Rust-এ লেখা—যেখানে কম্পাইলার সক্রিয়ভাবে অপ্টিমাইজ করে পারে কারণ এটি জানে নিয়মগুলো মানা হচ্ছে।

Unsafe Rust: স্পষ্ট এস্কেপ হ্যাচ

unsafe আছে কারণ সিস্টেম প্রোগ্রামিং কখনও কখনও এমন ক্ষমতা চায় যা কম্পাইলার সাধারণভাবে নিরাপদ বলে প্রমাণ করতে পারে না। সাধারণ কারণগুলো:

• FFI (foreign function interfaces): C/C++ লাইব্রেরি কল করা বা সেগুলো থেকে ডাকা।
• নিম্ন-স্তরের অপারেশন: হার্ডওয়্যার, মেমরি-ম্যাপড আইও, বা OS API-র সঙ্গে ইন্টারঅ্যাকশন।
• পারফরম্যান্স-ক্রিটিক্যাল বিশেষ কেস: ডেটা স্ট্রাকচার, আলোকেটর, বা concurrency প্রিমিটিভস বাস্তবায়ন যেখানে ম্যানুয়ালি ইনভেরিয়েন্ট ধরে রাখা লাগে।

unsafe ব্যবহার করলেই সব চেক বন্ধ হয়ে যায় না। এটি কেবল কিছু অপারেশন (যেমন র-এ ডিরেফারেন্সিং) অনুমোদন করে যা অন্যথায় নিষিদ্ধ।

আপনি যে সীমা নির্ধারণ করতে পারেন

রাস্ট আপনাকে বাধ্য করে unsafe ব্লক ও ফাংশন চিহ্নিত করতে—এটি কোড রিভিউতে ঝুঁকি দৃশ্যমান করে। সাধারণ প্যাটার্ন হলো একটি ছোট “unsafe কোর” রাখা এবং সেটিকে সেফ API-তে ওয়াপ করে দেওয়া, ফলে প্রজেক্টের অধিকাংশ অংশ safe Rust-এ থাকে আর ছোট, ঠিকঠাক পরিচিত অংশ ইনভেরিয়েন্ট বজায় রাখে।

ব্যবহারিক গাইডলাইন

unsafe-কে একটি শক্তিশালী টুল ধরা উচিত:

• unsafe ব্লকগুলো ছোট ও লোকালাইজড রাখুন।
• স্পষ্ট মন্তব্য লিখুন যেখানে নিরাপত্তার অনুমানগুলো ব্যাখ্যা করা আছে।
• unsafe পরিবর্তনের জন্য অতিরিক্ত রিভিউ বাধ্য করুন।
• টেস্ট রাখুন, স্ট্রেস টেস্টসহ এজ কেস নিরীক্ষার জন্য।

ভালো করলে, unsafe Rust সিস্টেম প্রোগ্রামিংয়ের সেই অংশগুলোর নিয়ন্ত্রিত ইন্টারফেস হয়ে ওঠে—যেখানে ম্যানুয়াল নিখুঁততা দরকার, কিন্তু বাকি পুরো কোডবেস রাস্টের নিরাপত্তা সুবিধা পায়।

Mozilla, Servo, এবং পরীক্ষণ থেকে ইকোসিস্টেমে রূপান্তর

রাস্ট কাগজে কেবল চমৎকার ধারণা রাখে বলে “বাস্তব” হয়নি—এটি বাস্তব হয়ে উঠল কারণ Mozilla ঐ ধারণাগুলোকে চাপের নিচে টেস্ট করেছিল।

কেন Mozilla-র অনুকূলতা ছিল

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

রাস্টকে সমর্থন করা ঐ লক্ষ্যটির সাথে খাপ খায়: সিস্টেম প্রোগ্রামিংয়ের গতি বজায় রেখে বড় বাগ শ্রেণী হ্রাস করা। Mozilla-র অংশগ্রহণ পাশাপাশিই বিশ্বের কাছে সংকেত পাঠিয়েছিল যে রাস্ট কেবল গ্রেডন হোয়ার-এর ব্যক্তিগত পরীক্ষা নয়—বরং একটি ভাষা যা পৃথিবীর কঠিনতম কোডবেসগুলোর একটির বিরুদ্ধে পরীক্ষা করা যেতে পারে।

Servo: একটি পরীক্ষাগার, কেবল একটি ডেমো নয়

Servo—পরীক্ষামূলক ব্রাউজার ইঞ্জিন প্রজেক্ট—হল রাস্টকে স্কেলে টেস্ট করার একটি উচ্চ-প্রোফাইল জায়গা। লক্ষ্য ছিল ব্রাউজার বাজার জেতা নয়। Servo ছিল একটি ল্যাব যেখানে ভাষা ফিচার, কম্পাইলার ডায়াগনস্টিক, এবং টুলিং বাস্তব পরিস্থিতির সাথে পরীক্ষা করা হয়েছিল: বিল্ড সময়, ক্রস-প্ল্যাটফর্ম সাপোর্ট, ডেভিএক্স, পারফরম্যান্স টিউনিং, এবং প্যারালালিজমে সঠিকতা।

আরও গুরুত্বপূর্ণভাবে, Servo ভাষার আশেপাশে ইকোসিস্টেম গঠন করতে সাহায্য করেছিল: লাইব্রেরি, বিল্ড টুলিং, কনভেনশন, এবং ডিবাগিং অনুশীলন—যা টয় প্রোগ্রামের বাইরে গেলে জরুরি।

যে ফিডব্যাক লুপ রাস্টকে ঘুরিয়েছে

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

এই ধাপের পরে রাস্টের বিস্তৃত বিবর্তন সম্পর্কে জানতে চাইলে দেখুন /blog/rust-memory-safety-without-gc।

রাস্ট কিভাবে C, C++, এবং GC-ভিত্তিক ভাষার সঙ্গে তুলনা করে

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

রাস্ট বনাম C/C++: ম্যানুয়াল মেমরি বনাম যাচাই করা নিয়ম

C ও C++-এ ডেভেলপাররা সরাসরি মেমরি পরিচালনা করে—অলকেট, ফ্রি, এবং পয়েন্টারগুলোকে বৈধ রাখার নিশ্চয়তা দেয়। ঐ স্বাধীনতা শক্তিশালী, কিন্তু use-after-free, double-free, buffer overflow, এবং সূক্ষ্ম লাইফটাইম বাগ সৃষ্টি করা সহজ করে তোলে। কম্পাইলার সাধারণত আপনাকে বিশ্বাস করে।

রাস্ট সেই সম্পর্ক উল্টে দেয়। আপনি এখনও নিম্ন-স্তরের নিয়ন্ত্রণ পান (স্ট্যাক বনাম হিপ সিদ্ধান্ত, পূর্বানুমেয় লেআউট), কিন্তু কম্পাইলার মান সম্পর্কে নিয়ম জোরদার করে—কে একটি মানের মালিক এবং রেফারেন্স কতক্ষণ থাকতে পারে। “পয়েন্টার নিয়ম মানো” বলার বদলে রাস্ট বলে “কম্পাইলারকে নিরাপত্তার প্রমাণ দেখাও,” এবং safe Rust-এ এমন কোড কম্পাইল হবে না যা ঐ গ্যারান্টি ভাঙতে পারে।

রাস্ট বনাম GC ভাষা: পূর্বানুমেয়তা ও নিয়ন্ত্রণ বনাম সুবিধা

গারবেজ-কালেক্টেড ভাষা (যেমন Java, Go, C#, বা অনেক স্ক্রিপ্টিং ভাষা) ম্যানুয়াল মেমরি পরিচালনার বদলে সুবিধা দেয়: অবজেক্টগুলো তাদের পৌঁছনীয়তা হারালে স্বয়ংক্রিয়ভাবে মুক্ত হয়ে যায়। এটি উৎপাদনশীলতায় বড় বাড়তি দেয়।

রাস্টের প্রতিশ্রুতি—“GC ছাড়া মেমরি নিরাপত্তা”—মানে আপনি রানটাইম GC-এর জন্য মূল্য পরেন না, যা অত্যন্ত ধাঁচা নিয়ন্ত্রণ দরকার হলে সহায়ক (লেটেন্সি, মেমরি ফিটিং, স্টার্টআপ টাইম, বা সীমিত পরিবেশে চালানোর ক্ষেত্রে)। ট্রেডঅফ হলো আপনি মালিকানা স্পষ্টভাবে মডেল করবেন এবং কম্পাইলারকে তা যাচাই করতে দেবেন।

শেখার বক্ররেখা (এবং কেন তা আছে)

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

কে সবচেয়ে উপকৃত (আর কে নাও হতে পারে)

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

রাস্ট সব জায়গায় প্রতিস্থাপন নয়; এটি একটি শক্তিশালী অপশন যখন আপনি C/C++-স্তরের পারফরম্যান্স চান এবং সেই সঙ্গে এমন নিরাপত্তা গ্যারান্টি চান যা ভরসা করা যায়।

কেন রাস্ট সিস্টেম প্রোগ্রামিংয়ের প্রত্যাশা বদলে দিল

রাস্ট “আরও সুন্দর C++” হয়ে নজর কেড়েনি। এটি কথোপকথন পরিবর্তন করেছিল কারণ এটি জোর দিয়েছে যে নিম্ন-স্তরের কোড একসঙ্গে দ্রুত, মেমরি-নিরাপদ, এবং খরচ সম্পর্কে স্পষ্ট হতে পারে।

নিরাপত্তা + গতি + স্পষ্টতা, একসাথে

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

এই পরিবর্তন গুরুত্বপূর্ণ ছিল কারণ এটি ডেভেলপারদেরকে “পারফেক্ট হতে বলছে” না—এটি বলছে স্পষ্ট হও, তারপর কম্পাইলার সেই স্পষ্টতাকে প্রয়োগ করবে।

ইন্ডাষ্ট্রি সিগন্যাল (সতর্কভাবে)

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

এর মানে রাস্ত সবসময় সেরা বিকল্প নয়—কিন্তু এটি নিরাপত্তা-ডিফল্ট ধারণাটিকে আর একটি বিলাসিতা না রেখে বাস্তবসম্মত করে তুলেছে।

রাস্ট সাধারণত কখন বিবেচিত হয়

রাস্ট প্রায়শই বিবেচিত হয়:

• CLI যা দ্রুত, পোর্টেবল, এবং নির্ভরযোগ্য হওয়া উচিত
• ব্যাকএন্ড সার্ভিস যেখানে পূর্বানুমেয় কর্মক্ষমতা এবং কম মেমরি-সংক্রান্ত ঘটনা জরুরি
• এম্বেডেড এবং অন্যান্য সীমিত-রিসোর্স পরিবেশ যেখানে GC পছন্দনীয় নয়
• WebAssembly টার্গেট যেখানে পারফরম্যান্স এবং বাইনারি উপর নিয়ন্ত্রণ গুরুত্বপূর্ণ

“নতুন মানদণ্ড” আসলে কী মানে

“নতুন মানদণ্ড” মানে সব সিস্টেম রাইডেক করে রিস্টে লেখা হবে না। এর মানে হলো মানটি উঠে গেছে: দলগুলো এখন আরোই প্রশ্ন করে, কেন মেমরি-অসেফ ডিফল্ট গ্রহণ করা হবে যখন করা যায় না? রাস্ট গ্রহণ না করলেও, তার মডেল ইকোসিস্টেমকে নিরাপদ API, স্পষ্ট ইনভেরিয়েন্ট, এবং সঠিকতা টুলিংকে মূল্য দিতে প্রভাবিত করেছে।

আরও ইঞ্জিনিয়ারিং ব্যাকস্টোরিযের জন্য /blog ব্রাউজ করুন।

মূল শিক্ষা এবং কোথায় আরও শিখবেন

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

মনে রাখার বড় ধারণা

রাস্ট একটি অনেকেই ধরে নেওয়া ট্রেডঅফকে পুনরায় ফ্রেম করে:

• আপনি শক্তিশালী মেমরি নিরাপত্তার গ্যারান্টি পেতে পারেন রানটাইম গারবেজ কালেক্টরের উপর নির্ভর না করে।
• আপনি সিস্টেম-স্তরের নিয়ন্ত্রণ এবং পারফরম্যান্স লক্ষ্য বজায় রাখতেও পারেন, সাথে এমন নিয়ম রাখতে পারেন যা মানুষ প্রায়ই মিস করে—কম্পাইলারকে প্রমাণ দেখাতে বলুন।

প্রায়োগিক পরিবর্তন শুধু “রাস্ট নিরাপদ” বলা নয়। এটি যে নিরাপত্তা ভাষার একটি ডিফল্ট বৈশিষ্ট্য হতে পারে, কোড রিভিউ ও টেস্টিং দ্বারা আমৃত্যু প্রয়োজনীয় অনুশীলন নয়—এটাই মূল ব্যাপার।

পরবর্তী করণীয় (অতিরিক্ত প্রতিশ্রুতি না দিয়ে)

আপনি যদি কৌতূহলী হন, পুরো রিফ্যাক্টরের প্রয়োজন নেই—রাস্ট কীভাবে লাগে তা জানার জন্য ছোটভাবে শুরু করুন।

শুরু করুন ছোট:

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

উপায়: একটি “পাতলা স্লাইস” লক্ষ্য নিন—যেমন “একটা ফাইল পড়ো, ট্রান্সফর্ম করো, আউটপুট লিখো”—এবং পরিষ্কার কোড লেখায় ফোকাস করুন, জটিলতার উপর নয়।

প্রজেক্টের ভিতরে একটি রাস্ট কম্পোনেন্ট প্রোটোটাইপ করলে, আশেপাশের পিসগুলো দ্রুত রাখা (অ্যাডমিন UI, ড্যাশবোর্ড, কন্ট্রোল প্লেন, সহজ API) সাহায্য করবে, এবং আপনি রাস্ট সার্ভিসের সঙ্গে পরিষ্কার বাউন্ডারির মাধ্যমে ইন্টিগ্রেট করতে পারবেন। প্ল্যাটফর্মগুলো যেমন Koder.ai সেই ধরনের “গ্লু” ডেভেলপমেন্ট ত্বরান্বিত করতে পারে—চ্যাট-চালিত ওয়ার্কফ্লো দিয়ে React ফ্রন্টএন্ড, Go ব্যাকএন্ড, এবং PostgreSQL স্কিমা দ্রুত জেনারেট করে, তারপর সোর্স এক্সপোর্ট করে রাস্ট সার্ভিসের সাথে একীভূত করা যায়।

সংক্ষিপ্ত পড়ার/দেখার তালিকা

• The Rust Programming Language (“the Rust Book”): /book/
• Rust by Example: /rust-by-example/
• গুরুত্বপূর্ণ টক/ইন্টারভিউ: Graydon Hoare Rust talk এবং Rust ownership borrow checker explanation সার্চ করুন প্রথম-ব্যক্তি কনটেক্সট এবং সহজ ওভারভিউর জন্য।

ফলো-আপের জন্য প্রশ্ন

আপনি যদি একটি দ্বিতীয় পোস্ট চান, কোনটা সবচেয়ে উপকারী হবে?

• বাস্তব এরর এবং সমাধান নিয়ে বোরো চেকারের সরল ইংরেজি ব্যাখ্যা
• বাস্তবে unsafe কিভাবে দায়িত্বশীলভাবে ব্যবহার করা হয়
• C/C++ দলের জন্য রাস্ট এক কম্পোনেন্ট বিবেচনা করার তুলনামূলক গাইড

আপনার প্রসঙ্গ (আপনি কী তৈরি করেন, এখন কোন ভাষা ব্যবহার করেন, এবং কী নিয়ে আপনি অপ্টিমাইজ করছেন) দিয়ে উত্তর দিন—আমি পরের বিভাগটি আপনার প্রয়োজন অনুযায়ী কাস্টমাইজ করব।