همه مطالب

۹ جولای ۲۰۲۶، تیم Rust نسخه‌ی ۱.۹۷.۰ رو منتشر کرد. این نسخه تغییرات زبانی بزرگی نداره، ولی سه چیزی که اضافه شده از اون دسته چیزهاییه که وقتی باهاشون کار می‌کنی، خوشحال می‌شی که هستن.

برای آپدیت:

rustup update stable

Symbol mangling v0 حالا پیش‌فرضه

این یکی یه تغییر زیرپوستیه که بیشتر وقت‌ها متوجهش نمی‌شی — تا وقتی که یه stack trace می‌گیری و یهو می‌بینی اسم functionها خوانا شدن.

وقتی Rust کد رو کامپایل می‌کنه، اسم هر item رو mangle می‌کنه تا با اسم‌های مشابه در crate‌های دیگه تداخل نداشته باشه. روش قدیمی از Itanium ABI که C++ هم ازش استفاده می‌کنه الهام گرفته بود — ولی مشکل داشت: generic parameterها فقط پشت یه hash پنهان می‌شدن، و بخش‌هایی از mangling از استاندارد Itanium منحرف شده بودن که همین باعث می‌شد demangler‌های خارجی درست کار نکنن.

روش جدید (v0) از Rust 1.59 به‌عنوان opt-in موجود بود، از نوامبر ۲۰۲۵ روی nightly پیش‌فرض شده بود، و حالا توی ۱.۹۷ به stable رسیده. نتیجه‌ی عملی: وقتی یه panic یا stack trace می‌بینی، اسم functionها همراه generic parameterهاشون نشون داده می‌شن، نه یه رشته‌ی hash‌شده‌ی نامفهوم.

روش قدیمی الان فقط روی nightly در دسترسه و برنامه اینه که در آینده کاملاً حذف بشه.

Cargo حالا warning‌ها رو مدیریت می‌کنه

تا قبل از این، رایج‌ترین راه برای deny کردن warning‌ها در CI این بود:

RUSTFLAGS=-Dwarnings cargo build

مشکل این روش اینه که -Dwarnings رو به هر invocation از rustc پاس می‌ده، و این build cache رو invalidate می‌کنه. یعنی هر بار که توی CI این flag رو داری، از کش استفاده نمی‌شه و همه چیز از صفر compile می‌شه.

از ۱.۹۷، Cargo خودش کنترل می‌کنه که warning‌ها چطور با موفقیت build تعامل داشته باشن. یه env var جدید اضافه شده:

# در CI: deny کردن warning‌ها
CARGO_BUILD_WARNINGS=deny cargo build

# موقع کار: خاموش کردن موقت warning‌ها
CARGO_BUILD_WARNINGS=allow cargo check

# حالت پیش‌فرض: نمایش بدون fail کردن
CARGO_BUILD_WARNINGS=warn cargo build

مزیت مهم اینه که این متغیر build cache رو invalidate نمی‌کنه. یعنی می‌تونی توی CI deny داشته باشی و همچنان از کش استفاده کنی. می‌شه با --keep-going هم ترکیبش کرد تا به‌جای توقف روی اولین خطا، همه‌ی خطاها و warning‌ها یکجا جمع بشن.

خروجی linker دیگه پنهان نمی‌شه

rustc وقتی کامپایل می‌کنه، یه linker رو از طرف کاربر صدا می‌زنه. تا الان اگه link موفق می‌شد، هر پیامی که linker داشت پنهان می‌شد. این رفتار گاهی مشکل‌ساز بود چون warning‌های واقعی linker — مثل deprecation warning برای یه optimization flag قدیمی — اصلاً دیده نمی‌شدن.

از ۱.۹۷، پیام‌های linker به‌صورت پیش‌فرض نمایش داده می‌شن:

warning: linker stderr: ignoring deprecated linker optimization setting '1'
  |
  = note: `#[warn(linker_messages)]` on by default

تیم Rust پیام‌هایی که false positive شناخته‌شده هستن رو فیلتر کرده تا نویز اضافه نداشته باشی. اگه یه پیام می‌بینی که فکر می‌کنی false positive هست، می‌تونی توی Cargo.toml آن را خاموش کنی:

[lints.rust]
linker_messages = "allow"

یه نکته مهم: این lint عمداً از گروه warnings جدا نگه داشته شده. یعنی CARGO_BUILD_WARNINGS=deny روی linker_messages تاثیر نمی‌ذاره — چون خروجی linker از پلتفرمی به پلتفرم دیگه فرق می‌کنه و نمی‌شه به‌طور قطعی همه‌شون رو deny کرد.

APIهای جدید stable شده

چند API مرتبط با bit manipulation اضافه شده که برای کدهای سطح‌پایین کاربردیه:

let x: u32 = 0b1010_1100;

// جدا کردن بیت بالایی
x.isolate_highest_one(); // => 0b1000_0000

// جدا کردن بیت پایینی
x.isolate_lowest_one(); // => 0b0000_0100

// مقدار بیت بالایی
x.highest_one(); // => 0b1000_0000

// مقدار بیت پایینی
x.lowest_one(); // => 0b0000_0100

// تعداد bitهای لازم برای نمایش مقدار
x.bit_width(); // => 8

همه‌ی این methodها روی NonZero<T> هم در دسترسن. char::is_control هم حالا توی context‌های const کار می‌کنه.

یه تغییر کوچیک برای کاربران WebAssembly

اگه با WebAssembly کار می‌کنی، یه breaking change هست که از نسخه‌ی ۱.۹۶ شروع شده: Rust دیگه به‌طور پیش‌فرض --allow-undefined به linker پاس نمی‌ده. یعنی symbolهای undefined الان linker error هستن، نه WebAssembly import‌های ضمنی. اگه intentional بود، باید صریح تعریفش کنی:

#[link(wasm_import_module = "env")]
unsafe extern "C" {
    fn my_extern_function();
}

این release از نظر حجم تغییرات زبانی یه نسخه‌ی آروم بود، ولی هر سه‌ی این تغییرها از اون دسته چیزهاییه که بعد از یه مدت کار کردن باهاشون، نفهمیدی چطور قبلاً بدونشون کار می‌کردی.

۹ جولای ۲۰۲۶، متا همزمان دو کار کرد: یه مدل جدید منتشر کرد و برای اولین‌بار پول گرفت. این دومی شاید مهم‌تر از اولی باشه.

متا سال‌ها روی open-source بود — Llama، Llama 2، Llama 3 — و هویتش رو روی این گذاشته بود که «ما مدل‌ها رو رایگان می‌دیم». Muse Spark 1.1 اولین مدل frontier متاست که پشت یه paid API قرار گرفته. این یعنی متا دیگه فقط یه تامین‌کننده‌ی مدل open-source نیست — داره مستقیم وارد همون بازاری می‌شه که Anthropic و OpenAI ازش پول در می‌آرن.

مدل چیه

Muse Spark 1.1 نسخه‌ی ارتقاءیافته‌ی Muse Spark اصلیه که اپریل ۲۰۲۶ منتشر شد — اولین مدل از Meta Superintelligence Labs، واحدی که Alexandr Wang (موسس Scale AI) رهبریش رو بر عهده داره. این مدل multimodal و reasoning-based هست و برای کارهای agentic طراحی شده: متن، تصویر، و ویدیو رو می‌فهمه، از ابزارها و سرویس‌های خارجی استفاده می‌کنه، کدنویسی و دیباگ می‌کنه، و می‌تونه وظایف چندمرحله‌ای رو با دخالت کمتر انسان انجام بده.

