۳۰ شهریور ۱۴۰۳

Techboy

اخبار و اطلاعات روز تکنولوژی

فراتر از C++: وعده Rust، Carbon و Cppfront

در افق توسعه دهندگان C/C++ به دنبال تغییر هستند. Rust، Carbon و Cppfront همگی جایگزین های امیدوارکننده ای برای زبان های قدیمی هستند که برنامه نویسان دوست دارند از آن متنفر باشند.

در افق توسعه دهندگان C/C++ به دنبال تغییر هستند. Rust، Carbon و Cppfront همگی جایگزین های امیدوارکننده ای برای زبان های قدیمی هستند که برنامه نویسان دوست دارند از آن متنفر باشند.

از برخی جهات، C و C++ دنیا را اجرا می کنند. شما هرگز آن را از سر و صدای زیاد در مورد سایر زبان های برنامه نویسی، مانند Python و Go نمی دانید، اما اکثریت قریب به اتفاق برنامه های دسکتاپ و عملکرد با عملکرد بالا در بازار انبوه سیستم‌ها به زبان C++ نوشته می‌شوند و اکثر برنامه‌های جاسازی شده به زبان C نوشته می‌شوند. ما در مورد برنامه‌های تلفن هوشمند یا برنامه‌های وب صحبت نمی‌کنیم: اینها زبان‌های خاصی مانند Java و Kotlin دارند. برای Android و Objective-C و Swift برای iOS. آنها فقط از C/C++ برای حلقه‌های داخلی که نیاز شدید به سرعت دارند و برای کتابخانه‌های مشترک در بین سیستم‌عامل‌ها استفاده می‌کنند.

C و C++ برای مدت طولانی بر برنامه نویسی سیستم ها تسلط داشته اند، تصور جابجایی آنها دشوار است. با این حال بسیاری از کارشناسان می گویند که زمان آن فرا رسیده است که آنها بروند و برنامه نویسان از جایگزین های بهتری استقبال کنند. مارک روسینوویچ، مدیر ارشد فناوری Microsoft Azure اخیراً با پیشنهاد توسعه‌دهندگان C و C++ باید به Rust بروند. «صنعت باید آن زبان‌ها را منسوخ اعلام کند،» weروسیه

بسیاری از توسعه دهندگان در حال کاوش هستند زنگ به عنوان یک جایگزین آماده تولید برای C/C++، و گزینه های دیگری نیز در افق وجود دارد. در این مقاله، ما شایستگی و آمادگی سه زبان جایگزین زبان C/C++ را بررسی خواهیم کرد: Rust، Carbon و cppfront. ابتدا، بیایید نگاهی به تاریخچه و برخی از نقاط دردناک C/C++ بیندازیم.

نقاط درد C++

C++ توسط Bjarne Stroustrup در آزمایشگاه Bell در سال ۱۹۷۹ توسعه داده شد. از آنجایی که C++ تلاشی برای افزودن ویژگی های شی گرا (به اضافه سایر پیشرفت ها) به C است، استراستروپ در ابتدا آن را “C with Objects” نامید. Stroustrup این زبان را به تغییر نام داد. C++ در سال ۱۹۸۳، و این زبان در خارج از آزمایشگاه Bell در سال ۱۹۸۵ در دسترس قرار گرفت. اولین کامپایلر تجاری C++، Cfront، در آن زمان منتشر شد. Cfront C++ را به C ترجمه کرد، که سپس می‌توان آن را کامپایل و پیوند داد. بعدها کامپایلرهای C++ کد شی تولید کردند. فایل هایی که مستقیماً به یک پیوند دهنده وارد می شوند.

از آن زمان، تلاش برای استانداردسازی C++ پیوسته بوده است، با انتشار زبان برنامه نویسی C++ استروستروپ در سال ۱۹۸۵ و ARM در سال ۱۹۹۰- یکنشاندار C++ Reference Mسالانه. اینها با یک سری استانداردهای ++ ANSI/ISO دنبال شدند، در سال‌های ۱۹۹۸، ۲۰۰۳، ۲۰۱۱، ۲۰۱۴، ۲۰۱۷، ۲۰۲۰، با برنامه بعدی برای سال ۲۰۲۳. همچنین مشخصات فنی میانی برای تعریف مکمل‌ها وجود دارد.

