مقاله‌های رسمی

جمع‌بندی

فارغ از این‌که چه‌قدر از ترافیک Cursor واقعاً به مدل‌های OpenAI وابسته‌ست، این ماجرا یه نمونه‌ی خوب از اینه که رقابت بین شرکت‌های بزرگ AI داره از سطح مدل‌ها به سطح قراردادهای پلتفرمی هم کشیده می‌شه؛ جایی که تصمیم‌های تجاری بزرگ (مثل خرید یه استارتاپ توسط SpaceX) می‌تونه مستقیماً روی این‌که یه ابزار کدنویسی به کدوم مدل‌ها دسترسی داره اثر بذاره. برای توسعه‌دهنده‌هایی که روی Cursor کار می‌کنن، خبر خوب اینه که سه ماه فرصت دارن قبل از این‌که این تغییر عملی بشه، و با توجه به این‌که سهم OpenAI از ترافیک محدوده، به احتمال زیاد تجربه‌ی روزمره‌شون خیلی تغییر نمی‌کنه.

UTF-8 به‌صورت پیش‌فرض همه‌جا

از این نسخه به بعد، وقتی encoding رو صریح مشخص نکنی (مثلاً توی open())، پایتون به‌جای وابسته بودن به تنظیمات سیستم‌عامل، از UTF-8 استفاده می‌کنه. این یعنی رفتار یکسان روی ویندوز، مک و لینوکس، ولی اگه پروژه‌ای داری که به رفتار قدیمی وابسته بوده، بهتره از PYTHONUTF8=0 برای برگردوندن رفتار قبلی استفاده کنی یا صریحاً encoding رو همیشه مشخص کنی.

لیست کامل تغییرات

جمع‌بندی

3.15.0rc1 دقیقاً همونیه که اسمش می‌گه؛ یه پیش‌نمایش تقریباً نهایی، نه یه نسخه‌ی آزمایشی نصفه‌نیمه. اگه پکیجی نگه می‌داری که خیلیا ازش استفاده می‌کنن، الان بهترین زمانه که wheel های سازگار با 3.15 رو منتشر کنی و تست کنی. برای پروژه‌ی production خودت هم بهتره صبر کنی تا نسخه‌ی نهایی اکتبر بیاد؛ ولی چیزهایی مثل lazy imports و frozendict به اندازه‌ی کافی جذاب هستن که ارزش یه تست زودهنگام رو داشته باشن.

این نسخه هنوز LTS نیست

نود ۲۶ فعلاً روی خط Current قرار داره و طبق برنامه‌ی رسمی، قراره اکتبر وارد LTS بشه. یعنی ۲۶.۸.۰ بیشتر برای کسانی مناسبه که می‌خوان زودتر فیچرهای جدید رو امتحان کنن؛ اگه پروژه‌ی production داری و ثبات برات مهم‌تر از تازگیه، همون ۲۴.۲۰.۰ Krypton که هم‌زمان روی LTS منتشر شده گزینه‌ی مطمئن‌تریه.

در کل، ۲۶.۸.۰ از اون آپدیت‌های ساکت ولی مفیده؛ هیچ‌کدوم از تغییرات به تنهایی breaking نیستن، ولی مجموعشون زندگی رو برای کارهایی مثل ساخت zip، رمزنگاری امن‌تر و مدیریت statementهای sqlite کمی راحت‌تر می‌کنه.

هویت مدل: بازی حدس‌زدن که بالاخره تموم شد

بازی حدس زدن راجع به این‌که پشت Ox Alpha کیه، بالاخره تموم شد. گوگل، شیائومی، دیپ‌سیک و MAI مایکروسافت همه یه‌جایی توی این حدس‌زدن‌ها مطرح شدن، ولی امروز خود Z.ai (همون Zhipu) رسماً تأیید کرد که Ox Alpha چیزی نیست جز GLM-5.3-Flash؛ اولین مدل native چندوجهی از خانواده‌ی GLM-5. تا قبل از تأیید رسمی، توسعه‌دهنده‌ها با مقایسه‌ی توکنایزر و انکودر ویدیو به همین نتیجه رسیده بودن، ولی حالا دیگه حدس نیست. طبق گفته‌ی خود Z.ai، این مدل ۳۲۰ میلیارد پارامتر کل داره ولی فقط ۱۸ میلیارد پارامترش روی هر توکن فعال می‌شه (یعنی معماری MoE)، تحت لایسنس MIT منتشر شده، و قراره حدود ۰.۱۵ دلار برای هر میلیون توکن ورودی قیمت بخوره؛ یعنی چیزی حدود یک‌دهم قیمت مدل‌های هم‌رده‌اش. همون شبی که خبر تأیید منتشر شد، وزن‌های مدل هم عمومی شدن.

بنچمارک‌های رسمی چی می‌گن؟

راجع به عملکرد هم عددها یک‌دست نیستن. یه تست ده‌تایی از بنچمارک DeepSWE نشون داد Ox Alpha با ۸۰ درصد، از Claude Fable 5 با ۶۵ درصد و از GPT-5.6 Sol با ۵۲ درصد جلوتره؛ ولی وقتی همین بنچمارک رو با ۱۱۳ تسک کامل اجرا کردن، عدد Ox Alpha به حدود ۶۳ درصد رسید که تقریباً هم‌سطح GPT-5.6 Sol شد، نه اون فاصله‌ی چشمگیر اول. توی Kingbench هم با ۸۷.۵ درصد، پشت سر GLM-5.3 با ۹۱.۲۵ درصد قرار گرفت ولی جلوتر از Opus 4.8 که ۸۰ درصد گرفته. یه بنچمارک خصوصی دیگه هم هست که نتیجه‌ی کاملاً متفاوتی داده و این مدل رو در حد مدل‌های دو نسل قبل، مثل Kimi 2.6، رده‌بندی کرده. یعنی بستگی داره چه نوع تسکی بهش بدی؛ ظاهراً روی کارهای فرانت‌اند و طراحی UI به‌طور خاص قوی‌تر عمل می‌کنه تا روی منطق خالص کد.