context window یه میلیون توکن داره، که برای کارهای agentic طولانی‌مدت عدد مهمیه. یه ویژگی هم که متا روش تاکید کرده اینه که مدل می‌تونه به‌جای اینکه sequential کار کنه، parallel subagent بزنه — یعنی چند بخش از یه task رو همزمان پیش ببره.

کجا قوی‌ترین، کجا عقب‌تر

متا روی benchmark‌هایی مثل MCP Atlas، JobBench، Humanity's Last Exam، و FinanceBench عملکرد خوبی نشون داده. MCP Atlas مخصوصاً مهمه چون tool-call success رو روی task typeهای مختلف می‌سنجه — و این دقیقاً همون چیزیه که برای ساختن agent واقعی اهمیت داره.

ولی متا خودش هم صادق بوده: روی benchmark‌های خالص کدنویسی و reasoning، Opus 4.8 از آنتروپیک و GPT-5.5 از OpenAI هنوز جلوترن. و Mythos 5 و Fable 5 آنتروپیک و GPT-5.6 سول از OpenAI هم کلاً در یه لیگ دیگه‌ان. Muse Spark 1.1 رو نه باید با بهترین مدل‌های موجود مقایسه کنی، نه باید دست کم بگیریش.

قیمت‌گذاری

هر یک‌میلیون توکن ورودی ۱.۲۵ دلار، خروجی ۴.۲۵ دلار. این عدد رو بذار کنار بقیه:

توکن ورودی‌های Claude Haiku 4.5 و GPT-5.6 Luna از Muse Spark ارزون‌ترن، ولی Sonnet 4.6 آنتروپیک و مدل‌های میانه‌ی OpenAI گرون‌ترن. یعنی Muse Spark 1.1 توی طیف mid-tier قیمتی قرار می‌گیره — نه ارزون‌ترین، نه گرون‌ترین. برای کسی که می‌خواد یه مدل agentic با context window بزرگ و قیمت معقول داشته باشه، جای جالبیه.

توسعه‌دهنده‌هایی که ثبت‌نام می‌کنن ۲۰ دلار اعتبار رایگان می‌گیرن.

نکته‌ای که توسعه‌دهنده‌ها باید بدونن

Meta Model API هم با OpenAI SDK سازگاره هم با Anthropic Messages format. یعنی اگه الان روی یکی از این دوتا کار می‌کنی، اشتکال‌پذیری به Muse Spark نیاز به rewrite نداره — فقط base URL رو به api.meta.ai/v1 تغییر بده، key بده، و اسم مدل رو muse-spark-1.1 بذار.

این یه تصمیم توزیع‌گر هوشمندانه‌ست. یعنی تیم‌ها می‌تونن Muse Spark رو A/B کنن با مدل فعلیشون بدون اینکه stack رو از نو بسازن.

این هفته برای متا

Muse Spark 1.1 تنها چیزی نبود که این هفته از متا اومد. دو روز قبلش Muse Image و Muse Video هم منتشر شدن — اولین مدل‌های تولید تصویر و ویدیوی Superintelligence Labs. ولی Muse Image یه جنجال هم به‌همراه آورد: اجازه داد کاربرا روی عکس‌های public اینستاگرامی که دیگران گذاشتن افکت AI اعمال کنن، بدون اینکه از صاحب عکس اجازه گرفته بشه. این تصمیم با اعتراض زیادی روبه‌رو شد.

وضعیت دسترسی

مدل الان توی «Thinking mode» در اپ Meta AI و سایت meta.ai در دسترسه — بدون نیاز به API. برای توسعه‌دهنده‌ها، Meta Model API به‌صورت public preview فعلاً فقط برای آمریکاییاست.

متا گفته این مدل در آینده جای Llama رو توی WhatsApp، Instagram، Facebook، و عینک‌های هوشمند متا هم می‌گیره. مارک زاکربرگ هم برای اولین‌بار از جولای ۲۰۲۳ روی X پست گذاشت که این مدل «strong agentic and coding model at a very low price» هست. سه سال سکوت روی یه پلتفرم برای اعلام یه مدل AI — این یه نشانه از اینه که داخل متا چقدر به این لانچ اهمیت می‌دن.

رقابت AI این هفته به‌طرز جالبی شلوغ بود. بازار داره به یه سمتی می‌ره که قیمت‌ها پایین‌تر، context windowها بزرگ‌تر، و تمرکز بیشتر روی کار agentic هست. Muse Spark 1.1 دقیقاً وسط همین جریانه.

۸ جولای ۲۰۲۶، مایکروسافت نسخه‌ی stable از TypeScript 7 رو منتشر کرد. بعد از حدود یه سال preview و beta و RC، حالا دیگه آزمایشی نیست.

اگه مقاله‌ی قبلی ما درباره‌ی RC رو خونده باشی، می‌دونی ماجرا از کجا شروع شد: مایکروسافت کامپایلر TypeScript رو که از ابتدا با JavaScript نوشته شده بود، با Go بازنویسی کرد. ولی «بازنویسی» دقیقاً کلمه‌ی درستی نیست — این یه port بود. ساختار کد، الگوریتم‌ها، و data structureها حفظ شدن، فقط زبان پیاده‌سازی عوض شد. نتیجه اینه که semantics تایپ‌چک دقیقاً همونه، ولی سرعتش حالا چیز دیگه‌ایه.

اعداد واقعی روی پروژه‌های واقعی

مایکروسافت همراه با اعلام stable، benchmark روی چند codebase واقعی منتشر کرده. روی VS Code با ۲.۳ میلیون خط کد، تایپ‌چک از ۱۲۵ ثانیه به ۱۰.۶ ثانیه رسیده — نزدیک ۱۲ برابر. روی Sentry با ۱.۹ میلیون خط، ۱۵.۷ ثانیه. روی Bluesky با ۶۲۸ هزار خط، ۲.۸ ثانیه. روی Playwright با ۵۲۸ هزار خط، ۱.۴۷ ثانیه.

عدد کلی که مایکروسافت می‌گه «اغلب بین ۸ تا ۱۲ برابر» هست — نه ۱۰ برابر ثابت. این بستگی داره به اندازه‌ی پروژه و ساختار dependency graph.

دلیل این سرعت دو چیز بود: اول، Go binary به‌جای JavaScript interpreted اجرا می‌شه. دوم، کامپایلر جدید می‌تونه از shared memory parallelism استفاده کنه. به‌صورت پیش‌فرض با ۴ worker تایپ‌چک می‌کنه — می‌تونی با flag --checkers این عدد رو تنظیم کنی. worker بیشتر یعنی سریع‌تر، ولی رم بیشتر هم می‌خواد.

برای چی این‌قدر طول کشید؟

وقتی مارس ۲۰۲۵ Anders Hejlsberg این پروژه رو اعلام کرد، خیلی‌ها انتظار نداشتن که اینقدر زود stable بشه. در واقع beta اپریل ۲۰۲۶ اومد، RC ژوئن ۲۰۲۶، و stable جولای ۲۰۲۶ — تقریباً ۱۵ ماه از اعلام تا stable. دلیل این سرعت نسبی اینه که از صفر طراحی نشد؛ port بود نه rewrite.

مایکروسافت بیش از یه سال با تیم‌های داخلی و شرکت‌هایی مثل Bloomberg، Canva، Figma، Google، Notion، Slack، Vercel و VoidZero روی preview buildها کار کرد. نتیجه اینه که از روز اول stable، این مدل‌ها روی codebaseهای میلیون‌خطی تایید شده.

نصب

npm install -D typescript@latest

همین. دیگه خبری از @typescript/native-preview یا tsgo نیست — اون package برای دوران beta بود. از این به بعد همه چیز از همون typescript package معمولی میاد و با همون tsc اجرا می‌شه.

برای چک کردن نسخه:

npx tsc --version  # باید TypeScript 7.x.x باشه

