TE
テックエコー
ホーム24時間トップ最新ベスト質問ショー求人
GitHubTwitter
ホーム

テックエコー

Next.jsで構築されたテクノロジーニュースプラットフォームで、グローバルなテクノロジーニュースとディスカッションを提供します。

GitHubTwitter

ホーム

ホーム最新ベスト質問ショー求人

リソース

HackerNews APIオリジナルHackerNewsNext.js

© 2025 テックエコー. すべての権利を保有。

Matt Godbolt sold me on Rust by showing me C++

591 ポイント投稿者: LorenDB2日前

49 comments

dvratil2日前
The one thing that sold me on Rust (going from C++) was that there is a single way errors are propagated: the Result type. No need to bother with exceptions, functions returning bool, functions returning 0 on success, functions returning 0 on error, functions returning -1 on error, functions returning negative errno on error, functions taking optional pointer to bool to indicate error (optionally), functions taking reference to std::error_code to set an error (and having an overload with the same name that throws an exception on error if you forget to pass the std::error_code)...I understand there&#x27;s 30 years of history, but it still is annoying, that even the standard library is not consistent (or striving for consistency).<p>Then you top it on with `?` shortcut and the functional interface of Result and suddenly error handling becomes fun and easy to deal with, rather than just &quot;return false&quot; with a &quot;TODO: figure out error handling&quot;.
评论 #43908294 未加载
评论 #43908381 未加载
评论 #43908158 未加载
评论 #43908219 未加载
评论 #43908682 未加载
评论 #43908981 未加载
评论 #43924618 未加载
评论 #43908133 未加载
评论 #43910388 未加载
评论 #43922951 未加载
评论 #43912904 未加载
评论 #43909007 未加载
评论 #43909521 未加载
评论 #43908623 未加载
评论 #43908419 未加载
评论 #43912855 未加载
评论 #43913794 未加载
评论 #43913484 未加载
评论 #43914514 未加载
评论 #43917029 未加载
评论 #43908540 未加载
评论 #43908212 未加载
评论 #43914062 未加载
评论 #43909117 未加载
choeger1日前
All this has been known in the PL design community for <i>decades</i> if not half a century by now.<p>Two things are incredibly frustrating when it comes to safety in software engineering:<p>1. The arrogance that &quot;practitioners&quot; have against &quot;theorists&quot; (everyone with a PhD in programming languages)<p>2. The slowness of the adoption of well-tested and thoroughly researched language concepts (think of Haskell type classes, aka, Rust traits)<p>I like that Rust can pick good concepts and design coherent language from them without inventing its own &quot;pragmatic&quot; solution that breaks horribly in some use cases that some &quot;practitioners&quot; deem &quot;too theoretical.&quot;
评论 #43917609 未加载
评论 #43915349 未加载
评论 #43913128 未加载
评论 #43916215 未加载
quietbritishjim1日前
I always enjoy reading articles like this. But the truth is, having written several 100s of KLOC in C++ (i.e., not an enormous amount but certainly my fair share) I just almost never have problems with this sort accidental conversion in practice. Perhaps it might trip me up occasionally, but will be noticed by literally just running the code once. Yes, that is an extra hurdle to trip over and resolve but that is trivial compared to the alternative of creating and using wrapper types - regardless of whether I&#x27;m using Rust or C++. And the cost of visual noise of wrapper types, already higher just at the writing stage, then continues to be a cost every time you read the code. It&#x27;s just not worth it for the very minor benefit it brings.<p>(Named parameters would definitely be great, though. I use little structs of parameters where I think that&#x27;s useful, and set their members one line at a time.)<p>I know that this is an extremist view, but: I feel the same way about Rust&#x27;s borrow checker. I just very rarely have problems with memory errors in C++ code bases with a little thought applied to lifetimes and use of smart pointers. Certainly, lifetime bugs are massively overshadowed by logic and algorithmic bugs. Why would I want to totally reshape the way that I code in order to fix one of the <i>least</i> significant problems I encounter? I actually wish there were a variant of Rust with all its nice clean improvements over C++ <i>except</i> for lifetime annotations and the borrow checker.<p>Perhaps this is a symptom of the code I tend to write: code that has a lot of tricky mathematical algorithms in it, rather than just &quot;plumbing&quot; data between different sources. But actually I doubt it, so I&#x27;m surprised this isn&#x27;t a more common view.
评论 #43913644 未加载
评论 #43914163 未加载
评论 #43913623 未加载
评论 #43914148 未加载
评论 #43913574 未加载
评论 #43913894 未加载
socalgal21日前
I already hated C++ (having written 100s of thousands of lines of it in games and at FAANG)<p>I&#x27;d be curious to know what if any true fixes are coming down the line.<p>This talk: &quot;To Int or to Uint, This is the Question - Alex Dathskovsky - CppCon 2024&quot; <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=pnaZ0x9Mmm0" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=pnaZ0x9Mmm0</a><p>Seems to make it clear C++ is just broken. That said, and I wish he&#x27;d covered this, he didn&#x27;t mention if the flags he brings up would warn&#x2F;fix these issues.<p>I don&#x27;t want a C++ where I have to remember 1000 rules and if I get one wrong my code is exploitable. I want a C++ where I just can&#x27;t break the rules except when I explicitly opt into breaking them.<p>speaking of which, according to another C++ talk, something like 60% of rust crates are dependent on unsafe rust. The point isn&#x27;t to diss rust. The point is that a safe C++ with opt into unsafe could be similar to rust&#x27;s opt into unsafe
评论 #43912670 未加载
评论 #43912606 未加载
thrwyexecbrain2日前
The C++ code I write these days is actually pretty similar to Rust: everything is explicit, lots of strong types, very simple and clear lifetimes (arenas, pools), non-owning handles instead of pointers. The only difference in practice is that the build systems are different and that the Rust compiler is more helpful (both in catching bugs and reporting errors). Neither a huge deal if you have a proper build and testing setup and when everybody on your team is pretty experienced.<p>By the way, using &quot;atoi&quot; in a code snippet in 2025 and complaining that it is &quot;not ideal&quot; is, well, not ideal.
评论 #43910728 未加载
评论 #43910069 未加载
评论 #43909244 未加载
评论 #43909532 未加载
评论 #43913902 未加载
bunderbunder1日前
This is actually the point where Rust starts to frustrate me a little bit.<p>Not because Rust is doing anything wrong here, but because the first well-known language to really get some of these things right also happens to be a fairly low-level systems language with manual memory management.<p>A lot of my colleagues seem to primarily be falling in love with Rust because it&#x27;s doing a good job at some basic things that have been well-known among us &quot;academic&quot; functional programming nerds for decades, and that&#x27;s good. It arguably made inroads where functional programming languages could not because it&#x27;s really more of a procedural language, and that&#x27;s also good. Procedural programming is a criminally underrated and misunderstood paradigm. (As much as I love FP, that level of standoffishness about mutation and state isn&#x27;t any more pragmatic than OOP being so hype about late binding that every type must support it regardless of whether it makes sense in that case.)<p>But they&#x27;re also thoroughly nerdsniped by the borrow checker. I get it, you have to get cozy with the borrow checker if you want to use Rust. But it seems like the moral opposite of sour grapes to me. The honest truth is that, for most the software we&#x27;re writing, a garbage collected heap is <i>fine</i>. Better, even. Shared-nothing multithreading is <i>fine</i>. Better, even.<p>So now we&#x27;re doing more and more things in Rust. Which I understand. But I keep wishing that I could also have a Rust-like language that just lets me have a garbage collector for the 95% of my work where the occasional 50ms pause during run-time just isn&#x27;t a big enough problem to justify a 50% increase in development and maintenance effort. And then save Rust for the things that actually do need to be unmanaged. Which is maybe 5% of my actual work, even if I have to admit that it often feels like 95% of the fun.
评论 #43917417 未加载
评论 #43922534 未加载
评论 #43917143 未加载
评论 #43924177 未加载
评论 #43923742 未加载
ModernMech2日前
What sold me on Rust is that I&#x27;m a very bad programmer and I make a lot of mistakes. Given C++, I can&#x27;t help but hold things wrong and shoot myself in the foot. My media C++ coding session is me writing code, getting a segfault immediately, and then spending time chasing down the reason for that happening, rinse and repeat.<p>My median Rust coding session isn&#x27;t much different, I also write code that doesn&#x27;t work, but it&#x27;s caught by the compiler. Now, most people call this &quot;fighting with the borrow checker&quot; but I call it &quot;avoiding segfaults before they happen&quot; because when I finally get through the compiler my code usually &quot;just works&quot;. It&#x27;s that magical property Haskell has, Rust also has it to a large extent.<p>So then what&#x27;s different about Rust vs. C++? Well Rust actually provides me a path to get to a working program whereas C++ just leaves me with an error message and a treasure map.<p>What this means is that although I&#x27;m a bad programmer, Rust gives me the support I need to build quite large programs on my own. And that extends to the crate ecosystem as well, where they make it very easy to build and link third party libraries, whereas with C++ ld just tells you that it had a problem and you&#x27;re left on your own to figure out exactly what.
评论 #43908867 未加载
评论 #43910096 未加载
jpc02日前
Amazing example of how easy it is to get sucked into the rust love. Really sincerely these are really annoying parts of C++.<p>The conversation function is more language issue. I don’t think there is a simple way of creating a rust equivalent version because C++ has implicit conversions. You could probably create a C++ style turbofish though, parse&lt;uint32_t&gt;([your string]) and have it throw or return std::expected. But you would need to implement that yourself, unless there is some stdlib version I don’t know of.<p>Don’t conflate language features with library features.<p>And -Wconversion might be useful for this but I haven’t personally tried it since what Matt is describing with explicit types is the accepted best practice.
评论 #43908659 未加载
GardenLetter272日前
It&#x27;s a shame Rust doesn&#x27;t have keyword arguments or named tuples to make handling some of these things easier without Args&#x2F;Options structs boilerplate.
评论 #43908500 未加载
评论 #43908653 未加载
评论 #43912118 未加载
评论 #43908333 未加载
评论 #43913516 未加载
grumbel2日前
There is &#x27;-Wconversion&#x27; to catch things like this. It will however not trigger in this specific case since g++ assumes converting 1000.0 to 1000 is ok due to no loss in precision.<p>Quantity(100) is counterproductive here, as that doesn&#x27;t narrow the type, it does the opposite, it casts whatever value is given to the type, so even Quantity(100.5) will still work, while just plain 100.5 would have given an error with &#x27;-Wconversion&#x27;.
评论 #43908438 未加载
评论 #43908555 未加载
favorited2日前
Side note, if anyone is interested in hearing more from Matt, he has a programming podcast with Ben Rady called Two&#x27;s Complement.<p><a href="https:&#x2F;&#x2F;www.twoscomplement.org" rel="nofollow">https:&#x2F;&#x2F;www.twoscomplement.org</a>
评论 #43908230 未加载
writebetterc2日前
Yes, Rust is better. Implicit numeric conversion is terrible. However, don&#x27;t use atoi if you&#x27;re writing C++ :-). The STL has conversion functions that will throw, so separate problem.
评论 #43910253 未加载
评论 #43908176 未加载
评论 #43910408 未加载
kasajian2日前
This seems a big silly. This is not a language issue. You can have a C++ library that does exactly all the things being shown here so that the application developer doesn&#x27;t worry about. There would no C++ language features missing that would accomplish what you&#x27;re able to do on the Rust side.<p>So is this really a language comparison, or what libraries are available for each language platform? If the latter, that&#x27;s fine. But let&#x27;s be clear about what the issue is. It&#x27;s not the language, it&#x27;s what libraries are included out of the box.
评论 #43908898 未加载
评论 #43908863 未加载
评论 #43908901 未加载
评论 #43909794 未加载
评论 #43908932 未加载
karel-3d1日前
Well, if you don&#x27;t want to confuse parameters, you should use Objective-C.<p>You would do<p>[orderbook sendOrderWithSymbol:&quot;foo&quot; buy:true quantity:100 price:1000.00]<p>Cannot confuse that!<p>(I never used swift, I think it retains this?)
评论 #43922569 未加载
jsat2日前
I see an article about how strict typing is better, but what would really be nice here is named parameters. I never want to go back to anonymous parameters.
评论 #43908741 未加载
评论 #43909858 未加载
评论 #43908994 未加载
mmaniac約8時間前
&gt; You know what&#x27;s the most interesting part of this whole article? The thing Rust is very famous for, memory safety, did not feature at all.<p>I think that&#x27;s the essential point, really... It&#x27;d be hard to argue that the rest of Rust isn&#x27;t overall &quot;better&quot; than C++, but the compromises made to flexibility and ergonomics to achieve memory safety in Rust are the biggest points of contention for Rust critics.
mattgodbolt2日前
Wow that guy, eh? He seems to turn up everywhere :D
评论 #43913201 未加载
brundolf2日前
Wait, Godbolt is someone&#x27;s <i>name</i>?
评论 #43910742 未加载
juliangmp約10時間前
&gt; No luck! Both clang 19 and gcc 14 will take that and not complain - even with -std=c++23 -Wall -Wextra -Wpedantic, which I use for all of the C++ code in this article!<p>I keep a list of &quot;additional&quot; error codes for my work with GCC and its at least two dozen parameters. The fact that some of these aren&#x27;t the default is outrageous to me. And Wconversion is one of those things that seemingly no one uses so every open source library I include gives me those errors.
morning-coffee2日前
Reading &quot;The Rust Book&quot; sold me on Rust (after programming in C++ for over 20 years)
评论 #43909177 未加载
amai1日前
ADA has solved these issues since the 80s:<p><a href="https:&#x2F;&#x2F;learn.adacore.com&#x2F;courses&#x2F;Ada_For_The_CPP_Java_Developer&#x2F;chapters&#x2F;05_Type_System.html#strong-typing" rel="nofollow">https:&#x2F;&#x2F;learn.adacore.com&#x2F;courses&#x2F;Ada_For_The_CPP_Java_Devel...</a>
tumdum_2日前
The one thing that sold me on Rust was that I no longer had to chase down heisenbugs caused by memory corruption.
评论 #43913761 未加载
TinkersW1日前
Dunno about this, the example C++ code is so obviously bad that I had no desire to watch the video.<p>Creating strong types for currency seems like common sense, and isn&#x27;t hard to do. Even the Rust code shouldn&#x27;t be using basic types.
评论 #43913785 未加载
markus_zhang2日前
What if we have a C that removes the quirks without adding too much brain drain?<p>So no implicit type conversions, safer strings, etc.
评论 #43908071 未加载
评论 #43908130 未加载
评论 #43908341 未加载
评论 #43908141 未加载
评论 #43908024 未加载
评论 #43908193 未加载
评论 #43913099 未加载
评论 #43908840 未加载
评论 #43909556 未加载
评论 #43908037 未加载
simpaticoder2日前
I don&#x27;t get it. Isn&#x27;t this a runtime problem and not a compile-time problem? buy() or sell() is going to be called with dynamic parameters at runtime, in general. That is, calls with concrete values are NOT going to be hard-coded into your program. I would write the function to assert() invariants within the function, and avoid chasing compile-time safety entirely. If parameter order was a concern, then I&#x27;d modify the function to take a struct, or similar.
评论 #43910710 未加载
adamc2日前
Coming from python (or Common Lisp, or...), I wasn&#x27;t too impressed. In Python I normally make args for any function with more than a couple be keyword arguments, which guarantees that you are aware of how the arguments are being mapped to inputs.<p>Even Rust&#x27;s types aren&#x27;t going to help you if two arguments simply <i>have</i> the same types.
评论 #43908499 未加载
DrBazza1日前
The implicit problem here (pun intended) in the given examples are implicitness vs. explicitness.<p>Rust chose (intentionally or otherwise) to do the opposite of the many things that C++ does, because C++ does it wrong. And C++ does it wrong because we didn&#x27;t know any better at the time, and the world, pre-internet, was much less connected. Someone had to do it first (or first-ish).<p>The main thing I like about Rust is the tooling. C++ is death by a thousand build systems and sanitizers.
zombot1日前
Types are a catastrophe in C++ that cannot be fixed, no matter how much cruft you bolt on after the fact. It&#x27;s time to leave this dinosaur and use a sane language.
feverzsj1日前
The C++ code is just pure nonsense. If you really want to be fool-proofing, C++ offers concept, which is far superior to what rust offers.
nyanpasu642日前
The problem I&#x27;ve always had with unit type wrappers is you can&#x27;t convert between a &amp;[f32] and a &amp;[Amplitude&lt;f32&gt;] like you can convert a single scalar value.
评论 #43912786 未加载
评论 #43910307 未加载
xarope1日前
This reminds me of SQL&#x27;s constraints, or pydantic&#x27;s custom types and validators, which can validate that a value should be an int, and between 0-999, and not exceed, e.g. -1 or 1000.<p>pydantic is a library for python, but I&#x27;m not aware of anything similar in rust or golang that can do this yet? (i.e. not just schema validation, but value range validation too)
评论 #43918793 未加载
评论 #43912721 未加载
antirez2日前
You can have two arguments that are semantically as distinct and important as quantity and price and be both integers, and if you swap them is a big issue anyway. And you would be forced, if you like this kind of programming, to create distinct types anyway. But I never trust this kind of &quot;toy&quot; defensive programming. The value comes from testing very well the code, from a rigorous quality focus.
atemerev2日前
Right. I attempted using Rust for trading-related code as well. However, I failed to write a dynamically linked always sorted order book where you can splice orders in the middle. It is just too dynamic for Rust. Borrow checker killed me.<p>And don&#x27;t get me started on dynamic graphs.<p>I would happily use Rust over C++ if it had all other improvements but similar memory management. I am completely unproductive with Rust model.
评论 #43909428 未加载
评论 #43909131 未加载
评论 #43908709 未加载
评论 #43908277 未加载
TnS-hun1日前
Examples miss angle brackets. For example:<p><pre><code> template explicit Quantity(T quantity) : m_quantity(quantity) { sendOrder(&quot;GOOG&quot;, false, Quantity(static_cast(atoi(&quot;-100&quot;))),</code></pre>
gbin2日前
Interestingly in Rust I would immediately use an Enum for the Order! Way more powerful semantically.
nmeofthestate1日前
If I tried to repro this problem in C++ code I believe it would fail clang tidy checks because of the implicit numeric casts.
skywal_l2日前
I love his videos on computerphile. One was just dropped a few hours ago: <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=1su3lAh-k4o" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=1su3lAh-k4o</a>
monkeyelite1日前
This article compares onlye one specific feature of C++ with Rust - integral type conversions.
评论 #43914108 未加载
mrsofty1日前
Godbolt is a legend and I don&#x27;t care what the others say. I believe him when he said he was &quot;just helping&quot; that sheep through the hedge. Well deserved praise Matty-poo and well written article.
time4tea1日前
aka use Tiny Types, they will help you.<p>Been true in all statically typed languages for decades!<p>It&#x27;s good advice.
mansoor_1日前
FYI newer builds of GCC have this functionality.
hacker_homie2日前
Wconversion And werror?
Horffupolde1日前
Would this also work for Zig?
nailer1日前
&gt; Before we go any further, let me just say he acknowledges floating point is not right for price and later talks about how he usually deals with it. But it makes for a nice example, bear with us.<p>OK but &quot;this makes for a nice example&quot; is silly, given that the only reason the example throws an error is that you used a float here, when both `quantity` and `price` would have been ints.<p><pre><code> error[E0308]: arguments to this function are incorrect --&gt; order&#x2F;order-1.rs:7:5 | 7 | send_order(&quot;GOOG&quot;, false, 1000.00, 100); &#x2F;&#x2F; Wrong | ^^^^^^^^^^ ------- --- expected `f64`, found `{integer}` | | | expected `i64`, found `{float}` </code></pre> I love Rust, but this is artificial.
评论 #43916059 未加载
mempko2日前
Rust does seem to have a lot of nice features. My biggest blocker for me going to Rust from C++ is that C++ has much better support for generic programming. And now that Concepts have landed, I&#x27;m not aware of any language that can compete in this area.
spyrja2日前
To be fair, this sort of thing doesn&#x27;t have to be so much worse in C++ (yes, it would have been nice if it had been built into the language itself to begin with). You just need a function to do a back-and-forth conversion which then double-check the results, ie:<p><pre><code> #include &lt;exception&gt; #include &lt;sstream&gt; template &lt;typename From, typename To&gt; void convert_safely_helper_(From const&amp; value, To&amp; result) { std::stringstream sst; sst &lt;&lt; value; sst &gt;&gt; result; } &#x2F;&#x2F; Doesn&#x27;t throw, just fails template &lt;typename From, typename To&gt; bool convert_safely(From const&amp; value, To* result) { From check; convert_safely_helper_(value, *result); convert_safely_helper_(*result, check); if (check != value) { *result = To(); return false; } return true; } &#x2F;&#x2F; Throws on error template &lt;typename To, typename From&gt; To convert_safely(From const&amp; value) { To result; if (!convert_safely(value, &amp;result)) throw std::logic_error(&quot;invalid conversion&quot;); return result; } #include &lt;iostream&gt; template &lt;typename Buy, typename Quantity, typename Price&gt; void sendOrder(const char* symbol, Buy buy, Quantity quantity, Price price) { std::cout &lt;&lt; symbol &lt;&lt; &quot; &quot; &lt;&lt; convert_safely&lt;bool&gt;(buy) &lt;&lt; &quot; &quot; &lt;&lt; convert_safely&lt;unsigned&gt;(quantity) &lt;&lt; &quot; &quot; &lt;&lt; convert_safely&lt;double&gt;(price) &lt;&lt; std::endl; } #define DISPLAY(expression) \ std::cout &lt;&lt; #expression &lt;&lt; &quot;: &quot;; \ expression template &lt;typename Function&gt; void test(Function attempt) { try { attempt(); } catch (const std::exception&amp; error) { std::cout &lt;&lt; &quot;[Error: &quot; &lt;&lt; error.what() &lt;&lt; &quot;]&quot; &lt;&lt; std::endl; } } int main(void) { test([&amp;] { DISPLAY(sendOrder(&quot;GOOG&quot;, true, 100, 1000.0)); }); test([&amp;] { DISPLAY(sendOrder(&quot;GOOG&quot;, true, 100.0, 1000)); }); test([&amp;] { DISPLAY(sendOrder(&quot;GOOG&quot;, true, -100, 1000)); }); test([&amp;] { DISPLAY(sendOrder(&quot;GOOG&quot;, true, 100.5, 1000)); }); test([&amp;] { DISPLAY(sendOrder(&quot;GOOG&quot;, 2, 100, 1000)); }); } </code></pre> Output:<p><pre><code> sendOrder(&quot;GOOG&quot;, true, 100, 1000.0): GOOG 1 100 1000 sendOrder(&quot;GOOG&quot;, true, 100.0, 1000): GOOG 1 100 1000 sendOrder(&quot;GOOG&quot;, true, -100, 1000): GOOG 1 [Error: invalid conversion] sendOrder(&quot;GOOG&quot;, true, 100.5, 1000): GOOG 1 [Error: invalid conversion] sendOrder(&quot;GOOG&quot;, 2, 100, 1000): GOOG [Error: invalid conversion] </code></pre> Rust of course leaves &quot;less footguns laying around&quot;, but I still prefer to use C++ if I have my druthers.
评论 #43912644 未加载
jovial_cavalier1日前
Hey, check this out:<p>#include &lt;iostream&gt;<p>struct Price { double x; };<p>struct Quantity { int x; };<p>void sendOrder(const char *symbol, bool buy, Quantity quantity, Price price) {<p><pre><code> std::cout &lt;&lt; symbol &lt;&lt; &quot; &quot; &lt;&lt; buy &lt;&lt; &quot; &quot; &lt;&lt; quantity.x &lt;&lt; &quot; &quot; &lt;&lt; price.x &lt;&lt; std::endl; </code></pre> }<p>int main(void) {<p><pre><code> sendOrder(&quot;GOOG&quot;, false, Quantity{100}, Price{1000.00}); &#x2F;&#x2F; Correct sendOrder(&quot;GOOG&quot;, false, Price{1000.00}, Quantity{100}); &#x2F;&#x2F; compiler error </code></pre> }<p>If you&#x27;re trying to get it to type check, you have to make a type first.<p>I don&#x27;t appreciate these arguments, and view them as disingenuous.
评论 #43919707 未加载
codedokode2日前
What about catching integer overflow? Free open-source languages still cannot do it unlike they commercial competitors like Swift?
评论 #43910683 未加载
评论 #43912986 未加载
评论 #43909444 未加载
评论 #43908922 未加载
评论 #43909326 未加载
globalnode1日前
My admittedly uninformed impression of Rust is that its a lot like Go (in spirit?), a language invented to shepherd novice programmers into not making mistakes with resource usage.<p>I imagine faceless shameless mega-corps with thousands of Rust&#x2F;Go peons coding away on the latest soulless business apps. Designed to funnel the ignorant masses down corridors of dark pattern click bait and confusing UX.<p>Having exposed my biases, happy to be proven wrong. Why are game studios still using C++? Because that&#x27;s the language game programmers know and feel comfortable with? Or some other reason?<p>Embedded is still C, games are C++, scientific and data are Python and R (I&#x27;m talking in general here). What is the niche for Rust?
评论 #43913433 未加载
评论 #43913434 未加载
评论 #43914122 未加载
评论 #43913456 未加载
评论 #43913444 未加载
评论 #43914112 未加载