به هیچ عنوان نمی‌تونم به این بنچمارک‌ها اعتماد کنم، چون واقعاً چیزی که من دیدم با هایپی که توی اینترنت هست روی این مدل متفاوته. شاید من اشتباه استفاده می‌کنم ازش.

تجربه‌ی کاربرها

همین ناهماهنگی رو توی تجربه‌ی کاربرها هم می‌بینی. بعضی‌ها گفتن روی opencode مدام تایم‌اوت می‌گیره و عملاً غیرقابل استفاده می‌شه، ولی همون مدل روی Hermes Agent بدون مشکل کار کرده. بعضی هم از اجراهای چند ساعته برای یه مقایسه‌ی ساده گلایه کردن؛ که با همون کندی‌ای که خودم حس کردم هم‌خونی داره. از چندین نفر پرسیدم و مثل این‌که اون‌ها هم عملاً نمی‌تونستن استفاده کنن ازش. من استفاده کردم، ولی چیز Wow‌ای برای من به‌شخصه نبود.

ضعف‌های مدل (تجربه‌ی خودم)

یه نکته‌ی دیگه که موقع کار باهاش برام مهم بود: توی نوشتن محتوای فارسی اصلاً خوب عمل نمی‌کنه. اگه دنبال یه مدل برای تولید متن فارسی روون می‌گردی، فعلاً این گزینه‌ی خوبی نیست.

این مدل به شدت کند عمل می‌کنه، در حدی که قبل از این، کندترین مدلی که دیده بودم Nemotron از Nvidia بود که با اومدن این مدل جاشو گرفت برای من (نموترون رو از چند پروایدر تست کردم و همه‌شون همون‌قدر کند بودن).

من نمی‌دونم این جریانِ این‌که این مدل روی تسک‌های UI به‌شدت خوب عمل می‌کنه از کجا میاد؛ حقیقتاً فکر نمی‌کنم چیز خاصی باشه، چون شخصاً بررسیش کردم.

یه چیز جالب دیگه هم توی تست‌هام دیدم: وقتی به چت‌جی‌پی‌تی و کلاد یه دستور می‌دی که یک کاری رو انجام بده و بعد در حالی که روی یه پروژه‌ی دیگه‌ای دوباره بهش می‌گی همون کار قبلی رو روی این پروژه انجام بده، هر دو متوجه می‌شن که کانتکست فرق داره و مال یک پروژه‌ی دیگه‌ست و می‌پرسن منظورت همین پروژه‌ی فعلیه یا اون یکی قبلی که تأیید کنی؛ ولی Ox Alpha بدون هیچ سؤالی مستقیم می‌ره سراغ پروژه‌ی قبلی، تا وقتی که خودم absolute path رو بهش بدم. این‌جور جاهاست که فرق بین «قوی بودن توی بنچمارک» و «فهمیدن context واقعی کار تو» خودش رو نشون می‌ده.

به نظرم بنچمارک‌ها زیادم حقیقت رو، حداقل در استفاده‌ی واقعی از مدل‌ها، نمی‌گن.

دیگه استدلال به تنهایی ملاک نیست

یه چیزی هم که این روزها بیشتر و بیشتر حس می‌کنم اینه که دیگه صرفاً «قدرت استدلال» ملاک اصلی انتخاب نیست. فاصله‌ی بین مدل‌های بالای بازار داره کم می‌شه و کم‌کم همه‌شون توی این بخش خوب یا خیلی خوب هستن؛ چیزی که واقعاً فرق ایجاد می‌کنه بیشتر سرعت، قیمت، و همون درک درست از context کاره تا صرفاً یه عدد بالاتر توی بنچمارک استدلال.

نظر خودم راجع به استفاده از GLM-5.3-Flash

رک بگم: نه. در صورتی که مدل رایگان نباشه (با این سرعت) یا این‌که مثلاً پولی بشه ولی بسیار ارزون باشه (در حد همون Spark 1.2 یا حالا یکم بالاتر) یا شاید در سطح DeepSeek Flash، من به‌شخصه از این مدل، با این‌که واقعاً قدرت بالایی داره، استفاده نمی‌کنم؛ به چند دلیل:

• استدلال رو می‌سپارم به مدلی که بهش اعتماد دارم، مثل Claude یا GPT، دلیلش هم اینه که برای من ثابت شده‌ن.

• اون حجم از استدلالی که مدل‌های سریع‌تر یا حتی رایگان نمی‌تونن انجام بدن رو معمولاً خودم راجبش فکر می‌کنم و با چندین AI مشورت می‌کنم، نه این‌که فقط به یک مدل بسپارمش.

جمع‌بندی

حالا که هویتش مشخص شده و وزن‌هاش هم منتشر شدن، دیگه اون بهانه‌ی «نمی‌دونیم دیتامون کجا می‌ره» با همون شدت قبل معنا نداره، ولی همچنان بهتره قبل از استفاده‌ی جدی، مستندات رسمی Z.ai راجع به نگهداری دیتا رو خودت بخونی. تجربه‌ی خودت با این مدل چی بوده؟ همون چیزی که بنچمارک‌های رسمی می‌گن رو حس کردی یا مثل من فکر می‌کنی هنوز رقابت خاصی بین این و مدل‌های OpenAI و Anthropic، حداقل در رده‌های بالا، نیست؟

زمان‌بندی: چرا درست بعد از خرید Qualcomm

نکته‌ی جالبی که تقریباً همه‌ی گزارش‌ها روش تأکید کردن، زمان‌بندیه. Qualcomm خرید Modular رو ۲۹ جولای نهایی کرد؛ فقط سه هفته بعد، اولین حرکت بزرگ مالک جدید این بوده که کامپایلر رو کاملاً ببخشه. این تصمیم برای خیلی‌ها غیرمنتظره بود، چون تاریخچه‌ی Qualcomm تو متن‌باز چندان درخشان نیست، و بعضی تو کامیونیتی نگران بودن که خرید یه شرکت سازنده‌ی چیپ، تعهد Modular به یه پلتفرم توسعه‌ی خنثی از نظر vendor رو به خطر بندازه.