هر ویرایشی در استاندارد C++ دارای ویژگی‌هایی اضافه شده است، اما هیچ کدام یادگیری زبان را آسان‌تر یا کامپایل سریع‌تر نکرده است. هر کسی که یک برنامه چند میلیون خطی C++ ساخته باشد، بار انتظار برای کامپایل‌ها را درک می‌کند. راب پایک زمان کامپایل C++ را به عنوان انگیزه خود برای توسعه Go ذکر می کند: «در حدود سپتامبر ۲۰۰۷، من در حال انجام برخی کارهای جزئی اما محوری بر روی یک برنامه عظیم Google C++ بودم، برنامه ای که همه شما با آن تعامل داشتید، و مجموعه های من حدود ۴۵ دقیقه طول کشید. در خوشه کامپایل توزیع شده عظیم ما.” راه حل Pike توسعه یک زبان جدید به نام Go بود که در نهایت مورد قبول بسیاری قرار گرفت، اما نه توسط برنامه نویسان C++.

Zig با رشد سریع در نظرسنجی Stack Overflow برای پردرآمدترین زبان برنامه نویسی برتری دارد

من شخصا روی یک برنامه ++C کار کردم که “فقط” ۲ میلیون خط کد بود. در آن زمان، چندین ساعت طول کشید تا یک کامپایل و پیوند کامل روی یک کامپیوتر هشت هسته ای انجام شود و حدود ۱۰ دقیقه برای بارگذاری در ویژوال استودیو و حل همه نمادها طول کشید. من روی مشکل کامپایل با اتوماسیون کار کردم: یک اسکریپت داشتم که یک کپی جدید از کد را از مخزن مشترک در تاریکی شب بیرون می آورد، سپس همه چیز را از ابتدا کامپایل می کرد. من با جوشاندن آب، دم کردن چای و نوشیدن آن با هم تیمی هایم هر روز صبح پس از باز کردن ویژوال استودیو، مشکل بارگذاری کند را حل کردم. (به من گفته شده است که ویژوال استودیو مشکل بارگذاری کند را برطرف کرده است.)

برای توسعه‌دهندگانی که به دنبال جایگزین‌هایی برای C++، Rust، Carbon و Cppfront هستند، همه نامزدهای قوی هستند. از این سه، فقط Rust در حال حاضر آماده تولید است.

زنگ به عنوان جایگزین C++

صفحه اصلی Rust-lang سه دلیل اصلی را برای انتخاب Rust بیان می کند: عملکرد، قابلیت اطمینان و بهره وری . Rust به گونه ای طراحی شده است که استفاده از آن سریع، ایمن و آسان باشد، با هدف اصلی توانمندسازی همه برای ساختن نرم افزار قابل اعتماد و کارآمد.

تا آنجا که عملکرد، Rust هم سریع و هم از نظر حافظه کارآمد است: بدون زمان اجرا یا جمع‌آوری زباله، می‌تواند خدمات حیاتی عملکرد را تامین کند، روی دستگاه‌های جاسازی شده اجرا شود و به راحتی با زبان‌های دیگر ادغام شود. از نظر قابلیت اطمینان، سیستم نوع غنی و مدل مالکیت Rust ایمنی حافظه و ایمنی رشته را تضمین می‌کند – که توسعه‌دهندگان می‌توانند از آن برای حذف بسیاری از کلاس‌های باگ در زمان کامپایل استفاده کنند. برای بهره‌وری، Rust دارای مستندات عالی، یک کامپایلر دوستانه با پیام‌های خطای مفید و ابزارهای درجه یک – یک مدیر بسته یکپارچه و ابزار ساخت، پشتیبانی هوشمند چند ویرایشگر با تکمیل خودکار و بازرسی‌های نوع، یک فرمت‌کننده خودکار و موارد دیگر است. .

موارد استفاده از Rust پشتیبانی شده شامل ابزارهای خط فرمان ساخت، کامپایل در WebAssembly (روشی برای شارژ کردن جاوا اسکریپت شما)، ساخت خدمات شبکه و ایجاد نرم افزار برای سیستم های تعبیه شده با منابع کم. استفاده از Rust در تولید بیشتر شده است، از جمله استفاده در Firefox، Dropbox ، Cloudflare، NPM، < a href="https://www.youtube.com/watch?v=u6ZbF4apABk" rel="nofollow">Yelp، و InfluxDB IOx. InfluxDB همچنین اکنون از DataFusion، یک موتور جستجوی SQL بومی Rust استفاده می‌کند. برای Apache Arrow.