چی ممکنه بشکنه

TypeScript 7 با TypeScript 6 از نظر تایپ‌چک compatible هست — یعنی کدی که با ۶ compile می‌شد باید با ۷ هم compile بشه. با این حال، چند تغییر هست که باید بدانی:

--target es5 و format‌های output مثل AMD، UMD و SystemJS حذف شدن. moduleResolution: "node10" (همون قدیمی‌ترها که node می‌نوشتن) هم نیست. rootDir حالا به‌صورت پیش‌فرض ./ هست نه root پروژه، و types به‌صورت پیش‌فرض آرایه‌ی خالیه.

اگه مستقیم از TypeScript 5 یا قدیمی‌تر upgrade می‌کنی — نه ۶ — احتمال مشکل بیشتره چون این deprecationها توی ۶ warning بودن و حالا توی ۷ hard error شدن. توصیه اینه که اگه روی ۵ هستی، اول به ۶ بری و بعد به ۷.

یه چیز مهم که هنوز نیست

API برنامه‌نویسی TypeScript — همونی که ابزارهایی مثل typescript-eslint، ts-morph، و custom transformerها ازش استفاده می‌کنن — توی ۷.۰ پایدار نیست. مایکروسافت گفته این API توی نسخه‌ی ۷.۱ که چند ماه دیگه میاد آماده می‌شه.

یعنی اگه workflow‌ات به این ابزارها وابسته‌ست، فعلاً باید یه سری چیزها رو pinned روی TypeScript 6 نگه داری:

npm install -D @typescript/typescript6   # aliased package برای linting

مایکروسافت یه compatibility package برای این کار منتشر کرده تا بتونی هم ۶ هم ۷ رو side-by-side داشته باشی.

editor

برای VS Code، TypeScript Native Preview extension که قبلاً جداگانه نصب می‌کردی دیگه لازم نیست — همون typescript package که توی پروژه نصبه، editor هم ازش استفاده می‌کنه. فقط یه بار VS Code رو restart کن.

اگه روی editor دیگه‌ای کار می‌کنی (Neovim، Zed، Cursor)، language server protocol یکیه — هر clientی که از tsserver استفاده می‌کنه خودش سریع‌تر می‌شه بدون اینکه config خاصی بخواد.

نظر شخصی

این نوع تغییرات نادره. معمولاً «مهم‌ترین release در سال‌های اخیر» یه عبارت overused هست، ولی اینجا واقعاً صدق می‌کنه — نه به‌خاطر یه feature جدید، بلکه به‌خاطر اینکه یه چیزی که همه باهاش کنار اومده بودن (کامپایلر کند) یهو یه مقیاس کامل فرق کرده. اگه روی پروژه‌ی بزرگی کار می‌کنی که تایپ‌چک CI بیشتر از یه دقیقه طول می‌کشه، آپدیت کردن به ۷ احتمالاً صرفه‌جویانه‌ترین کاریه که می‌تونی این هفته انجام بدی.

این موضوع واقعا من رو به شخصه آزار میداد. من سیستمم بد  نیست ولی تاپ ناچم نیست و خب لود شدن تایپ اسکریپت برام انقدر کند بود که واقعا ازاردهنده بود. هنوز بررسیش نکردم ولی خب I have a lot of hope

اگه روی یه پروژه‌ی Next.js بزرگ کار کردی و یه نقطه‌ای رسیدی که Task Manager رو باز کردی و دیدی dev server تنهایی داره ۸ گیگ رم می‌خوره، می‌دونی این احساس چیه. Turbopack از اول با این طراحی اومد که همه‌چیز رو cache کنه تا compile سریع‌تر باشه — ولی قیمتش این بود که هرچقدر بیشتر توی پروژه می‌چرخیدی، حافظه بیشتری می‌خورد و هیچ‌وقت هم آزاد نمی‌کرد.

نسخه‌ی ۱۶.۳ این trade-off رو عوض کرده.

مصرف حافظه: ۹۰ درصد کمتر

تیم Turbopack سه ماه روی این کار کرد. نتیجه چیه؟ روی codebase داشبورد vercel.com، بعد از compile کردن ۵۰ route، مصرف حافظه از ۲۱.۵ گیگابایت به ۲ گیگابایت رسیده — یعنی ۹۰ درصد کمتر. روی سایت nextjs.org هم از ۴۶۰۰ مگابایت به ۸۴۰ مگابایت، یعنی حدود ۸۲ درصد کاهش.

چطور؟ با یه مکانیزم جدید به اسم memory eviction. ایده ساده‌ست: به‌جای اینکه نتایج cache شده برای همیشه توی RAM نگه داشته بشن، حالا Turbopack می‌تونه اونایی که دیگه فعال استفاده نمی‌شن رو بریزه روی دیسک و از حافظه پاک کنه. این feature روی filesystem cache که از نسخه‌ی ۱۶.۱ اضافه شده بود تکیه می‌کنه، و توی ۱۶.۳ هر دو به‌صورت پیش‌فرض فعال هستن.

اگه بخوای غیرفعالش کنی یا رفتارش رو debug کنی:

const nextConfig = {
  experimental: {
    turbopackMemoryEviction: false,
  },
};

یه چیز مهم: عدد دقیق کاهش حافظه برای هر پروژه فرق می‌کنه. بستگی داره به اینکه route graph پروژه‌ات چقدر بزرگه و توی یه session چقدر ازش استفاده کردی.

filesystem cache برای build

تا الان، filesystem cache فقط توی next dev کار می‌کرد. از ۱۶.۳، همین cache برای next build هم در دسترسه.

اعداد رو ببین: روی nextjs.org، build با cache از ۲۱ ثانیه به ۹.۲ ثانیه رسیده — ۲.۳ برابر سریع‌تر. روی vercel.com/geist که یه design system بزرگه، از ۳۰ ثانیه به ۵.۵ ثانیه — یعنی ۵.۵ برابر. روی vercel.com/home که پروژه‌ی سنگین‌تریه، بهبود کمتره: از ۶۶ به ۴۶ ثانیه.

فعال کردنش یه flag می‌خواد:

const nextConfig = {
  experimental: {
    turbopackFileSystemCacheForBuild: true,
  },
};

برای CI هم می‌شه از این استفاده کرد: کافیه پوشه‌ی .next رو بین runها کش کنی. وقتی Turbopack اون دایرکتوری رو اول build پیدا کنه، از کار قبلی استفاده می‌کنه به‌جای اینکه همه‌چیز رو از صفر compile کنه.

React Compiler با Rust

React Compiler از نسخه‌ی ۱۶.۰ توی Next.js stable بوده، ولی تا الان فقط به‌عنوان یه Babel transform اجرا می‌شد. مشکل اینجا بود که Babel روی پروژه‌های بزرگ سنگین می‌شد و build رو کند می‌کرد.

تیم React یه پورت native از این compiler با Rust نوشته، و تیم Turbopack سریع این رو integrate کرده. نتایج اولیه روی پروژه‌هایی مثل v0 نشون می‌ده که compile time بین ۲۰ تا ۵۰ درصد بهتر می‌شه. فعلاً experimental هست:

const nextConfig = {
  reactCompiler: true,
  experimental: {
    turbopackRustReactCompiler: true,
  },
};

import.meta.glob

Turbopack حالا از API ای که Vite معروفش کرده پشتیبانی می‌کنه:

const posts = import.meta.glob('./posts/*.mdx');

این به‌جای اینکه مجبور بشی اسم همه‌ی فایل‌ها رو hardcode کنی، هر فایلی که با pattern مطابقت داشته باشه رو import می‌کنه. نتیجه یه object هست که key‌هاش path فایل‌هاست:

for (const path in posts) {
  const post = await posts[path]();
}

می‌تونی با eager: true همه‌شون رو بلافاصله import کنی، یا فقط چند export خاص رو بگیری، یا pattern‌های منفی بگذاری. file watcher هم بهش وصله — اگه فایلی اضافه یا حذف شد، خودش recompile می‌کنه.

یه نکته: این feature فقط روی Turbopack کار می‌کنه. اگه هنوز با --webpack build می‌گیری، اینجا نیست.

HMR سریع‌تر و runtime کوچیک‌تر

دو بهبود دیگه که کمتر headline می‌گیرن ولی در عمل احساس می‌شن: اول اینکه HMR subscription tracking بهتر شده — با یکی کردن چند subscription در جاهایی که قبلاً جداگانه بودن، dev server cold start روی اپ‌های پیچیده بیش از ۱۵ درصد سریع‌تر شده. دوم اینکه runtime code ای که Turbopack به هر route اضافه می‌کنه کوچیک‌تر شده — چون حالا فقط کدی که واقعاً استفاده می‌شه (مثل WebAssembly loader یا worker support) شیپ می‌شه، نه همه‌چیز یکجا.

یه feature کوچیک‌تر هم برای monorepoها اومده: با turbopackLocalPostcssConfig: true می‌تونی per-package پیکربندی PostCSS داشته باشی به‌جای اینکه همه از root config بخوننن.

اگه الان روی Next.js 16.x هستی، این آپدیت شاید مهم‌ترین چیزیه که از نظر DX روزانه حسش می‌کنی — نه یه feature جدید، بلکه اینکه وقتی ساعت‌ها روی پروژه کار می‌کنی، IDE و dev server با هم دیگه دعوا نمی‌کنن سر رم.

اگه یه پروژه‌ی TypeScript بزرگ داری و تایپ‌چک هر بار چند دقیقه طول می‌کشه، این خبر برات جالبه: مایکروسافت ۱۸ ژوئن ۲۰۲۶ نسخه‌ی Release Candidate از TypeScript 7 رو منتشر کرد. نسخه‌ی stable هم قراره تا اواخر جولای ۲۰۲۶ بیاد.

چیزی که این نسخه رو از همه‌ی نسخه‌های قبلی متمایز می‌کنه اینه که کامپایلر دیگه با JavaScript نوشته نشده — حالا با Go نوشته شده. این پروژه از مارس ۲۰۲۵ با اعلام Anders Hejlsberg شروع شد، حدود پانزده ماه در فضای عمومی توسعه پیدا کرد، و حالا به مرحله‌ای رسیده که مایکروسافت می‌گه آماده‌ی استفاده‌ی روزانه است.

چرا Go؟

سوال منطقیه. TypeScript خودش یه زبان strongly-typed هست، چرا کامپایلرش رو با Go بنویسن نه Rust یا حتی TypeScript خودش؟

دلیل اصلی اینه که Go برای این نوع workload — یعنی parse کردن فایل‌های موازی، مدیریت حافظه‌ی مشترک، و پیاده‌سازی یه language service همزمان — tooling و runtime بهتری داره. Rust هم می‌تونست کار کنه، ولی تیم تصمیم گرفت با Go برگشت سریع‌تری داشته باشه.

نکته‌ی مهم‌تر اینه که این یه port هست نه یه rewrite از صفر. تیم TypeScript ساختار کد، الگوریتم‌ها، و data structureهای کامپایلر رو حفظ کرده — فقط زبان پیاده‌سازی عوض شده. این یعنی semantics تایپ‌چک دقیقاً همونه. در آزمون‌هایی که مایکروسافت انجام داده، از حدود ۲۰ هزار تست‌کیس کامپایلر، TypeScript 7 در همه جز ۷۴ مورد دقیقاً همون خطاهای TypeScript 6 رو برمی‌گردونه.

چقدر سریع‌تره؟

عدد رسمی که مایکروسافت داده «اغلب حدود ۱۰ برابر سریع‌تر از TypeScript 6» هست. این یه میانگین روی پروژه‌های مختلفه، نه یه عدد ثابت. روی codebase خود VS Code که حدود ۱.۵ میلیون خط هست، تایپ‌چک از ۷۷.۸ ثانیه به ۷.۵ ثانیه رسیده — حدود ۱۰.۴ برابر. زمان لود پروژه توی editor هم از ۹.۶ ثانیه به ۱.۲ ثانیه رسیده، و مصرف حافظه هم تقریباً نصف شده.

دو چیز این سرعت رو ممکن کرده: اول، Go binary به‌جای کد JavaScript interpreted اجرا می‌شه. دوم، مایکروسافت ساختار language service رو بازطراحی کرده تا از shared-memory parallelism استفاده کنه — چیزی که با runtime تک‌thread قبلی اصلاً ممکن نبود.

چی تغییر کرده که ممکنه کدت رو بشکنه

TypeScript 7 یه سری breaking change داره که اکثرشون از نسخه‌ی ۶ که «bridge release» بود، deprecated شده بودن:

پشتیبانی از --target es5 حذف شده. اگه هنوز برای مرورگرهای قدیمی build می‌گیری، باید از ابزارهای دیگه‌ای مثل Babel استفاده کنی. فرمت‌های output مثل AMD، UMD و SystemJS هم حذف شدن. moduleResolution: "node10" (که قبلاً به اسم node هم شناخته می‌شد) حذف شده و باید به bundler یا node16 تغییر پیدا کنه. --baseUrl و --paths هم رفتار قبلی‌شون رو ندارن و باید با paths توی tsconfig.json جایگزین بشن.

یه تغییر مهم دیگه اینه که rootDir حالا به‌صورت پیش‌فرض به ./src اشاره می‌کنه نه root پروژه.

مایکروسافت می‌گه ۹۵ درصد پروژه‌های TypeScript 6 بدون تغییر compile می‌شن. ولی اون ۵ درصد رو باید جدی بگیری — خصوصاً اگه پروژه‌ی قدیمیه یا config پیچیده داره.

API programmatic هنوز آماده نیست

یه محدودیت مهم که باید بدانی: API برنامه‌نویسی TypeScript — همونی که ابزارهایی مثل ts-jest، ts-node، و eslint-plugin-typescript ازش استفاده می‌کنن — هنوز در TypeScript 7 پایدار نیست. مایکروسافت گفته این API توی نسخه‌ی ۷.۱ که چند ماه بعد از ۷.۰ stable میاد آماده می‌شه.

یعنی اگه از این ابزارها استفاده می‌کنی، باید صبر کنی یا با احتیاط تست کنی.

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

npm install -D typescript@rc

همین. بعد از این:

npx tsc --version   # باید v7.0.0-rc باشه
npx tsc --noEmit    # تایپ‌چک کل پروژه

tsc داخل typescript@rc همون باینری Go هست. اسم tsgo که توی preview‌های ۲۰۲۵ استفاده می‌شد، حالا فقط برای nightly channel مانده.

برای rollback هم typescript@6 رو کنار داشته باش:

npm install -D typescript@6   # نسخه‌ی قبلی

آیا الان باید به پروداکشن ببریش؟

RC هست، نه stable. مایکروسافت می‌گه «highly stable» هست و بیش از یه سال pre-release testing داشته، ولی هنوز GA نشده.

برای سرویس‌های داخلی و pipeline های CI که فقط type-check می‌کنن و emit نمی‌کنن، همین الان می‌ارزه امتحانش کنی. اگه از API برنامه‌نویسی استفاده می‌کنی یا workflow پیچیده‌ای داری، صبر کن stable بیاد — که طبق برنامه اواخر جولای ۲۰۲۶ هست.