استدلال منطقی پشت این تصمیم اینه: هر ساعتی که یه توسعه‌دهنده صرف قفل‌شدن تو CUDA (اکوسیستم اختصاصی NVIDIA) می‌کنه، یه ساعتیه که تراشه‌های Qualcomm نمی‌تونن گزینه‌ی رقیب باشن. باز کردن toolchain برای Qualcomm عملاً هزینه‌ای نداشته (چون هیچ‌وقت قرار نبوده از فروش لایسنس کامپایلر پول دربیاره)، ولی می‌تونه به پذیرش گسترده‌تر Mojo رو انواع سخت‌افزار کمک کنه؛ از جمله سخت‌افزار خود Qualcomm.

گستره‌ی سخت‌افزاری: فراتر از NVIDIA

طبق اعلام‌های ModCon، پلتفرم Modular (که Mojo موتور اصلیشه) الان از AWS Trainium و Google TPU هم پشتیبانی می‌کنه، علاوه بر GPU های NVIDIA، AMD، و Apple Silicon. حتی یه دمو رو یه شتاب‌دهنده‌ی چینی (Houmo، با ۲۴ گیگابایت حافظه‌ی M.2) هم نشون داده شده. تراشه‌های خود Qualcomm (مثل Cloud AI 100 Ultra و Dragonfly) هم حالا هدف اول‌درجه‌ی این stack هستن. یه مقام از GV (سرمایه‌گذار وابسته به گوگل) این چشم‌انداز رو این‌طور خلاصه کرده: «هر مدل هوش مصنوعی رو هر تراشه‌ای اجرا کن.»

نکته‌ی مهم: MAX هنوز کاملاً باز نشده

یه تمایز مهم که نباید فراموشش کرد: Mojo (خود زبون و کامپایلر) کاملاً متن‌بازه، ولی MAX (لایه‌ی بالاتر که مدل‌های هوش مصنوعی رو serve و بهینه می‌کنه) فقط «source-available» شده، نه open source؛ یعنی می‌تونی کدش رو ببینی، ولی زیر یه لایسنس community با شرایط خاص (محدودیت‌هایی درباره‌ی telemetry، برندینگ، و ساختن جایگزین‌های رقیب) قرار داره. طبق تحلیل Forbes، محدودیت‌های قدیمی مبتنی بر تعداد دستگاه از MAX برداشته شده که پیشرفت واقعی‌یه، ولی source-available با governance واقعی کامیونیتی فرق داره. ریسک بزرگ‌تر هم اینه که Modular Cloud (لایه‌ای که تصمیم می‌گیره workload ت رو کدوم تراشه اجرا بشه) کاملاً proprietary باقی مونده؛ یعنی Apache 2.0 فقط خود زبون رو محدود می‌کنه، نه ابر (cloud) بالادستیش.

پشتیبانی پلتفرم

Mojo فعلاً از macOS و لینوکس پشتیبانی می‌کنه. طبق اعلام Modular، دارن مستقیم با تیم ویندوز مایکروسافت همکاری می‌کنن تا Mojo رو به‌صورت native (نه فقط از طریق WSL) به ویندوز بیارن؛ این یکی از پرتقاضاترین درخواست‌های کامیونیتی Mojo بوده.

این برای توسعه‌دهنده‌ها چه معنایی داره

اگه دنبال یه زبون سیستمی با سینتکس نزدیک به پایتون هستی که بتونه هم‌زمان CPU، GPU، و شتاب‌دهنده‌های AI رو با performance بالا هدف بگیره، Mojo حالا از هر نظر (نه فقط کتابخونه، بلکه کل زنجیره‌ی ساخت) قابل بازرسی و تغییره؛ چیزی که برای شرکت‌هایی که نگران قفل‌شدن تو یه vendor خاص (مثلاً NVIDIA/CUDA) هستن، جذابیت واقعی داره. با این حال، CUDA همچنان عمیق‌ترین و جاافتاده‌ترین toolchain مخصوص سخت‌افزار NVIDIA است؛ یه دهه کتابخونه، پشتیبانی driver، و ابزار که Mojo قرار نیست یک‌شبه جایگزینش کنه. اگه پروژه‌ت به ویندوز وابسته‌ست، فعلاً باید صبر کنی تا پشتیبانی native تکمیل بشه.

متد debounceId() مشخص می‌کنه این بازه‌ی زمانی برای کدوم resource حساب بشه، و maxWait سقف می‌ذاره که اگه event خیلی زیاد و پشت‌سرهم fire بشه، اجرای کار برای همیشه عقب نیفته. این debounce فقط رو همون listener اعمال می‌شه؛ بقیه‌ی listener های همون event همچنان هر بار اجرا می‌شن. یه نکته‌ی مهم: یه listener که #[DebounceFor] داره، نمی‌تونه هم‌زمان ShouldBeUnique رو implement کنه؛ dispatcher یه LogicException پرتاب می‌کنه، چون uniqueness اولین dispatch رو نگه می‌داره ولی debounce آخرین رو.

Queue::forward(): مسیردهی مجدد صف از یه نقطه

این متد جدید همه‌چیزی که به یه صف dispatch می‌شه رو به یه صف دیگه، یه connection دیگه، یا هر دو، منتقل می‌کنه؛ همه‌ی این‌ها از یه نقطه‌ی مرکزی تو service provider، بدون نیاز به تغییر کلاس‌های job یا محل‌های dispatch:

این forward ها از همون hook ای که Queue::route() استفاده می‌کنه عبور می‌کنن، پس مهم نیست job از چه مسیری به صف می‌رسه؛ همیشه اعمال می‌شه.

بهبودهای Process

سه تا اضافه‌ی مربوط به facade Process:

Process pool های iterable: قبلاً foreach روی ProcessPoolResults عملاً هیچی رو iterate نمی‌کرد (چون این کلاس هیچ پراپرتی public ای نداشت)، یعنی حلقه‌ای که برای چک کردن exit code نوشته می‌شد، بی‌صدا هیچی رو چک نمی‌کرد. حالا هر دو کلاس IteratorAggregate رو implement می‌کنن.