Rust به سختی یادگیری شهرت دارد، اگرچه احتمالاً به سختی C++ نیست. یک نکته مهم فروش این است که به طور پیش فرض ایمن است، به این معنی که در Safe Rust< /a> لازم نیست نگران ایمنی نوع یا ایمنی حافظه باشید. همچنین می‌توانید در صورت نیاز، شیوه‌های کدگذاری ناامن را با استفاده از ویژگی unsafe فعال کنید. گاهی اوقات، شما نیاز دارید که اشاره گرهای خام را ارجاع دهید، توابع C را فراخوانی کنید، استاتیک را تغییر دهید، یا به فیلدهای یک union دسترسی پیدا کنید. همه اینها ناامن هستند، بنابراین برای استفاده از آنها در برنامه Rust باید آنها را ناامن علامت گذاری کنید. (همچنین باید آنها را به صورت دستی بررسی کنید، زیرا نمی توانید برای تصحیح هر اشتباهی که در کد ناامن مرتکب می شوید، به کامپایلر وابسته باشید.)

همه چیز درباره لودرهای کلاس جاوا

کربن به عنوان جایگزین C++

زبان کربن جدید و آزمایشی که در جلسه CPP North معرفی شد در ۱۹ جولای ۲۰۲۲، به عنوان یک زبان جانشین احتمالی برای C++ در نظر گرفته شده است. در حالی که کربن به هیچ وجه آماده استفاده نیست، یک مخزن منبع دارد، Discord، یک مدل حکمرانی، و یک مترجم که می‌توانید استفاده آنلاین یا در macOS یا Linux نصب کنید. در حال حاضر فاقد کامپایلر، زنجیره ابزار یا حتی طراحی کامل زبان ۰.۱ است.

اهداف بیان شده پروژه زبان کربن عبارتند از: نرم افزارهای حیاتی عملکرد. تکامل نرم افزار و زبان؛ کدی که خواندن، درک و نوشتن آسان است. مکانیسم های ایمنی و آزمایش عملی؛ توسعه سریع و مقیاس پذیر؛ سیستم عامل های مدرن، معماری های سخت افزاری و محیط ها؛ و قابلیت همکاری و مهاجرت از کد C++ موجود.

این پروژه همچنین دارای غیر هدف واضح است. ایجاد یک رابط باینری برنامه (ABI) برای کل زبان و کتابخانه و اطمینان از بی نقص بودن به عقب یا جلو سازگاری اهداف کربن نیستند.

طبق گفته کیت گرگوری، یکی از پروژه ها به همراه ریچارد اسمیت (از کمیته استانداردهای ISO C++) و Chandler Carruth (مهندس اصلی نرم‌افزار در Google)، کنار گذاشتن سازگاری با عقب‌تر، پروژه را آزاد می‌کند تا تغییرات مثبتی را که در زبان C++ مجاز نمی‌باشند، با مزیت اصلی کاهش ایجاد کند. بدهی فنی به جای سازگاری با عقب، Carbon ارتقاء نسخه مبتنی بر ابزار و مهاجرت C++ را ارائه می دهد. ارتقاهای مبتنی بر ابزار و مهاجرت بسیار بهتر از ارتقاهای دستی طاقت فرسا و طولانی است که توسعه دهندگان ++C باید با هر تغییر عمده در زبان انجام دهند.

در مثال کد زیر، که از مخزن کربن است، چیزهای زیادی برای جذب وجود دارد. من نظراتی را برای کمک اضافه کرده ام.


//packages are namespaces as well as units of distribution
//Nothing in Carbon goes into the global namespace, unlike C++
//There is only one api file per package. Other files are impl
 
package Sorting api;
 
//fn declares a function
//[T means the parameter type T is generic
//Note the change from <...> to [...] for generics
//:! Means the passed type is checked at compile time
//Comparable and Movable are attributes of the generic T
//Slice hasn’t been fully specified, but think Go slices
//-> is a return value type
//i64 is a 64-bit signed integer type
//var declares a mutable variable
//& is the address-of operator, as in C/C++
 
fn Partition[T:! Comparable & Movable](s: Slice(T))
     -> i64 {
  var i: i64 = -1;
 
  for (e: T in s) {
    if (e <= s.Last()) {
      ++i;
      Swap(&s[i], &e);
    }
  }
  return i;
}
 
//let declares an immutable constant r-value
 
fn QuickSort[T:! Comparable & Movable](s: Slice(T)) {
  if (s.Size() <= 1) {
    return;
  }
  let p: i64 = Partition(s);
  QuickSort(s[:p - 1]);
  QuickSort(s[p + 1:]);
}

برای نمونه‌های کد کربن بیشتر، به نگاه کنید سند طراحی زبان و داده‌های آزمایشی کاوشگر کربن.

استروستروپ درباره همه اینها چه فکر می کند؟ نه خیلی، در این مرحله. “کربن آنقدر جدید و نامشخص است که واقعاً نمی توانم نظرات فنی معناداری داشته باشم.”

Cppfront به عنوان جایگزین C++