این بزرگ‌ترین تغییر توی TypeScript از همون اول بود. نه یه feature جدید، نه یه syntax تازه — یه تغییر بنیادی توی اینکه کامپایلر اصلاً چطور کار می‌کنه. و از اون نوع تغییراتیه که اکثر توسعه‌دهنده‌ها بدون اینکه بدونن چی عوض شده، فقط حس می‌کنن IDE یهو خیلی سریع‌تر شده.

یه چیز جالب داره توی فضای توسعه نرم‌افزار اتفاق می‌افته: یه بخش قابل‌توجه از کدی که توی Next.js نوشته می‌شه دیگه توسط انسان‌ها تایپ نمی‌شه. Claude Code، Cursor، Codex — این‌ها دارن به ابزارهای اصلی خیلی از تیم‌ها تبدیل می‌شن. تیم Next.js یه سوال جالب پرسیده: اگه فریم‌ورک می‌دونست که اکثر کدش رو یه agent می‌نویسه، چی فرق می‌کرد؟

۲۶ ژوئن ۲۰۲۶، Next.js 16.3 یه پست مجزا فقط برای بهبودهای AI-محور منتشر کرد — چیزی که قبلاً سابقه نداشت. این مقاله رو مرور می‌کنه.

AGENTS.md: agent بخونه، نه training data رو

توی نسخه‌ی ۱۶.۲، Next.js شروع کرد به bundled کردن مستنداتش داخل پروژه. ایده ساده بود: agent‌ها اغلب از training data خودشون استفاده می‌کنن، که ممکنه چند نسخه عقب‌تر باشه. اگه داک‌های نسخه‌ی فعلی رو داخل node_modules بگذاری و از طریق AGENTS.md بهش اشاره کنی، agent مجبور می‌شه نسخه‌ی درست رو بخونه.

توی ۱۶.۳، next dev به‌طور خودکار این pointer رو می‌نویسه و به‌روز نگه می‌داره. پروژه‌های قدیمی‌تر می‌تونن با یه codemod یه‌بار این کار رو بکنن:

npx @next/codemod@canary agents-md

بلوکی که next dev به AGENTS.md اضافه می‌کنه صریحه:

<!-- BEGIN:nextjs-agent-rules -->
# This is NOT the Next.js you know
This version has breaking changes — APIs, conventions, and file structure
may all differ from your training data. Read the relevant guide in
`node_modules/next/dist/docs/` before writing any code.
<!-- END:nextjs-agent-rules -->

این بلوک فقط وقتی next dev یه AI coding agent رو توی environment تشخیص بده نوشته می‌شه، و هر چیزی بیرون از marker‌ها دست‌نخورده می‌مونه.

Skills: وقتی داک کافی نیست

Skills برای workflow‌های چندمرحله‌ای‌اند — جایی که داک‌ها تنها نمی‌تونن agent رو از اول تا آخر هدایت کنن. سه Skill جدید اضافه شده:

next-dev-loop: به agent دسترسی به dev loop کامل می‌ده — مرورگر، console، network، و درخت React. بعد از هر ویرایش می‌تونه ببینه صفحه هنوز کار می‌کنه یا نه.

npx skills add vercel/next.js --skill next-dev-loop

next-cache-components-adoption: Cache Components رو توی پروژه فعال می‌کنه و یه feature در یه زمان پیش می‌ره. دو mode داره: incremental که یه PR مکانیکی می‌سازه و بقیه رو می‌ذاره برای بعد، و direct که همه‌ی route‌ها رو یه‌جا روی یه branch تغییر می‌ده.

next-cache-components-optimizer: یه route رو برای instant navigation بهینه می‌کنه با یه حلقه‌ی observe-fix-iterate روی static shell. قبل و بعد از هر تغییر screenshot می‌گیره؛ اگه تصاویر یکسان باشن، تغییر rollback می‌شه.

Agent Browser با React introspection

next-browser که توی ۱۶.۲ اضافه شده بود حالا merge شده توی agent-browser — یه CLI همه‌منظوره که فراتر از Next.js هم کار می‌کنه.

نسخه‌ی ۰.۲۷ یه چیز مهم اضافه کرده: React DevTools introspection. Agent‌ها الان می‌تونن درخت کامپوننت رو لیست کنن، یه کامپوننت خاص رو inspect کنن، re-renderها رو profile کنن، و ببینن چی یه render رو نگه داشته.

Actionable errors: خطا با دستورالعمل

وقتی Cache Components فعاله، یه await روی سرور یه انتخابه. Instant Insights این انتخاب رو به‌عنوان یه error با سه fix مشخص نشون می‌ده: Stream با <Suspense>، Cache با "use cache"، یا Block با export const instant = false.

اما مهم‌تر از خود error، یه دکمه‌ی «Copy prompt» اضافه شده. این دکمه fix انتخاب‌شده رو بسته‌بندی می‌کنه توی یه پرامپت آماده برای agent: شناسایی کد مشکل‌دار، خوندن داک مربوط، اعمال pattern، و تایید نتیجه توی مرورگر از طریق next-dev-loop.

همین fix menu توی terminal هم هست. next build و next dev هر دو خطاها رو با گزینه‌های labeled و لینک به بخش مربوطه از داک‌ها output می‌کنن — یعنی agent‌هایی که dev overlay ندارن و فقط terminal رو می‌خونن همون اطلاعات رو می‌گیرن.

هر error یه صفحه‌ی مجزا روی nextjs.org/docs/messages داره که برای خوندن توسط agent‌ها نوشته شده. هر صفحه همون ساختار رو داره: Patterns، Trade-offs، و Gotchas — یه چیزی که agent‌ها توی اولین تلاش احتمالاً بهش توجه نمی‌کنن.

MCP server: کوچیک‌تر و متمرکزتر

MCP server قبلاً یه knowledge base داخلی داشت. با اینکه bundled docs الان همون کار رو می‌کنه، اون ابزارها حذف شدن. در عوض، دو ابزار جدید اضافه شده: get_compilation_issues برای کل پروژه، و compile_route برای یه route خاص. agent‌ها اغلب next build می‌زدن فقط برای چک کردن compilation — این ابزارها همون سوال رو از dev server در حال اجرا جواب می‌دن، خیلی سریع‌تر.

Docs as Markdown

یه چیز ساده ولی کاربردی: به هر URL از داک‌های Next.js یه .md اضافه کن تا نسخه‌ی Markdown صفحه رو بگیری. همین برای صفحه‌های error هم کار می‌کنه.

ایندکس کامل روی /docs/llms.txt هست، و /docs/llms-full.txt همه‌ی صفحات رو توی یه فایل bundle می‌کنه — طبق convention استاندارد llms.txt.

یه قدم به سمت agent-first development

اگه بخوای خیلی ساده بگی چی اضافه شده: Next.js داره سعی می‌کنه agent‌ها رو مثل یه نوع developer جدید در نظر بگیره — با نیازهای متفاوت. Agent به داک‌های به‌روز نیاز داره نه training data قدیمی، به خطاهای actionable نیاز داره نه فقط error message، و به یه feedback loop نیاز داره که بتونه بعد از هر تغییر runtime رو چک کنه.

فعلاً هنوز preview هست. اگه می‌خوای همین الان امتحان کنی:

npm install next@preview

و بعد ببین کدوم بخش از workflow توسعه‌ات واقعاً بهتر می‌شه — یا نمی‌شه.

۹ ژوئن، آنتروپیک Fable 5 رو با سروصدا لانچ کرد. سه روز بعد، همه‌ی دسترسی‌ها قطع شد. اگه اون روزها پای Claude بودی و یهو دیدی مدل پیش‌فرضت دوباره همون Sonnet قدیمیه، تخیلات نبود — دولت آمریکا دخالت کرده بود.