Exception جدا برای idle timeout: یه idle timeout حالا ProcessIdleTimedOutException خودش رو پرتاب می‌کنه، جدا از ProcessTimedOutException:

این تفکیک مهمه چون این دو حالت معنی کاملاً متفاوتی دارن: یکی یه پروسه‌ی گیرکرده‌ست، اون یکی فقط کنده.

Assertion های جدید برای Process fake: assertRanCount(2)، assertRanInOrder([...])، و متد recorded() برای فیلتر کردن جفت‌های پروسه/نتیجه‌ی ثبت‌شده با یه callback.

اضافات Eloquent Builder

• orWhereKey() و orWhereKeyNot() به whereKey() اضافه شدن؛ جایگزین بهتری برای orWhereIn('id', ...) تو کوئری‌هایی که نیاز به شرط primary key تو یه شاخه‌ی or دارن.
• wherePivot() و orWherePivot() حالا یه closure قبول می‌کنن که یه builder scope‌شده به مدل pivot بهش پاس می‌شه؛ یعنی scope های تعریف‌شده رو یه کلاس pivot سفارشی، مستقیم از کوئری رابطه قابل‌فراخوانی می‌شن.
• inOrderOf() حالا enum ها رو تو لیست مقادیرش قبول می‌کنه.

دیده‌شدن بهتر Queue Worker

یه event جدید به اسم JobReleased حالا موقعی که یه job از handler خودش یا از middleware ای مثل WithoutOverlapping به صف برگردونده می‌شه، fire می‌شه. تا قبل از این، JobReleasedAfterException فقط release هایی که به‌خاطر throw شدن یه exception اتفاق می‌افتادن رو پوشش می‌داد؛ یعنی release ناشی از overlap کاملاً نامرئی بود.

Worker ها هم حالا وقتی صفی که ازش مصرف می‌کنن pause می‌شه، یه پیام تو خروجی چاپ می‌کنن، و همین‌طور وقتی resume می‌شه. از وقتی API پاز صف تو Laravel 13.25 اومد، یه worker پاز‌شده فقط تولید خروجی رو متوقف می‌کرد و شبیه یه hang به نظر می‌رسید؛ این آپدیت این ابهام رو برطرف می‌کنه.

بقیه‌ی رفع باگ‌ها و بهبودها

• پشتیبانی از Guzzle 8 در کنار Guzzle 7.
• دستور db:seed --class=SpecificSeeder حالا همون خروجی پیشرفت RUNNING/DONE رو نشون می‌ده که seeder های تودرتو از قبل داشتن.
• یه دسته بهبود امنیت/پایداری Redis: چک‌های صف pause‌شده دیگه رو کلاستر cross-slot read انجام نمی‌دن، pruning تگ‌های کش همه‌ی master node ها رو اسکن می‌کنه و دیگه رو تگ‌های قدیمی loop بی‌نهایت نمی‌زنه، یه pipeline یا transaction fail‌شده اتصال رو قابل‌استفاده نگه می‌داره.
• درایور صف Cloud متد managedQueues() رو expose می‌کنه، و long-poll های timeout‌شده‌ی cloud agent حالا retry می‌شن.
• throwUnless() دیگه تو یه حالت خاص که باید throw می‌کرد، بی‌صدا هیچ کاری نمی‌کنه.
• تنظیم readonly=false تو Microsoft SQL Server رعایت می‌شه، و quote های تکی تو attribute های JSON path پستگرس escape می‌شن.

نکات آپگرید

طبق اعلام رسمی، هیچ breaking change ای برای اپلیکیشن‌های معمولی انتظار نمی‌ره. فقط دو نکته‌ی ریز رو باید بدونی: یه listener که #[DebounceFor] داره، اگه هم‌زمان ShouldBeUnique رو هم implement کنه، حالا یه LogicException می‌گیره؛ و internal های whereKey()/whereKeyNot() ادغام شدن، که فقط اگه Eloquent builder رو extend کرده باشی و این متدها رو override کرده باشی برات مهمه.

جمع‌بندی

اگه بخوایم Laravel 13.26 رو خلاصه کنیم: تمرکز اصلی رو مهاجرت تنبل بین storage ها (read-through disks)، کنترل بهتر روی صف‌ها (debounce برای listener، forward برای مسیردهی مجدد، دیده‌شدن بهتر worker)، و صیقل دادن جزئیات Process و Eloquent builder گذاشته. مثل چند نسخه‌ی اخیر، آپگرید نسبتاً بی‌دردسره و می‌شه بدون نگرانی زیاد بهش رفت.

تضمین رسمی رفتار ManuallyDrop<Box<_>>

تو Rust 1.96، یه رفتار نامشخص (undefined behavior) مربوط به تعامل ManuallyDrop و Box رفع شده بود. تو این نسخه، مستندات رسمی آپدیت شده تا تضمین کنه این رفتار درست، برای همیشه پایدار می‌مونه؛ یعنی این دیگه یه رفع باگ ساده نیست، بلکه یه ضمانت رسمی و مستند از سمت زبونه (مرتبط با RFC 3336).

تغییرات زبانی

Lifetime shortening تو unsize coercion: حالا می‌شه lifetime یه &mut رو حتی تو موقعیت invariant، هنگام unsize-coercing کوتاه کرد. مثلاً می‌شه Cell<&'long mut i32> رو به Cell<&'short mut dyn Send> تبدیل کرد؛ این کوتاه‌سازی قبلاً فقط هنگام تبدیل &mut به &، یا & به & مجاز بود.

سخت‌گیری بیشتر repr(transparent): این attribute حالا سخت‌گیرتر شده درباره‌ی این‌که کدوم فیلدها layout «بی‌اهمیت» (trivial) دارن و می‌شه نادیده‌شون گرفت؛ انواع repr(C)، انواع با فیلد خصوصی، و انواع #[non_exhaustive] دیگه trivial در نظر گرفته نمی‌شن.