هرب ساتر به مدت یک دهه به عنوان رئیس کمیته استانداردهای ISO C++. او یک معمار نرم‌افزار در مایکروسافت است، جایی که او طراحی برنامه‌های افزودنی زبان C++/CLI، C++/CX، C++ AMP و سایر فناوری‌ها را رهبری می‌کند. با Cpp2 و cppfront، ساتر می‌گوید: «هدف او این است که بررسی کند آیا راهی وجود دارد که بتوانیم خود C++ را برای تبدیل شدن به ۱۰ برابر ساده‌تر، ایمن‌تر و کاربردی‌تر توسعه دهیم. او توضیح می دهد:

بررسی آزول نشان می‌دهد جاوا 11 و جاوا 17 منجر به استفاده از جاوا می‌شوند

ساتر در سال‌های ۲۰۱۵ و ۲۰۱۶ روی طراحی “syntax 2” (Cpp2) کار کرد و از سال ۲۰۲۱ مشغول نوشتن کامپایلر Cppfront برای نمونه سازی همه پیشنهادهای تکامل ISO C++ و گفتگوهای کنفرانسی که او از سال ۲۰۱۵ ارائه کرده است. نمونه اولیه اکنون شامل syntax 2 است. برای C++ که طرح‌های کامل آن‌ها از جمله تغییرات غیرقابل پیش‌بینی را فعال می‌کند.

Cppfront ساتر مجموعه رگرسیون شامل دوجین نمونه از C++ ترکیبی است. و کد Cpp2 و دوجین نمونه دیگر از Cpp2 خالص. مانند Stroustrup Cfront اصلی، Sutter’s Cppfront پلی است برای فعال کردن توسعه Cpp2 و آزمایش با نحو جدید تا زمانی که امکان کامپایل Cpp2 مستقیماً در کد شیء وجود داشته باشد.

زنگ، کربن یا Cppfront؟

Rust، Carbon، و Cppfront همگی به عنوان جایگزین های C++ نشان می دهند. برای کربن، احتمالاً به دنبال یک چرخه توسعه پنج ساله هستیم تا زمانی که برای تولید عرضه شود. Cppfront ممکن است زودتر برای تولید در دسترس باشد، و Rust در حال حاضر وجود دارد.

هر سه زبان با C++ در سطح باینری قابل همکاری هستند (یا خواهند بود). این بدان معناست که هر سه زبان می توانند با افزودن ماژول های جدید غیر C++ به شما امکان بهبود تدریجی برنامه های C++ موجود را بدهند.

در مورد Cppfront، ترکیب کد منبع C++ و Cpp2 قبلاً، حداقل تا حدی، پیاده‌سازی شده است و در مجموعه رگرسیون Sutter گنجانده شده است. ابزار کربن شامل انتقال خودکار کد منبع C++ خواهد بود. یک سوال باز این است که آیا این ۱۰۰٪ کد C++ شما را منتقل می کند یا از شما می خواهد که به صورت دستی درصدی از کد خود را بازنویسی کنید که در غیر این صورت عملکرد بدی دارد، استانداردهای کربن را نقض می کند یا از شما می خواهد که اگر می خواهید آن را ترک کنید، آن را به عنوان ناامن علامت گذاری کنید. به تنهایی.

Rust از قبل ایمنی حافظه را نشان می‌دهد. شما به معنای واقعی کلمه نمی توانید کد Rust را کامپایل کنید که ایمنی حافظه را نقض کند، مگر اینکه آن را ناامن علامت گذاری کنید. Carbon و Cppfront مطمئناً مکانیسم های ایمنی حافظه را اجرا خواهند کرد. ما هنوز دقیقاً نمی دانیم آنها چه خواهند بود.

یادگیری Rust خیلی آسان نیست، حتی اگر C++ را بلد باشید، اگرچه به من گفته شده است که یادگیری Rust در واقع کمی ساده تر از یادگیری C++ است اگر از ابتدا شروع کنید. با این وجود، برنامه نویسان C++ و Go معمولا موفق می شوند Rust را در یک یا دو هفته دریافت کنند.

آنچه از Cpp2 از Herb Sutter دیده‌ایم روشن می‌کند که برنامه‌نویسان ++C آن را یک انتقال نسبتاً آسان می‌دانند، حتی اگر C++ تولید شده توسط Cppfront در حال حاضر نسبتاً زشت است. ابزار تبدیل C++ Carbon باید یک ابزار ویرایش جانبی را فعال کند، دقیقاً مانند پشتیبانی IntelliJ برای یادگیری Kotlin با تبدیل کد جاوا موجود.

در نهایت، همانطور که استروستروپ در نظرات خود در مورد کربن اشاره کرد، باید منتظر بمانیم و ببینیم که هر زبان و ابزار آن چگونه عمل می کنند.