۱۲ ژوئن، وزارت بازرگانی آمریکا یک دستورالعمل کنترل صادرات اعمال کرد که به‌خاطرش آنتروپیک مجبور شد دسترسی به Fable 5 و Mythos 5 رو برای همه قطع کند. دلیل رسمی این بود که شرکت نمی‌توانست در لحظه تشخیص دهد کاربر اهل کجاست، پس به‌جای محدودیت جغرافیایی، کل سرویس رو خواباند. بعداً مشخص شد محققی در آمازون روشی برای دور زدن safeguardهای Fable 5 پیدا کرده که مدل رو به پیدا کردن آسیب‌پذیری و نوشتن کد اکسپلویت وادار می‌کرده. آنتروپیک بلافاصله یه کلاسیفایر جدید آماده کرد تا این حفره رو ببندد، و بعد از ۱۸ روز توقف، ۳۰ ژوئن وزارت بازرگانی آمریکا محدودیت رو برداشت.

از اول جولای، Fable 5 برگشته — این‌بار با دسترسی جهانی و safeguardهای تقویت‌شده.

این ۱۸ روز برای کاربران معمولی یعنی چی بود

بذار صادق باشیم: اگه از نسخه‌ی رایگان یا Pro استفاده می‌کردی، احتمالاً اصلاً Fable 5 رو لمس نکردی. مدل از همان ابتدا فقط تا ۲۲ ژوئن روی پلن‌های Pro، Max و Team رایگان بود، و بعدش به کردیت نیاز داشت. یعنی پنجره‌ی دسترسی رایگان برای اکثر کاربران از اول هم کوتاه بود.

و همین‌جا بود که Sonnet 5 وارد شد — نه به‌عنوان جایگزین Fable، بلکه به‌عنوان چیزی که قرار بود برای بیشتر کاربران مدل روزمره باشد. آنتروپیک Sonnet 5 رو همزمان با اعلام بازگشت Fable معرفی کرد، و از همان روز اول به‌عنوان مدل پیش‌فرض برای پلن‌های Free و Pro تعریف شد.

ولی اگه روی نسخه‌ی رایگان یا حتی High توی پلن پولی امتحانش کردی، احتمالاً همون چیزی رو دیدی که من دیدم: با یه پرامپت و نصفه جواب برنمی‌گردوند. نه یه مکالمه‌ی طولانی، نه یه کار سنگین — یه سوال معمولی. محدودیت نرخ Sonnet 5 فعلاً خیلی سریع‌تر از نسخه‌های قبلی فعال می‌شود، مخصوصاً توی ساعت‌های شلوغ. آنتروپیک گفته که rate limitها رو برای پلن‌های مختلف افزایش داده، ولی در تستی که من انجام دادم در مدل رایگان جدید واقعا اینطور بنظر نیومد.

Sonnet 5 واقعاً چقدر فرق دارد

ادعای اصلی آنتروپیک این است که Sonnet 5 به عملکرد Opus 4.8 نزدیک است، ولی با قیمت خیلی پایین‌تر. در API، نرخ تعارفی تا پایان اوت ۲۰۲۶ برای هر یک‌میلیون توکن ورودی دو دلار و خروجی ده دلار است، بعدش به سه و پانزده دلار می‌رسد. Opus 4.8 روی همین مقیاس پنج و بیست‌وپنج دلار است. از نظر اعداد، Sonnet 5 روی بنچمارک‌های BrowseComp و OSWorld-Verified خیلی به Opus 4.8 نزدیک‌تر از Sonnet 4.6 است.

تفاوت اصلی در agentic قابلیت‌هاست: برنامه‌ریزی چندمرحله‌ای، کنترل مرورگر و ترمینال، و چک‌کردن خودکار خروجی بدون این‌که لازم باشد توی پرامپت بگویی «جوابت رو بررسی کن». اینا قابلیت‌هایی بودند که قبلاً بیشتر مختص مدل‌های Opus بود. از نظر امنیت سایبری هم آنتروپیک می‌گوید Sonnet 5 هیچ‌وقت روی داده‌های تخصصی امنیتی آموزش ندیده، و در تست‌هایی که با موزیلا انجام شده، روی آسیب‌پذیری‌های شناخته‌شده‌ی فایرفاکس هیچ اکسپلویت کاملی تولید نکرده. به همین خاطر هم دولت آمریکا سراغش نیامده.

Fable 5 الان چه وضعیتی دارد

Fable 5 برگشته، ولی نه به همان شکلی که اول لانچ شده بود. دسترسی رایگان روی پلن‌های Pro و Max تموم شده — حالا به کردیت نیاز دارد. Anthropic گفته هدفش این است که در آینده Fable رو دوباره به‌عنوان بخشی از پلن‌های اشتراکی برگرداند، ولی زمان مشخصی نداده.

Mythos 5 هنوز محدود است. آنتروپیک دسترسی رو برای یه سری سازمان‌های آمریکایی تاییدشده برقرار کرده و داره فهرست Project Glasswing رو گسترش می‌دهد، ولی برای عموم در دسترس نیست و ظاهراً تا مدتی هم نخواهد بود.

یه چیز جالب توی این ماجرا این بود که آنتروپیک، آمازون، مایکروسافت و گوگل با هم یه چارچوب مشترک برای رتبه‌بندی شدت jailbreakها پیشنهاد دادند. این نشان می‌دهد که وقتی مدل‌ها به این سطح از توانایی می‌رسند، بحث‌های امنیتی دیگر فقط داخلی نیست — صنعت داره سعی می‌کند یه زبان مشترک برای این مکالمات پیدا کند.

یه نکته‌ی مهم که باید بدانی: Fable 5 فعلاً فقط از طریق API در دسترس است. اگه انتظار داری توی claude.ai یا Claude Code بروی و از منوی مدل‌ها انتخابش کنی، ناامید می‌شوی. آنتروپیک گفته که قصد دارد Fable رو دوباره به پلن‌های اشتراکی برگرداند، ولی نه الان و نه با زمانبندی مشخص.

یه نظر شخصی که شاید ارزش داشته باشه بشنوی

وسط همه‌ی این سروصداها، یه چیزی هست که کمتر کسی می‌گوید: Sonnet 4.6 هنوز خیلی خوبه. اگه کارت کد نوشتن، توضیح مفاهیم، خلاصه‌سازی، یا همین کارهای روزمره‌ی برنامه‌نویسیه، Sonnet 4.6 تقریباً همه‌شان رو راه می‌اندازد — و مهم‌تر از اون، رایگانه یا خیلی ارزون‌تر.

Sonnet 5 و Fable 5 قابلیت‌های واقعی دارند، مخصوصاً توی کارهای agentic طولانی‌مدت که مدل باید خودش چندین مرحله رو مدیریت کند. ولی برای اکثر کارهای روزانه‌ای که یه توسعه‌دهنده‌ی معمولی باهاشون طرفه، این فاصله‌ای که بین نسخه‌ها هست توی عمل خیلی کمتر از اعداد بنچمارک‌هاست. قبل از اینکه بروی کردیت بخری یا پلن رو ارتقا بدی، ارزش داره یه هفته با همان Sonnet 4.6 کار کنی و ببینی کجا واقعاً به دیوار می‌خوری — اگه اصلاً بخوری.