لینت‌های امنیتی جدید: یه لینت جدید deny-by-default به اسم invalid_runtime_symbol_definitions اضافه شده که فعلاً سمبل‌های runtime اصلی مثل memcmp، memset، و strlen رو هدف می‌گیره (با برنامه‌ریزی برای گسترش تو نسخه‌های بعدی). یه لینت warn-by-default هم به اسم c_void_returns اضافه شده که استفاده از core::ffi::c_void به‌عنوان نوع بازگشتی رو چک می‌کنه.

API های جدید کتابخونه‌ی استاندارد

چند تا API جدید هم پایدار شدن که ارزش دونستن دارن: str::substr_range و [T]::subslice_range (برای پیدا کردن محدوده‌ی یه substring/subslice)، یه متد strip_circumfix برای هر دوی این‌ها، پیاده‌سازی Send و Sync برای std::process::CommandArgs، پارس کردن radix رو انواع NonZero، متدهای تبدیل lossy UTF-16 رو String، و چند تا کمک‌کننده‌ی جدید برای mutation اتمیک. یه ماژول جدید به اسم std::range::legacy هم اضافه شده که برای نگهداری کدبیس‌های قدیمی‌تر مفیده.

پلتفرم‌های جدید

سه تا هدف جدید به لیست پلتفرم‌های پشتیبانی‌شده اضافه شدن: ویژگی‌های target d، e، و f تو RISC-V حالا تو cfg(target_feature = "?") پایدار شدن، و powerpc64-unknown-linux-gnuelfv2 و aarch64-unknown-linux-pauthtest هم به‌عنوان هدف Tier 3 اضافه شدن.

نکته‌ی کوچیک ولی مهم برای نگهداری کد

یه نکته‌ی جالب اینه که ماکروی derive که تو {core,std}::derive در دسترسه، در واقع به‌طور ناخواسته از نسخه‌ی 1.96 پایدار شده بود، ولی حالا رسماً به‌عنوان یه API پایدارشده پذیرفته شده. برای همین، حداقل نسخه‌ی موردنیاز Rust (MSRV) برای این ماکرو، 1.96 است، نه 1.98؛ یه نکته‌ی ریز که موقع مستندسازی وابستگی‌های پروژه‌ت ارزش توجه داره.

چطور آپدیت کنیم

اگه از قبل Rust رو با rustup نصب کردی، آپدیت به این نسخه فقط یه دستوره:

اگه تازه‌کاری، دستورالعمل نصب رو می‌تونی مستقیم از سایت رسمی Rust بگیری. برای دیدن کامل تغییرات کامپایلر، Cargo، و Clippy، بهتره یادداشت‌های رسمی release رو رو گیت‌هاب چک کنی.

جمع‌بندی

Rust 1.98 نسخه‌ای‌یه که تمرکز زیادی روی محاسبات عددی و performance گذاشته؛ متدهای algebraic برای اعشاری‌ها و استانداردسازی سریال‌سازی عدد صحیح، هر دو مستقیم برای کدی که محاسبات سنگین یا حجم بالای تبدیل عدد به رشته داره مفیدن. تغییرات زبانی این نسخه هم بیشتر جنبه‌ی سخت‌گیری و ایمن‌سازی دارن (مثل repr(transparent) و لینت‌های جدید) تا اضافه کردن قابلیت‌های کاملاً جدید؛ یعنی برای اکثر پروژه‌ها، آپگرید باید بدون درگیری خاصی پیش بره.

از نظر performance، سرعت Marshal تقریباً هم‌سطح پیاده‌سازی قبلیه، ولی Unmarshal به‌طور محسوسی سریع‌تر شده.

بهبودهای Runtime

تخصیص حافظه‌ی سریع‌تر: کامپایلر حالا برای تخصیص‌های کوچیک (زیر ۸۰ بایت)، فراخوانی‌هایی به روتین‌های تخصیص size-specialized تولید می‌کنه؛ این کار هزینه‌ی بعضی از این تخصیص‌ها رو تا ۳۰ درصد کم می‌کنه. طبق گزارش‌ها، بهبود کلی رو برنامه‌های واقعی و allocation-heavy حدود ۱ درصده، با هزینه‌ی حدود ۶۰ کیلوبایت حجم اضافه‌ی باینری.

پروفایل نشتی goroutine: قابلیتی که به‌صورت آزمایشی تو Go 1.26 معرفی شده بود، حالا به یه پروفایل رسمی تبدیل شده. پکیج runtime/pprof الان یه پروفایل goroutineleak داره که با اجرای یه چرخه‌ی garbage collection، goroutine هایی که برای همیشه بلاک شدن رو شناسایی می‌کنه؛ ابزار مفیدی برای دیباگ کردن نشتی‌های goroutine تو production.

SIMD: از amd64 به arm64 و WebAssembly

پشتیبانی آزمایشی SIMD که از Go 1.26 تو پکیج simd/archsimd شروع شده بود، تو این نسخه گسترش پیدا کرده. علاوه بر بازنگری API مربوط به amd64، حالا از SIMD ۱۲۸ بیتی «Neon» رو arm64 و SIMD ۱۲۸ بیتی رو WebAssembly هم پشتیبانی می‌شه. این پکیج با فعال کردن متغیر محیطی GOEXPERIMENT=simd موقع build در دسترسه، ولی API ش هنوز پایدار در نظر گرفته نمی‌شه. یه پکیج جدید دیگه هم به اسم simd معرفی شده که پشتیبانی SIMD قابل‌حمل و مستقل از سایز بردار ارائه می‌ده؛ رو سخت‌افزارهایی که دسترسی دارن، به دستورات vector واقعی کامپایل می‌شه و رو بقیه، به emulation خالص Go برمی‌گرده.

کتابخونه‌ی استاندارد: چند تا اضافه‌ی کاربردی

پکیج uuid: حالا تولید و parse کردن UUID مستقیم تو کتابخونه‌ی استاندارده؛ دیگه نیازی به یه dependency خارجی برای این کار رایج نیست.

crypto/mldsa: پشتیبانی از یه الگوریتم امضای دیجیتال پسا-کوانتومی (ML-DSA) به کتابخونه‌ی استاندارد کریپتوگرافی اضافه شده؛ گامی مهم برای آماده‌سازی کدبیس‌ها در برابر تهدید کامپیوترهای کوانتومی.

