TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Why Not Rust?

310 点作者 dochtman超过 4 年前

34 条评论

Animats超过 4 年前
As I&#x27;ve said before, Go has the advantage of mediocrity. It&#x27;s boring as a language, but it does automatically most of the things you need for web back-end stuff. It&#x27;s garbage-collected and does subscript checking, so you&#x27;re covered on memory safety. There are stable libraries for most things you need in a web server, and those are mostly the same libraries Google is using internally, so they&#x27;re well tested. The green thread&#x2F;goroutine approach means you don&#x27;t have the problems which come from &quot;async&quot; and threads in the same program; there&#x27;s only one concurrent task construct.<p>There&#x27;s a lot to be said for that. You can put junior programmers on something and they&#x27;ll probably get it more or less right.<p>Rust is very clever. The borrow checker was a huge step forward. It changed programming. Now, everybody gets ownership semantics. Any new language that isn&#x27;t garbage collected will probably have ownership semantics. Before Rust, only theorists discussed ownership semantics much. Ownership was implicit in programs, and not talked about much.<p>Tying locking to ownership seems to have worked in Rust. A big problem with locking has been that languages didn&#x27;t address which lock covers what data. Java approached that with &quot;synchronized&quot;, but that seems to have been a flop. (Why?) Ada had the &quot;rendezvous&quot;, a similar idea. Rust seems to have made forward progress in that area.<p>I used to say that the big problems in C are &quot;How big is it?&quot;, &quot;Who owns it for deletion purposes?&quot;, and &quot;Who locks it?&quot; At last, with Rust we see strong solutions to those problems in wide use.<p>Much work has gone into Rust, and it will have much influence on the design of later languages. We&#x27;re finding out what happens with that model, what&#x27;s useful, what&#x27;s missing, and what&#x27;s cruft.<p>In the next round of languages, we&#x27;ll probably have to deal directly with non-shared memory. Totally shared memory in multiprocessors is an illusion maintained by elaborate cache interlocking and huge inter-cache bandwidth. That has scaling limits. Future languages will probably have to track which CPUs can access which data. &quot;Thread local&quot; and &quot;immutable&quot; are a start.
评论 #24537877 未加载
评论 #24539795 未加载
评论 #24538137 未加载
评论 #24538271 未加载
评论 #24537954 未加载
评论 #24538700 未加载
评论 #24537719 未加载
评论 #24539577 未加载
评论 #24538633 未加载
评论 #24540677 未加载
评论 #24541109 未加载
评论 #24537840 未加载
the_duke超过 4 年前
&gt; Not All Programming is Systems Programming<p>Personally I often use Rust for &quot;non systems-programming&quot; tasks, even though I really wish a more suitable language existed.<p>Rust has plenty of downsides, but hits a particular sweet spot for me that is hard to find elsewhere:<p>* Expressive, pretty powerful, ML and Haskell inspired type system<p>* Memory safe. In higher level code you have almost zero justification for `unsafe`, unless you really need a C library.<p>* Immutable by default. Can feel almost functional, depending on code style.<p>* Error handling (it&#x27;s not perfect by any means, but much better than exceptions in my book)<p>* Very coherent language design. The language has few warts, in part thanks to the young age.<p>* Great package manager and build system.<p>* Good tooling in general (compiler errors, formatter, linter, docs generation, ... )<p>* Library availability is great for certain domains, decent for many.<p>* Statically compiled. Mostly statically linked. Though I often wish there was an additional interpreter&#x2F;JIT with a REPL.<p>* Good performance without much effort.<p>* Good concurrency&#x2F;parallelism primitives, especially since async<p>* Increasingly better IDE support, thanks to the author of this blog post! (rust-analyzer)<p>So I often accept the downsides of Rust, even for higher level code, because I don&#x27;t know another language that fits.<p>My closest alternatives would probably be Go, Haskell or F#. But each don&#x27;t fit the above list one way or another.
评论 #24538060 未加载
评论 #24538805 未加载
评论 #24537497 未加载
评论 #24537407 未加载
评论 #24537296 未加载
评论 #24537219 未加载
评论 #24537470 未加载
评论 #24537445 未加载
评论 #24538105 未加载
评论 #24537395 未加载
aazaa超过 4 年前
&gt; Programmer’s time is valuable, and, if you pick Rust, expect to spend some of it on learning the ropes.<p>Of all the arguments, time-to-productivity may be the most compelling. Rust will keep most new programmers from being productive far longer than any other language. I&#x27;d say 3x minimum.<p>What&#x27;s a little surprising, though, is how many of the difficulties beginners have stem from just one concept: <i>ownership</i>.<p>Counterintuitively, ownership is quite simple. But what&#x27;s mind-bending about it is that it doesn&#x27;t exist in any other language a beginner is likely to have used. Yet ownership pervades Rust, sometimes in very hard to detect ways. And perversely, it&#x27;s possible to write a lot of Rust without ever &quot;seeing&quot; ownership thanks to the complier.<p>Eventually, though, the beginner comes face-to-face with ownership without recognizing the trap s&#x2F;he&#x27;s fallen into. Ownership isn&#x27;t something you can &quot;discover&quot; by messing around in the same way that most language features can be teased apart. The term &quot;fighting with the borrow checker&quot; is actually a symptom not of a struggle with a feature but a struggle with a basic, non-negotiable concept that hasn&#x27;t been learned.<p>I can recommend this video for getting over the hump:<p><a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?list=PLLqEtX6ql2EyPAZ1M2_C0GgVd4A-_L4_5&amp;v=1QoT9fmPYr8" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?list=PLLqEtX6ql2EyPAZ1M2_C0GgV...</a><p>In my experience, Rust productivity shoots up by a lot given a basic understanding of ownership.
评论 #24537808 未加载
评论 #24538039 未加载
评论 #24538089 未加载
throwaway78123超过 4 年前
Rust in prod has been bittersweet for us. Our main goal was to 1) do our job and 2) leverage some of the great promises of Rust.<p>Deterministic memory management and bare metal performance are great and have been realized benefits. The great promises were realized.<p>On the “do your job” front though, the lack of a good STABLE library ecosystem has been a real issue and big source of frustration. It seems that most library developers in the Rust community are hackers writing Rust for fun, and I do not say that in a negative way. But the consequence is that things are usually not super well maintained, but more critically are targeting Rust Nightly (which makes sense as Nightly has all the new cool compiler stuff).<p>Add the scarce professional talent pool, the unavoidable steep learning curve, low bus factor risk... It’s just hard to justify pushing (professionally) more Rust beyond its niche.<p>With Mozilla pulling out (to some extent), the big focus on Web-assembly... it just feels off if all you want to do is build boring backends.<p>The contrast with Golang’s “boring as a feature” is quite interesting in that regard.<p>Time will tell if Rust will make it to the major leagues, or will be another Haskell.
评论 #24537972 未加载
评论 #24540974 未加载
评论 #24538001 未加载
slmjkdbtl超过 4 年前
I (hobby gamedev) moved from Rust to C a few weeks ago, here&#x27;s something that made me switch:<p>1. Compilation time (no more words needed)<p>2. Forced to use Cargo for managing dependencies. The downside of a good dependency toolchain is that people will use it and there will be tons of indirect dependencies. For cross-platform development it&#x27;s very common to see one of your indirect dependencies doesn&#x27;t support the platform you wanted, and there&#x27;s no way around it (even you know how to fix it you&#x27;ll have to submit a pr and wait till the merge and crates.io release (takes years), or download the whole dependency chain and use everything locally which is a total mess)<p>3. Too strict. As a hobby gamedev the thing I value the most is the joy of programming, I don&#x27;t want to spend all my time trying to figure out how to solve a borrow checker issue (you&#x27;ll always face them no matter how good you&#x27;re at Rust, and I don&#x27;t want to use Rc&lt;RefCell&lt;T&gt;&gt; everywhere), and I just want to be able to use global variables without ugly unsafe wrappers in my naive single threaded application.<p>As a language I love every aspect of Rust, just ergonomically I don&#x27;t want to deal with it now.
评论 #24539160 未加载
评论 #24539585 未加载
the__alchemist超过 4 年前
I hope this isn&#x27;t too much of a tangent given the article&#x27;s subject is details and specifics. I adore Rust for it&#x27;s unique combination of features:<p>- Can write fast, and systems-level code; something typically dominated by C&#x2F;++<p>- Makes standalone executables<p>- Modern, high-level language features<p>- Best-in-class tooling and docs (As the article points out)<p>I&#x27;m not familiar with another language that can do these together. It&#x27;s easy to pidgeonhole Rust as a &quot;safe&quot; language, but I adore it on a holistic level. I&#x27;ve found Rust&#x27;s consolidated, official tooling makes the experience approachable for new people.
评论 #24537256 未加载
评论 #24537206 未加载
jeffrallen超过 4 年前
In the section on &quot;Rust is big and you have to learn it&quot; the author was too nice to people like me: I&#x27;m just not smart enough to manage the demands Rust puts on me while also solving my own problem.<p>I feel like this is a really serious problem for Rust: the number of people capable of making the right choices among the 10 ways to structure a class is too small. This is also why there&#x27;s too much dangerously bad C and C++ in the world.
评论 #24537452 未加载
andrewmcwatters超过 4 年前
Not many people just come out and say it, but I think Rust is an ugly programming language. That&#x27;s a good enough reason for me.
评论 #24540632 未加载
评论 #24537976 未加载
评论 #24537842 未加载
评论 #24538376 未加载
est31超过 4 年前
A big thing missed here is compatibility. The systems programming market is huge but most of it is covered by C&#x2F;C++ programs, many of which being giant codebases with millions of engineer hours inside them. You can&#x27;t just rewrite them in Rust. And Rust will always be second in place when it comes to interacting with C&#x2F;C++ codebases, C++ will always be better at it, and if it&#x27;s only the explicit safety barrier.<p>So languages like Rust are relegated to picking up the new greenfield codebases and some few codebases where engineers felt courageous enough to introduce it.<p>Overall, the signs are good though. I think it&#x27;s much easier to onboard new engineers to Rust rather than to the company specific dialect of C++.
评论 #24537369 未加载
评论 #24537340 未加载
csomar超过 4 年前
&gt; Rust is a systems programming language.<p>While Rust is a systems programming language, it has a very advanced Traits system. This makes it, in my opinion, more powerful than your average scripting language (Python, JavaScript, etc...) I have recently used Rust for something that I should have, normally, used JavaScript or Python for. Based on my experience, I probably gained in development time because I didn&#x27;t do much debugging. Rust code <i>just</i> works, it&#x27;s simply amazing.<p>&gt; Complexity<p>One way to approach this, is to actually enjoy this complexity because there is <i>real</i> theoretical computer science behind it. It&#x27;s not complexity for its own sake.<p>&gt; Compile Times<p>This one is really annoying even with a powerful processor.<p>&gt; Maturity<p>I&#x27;d argue that since many high profile companies like Facebook, Google and Microsoft used Rust to start new projects (like Libra, Fuchsia); Rust is stable enough to be used in a production capacity. You&#x27;ll probably benefit more if the project is new and thus have less time dealing with C compatibility.
评论 #24551930 未加载
评论 #24539479 未加载
评论 #24541003 未加载
评论 #24539512 未加载
k__超过 4 年前
Sure, not everything is system programming, but Rust has some higher level features that are even missing in languages like JavaScript and Python. Pattern matching is very powerful.<p>I&#x27;m not entirely sure, but have the feeling that Rust&#x27;s &quot;cons&quot; are mostly short term draw backs and the &quot;pros&quot; could be really valuable in the long run.
评论 #24539542 未加载
评论 #24538512 未加载
rvz超过 4 年前
Another thing not mentioned is there&#x27;s still no mature cross-platform production ready GUI libraries written in Rust yet. None of them come even close to Qt or countering Electron. Just mere unmaintained bindings to them. [0]<p>I guess it is either Electron (HTML&#x2F;CSS&#x2F;JS) + 200MB Chromium engine or Qt5 (C++) for now.<p>[0] <a href="https:&#x2F;&#x2F;www.areweguiyet.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.areweguiyet.com&#x2F;</a>
评论 #24537308 未加载
评论 #24537923 未加载
评论 #24538123 未加载
pron超过 4 年前
&gt; we don’t know how to create a simpler memory safe low-level language.<p>This may well be true, but using a memory-safe language is never, ever the goal. The goal is creating correct and secure <i>programs</i> -- that have as few bugs and security flaws as possible&#x2F;required -- as cheaply as possible. While a memory safe language in the style of Rust is one means toward that end, that eliminates an important class of bugs at the cost of language complexity, it is not the best way toward that goal, at least not that we know, and it is certainly not the only one [1]. I.e. the hypothesis that if I want to write a program that&#x27;s as correct as possible&#x2F;needed as cheaply as possible then I should necessarily use the language that gives me the most sound guarantees regardless of the cost this entails is just some people&#x27;s guess. It&#x27;s hard to say if it&#x27;s a good guess or a bad one because it&#x27;s clear that we&#x27;re talking about specific sweet-spots on a wide spectrum of options that could be very context-dependent, but it&#x27;s still a guess, with good arguments both in its favour as well as against.<p>&gt; In Rust, there are choices to be made, some important enough to have dedicated syntax.<p>Not only that, but those choices are exposed in the type signature and are, therefore, viral. Changing some internal technical implementation detail can require changes in all consumers. This is not a problem with the type system -- on the contrary, Rust&#x27;s type system ensures that all the changes that need to be made are made -- but it is a fundamental problem with <i>all</i> low level language. They all suffer from <i>low abstraction</i>, i.e. a certain interface can represent a smaller number of implementations than in high-level languages (even if the choice is not explicit in the type, like, say, in C, the usage pattern is part of the interface). But Rust&#x27;s choice to expose such details in the types has its downsides as well.<p>&gt; If you use C, you can use formal methods to prove the absence of undefined behaviors<p>C now also has sound static analysis tools [2] that <i>guarantee</i> no undefined behaviour with a nearly fully automatic proof that scales to virtually any code size and requires relatively little effort, certainly compared to a rewrite.<p>[1]: Another low-level language with an emphasis on the same goal of correctness, Zig, takes an approach that is radically different from Rust&#x27;s and is so simple it can be fully learned in a day or two. Which of the two approaches, if any, is better for correctness can only be answered empirically.<p>[2]: Like <a href="https:&#x2F;&#x2F;trust-in-soft.com&#x2F;" rel="nofollow">https:&#x2F;&#x2F;trust-in-soft.com&#x2F;</a>, from the makers of Frama-C
mbo超过 4 年前
&gt; “Rust should have stable ABI” — I don’t think this is a strong argument. Monomorphization is pretty fundamentally incompatible with dynamic linking and there’s C ABI if you really need to.<p>This is an interesting topic unto itself, described in one of my favourite pieces of technical writing of all time:<p>How Swift Achieved Dynamic Linking Where Rust Couldn&#x27;t - Alexis Beingessner - <a href="https:&#x2F;&#x2F;gankra.github.io&#x2F;blah&#x2F;swift-abi&#x2F;" rel="nofollow">https:&#x2F;&#x2F;gankra.github.io&#x2F;blah&#x2F;swift-abi&#x2F;</a>
zelly超过 4 年前
Memory errors are not as big of an issue in the real world as the designers of Rust seem to assume. Andrei Alexandrescu has this quote about how Rust skipped leg day. You should all look it up. Here&#x27;s what actually matters, in the real world, for the type of programs I&#x27;d choose Rust or a Rust-adjacent language:<p>- Fast compile times<p>- Easy build system. Must be parallel, saturate all cores, and handle distributed builds as a built-in first-class feature. Should be able to produce static binaries or dynamically linked binaries. Should be able to consume binary dependencies (that means a stable ABI).<p>- Optimized, fuzzed, highly-tested, standards compliant web stack built-in<p>- Ability to compile CUDA kernels, built-in<p>- Automatic memory management with an escape hatch for where manual is necessary<p>- Rich metaprogramming and compile-time reflection<p>- Created by or funded by a large U.S. corporation so that PMs are likely to choose it.<p>- IDE&#x2F;LSP language server&#x2F;editor plugins maintained by the language designers<p>Failing this, you are an academic language, not a real world industry programming language in 2020.
评论 #24539319 未加载
评论 #24544488 未加载
snarkypixel超过 4 年前
Yeah, compiling in Rust was the bane of my existence. I tried to stay on old versions for as long as possible to avoid compiling.<p>At some points, I&#x27;d basically have to wait 10-15min.. so I&#x27;d go for a walk or grab coffee. Then I&#x27;d switch to javascript and it felt like going at the speed of light. To each their own.
ncmncm超过 4 年前
This is a pretty good summary.<p>Not to pile on, because Rust is still in a fragile condition, but the point that Rust cannot, and never will be able to call, typical C++ libraries deserves a boost (no pun intended).<p>This matters because C++ has more facilities to encapsulate powerful semantics into libraries than any other language. People write libraries in C++ that cannot be written in other languages, routinely.<p>This makes it usually impractical to integrate Rust code into an existing modern C++ codebase, unless it implements a wholly independent subsystem. That matters because effectively all of the most demanding systems-level work, today, is conducted in C++, not C (old OS kernels and databases excepted).<p>The longevity problem also deserves attention. The normal, expected fate of any new language is to die. It practically takes a miracle to survive, and we have no way to predict miracles. So, we don&#x27;t know if there will be anyone to maintain Rust code written today.<p>What will it take to survive? It comes down to numbers. Rust has an excellent adoption rate for a language at this stage. To survive, it <i>might</i> be enough were the rate to increase by two orders of magnitude.<p>You don&#x27;t get that just by more and better publicity. It needs change. But the changes needed are, by experience, very, very unpopular among existing Rust users.<p>Rust will never displace C++ or C. C++ does things Rust can&#x27;t. C will dwindle only as its user base retires, because C users actually like it for its failings: it makes them feel tough (or something). Rust is an overwhelmingly better language than Java or Go, and the world would be a better place if Rust were to displace them.<p>But neither of those has the specific problems that the borrow checker demands be solved. They have other, graver weaknesses. So, for Rust to displace them, its advocates will need to change their approach to appeal to users of those languages.<p>That will require at least a different build model that admits an order of magnitude faster builds, and a looser use of the borrow checker that generates less frustration. It might need accommodations to integrate in Go and Java projects, maybe including support for a JVM target, virtual call mechanism, and import of foreign Go and Java modules.<p>To get any of that, the project will need to excite people now in those environments with the prospect of easing their pain. Rust&#x27;s advantage there is that their pain is great, and Rust could ease it.
评论 #24541113 未加载
评论 #24538144 未加载
Karupan超过 4 年前
&gt; Complexity - Programmer’s time is valuable, and, if you pick Rust, expect to spend some of it on learning the ropes<p>This has been my experience as well. I&#x27;ve been trying out Rust for a week now and as an experienced programmer, the complexity of the language is overwhelming. That said, you don&#x27;t need to know all language constructs to get started. In the last week, I&#x27;ve been able to build a simple but useful cross-platform GUI app after reading only the ownership&#x2F;lifetime section of the Rust book.<p>But yes, it is not for everyone and it certainly isn&#x27;t a simple language to pick up.
评论 #24550974 未加载
baby超过 4 年前
From a security point of view, the major issue with Rust is still the shallow standard library, a shame the article doesn&#x27;t emphasizes this and instead lists this as a negligible point. How many will end up using rust wrongly due to the lack of a rand library, or anything cryptography, etc. And that&#x27;s nothing compared to the lack of a hex encoder&#x2F;decoder, of a tcp library, of a json library, etc. Compare that to Golang and Rust has a lot to improve on.
评论 #24539482 未加载
mhh__超过 4 年前
I think Andrei Alexandrescu&#x27;s comment that Rust &quot;skipped leg day&quot; is still mostly true (Rust does what it set out to do better than anyone else but the metaprogramming in particular isn&#x27;t very attractive)
评论 #24537695 未加载
jart超过 4 年前
TIL Rust is working on its own version of ASAN and UBSAN: <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;miri" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;miri</a> How shocking.
评论 #24538780 未加载
networkimprov超过 4 年前
Will the compiler performance eventually match C++, or are there fundamental limits to it?
评论 #24537263 未加载
评论 #24537425 未加载
评论 #24539536 未加载
jhoechtl超过 4 年前
Too complicated which means when your lead rust dev leaves good luck finding another one.
评论 #24537243 未加载
评论 #24537335 未加载
评论 #24537485 未加载
评论 #24537457 未加载
评论 #24541199 未加载
ajxs超过 4 年前
The article fails to mention Ada&#x27;s capabilities in the area of formal verification. The &#x27;SPARK&#x27; subset of the language is designed explicitly for this purpose.<p>Modern Ada&#x2F;SPARK also support Rust style &#x27;safe-pointers&#x27;: <a href="https:&#x2F;&#x2F;blog.adacore.com&#x2F;using-pointers-in-spark" rel="nofollow">https:&#x2F;&#x2F;blog.adacore.com&#x2F;using-pointers-in-spark</a>
fortran77超过 4 年前
Thanks! This convinced me. I&#x27;ll stick to C for low-level, C++ for CUDA stuff, and C# for everything else.
评论 #24537300 未加载
评论 #24537612 未加载
评论 #24537305 未加载
评论 #24537094 未加载
chubs超过 4 年前
I&#x27;ve been pondering similar issues re Rust a lot lately too. Mainly that it&#x27;s very safe and fast, but that is offset by how difficult it is to use.<p>I recently had an idea: What if i made a subset of Swift and a transpiler that outputs simple C? The C output would make it a great contender for integrations with existing code in the &#x27;systems programming&#x27; genre.<p>Swift is such a lovely language, far simpler than Rust, but being tied to apple&#x27;s ecosystem and LLVM makes it difficult to use for many of these areas.<p>This would also be great for embedded, which is something i&#x27;m also passionate about.<p>End result would be: productive + simple + safe language, great for systems&#x2F;embedded IoT stuff.<p>Anyway i&#x27;ve submitted the idea for an R&amp;D grant, we&#x27;ll see if it goes anywhere. Would love to hear people&#x27;s thoughts.
forrestthewoods超过 4 年前
&gt; Rust also lacks an analog for the pimpl idiom, which means that changing a crate requires recompiling (and not just relinking) all of its reverse dependencies.<p>Interesting. I did not know this. I would have thought Box&lt;dyn Foo&gt; would have achieved PIMPL. Is that not the case?
评论 #24537207 未加载
评论 #24537267 未加载
Ericson2314超过 4 年前
Great blog post<p>&gt; Rust also lacks an analog for the pimpl idiom, which means that changing a crate requires recompiling (and not just relinking) all of its reverse dependencies.<p>I really hope `extern type` could help with this. <i>edit</i> wrote <a href="https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;pull&#x2F;2984#issuecomment-695844429" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;rust-lang&#x2F;rfcs&#x2F;pull&#x2F;2984#issuecomment-695...</a> on how I think it could.
stephc_int13超过 4 年前
In the videogames world we - need very good performance - don&#x27;t care about memory safety (not an issue) - also need fast compile time
评论 #24537496 未加载
评论 #24537844 未加载
评论 #24537354 未加载
评论 #24537959 未加载
评论 #24537542 未加载
doonesbury超过 4 年前
This is one of better critiques I&#x27;ve read. I still think as a matter of market and solutions for same rust will continue to be a player. But I&#x27;m not game for rust to learn at the same time while I make, say, a distributed system. Frama-C with c++ I still think is the better combo
baby超过 4 年前
OK this annoyed me enough that I wrote my rebuttal :) <a href="https:&#x2F;&#x2F;www.cryptologie.net&#x2F;article&#x2F;505&#x2F;why-not-rust-for-security&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.cryptologie.net&#x2F;article&#x2F;505&#x2F;why-not-rust-for-sec...</a>
amelius超过 4 年前
&gt; All this complexity is there for a reason — we don’t know how to create a simpler memory safe low-level language. But not every task requires a low-level language to solve it.<p>And what most people forget is that complexity works <i>against</i> safety: the less the programmer is distracted by other issues (e.g. memory management), the more they can focus on security.
评论 #24537048 未加载
评论 #24537086 未加载
评论 #24537189 未加载
评论 #24537717 未加载
georgehm超过 4 年前
big plus one for Kotlin as a general purpose language
jahaja超过 4 年前
My main issue with &quot;complex&quot; or &quot;expressive&quot; languages are how they scale. Certainly not with regards to performance or throughput, but rather with how they scale with people. How will the code base look after 5 years and when a company have 50, 100, 200 devs instead of 10?<p>Expressive languages invites people to have their own dialects, their own little version of the language. It also invites people to be too smart for their own good and especially for the team&#x27;s good, resulting in code that&#x27;s very hard to debug and maintain <i>for other people than themselves</i>. I&#x27;ve seen in the game industry with C++ how bad it can get[1]. Because in practice there&#x27;s pressure, deadlines, temporary stand-ins &quot;helping&quot; other teams to finish their sub-projects. There just isn&#x27;t always time to be strict, so code rot will always sneak in. Of course this happens in all languages, but I find it much less extensive in so-called &quot;boring languages&quot;.<p>[1] Because of this I&#x27;m actually really surprised that a few big game industry companies have recently adpoted Rust, because the main problems afaik were code complexity over time and build times.
评论 #24539544 未加载