وقتی روی یک پروژه بزرگ یا حتی یک وب‌سایت شخصی کار می‌کنید، اطلاعات حساسی مثل کلیدهای API (API Keys)، آدرس دیتابیس‌ها و رمزهای عبور وجود دارن که به هیچ وجه نباید به صورت مستقیم (Hard-code) داخل کدهای شما قرار بگیرن. قرار دادن این اطلاعات داخل کد، نه تنها امنیت پروژه رو به خطر می‌اندازه، بلکه فرآیند تغییر اون‌ها را در محیط‌های مختلف (مثل محیط توسعه و محیط پروداکشن) به یک چالش بزرگ تبدیل می‌کنه.
اینجاست که فایل‌های .env به کار میان. در این مقاله می‌خوایم بررسی کنیم که فریم‌ورک Next.js چطور کار با متغیرهای محیطی رو برای ما راحت کرده، این فایل‌ها چه اولویت‌هایی دارن و چطور می‌تونیم به بهینه‌ترین شکل ممکن از اون‌ها استفاده کنیم.
چطور فایل‌های .env زندگی ما رو راحت‌تر می‌کنن؟
به زبان ساده، متغیرهای محیطی به شما اجازه میدن تنظیمات پروژه رو از خودِ کد جدا کنید. Next.js به صورت پیش‌فرض و بدون نیاز به نصب هیچ پکیج اضافی (مثل dotenv)، از این فایل‌ها پشتیبانی می‌کنه.
شما می‌تونید چندین فایل .env برای سناریوهای مختلف داشته باشید، اما نکته مهم اینه که بدونید Next.js با چه ترتیبی و بر اساس چه اولویتی این فایل‌ها رو می‌خونه.
ترتیب اولویت فایل‌های .env در Next.js (از بیشترین به کمترین):
نکست‌جی‌اس برای جابجایی بین محیط‌های مختلف (توسعه، پروداکشن و تست) بسیار هوشمند عمل می‌کنه. ترتیب خونده شدن فایل‌ها به این صورت هستش:
فایل‌های اختصاصی محیط با پسوند .local: مثل .env.development.local یا .env.production.local. این فایل‌ها بالاترین اولویت رو دارن و معمولاً در سیستم هر برنامه‌نویس به صورت محلی ذخیره می‌شن و نباید به گیت‌هاب push بشن.
فایل .env.local: این فایل در تمامی محیط‌ها (به جز محیط تست) اولویت بسیار بالایی داره و برای تعریف متغیرهای محلی عمومی استفاده میشه.
فایل‌های اختصاصی محیط: شامل .env.development (وقتی دستور next dev رو می‌زنید)، .env.production (وقتی پروژه با next start بالا میاد) و .env.test. نکست‌جی‌اس بر اساس وضعیت پروژه، فقط یکی از این فایل‌ها رو انتخاب می‌کنه و بقیه رو کاملاً نادیده می‌گیره.
فایل پایه .env: پایین‌ترین اولویت رو داره. این فایل به عنوان یک نسخه‌ی پشتیبان (Fallback) عمل می‌کنه؛ یعنی اگر متغیری در فایل‌های بالایی پیدا نشه، نکست‌جی‌اس این فایل رو چک می‌کنه.

دسترسی به متغیرها: مرز بین سرور و کلانیت
به صورت پیش‌فرض، تمام متغیرهایی که در فایل‌های .env تعریف می‌کنید فقط و فقط در سمت سرور (Node.js) قابل دسترسی هستن (مثلاً در API روت‌ها یا Server Components). این یک قابلیت امنیتی هستش تا اطلاعات حساس شما به مرورگر کاربر ارسال نشه.
اما اگر بخواید از یک متغیر در کامپوننت‌های سمت کلایت (Client Components) استفاده کنید، باید این کار رو انجام بدید:
کافیه اسم متغیر رو با عبارت NEXT_PUBLIC_ شروع کنید. با این کار، Next.js متوجه می‌شه که این متغیر حساس نیست و اجازه میده که در سمت کلایت هم بهش دسترسی داشته باشید:

# فقط در سمت سرور دسترسی دارد
ANALYTICS_SECRET_KEY=secret_123 

# هم در سرور و هم در کامپوننت‌های کلایت دسترسی دارد
NEXT_PUBLIC_API_URL=https://api.codoloper.com

export const apiUrl = process.env.NEXT_PUBLIC_API_URL;

export const isDevelopment = process.env.NODE_ENV === "development";

export const isProduction = process.env.NODE_ENV === "production";

import { apiUrl, isProduction} from "@/configs/global";

تا همین چند روز پیش، GPT-5.5 تازه‌ترین مدل OpenAI بود. حالا نسل بعدی رسیده، اما این‌بار ماجرا فقط سر یک عدد جدید نیست؛ یک تغییر نام‌گذاری و یک محدودیت دسترسی غیرمعمول هم همراهش آمده که شاید جالب‌تر از خود مدل باشد.

OpenAI روز جمعه (۲۶ ژوئن ۲۰۲۶) پیش‌نمایش خانواده‌ی GPT-5.6 را منتشر کرد: سه مدل با نام‌های Sol، Terra و Luna. این اولین‌باری است که OpenAI به‌جای فقط افزایش عدد نسخه، یک نام‌گذاری ماندگار هم برایش گذاشته. طبق توضیح خودشان، از این به بعد عدد نشان‌دهنده‌ی نسل مدل است، و Sol/Terra/Luna رده‌های قابلیت هستند که می‌توانند هرکدام با سرعت خودشان پیش بروند. Sol پرچم‌دار و قوی‌ترین عضو خانواده است، Terra برای کارهای روزمره با تعادل بین قیمت و توان طراحی شده (و طبق ادعای OpenAI عملکردی نزدیک به GPT-5.5 دارد ولی دو برابر ارزان‌تر است)، و Luna ارزان‌ترین و سریع‌ترین گزینه است.

از نظر قابلیت، جایی که بیشترین پیشرفت دیده می‌شود کدنویسی، زیست‌شناسی محاسباتی، و امنیت سایبری است. روی Terminal-Bench 2.1 که گردش‌کارهای پیچیده‌ی خط‌فرمان را می‌سنجد، Sol رکورد جدیدی ثبت کرده. در حوزه‌ی ژنومیک هم روی بنچمارک GeneBench v1 نتیجه‌ی بهتری نسبت به GPT-5.5 گرفته، آن‌هم با مصرف توکن کمتر. یک حالت استدلال جدید به اسم max هم اضافه شده که زمان فکر کردن مدل را به حداکثر می‌رساند، و یک حالت ultra که کار را بین چند ساب‌ایجنت تقسیم می‌کند تا کارهای پیچیده سریع‌تر پیش بروند.

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

چرا فقط ۲۰ شرکت می‌توانند استفاده کنند

OpenAI می‌گوید Sol قوی‌ترین مدلشان تا الان در کارهای امنیتی طولانی‌مدت مثل پیدا کردن آسیب‌پذیری و exploit‌نویسی است؛ روی بنچمارک ExploitBench، با حدود یک‌سوم توکن خروجی، عملکردی نزدیک به مدل Mythos Preview آنتروپیک دارد. این سطح از توانایی، در عمل یعنی مدل می‌تواند هم به تیم‌های امنیتی برای پیدا کردن و رفع باگ کمک کند، و هم در دست اشتباه، ابزار حمله باشد.

طبق گزارش Axios، دولت آمریکا از OpenAI خواسته که عرضه‌ی این مدل را محدود کند، دقیقاً همان‌طور که پیش‌تر برای مدل‌های Fable 5 و Mythos 5 آنتروپیک هم اتفاق افتاده بود. در نتیجه، فعلاً فقط حدود ۲۰ شرکت که مشارکتشان مورد تایید دولت بوده، به‌صورت پیش‌نمایش محدود به این مدل دسترسی دارند. خود OpenAI هم در پست رسمی‌اش صریح گفته که این رویکرد را راه‌حل بلندمدت نمی‌داند و آن را موقتی می‌خواند، اما معتقد است این مسیر سریع‌ترین راه برای رسیدن به انتشار عمومی در هفته‌های آینده است.