CutLast: یه تابع جدید که یه slice بایت رو حول آخرین رخداد یه جداکننده برش می‌ده (برخلاف Cut معمولی که اولین رخداد رو در نظر می‌گیره).

Toolchain و ابزارها

go mod tidy هوشمندتر: برای ماژول‌هایی که رو Go 1.27 یا بالاتر هستن، این دستور حالا بلوک‌های require پراکنده رو تو دو بلوک استاندارد (یکی برای وابستگی مستقیم، یکی غیرمستقیم) ادغام می‌کنه، در حالی که کامنت‌های ضمیمه‌شده رو هم حفظ می‌کنه.

go tool trace امن‌تر: وقتی فقط یه پورت مشخص کنی، رابط trace حالا فقط رو localhost گوش می‌ده، هماهنگ با رفتار go tool pprof؛ برای گوش دادن گسترده‌تر، باید صراحتاً یه آدرس مشخص بدی.

حذف پشتیبانی Bazaar: دستور go دیگه از سیستم کنترل نسخه‌ی Bazaar (bzr) پشتیبانی نمی‌کنه.

پشتیبانی Response file: ابزارهای compile، link، asm، cgo، cover، و pack حالا از response file (با فرمت سازگار با GCC) پشتیبانی می‌کنن؛ کمک بزرگی برای سیستم‌های build ای که به محدودیت طول خط فرمان برخورد می‌کنن.

بهبودهای go fix: این دستور modernizer های جدیدی گرفته که کمک می‌کنن کد قدیمی‌تر رو به الگوهای مدرن‌تر Go آپدیت کنی.

تغییرات پلتفرم

طبق گزارش‌ها، این نسخه الزامات پلتفرمی برای macOS رو هم تغییر داده (جزئیات دقیق تو یادداشت‌های رسمی release اومده)، پس اگه رو مک کار می‌کنی، قبل از آپگرید، حتماً حداقل نسخه‌ی موردنیاز رو چک کن.

چطور همین الان امتحانش کنیم

باینری‌ها و نصب‌کننده‌های Go 1.27 از صفحه‌ی دانلود رسمی (go.dev/dl) در دسترسن. اگه از JetBrains GoLand استفاده می‌کنی، نسخه‌ی 2026.2 همین الان از ویژگی‌های زبانی جدید، modernizer های go fix، و پروفایل جدید goroutine leak پشتیبانی می‌کنه. تیم Go هم بیست‌وپنجم آگوست، از ساعت ۱۶:۰۰ تا ۱۷:۳۰ به وقت UTC، یه «Go 1.27 Release Party» آنلاین برگزار می‌کنه که می‌شه توش با جزئیات بیشتر این تغییرات آشنا شد.

جمع‌بندی

Go 1.27 با حدود ۱۶۰۰ کامیت بین این نسخه و Go 1.26، یکی از نسخه‌هایی‌یه که واقعاً چیزی فراتر از بهبودهای معمولی نگهداری داره. متدهای generic، نسل جدید JSON، و بهبود چشمگیر تخصیص حافظه، همه چیزهایی هستن که مستقیم رو کد روزمره‌ی خیلی از تیم‌ها تأثیر می‌ذارن. با این حال، به‌خاطر تغییر پیش‌فرض‌های سخت‌گیرانه‌ی JSON v2 (رد کردن UTF-8 نامعتبر و کلیدهای تکراری)، قبل از آپگرید پروژه‌های production، ارزش داره تست‌هات رو کامل اجرا کنی تا مطمئن بشی داده‌ی ورودیت با این استانداردهای جدید مشکلی نداره.

نگرانی جدی: بدون شرایط مشخص برای داده

مهم‌ترین نکته‌ای که باید قبل از استفاده‌ی جدی از Origin بهش توجه کنی، مربوط به داده‌ست. طبق گزارش TechTimes، Origin با enrollment به‌صورت opt-out (نه opt-in) برای همه‌ی کاربران پولی فعال شده؛ یعنی به‌صورت پیش‌فرض روشنه، مگه این‌که ادمین سازمانت صراحتاً غیرفعالش کنه. در همون زمان انتشار، کرسر هیچ سند رسمی‌ای درباره‌ی نگه‌داری داده (data retention)، افشای subprocessor ها، سیاست استفاده از کد برای آموزش مدل، یا ابزار migration برای کدهایی که مستقیم رو Origin هاست می‌شن منتشر نکرده بود.

این نگرانی برای تیم‌هایی که کد اختصاصی، داده‌ی شخصی کاربر تو فیکسچرهای تست، credential های احتمالی تو تاریخچه‌ی commit، یا کدهای با محدودیت‌های قانونی/رگولاتوری دارن، جدی‌تره؛ چون الان کدشون رو زیرساختی هاست می‌شه که متعلق به SpaceX است، بدون این‌که سیاست مشخصی درباره‌ی نحوه‌ی استفاده از اون کد منتشر شده باشه.

دسترسی

Origin فقط برای پلن‌های Pro، Teams، و Enterprise در دسترسه، نه پلن رایگان. برای سازمان‌های Enterprise، ادمین‌ها می‌تونن صراحتاً opt-out کنن. برای شروع، باید یه اسم codebase (namespace) رو claim کنی که فعلاً تو دوره‌ی بتا قابل تغییر نیست، و بعد از اون می‌تونی ریپازیتوری جدید بسازی یا از طریق OAuth، ریپازیتوری‌های گیت‌هابت رو sync کنی.

جمع‌بندی

Origin نشون می‌ده کرسر (حالا زیر پرچم SpaceX) قصد داره فراتر از یه ادیتور کدنویسی بره و مستقیم وارد قلمروی زیرساخت توسعه‌ی نرم‌افزار (همون چیزی که گیت‌هاب و گیت‌لب سال‌هاست توش تسلط دارن) بشه. برای تیم‌هایی که کاملاً درگیر اکوسیستم کرسر هستن و از agent های کدنویسی زیاد استفاده می‌کنن، یکپارچگی ریپازیتوری/PR/agent تو یه محیط واحد می‌تونه جذاب باشه. ولی با توجه به این‌که این محصول هنوز early beta است و مهم‌تر از همه، هیچ سند رسمی‌ای درباره‌ی شرایط داده منتشر نشده، توصیه می‌شه قبل از هاست کردن کد حساس یا اختصاصی رو Origin، منتظر انتشار این سیاست‌ها بمونی یا حداقل از تیم پشتیبانی کرسر مستقیم درباره‌ش سؤال کنی.

پایه‌ی نظری: Metric First-Order Temporal Logic

از نظر فنی، Dogwood رو یه فرمالیسم از رشته‌ی runtime verification به اسم MFOTL (Metric First-Order Temporal Logic) ساخته شده. عملگرهایی که به Cedar اضافه می‌کنه شامل چیزهایی مثل formerly (چیزی قبلاً اتفاق افتاده؟)، count_within (چند بار تو یه بازه‌ی زمانی؟)، count_distinct_within، و sum_within (مجموع یه مقدار تو یه بازه) هستن؛ دقیقاً همون عملگرهایی که برای بیان قوانین بالا لازمه.

ادغام با Amazon Bedrock AgentCore

Dogwood مستقیم پشت یه قابلیت جدید تو AgentCore Policy قرار گرفته؛ لایه‌ای تو Amazon Bedrock AgentCore که مستقل از خود مدل عمل می‌کنه: مدل یه tool call رو پیشنهاد می‌ده، policy engine قبولش می‌کنه یا ردش می‌کنه، و خود مدل هیچ‌وقت مستقیم درگیر اجرای enforcement نمی‌شه. تا قبل از این، این چک‌ها کاملاً stateless بودن؛ حالا با «temporal policies» که Dogwood قدرتش رو می‌ده، این تصمیمات می‌تونن به تاریخچه‌ی سشن agent هم نگاه کنن.

AWS همچنین یه ابزار به اسم Policy Authoring هم معرفی کرده که با هوش مصنوعی، سند policy نوشته‌شده به زبون طبیعی رو مستقیم به قوانین Dogwood درست تبدیل می‌کنه؛ یعنی لازم نیست حتماً خودت سینتکس Dogwood رو یاد بگیری تا بتونی قوانین سازمانیت رو پیاده کنی.

چطور همین الان امتحانش کنیم

Dogwood زیر لایسنس Apache 2.0 منتشر شده و شامل یه راهنمای زبان و یه پیاده‌سازی مرجع (reference interpreter) روی گیت‌هابه. برای شروع:

یه نمونه‌ی خیلی ساده از یه قانون Dogwood که همون سناریوی پرداخت اول مقاله رو حل می‌کنه، تقریباً این‌طور به نظر می‌رسه (بر پایه‌ی گسترش Cedar):

یعنی پرداخت فقط زمانی مجازه که قبلش یه فاکتور برای همون resource ثبت شده باشه، و مجموع پرداخت‌های همون روز از یه سقف مشخص بیشتر نشه.

اگه از قبل رو Amazon Bedrock AgentCore کار می‌کنی، AgentCore Policy همین الان از Dogwood پشتیبانی می‌کنه و می‌تونی مستقیم ازش استفاده کنی. اگه رو یه استک دیگه کار می‌کنی، می‌تونی پیاده‌سازی مرجع رو مستقیم از گیت‌هاب بگیری و باهاش آزمایش کنی.

نکته‌ی مهم: هنوز برای production آماده نیست

خود AWS صراحتاً اعلام کرده که پیاده‌سازی مرجع Dogwood برای اکتشاف و تست طراحی شده، نه استفاده‌ی production. اگه بخوای این رو تو یه محیط واقعی اجرا کنی، باید خودت چیزهایی مثل نگه‌داری قابل‌اعتماد تاریخچه‌ی رویدادها، ایزوله‌سازی بین tenant های مختلف، و سیاست نگه‌داری داده رو پیاده‌سازی کنی؛ این‌ها جزو خود زبان یا reference interpreter نیستن.

چرا این موضوع مهمه

با گسترش استفاده از agent های خودمختار برای کارهای حساس (پرداخت، دسترسی به داده‌ی حساس، تغییرات زیرساختی)، مشکلی که Dogwood حلش می‌کنه دقیقاً همون چیزیه که این روزها تو خیلی از تیم‌های مهندسی مطرحه: چطور می‌شه به یه agent اجازه داد کار واقعی انجام بده، بدون این‌که مجبور بشیم به کل هیستوری رفتارش اعتماد کورکورانه داشته باشیم؟ Dogwood با اضافه کردن حافظه به لایه‌ی authorization (بدون از دست دادن قابلیت‌های اثبات‌پذیر Cedar)، یه جواب مشخص و متن‌باز به این سؤال می‌ده؛ و چون AWS از جامعه دعوت کرده که Dogwood رو تو محصولات و پروژه‌های خودشون هم بسازن، این رویکرد می‌تونه فراتر از خود AWS هم به یه استاندارد غیررسمی تبدیل بشه.

نتیجه‌ی هر ارزیابی می‌تونه allow، deny، یا یه زنجیره‌ی پیچیده‌تر شامل داور LLM یا تأیید انسانی (مثلاً از طریق Slack) باشه؛ یعنی برای عملیات پرریسک مثل kubectl delete pod، می‌شه درخواست رو متوقف کرد تا یه انسان تأییدش کنه.

مدیریت credential ها

یکی از نکات کلیدی طراحی اینه که credential های واقعی هیچ‌وقت رو خود agent نمی‌شینن. Agent فقط یه placeholder می‌فرسته، و این gateway است که موقع عبور دادن ترافیک، توکن واقعی رو جایگزینش می‌کنه. یعنی حتی اگه agent کامل کنترل بشه یا لاگش لو بره، خود secret ها هیچ‌وقت در معرض دید agent قرار نمی‌گیرن.

سه مدل استقرار

طبق ریپازیتوری رسمی گیت‌هاب، Claw Patrol سه شکل مختلف استقرار داره:

• clawpatrol run: یه تونل مخصوص هر پروسه باز می‌کنه (رو لینوکس با netns، رو مک با NetworkExtension)؛ فقط ترافیک همون دستور wrap‌شده از gateway عبور می‌کنه.
• clawpatrol join: یه تونل WireGuard کامل بالا میاره که کل ترافیک host رو مسیر می‌ده.
• clawpatrol gateway: خود proxy است؛ یه باینری تکی که HCL config رو لود می‌کنه و کلاینت‌ها رو می‌پذیره.

می‌تونی هرکدوم از این سه شکل رو بسته به نیازت انتخاب کنی؛ لازم نیست همیشه کل host رو مسیر بدی.

چطور همین الان امتحانش کنیم

پروژه زیر لایسنس MIT منتشر شده و از طریق اسکریپت نصب خود پروژه یا از سورس (که نیاز به Go و Node.js داره) قابل بیلده. برای شروع:

بعد از نصب، یه فایل HCL برای قوانینت می‌نویسی (مثلاً بلاک کردن DROP TABLE رو یه دیتابیس خاص، یا نیاز به تأیید انسانی برای حذف پاد رو Kubernetes production)، و agent ت رو طوری تنظیم می‌کنی که ترافیکش از یکی از سه مسیر بالا عبور کنه. ابزار همچنین یه دستور clawpatrol test هم داره که می‌تونی قوانینت رو در برابر یه سری fixture (رکورد شده از دشبورد یا نوشته‌شده‌ی دستی) تو CI تست کنی؛ اگه یه تغییر قانون، نتیجه‌ی یه fixture رو عوض کنه، تست fail می‌شه و diff نشونت می‌ده.

نکته‌ی مهم: هنوز alpha است

خود Deno صراحتاً اعلام کرده که Claw Patrol فعلاً alpha software است. پشتیبانی پروتکل‌ها دقیقاً به اندازه‌ی نیاز خود Deno گسترشه، نه بیشتر؛ اگه پروتکل خاصی می‌خوای که پشتیبانی نمی‌شه، باید یا خودت کدش رو اضافه کنی (مستندات کافی برای این کار هست)، یا از تیم Deno درخواست کنی. شرکت هم صراحتاً از جامعه خواسته که الگوهای قانون‌نویسی واقعی، پروتکل‌های موردنیاز بعدی، و باگ‌های مسیر نصب رو گزارش بدن.

جمع‌بندی

اگه داری agent هایی می‌سازی که دسترسی نوشتنی به زیرساخت واقعی (دیتابیس، کلاستر، سرویس‌های ابری) دارن، Claw Patrol یه لایه‌ی امنیتی جدی و متن‌باز ارائه می‌ده که فراتر از یه HTTP proxy ساده عمل می‌کنه؛ مخصوصاً به این خاطر که پروتکل‌های غیر-HTTP رو هم می‌فهمه و credential های واقعی رو از دید خود agent مخفی نگه می‌داره. ولی چون هنوز alpha است، برای استفاده‌ی production جدی، بهتره اول رو یه محیط تست یا staging امتحانش کنی و منتظر بلوغ بیشتر پروژه بمونی.

دسترسی و قیمت

Grok Bot فعلاً تو مرحله‌ی beta است و فقط برای مشترکین SuperGrok Heavy، Cursor Ultra، و Cursor Teams Premium در دسترسه؛ رو دسکتاپ (مک، ویندوز، لینوکس) و iOS، با اندروید که قراره بعداً اضافه بشه. مشتریان enterprise هم فعلاً باید تو یه لیست انتظار ثبت‌نام کنن. طبق گزارش Constellation Research، این سرویس از حدود ۱۲۰ دلار در ماه شروع می‌شه.

چرا الان و چرا این‌قدر مهمه

با این انتشار، SpaceXAI رسماً وارد بازار agent های سازمانی می‌شه؛ بازاری که تا الان بیشتر تحت تسلط اوپن‌ای‌آی و آنتروپیک بود. طبق گزارش Bloomberg، ایلان ماسک مستقیم تو ایکس اعلام کرده که بعد از رفع مشکلات اولیه‌ی beta و انتشار Grok 4.6 (که قراره همون هفته بیاد)، مقیاس تست Grok Bot رو گسترش می‌ده. این انتشار هم‌زمان با تمرکز بیشتر SpaceX رو بخش enterprise تکنولوژی اتفاق افتاده؛ چیزی که تو گزارش سه‌ماهه‌ی اخیر شرکت هم (چه درباره‌ی Cursor، چه درباره‌ی اتصال سازمانی از طریق Starlink) به‌وضوح دیده می‌شه.

نگرانی‌های امنیتی

طبق چند گزارش، از جمله Analytics Insight، این نوع دسترسی گسترده (login مستقیم به ابزارها و اطلاعات حساس شرکتی) نگرانی‌های امنیتی جدی‌ای هم به همراه داره؛ شرکت‌ها احتمالاً قبل از اجازه دادن به این‌جور bot ها برای دسترسی به اطلاعات حساس، به کنترل‌های دسترسی سخت‌گیرانه‌تری نیاز دارن. این دقیقاً همون چالشیه که هر ابزار agentic دیگه‌ای هم که دسترسی وسیع به سیستم‌های داخلی داره باهاش مواجهه.

جمع‌بندی

Grok Bot، مثل خیلی از محصولات agentic دیگه‌ای که این روزها می‌بینیم، نشون می‌ده صنعت هوش مصنوعی داره از مدل «سؤال و جواب ساده» به سمت «انجام کار واقعی و مستقل» حرکت می‌کنه. نکته‌ی مهمی که باید بهش توجه کرد اینه که این محصول هنوز تو مرحله‌ی early beta است، دسترسیش محدود به مشترکین پولی خاصیه، و مثل هر ابزار جدیدی که به سیستم‌های حساس دسترسی می‌گیره، ارزش داره قبل از استفاده‌ی جدی، سیاست‌های امنیتی و کنترل دسترسیش رو دقیق بررسی کنی.