نکته‌ی فنی‌تر این‌جاست: OpenAI می‌گوید Sol از آستانه‌ی «بحرانی سایبری» تعریف‌شده در Preparedness Framework خودشان رد نشده. در آزمایش‌هایی روی Chromium و Firefox، مدل توانسته باگ و قطعات پایه‌ی یک exploit را پیدا کند، اما نتوانسته به‌طور خودکار یک زنجیره‌ی کامل و قابل‌اجرا بسازد. با این حال، خودشان هم تاکید کرده‌اند که هیچ بنچمارکی نمی‌تواند همه‌ی روش‌های استفاده‌ی واقعی را پیش‌بینی کند؛ برای همین کنار قابلیت بالاتر، سیستم ایمنی چندلایه هم گذاشته‌اند: محدودیت‌های آموزش‌دیده در خود مدل، کلاسیفایرهای بررسی لحظه‌ای خروجی، و بازبینی در سطح حساب کاربری برای رفتارهای مشکوک تکرارشونده.

قیمت و زمان‌بندی

برخلاف رفتار همیشگی OpenAI که مدل جدید را معمولاً مستقیم برای همه باز می‌کند، این‌بار فقط از طریق API و Codex، و فقط برای همان گروه محدود تایید‌شده در دسترس است. خودشان گفته‌اند قصد دارند به‌زودی آن را برای کاربران ChatGPT، Codex و API به‌طور عمومی منتشر کنند.

قیمت‌گذاری هم بر اساس هر یک‌میلیون توکن مشخص شده: Sol پنج دلار ورودی و سی دلار خروجی، Terra دو و نیم دلار ورودی و پانزده دلار خروجی، و Luna یک دلار ورودی و شش دلار خروجی. یک تغییر کوچک ولی کاربردی هم در کشینگ پرامپت آمده: حالا می‌توان نقطه‌ی cache مشخص کرد و حداقل عمر کش به سی دقیقه رسیده، با این تفاوت که نوشتن در کش این‌بار ۱.۲۵ برابر نرخ معمولی ورودی هزینه دارد.

اگر شایعات و گزارش‌های قبل از انتشار رسمی را هم در نظر بگیری (که در روزهای منتهی به این پیش‌نمایش زیاد بودند)، رقابت اصلی روی همین نکته است: آنتروپیک به‌خاطر همان نوع محدودیت دولتی، فعلاً مدل Mythos-tier خودش را در دسترس عموم ندارد، و OpenAI به‌وضوح می‌خواهد از این فاصله استفاده کند. این‌که این محدودیت چقدر طول می‌کشد و چه زمانی Sol، Terra و Luna واقعاً به دست همه می‌رسند، چیزی است که باید منتظرش ماند.

اگر در حال توسعه پروژه‌های ری‌اکت یا نکست‌جی‌اس با TypeScript هستید، قطعا موقع نوشتن کامپوننت‌ها یا تعریف تمپلیت‌ها، به این سه تایپ (Type) برخوردید: ReactNode ،ReactElement و JSX.Element.

در این مقاله می‌خوایم به زبون ساده و با مثال‌های واقعی بررسی کنیم که این سه مفهوم دقیقاً چی هستن، چه تفاوتی با هم دارن و در چه سناریویی باید از کدومشون استفاده کنیم.
۱. مفهوم React Element:
یک React Element کوچک‌ترین واحد سازنده در یک اپلیکیشن ری‌اکت هستش. از نظر فنی، این تایپ یک شیء (Object) ساده و جاوااسکریپتیه که توصیف می‌کنه یک جزء از پورتال یا UI شما چطور باید به نظر برسه (مثلاً نوعش چیه، چه Propsهایی داره و فرزندانش کدوم هستن).
وقتی شما یک کامپوننت یا تگ HTML رو می‌نویسین، ری‌اکت در پشت صحنه اون رو به یک الگو تبدیل می‌کنه.
چه زمانی تولید می‌شه؟ هر زمانی که تابع React.createElement() فراخوانی شه.
ویژگی مهم: این تایپ نمی‌تونه شامل متن ساده (String)، عدد یا آرایه باشه؛ بلکه فقط و فقط یک آبجکت معتبر ری‌آکتیه.

// این یک ReactElement است
const element: React.ReactElement = <h1>سلام کادولوپر!</h1>; 

// این خطا ایجاد می‌کند چون رشته متنی به تنهایی ReactElement نیست
const invalidElement: React.ReactElement = "Hello World"; // Error!

// هر دو خط زیر از نظر عملکردی کاملاً یکسان هستند:
const buttonOne: React.ReactElement = <button>کلیک کنید</button>;
const buttonTwo: JSX.Element = <button>کلیک کنید</button>;

type ReactNode = ReactElement | string | number | Iterable<ReactNode> | ReactPortal | boolean | null | undefined;

// تمام موارد زیر به عنوان ReactNode کاملاً معتبر هستند:
const nodeText: React.ReactNode = "یک متن ساده";
const nodeNumber: React.ReactNode = 1405;
const nodeElement: React.ReactNode = <div>یک المان کامپوننت</div>;
const nodeNull: React.ReactNode = null;

type LayoutProps = {
  children: React.ReactNode; // بهترین انتخاب برای دریافت هر نوع محتوا
};

export default function Layout({ children }: LayoutProps) {
  return <main className="main-container">{children}</main>;
}

type ListProps = {
  // کاربر نمی‌تواند متن ساده بفرستد، حتماً باید یک کامپوننت یا تگ معتبر باشد
  children: React.ReactElement; 
};

const renderStatusIcon = (status: string): JSX.Element => {
  if (status === "success") return <SuccessIcon />;
  return <ErrorIcon />;
};

یه روز یکی از بچه‌های تیم اومد گفت «بیا کل بک‌اند رو GraphQL کنیم، REST قدیمیه». دو هفته بعد، همون آدم داشت با N+1 query کلنجار می‌رفت و آرزو می‌کرد کاش همون REST قدیمی رو نگه داشته بودیم. این داستان رو احتمالاً قبلاً جایی شنیدی، چون تقریباً هر تیمی یه نسخه از آن را تجربه کرده.

واقعیت این است که هیچ‌کدام از این سه‌تا «بهتر» نیستند؛ هرکدام برای یک نوع درد طراحی شده‌اند.

REST: همون که همه می‌شناسن

REST رو همه به‌خاطر سادگی‌اش دوست دارن. منبع‌محور است: هر URL یک resource را نشان می‌دهد و متدهای HTTP (GET، POST، PUT، DELETE) کاری که می‌خواهی روی آن انجام دهی را مشخص می‌کنند. کتابخانه‌ها همه‌جا هستند، کش کردن با HTTP caching معمولی کار می‌کند، و هر کسی که یک بار با API کار کرده، REST را بدون توضیح زیاد می‌فهمد.

مشکلش از

 همان‌جایی شروع می‌شود که اپلیکیشن‌ها پیچیده‌تر می‌شوند. فرض کن صفحه‌ی پروفایل کاربر را داری که هم اطلاعات کاربر، هم پست‌های اخیرش، هم تعداد فالوورها را نیاز دارد. در REST کلاسیک، این می‌شود سه (یا بیشتر) درخواست جدا، یا یک endpoint سفارشی که فقط برای همین صفحه ساخته‌ای و جای دیگری استفاده نمی‌شود. این پدیده اسم دارد: over-fetching وقتی داده‌ی اضافه می‌گیری، و under-fetching وقتی کم می‌گیری و باید درخواست دوم بزنی.

GET /users/42
GET /users/42/posts?limit=5
GET /users/42/followers/count

query {
  user(id: 42) {
    name
    posts(limit: 5) { title }
    followersCount
  }