19 ms·

Why Not Rust? (2020)

235 points by spekcular 5y ago

phendrenad2 5y ago
I've been prototyping a little program to manipulate disk image files. I chose Rust, because I wanted to see for myself what the big deal was. It's not a good language for prototyping. I think Rust will always be known as "that language you rewrite your code in once you know exactly what you want, and need to make it secure"
benibela 5y ago
I wrote all my code in Pascal to have fast compilation With reference counted strings/arrays, it has solved almost all memory safety issues for me.
- formerly_proven 5y ago
  Memory safety is easy if you use GC (so don't have to define lifetimes) and mandatory bounds checking (unless compiler/JIT can convince itself that it is not necessary). Arguably these tradeoffs are the correct choice for a large majority of all applications — developers agree, looking at the popularity of Python, Java, .NET, Go, PHP, Perl, ...
  - BenFrantzDale 5y ago
    The biggest leak I’ve seen was in the JavaScript (qml) side of a C++/qml app. You can still leak in GC languages by inadvertently holding on to things you are done with. The GC encourages you to not think about it, which is a problem.
    - aww_dang 5y ago
      Agreed. At a certain point thinking about garbage collection becomes more burdensome than just handling allocation explicitly.
      - benibela 5y ago
        There reference counting has an advantage of being deterministic, so it is easier to reason about than full garbage collection
    - valenterry 5y ago
      I disagree. Just because there is a GC, it doesn't mean one does not have to be aware of the existence of memory. OOM errors are thing even without leaks in GC languages. Besides, leaks are only a small part of memory safety anyways. And I'm not surprised that you find the biggest leak in Javascript, the language that probably the biggest percentage of amateur/inexperienced developers are working in. (which is not generally a bad thing, but increases the chance for these bugs)
    - formerly_proven 5y ago
      I don't consider memory leaks a memory safety issue since all they do use use up memory and cause failing allocations, which has to be handled one way or another regardless whenever you use dynamic memory.
srcreigh 5y ago
This was written in 2020
- ncmncm 5y ago
  Nothing mentioned in it is any different now. That Pimpl is not practical in Rust is interesting news to me. The author's blithe unconcern about Cargo dependency trees looks unwise just now.
bumblebritches5 5y ago
Ugly ass syntax.
quincunx 5y ago
| keep in mind that picking Java over Cobol for banking software in 90s retrospectively turned out to be the right choice Is the Java written in the 90's still the same Java written today? I feel the mentioned Lindy effect equally applies to dialect. C++ today is radically different to C++ from the 90's. I'd venture COBOL from the 90's is likely quite similar to COBOL today.
- exdsq 5y ago
  Looking at the Wikipedia page for Cobol 2002 and 2014, the last two major releases, it looks like they've gained features such as Object Oriented Programming, Recursion, data types like Booleans, pointers, and user-defined functions. So I'm going to bet modern COBOL looks totally different to that of the 90's!
  - IainIreland 5y ago
    I spent ~5 years working on a COBOL compiler. In practice, production COBOL compilers pick and choose which parts of the standard they choose to implement based on customer demand, and there's not a lot of demand for most of the new stuff. To a first approximation, almost all COBOL code is legacy code in maintenance mode, and I would guess that a significant fraction of COBOL running today has barely been touched since the 90s, if not earlier.
  - atrn 5y ago
    I'm still waiting for concurrent COBOL... PERFORM x CONCURRENTLY WITH y BUT NOT WITH z.
    - erik_seaberg 5y ago
      000100 MOVE 4 TO reference-count ATOMIC IF reference-count EQUAL TO 3.
srer 5y ago
There's a statement that Rust is a systems programming language, but that in most cases one doesn't need this, and that Go or Kotlin are thus in most cases better alternatives. This image of Rust as lower level than Go isn't one I agree with, but I can certainly see how people end up there. Go has it's garbage collector and userspace threading model, one gives up a lot of control to a runtime that you don't have to in Rust. But as the author mentions if we're after good enough speed these details aren't important. So I don't most of the time care if there's a GC or not. What I care about is the code I have to write, and Rust IMHO offers me nicer abstractions and more features. The Go world in their desire for simplicity, use a for loop for everything, but in Rust we have the excellent iterator trait. The Go world offers me product types, the Rust world offers product and sum types. The Go world offers some mechanisms for codegen, but it is a far cry from Rust's macros. Go I consider a modernized C, that is notable more for what you can't do than what you can, and how fast it can be learned - owing to a minimal and already familiar feature set. I confess that I have a bit of a chip on my shoulder, I have for the last few years been working as a Go developer and in the last few months it's started really started to grate me how much work things are. I really miss things like '#[derive(...)]'.
- moldavi 5y ago
  The author could have recommended Scala, which has all of Rust's type system benefits, plus garbage collection (and of course, minus the low level control over performance). YMMV though, as everyone uses Scala differently. A lot of Scala code goes in a more abstract direction, but if you use it in a more imperative Kotlin-esque way it's a very nice language.
- ncmncm 5y ago
  Go, like Java, was designed by people who intended never to write any code in the language, themselves. Both are languages which those individuals designed for use by people less intelligent, careful, and thoughtful than themselves. The case of Java demonstrates they were mistaken: their estimation of their own understanding was grossly outsized. I don't know enough about Go to say whether that is true of Go's designers.
  - 5y ago
moldavi 5y ago
I'm also curious about the architectural consequences of Rust. It seems to force us into a very procedural or functional style, and sometimes makes us use parallel collections for things in a way reminiscent of relational databases... which is often a good thing, but not always. I'd love to read others' opinions on the topic.
- epage 5y ago
  One of the things I valued in the C++ community is the idea of expressing underlying complexity more explicitly through language / API constructs to help steer people in the right direction (Pit of Success type of stuff). I feel like Rust is taking that further and helping show how nasty most of our GUI (at least) architectures are. I eagerly watch the progress of GUIs and other architectural work in Rust because they are helping to raise the popularity of solutions we've been ignoring because things have been "good enough".
  - moldavi 5y ago
    React and Polymer seemed like an okay balance of of OO and functional... are our current GUI architectures really that nasty?
    - epage 5y ago
      I'm speaking of more traditional GUI architecture where everything is a bidirectional graph of statically defined widgets. From my understanding, Elm and react style GUIs are some of the models people are looking to in Rust.
    - rackjack 5y ago
      GUI in Rust specifically is very unpleasant, from my limited experience.
- rackjack 5y ago
  Rust is just a (pretty opinionated) tool. When it works, it really works, and the architecture rises smoothly. When it doesn't work, it really doesn't work, and there's some teeth gnashing and maybe a little praying Zig reaches 1.0 soon. People want a be-all-end-all tool, but Rust is just not that, so you get tons of arguments about this or that use case. You wouldn't use a saw to hammer in a nail. Just treat it like a tool.
outerspace 5y ago
A programming language that offers no mechanism to handle memory allocation errors is not a system programming language. I have yet to come to a conclusion on the merits of Rust, but this claim about system programming always ticks me off.
- epage 5y ago
  First, I feel that is a bit of gate keeping. I've done a lot of systems work where Rust today would have been perfectly fine. We originally tried to track memory allocation errors but we gave up because we didn't test allocation failures and likely had large gaps in it and just found it wasn't worth the code bloat. We still checked for allocation failures for data transfer buffers but thats it. Second, Rust doesn't stop you from handling memory allocation errors. The standard library might fully support failable allocations but that doesn't stop you from using your own collections for that type of work. Third, this has been an item of interest for a long time in the Rust community and is actively being worked on as part of introducing Rust into Linux.
  - ncmncm 5y ago
    It does not take much sophistication to end up with multiple allocation arenas, any one of which might be exhausted without indicating general system failure. Being ill-equipped to use or recover from allocation failures in such arenas bodes poorly for a systems language.
    - johncolanduoni 5y ago
      If you’re allocating from multiple arenas, you’re not going to be using `new` in C++ or `Box` in Rust. Nothing stops you from writing an arena allocator that can return an error code in Rust any more than C++ does.
      - ncmncm 5y ago
        Hint: nobody uses "new" in C++ anymore. All the C++ containers, and make_unique etc. know how to use local arenas. I gather there has been some effort to get Rust library components aware of such things. Handling exhaustion in them is an interesting research topic.
synergy20 5y ago
Since life is short and time is not unlimited and I'm not a talent programmer, I have decided to stick with c/c++ plus some python/golang/javascript/sql for my software career all the way until it ends. Those are already more than enough for me to handle in fact. best luck to rust programmers, it's just too much for me and too late for me. I do use quite a few nice rust utilities(fd,rg,etc) daily.
- kitkat_new 5y ago
  if c/c++ really includes having good C++ knowledge then Rust will be kindergarten, promise
ferdowsi 5y ago
A previous workplace experimented with Rust for internal services and the feedback was almost uniformly negative. Commonly cited reasons were the long compile times, limited standard library, and generally unstable best practices. One interesting quote was "why are you forcing me to waste a bunch of time doing needless bookkeeping when I create and pass around a string?" The blog post about "Why strings seem hard in Rust" was not met with excited reactions.
- spekcular 5y ago
  What language did the workplace decide to use instead?
- ostenning 5y ago
  Internal services? What problem were you trying to solve with Rust exactly? Personally I wouldn't be writing web services with Rust, I don't think the language was really designed with that problem set in mind.
  - jrib 5y ago
    Which problem sets would you say rust excels at?
    - zarzavat 5y ago
      As a replacement for C or C++ (except 3D games where the choice of language is dictated by the engine). Kernels, databases, CLI programs, toasters, native code Python modules, etc. As a replacement for Go if you want a comprehensive type system instead of a skinny one.
      - FpUser 5y ago
        I use C++ for backend business servers and web services in particular with stellar results performance wise. Modern C++ along with the STL and loads of 3rd party libs makes rapid development of servers piece of cake.
smasher164 5y ago
My heuristic nowadays is if the workload is I/O bound, use Go. Otherwise, use Rust.
EugeneOZ 5y ago
The first “point” made me read the whole article skeptical. 1) Rust is a “general-purpose programming language”, not “system programming language”. 2) Performance is not even the most important reason. Syntax, features, guarantees - much more important.
deleted 5y ago
[deleted]
tayo42 5y ago
I wish there was more stuff like this out there about rust, something, anything to counter what feels like blind optimism and fanboy-ism for the language. For me its hard to get a good sense of the language being worth it. People really do hype it up, but i do know there are valid criticisms out there. IDK if they're all blog writers. My own recent experience trying to write a server kind of left me unsure about how practical using the language is after being pretty excited about it. I think the author wrote off "dependencies" to quickly. I'm kind of unsure about the state of dependencies. A lot of libraries seem to be peoples hobby/free time projects. I ran into strange comments in libraries where people don't actually seem to understand the domain they're writing the library in. Like I think all of the http frameworks are pet projects? My feeling after using rust and async was that it kind of tricks you into writing sub optimal code often. Like what could be solved with a singleton ends up needing a lot of boilerplate, new data structures, complex code so you end up writing in some other way, or burning your self with mutex.(aside note, everybody recommending a faster mutex that's not in the stdlibrary seems odd). I also dont know why npm and node get so much shit for needing so many libraries but rust and cargo get a pass for these small libraries everywhere.
- choeger 5y ago
  The state of the ecosystem is concerning, but natural. It always takes some time until the best/standard libraries become visible amongst the noise. Lastly, I was looking for Parser combinators and the first three hits and no commits for years. That's definitely a red flag for me.
- adamnemecek 5y ago
  What did you get stuck on? > I also dont know why npm and node get so much shit for needing so many libraries but rust and cargo get a pass for these small libraries everywhere. Because cargo is a better package manager in every aspect.
  - zozbot234 5y ago
    Because Rust is a `cargo` cult. /s
WalterBright 5y ago
The trouble with "why not" questions is it implicitly omits the reasons why.
CraigJPerry 5y ago
In my limited experience the compile speed issues are often overblown. The biggest rust project i compile regularly is deno. It doesn’t feel that slow. Cargo is great but it’s not continued to evolve fast enough. For example, there’s not enough defence against supply chain attacks yet. >> Rust’s price for improved control is the curse of choice The annoying unstated side effect of this is that on average, developers will choose the easiest option. E.g. quite a few blogs and tutorials wastefully use clone because it’s easier than wrangling with lifetimes (which admittedly have an developer-unfriendly habit of being quite virulent through your code) - or whatever other approach you fancy to avoid pointless copying. They do it just to get around the borrow checker. You don’t need to be processing that many strings with this approach before Python’s (lack of) speed is giving you a run for your money.
nsonha 5y ago
I'm glad to see this article, every week I roll eyes at people on HN claiming that rust targeting wasm will replace javascript. I'm not against replacing js, it just won't be a language that's made on the complete opposite side on the spectrum of PLs.
- jamil7 5y ago
  Or appearing in every other language discussion to bring up Rust.
johnisgood 5y ago
> Ada is memory safe if you don’t use dynamic memory (never call free). Take a look at https://docs.adacore.com/live/wave/spark2014/html/spark2014_ug/en/source/access.html#deallocation https://docs.adacore.com/live/wave/spark2014/html/spark2014_.... You can prove the absence of memory leaks, too. :)
- pitaj 5y ago
  Leaks are permitted in rust, and are not a memory safety concern. I don't think that's what he was talking about.
  - johnisgood 5y ago
    I just added that as an extra. The point is that you can have memory safety even if you do free. It may not have been the case with Ada (without SPARK) in the past.
    - johnisgood 5y ago
      I would also like to add these: > Values of such an access type can be deallocated safely. GNATprove generates verification conditions to ensure that no memory can be leaked. So... you can deallocate safely AND verify that no memory is leaked. Is it not wonderful? - https://docs.adacore.com/live/wave/spark2014/html/spark2014_ug/en/source/access.html#pointer-support-and-dynamic-memory-management https://docs.adacore.com/live/wave/spark2014/html/spark2014_... - https://docs.adacore.com/live/wave/spark2014/html/spark2014_ug/en/usage_scenarios.html#prove-absence-of-run-time-errors-aorte https://docs.adacore.com/live/wave/spark2014/html/spark2014_... > SPARK builds on the strengths of Ada to provide even more guarantees statically rather than dynamically. As summarized in the following table, Ada provides strict syntax and strong typing at compile time plus dynamic checking of run-time errors and program contracts. SPARK allows such checking to be performed statically. In addition, it enforces the use of a safer language subset and detects data flow errors statically.
ComputerGuru 5y ago
This is why I don’t understand why people insist on creating web frameworks in rust. It’s one thing to write a proxy server or load balancer in rust, it’s another thing to write your actual CRUD app in rust. And the community has bent over backwards to support this use case and expended enormous resources to that end. I write embedded firmware, replacements for GNU coreutils, system services, and more in rust and I love it. But I write my web apps in C# and I wouldn’t change that.
- cmrdporcupine 5y ago
  Fair enough, and I think I mostly agree. But it's worth pointing out that large amounts of the web facing services from FAANG companies that we all use daily ... are written in C++. They could just as easily be done in Rust.
  - valenterry 5y ago
    For these things, languages with gc should really be used.
- valenterry 5y ago
  I agree. Rust is not the right language for this, unless performance is the #1 concern (but mostly it is not). I'm looking forward to have something like Linux written in Rust though.
- Jnr 5y ago
  If people want to write things in Rust, let them write things in Rust. Hanging out at community Discord I see that there are a lot of new guys, students. They just want to experiment, and I am all for it. Yes, maybe it's not the most efficient thing from "business perspective", but maybe, eventually something new and exciting will come out of it. Programming is evolving, we had a lot of the same functionality available in older languages, using older paradigms, but eventually those stay in the past for a reason. I'm staying open minded and I am excited for the future.
cletus 5y ago
I'm in the camp that is long-term bullish on Rust. Memory safety is simply too important. I also consider C++ an unsalvageable mess at this point. Just a couple of thoughts reading this. > Compile Times This is (IMHO) the biggest problem with Rust as the article mentions. Apparently, this was due to some early unfortunate design decisions that resulted from the tight coupling with early Rust and Servo. Rust at this point is heavily tied to LLVM (I'm aware there's a gcc version in the works). If you don't know, the general structure is LLVM is to have a frontend and a backend. The frontend translates whatever your language is into LLVM-IR (intermediate representation), a sort of abstract assembly language. This isn't tied to any particular architecture (eg IIRC there are infinite registers in LLVM-IR). The backend translates that to a particular architecture. This is good because it's easier to get a compiler off the ground but gcc's performance is still second-to-none. Rust expands macros and the likes by producing a godawful amount of LLVM-IR and lets the backend strip out what's not needed. This works but impacts compile times. More details here [1]. > Complexity Yes and no. It's a bit like how dynamic programming languages originally rose to prominence because of the speed you could do things, or at least that was the argument. Static typing was seen as getting in the way or being too complex. I've come to the conclusion that this is a false economy. The best way I can put it is in Python you end up writing unit tests for spelling mistakes. The hierarchy of programming errors is IDE errors are better than compiler errors which are better than runtime errors. In an ideal world there's no difference between IDE errors and compiler errors but almost always there is. So Rust is actually forcing you to move runtime multithreaded issues into being compiler errors. This feels like more work (because it is) but it is infinitely preferable. Opponents will say, for example, that C++ has smart pointers to denote ownership. This is true but they have a runtime cost. Rust doesn't. And the effect of a runtime error in C++ is typically a core dump or just weirdly inconsistent behaviour (which is often worse). People routinely underestimate just how complex multithreaded code really is, particularly when they try and write lock-free abstractions (as is popular in C++) especially given the complexity of how processors actually work (eg out-of-order execution, branch prediction). There are various tools that are written to identify some of these issues (eg valgrind, asan, tsan, etc). While I was at Google I remember reading about how a bug had been found in an in-house written lock-free abstraction with some new tool that had been >7 years in production. But yet, even on HN, I too often hear "what's so hard about just putting a mutex on it". [1]: https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/rust-compilation-model-calamity
skwirl 5y ago
I am very nervous about Rust. My team recently started on a Rust project because we had a need to build something that would compile to WebAssembly. Without getting into too much detail, the WebAssembly runtimes for memory managed languages wouldn't work for what we're doing. We are not a company that does a lot with C/C++ and those of us who have used C/C++ do not particularly enjoy it, so we decided to go with Rust. I do like Rust and it has worked well for this particular project. The problem, though, is that now there's a Rust mania that has set in and a desire to write/rewrite lots of stuff with Rust. Based on what I've seen out there on the web, this seems like a common thing. While Rust offered a clear benefit to us for the WebAssembly work, for every other case the benefits of Rust are mostly absent or minimal but the drawbacks around losing a garbage collector, losing a large healthy package ecosystem, losing use of our existing internal libraries and tooling, etc. loom large. So I am in an unhappy position where I keep telling enthusiastic Rust advocates no. Another interesting thing is that people tell their friends that we are using Rust and now they want to apply to work for us. We have a hard time recruiting and there's part of me that wonders if we'd just be flooded with applicants if we started advertising Rust jobs. This is somewhat tempting - we might be able to easily hire teams of enthusiasts to churn out Rust but for how long? How long will it have this magic aura and following? I certainly don't want to be left with tons of crappy Rust code in a few years that nobody wants to maintain. I feel like HN has mostly been very enthusiastic about Rust. A thread critical of Rust is rare and I feel like it is refreshing.
- pingsl 5y ago
  I have the same opinion. The best thing about rust is that rust attracts more people to learn systems programming languages. And thus, there will be more system programmers. Nowadays, young people favor application programming far more than system programming. But the problem is there are not that many system programming opportunities. Then they decided to rewrite the existing systems with rust. We can find a lot of these examples on GitHub. Who knows if it is just a moment of enthusiasm, and how long will it last?
  - jmatthews 5y ago
    As someone who mostly enjoys cpp, for me the math just didn't seem worth it to really get fluent in rust. I agree there are less system jobs than app jobs kind of prima facie, but there's not exactly a lack of systems jobs for cpp programmers at the moment.
ajxs 5y ago
> Rust is a systems programming language. It offers precise control over data layout and runtime behavior of the code... It really doesn't. It doesn't even have native support for bitfields. When I tried doing low-level programming in Rust, this immediately struck me. Rust's semantics don't really offer much of an improvement over what already existed in this area. In addition to presenting all kinds of new, frustrating challenges. I've used Ada extensively in this area, and I just don't see what Rust has to offer that Ada didn't already address. I'm all too aware that string operations in low-level programming languages are always going to be prickly. Ada's standard library, even in its 80s incarnations, is light-years ahead of Rust in this area. Interoperability with other languages is another area where Ada beats Rust hands-down. The first thing I tried to do was integrate C and Rust, and realised immediately that it was a nightmare. In Ada, it really couldn't be simpler.
- zozbot234 5y ago
  > It really doesn't. It doesn't even have native support for bitfields. Many people would consider C bitfields half-baked in the first place, given that the feature is well-known to be underspecified in a way that leads to compatibility/portability concerns. Is this really the kind of stuff that Rust should concern itself with?
  - pitaj 5y ago
    Yeah I agree with rust's decision to not go there yet. They're only really used often in very low-level niches like mmio registers, where autogenerating handlers with svd2rust works great and provides a little bit of safety along with it. This is coming from someone who uses C bitfields every day on an embedded MCU.
    - ajxs 5y ago
      > They're only really used often in very low-level niches like mmio registers ... which are actually an incredibly common, totally everyday problem encountered by tens of thousands of developers everyday? > autogenerating handlers with svd2rust works great and provides a little bit of safety along with it. I don't think that requiring third-party tooling to implement something so basic is a suitable solution to this problem. What if the manufacturer of the device I'm working with hasn't released an SVD file? What if I'm not actually working on an MCU at all, but a peripheral driver?
pitaj 5y ago
(2020)
deleted 5y ago
[deleted]
deleted 5y ago
[deleted]
scythe 5y ago
>However, in many (most) cases, one doesn’t need ultimate performance or control over hardware resources. For these situations, modern managed languages like Kotlin or Go offer decent speed, I feel like D really deserves to be mentioned more often when talking about Rust alternatives. It's sort of the anti-Rust: improving on C++ by focusing on ergonomics rather than raw efficiency. It's likely more familiar to the C++ native than Kotlin and Go, and more directly comparable to Rust in that it has an expressive type system, compiles to native code, and interfacing well with C. I would say D is the best answer on average to the question "I like all those things Rust can do but I find it annoying to work with, what can I use instead?" whereas Kotlin or Go will not always be a great stand-in.
- pjmlp 5y ago
  The community is great, but D itself kind of suffers from lack of direction where they want to be, every couple of years there is this next big that is going to bring people into the community, none of them fully done to completion ironing all bugs out. So it remains a very nice language, but you need to be willing to get hands dirty fixing bugs and contributing back, if you feel going into production with it. All D success stories had their of fork of the D toolchain, or standard library, to certain extent.
  - mhh__ 5y ago
    If you consider Symmetry investments a D success story, we do not do that - we do have a fork of LDC but I've never needed to use it, as far as I'm aware it's just an early release in effect, no new features.
    - pjmlp 5y ago
      Good to know, although the point was not about new features, more like bug fixes and the alternative runtime as Sociomantic used to have. More than a sucess story, I consider Symmetry the very last hope to keep D relevant actually.
code_biologist 5y ago
The linked presentation deck "High Performance Managed Languages" is great! Deck PDF: https://qconlondon.com/london-2017/system/files/presentation-slides/highperformancemanagedlanguages.pdf https://qconlondon.com/london-2017/system/files/presentation... Video: https://www.youtube.com/watch?v=Pz-4co8IaI8 https://www.youtube.com/watch?v=Pz-4co8IaI8
dang 5y ago
Discussed at the time: Why Not Rust? - https://news.ycombinator.com/item?id=24536645 https://news.ycombinator.com/item?id=24536645 - Sept 2020 (319 comments)
pse_pan2233 5y ago
I'm someone who likes to write Rust and wants to use it all the time, but for my professional work I only choose it when I really need it, which is very seldom - actually it was only once for a CAD data converter where memory usage must be as low as possible. The reasons not to use it always for everything are: 1. The mental overhead is larger than most want to admit. It's not about the syntax, but about memory management of course. The time and effort spend there should be spend to solve the problem at hand. 2. Depending on a lot of third party libraries which are maintained by just 1 person.
jeff-davis 5y ago
The main reason I don't complain about rust is because complaints feel like a way to pressure developers to address my specific wish list, which feels wrong. But, this thread feels like an opportunity, so here goes: 1. It lacks a good way to control memory in different ways for different data structures. The allocator_api is still experimental. This feels strange for a systems language. 2. It's a complex language. There's no way around that. The developers have done a great job avoiding unnecessary complexity, but the benefits rust offers do have a complexity cost and you should really evaluate whether rust enables you to make up for it with simplicity elsewhere in the stack. 3. The sync/async situation feels like a division to me. Maybe that's inherent and not rust's fault, but it does feel like some kind of a divide. For instance, if you want a postgres driver, rust-postgres is great, but it follows the async approach and that means zillions of dependencies and long fresh-compile times. If it used a synchronous style, it would only depend on the standard library, and compilation would be very fast. Should there be two libraries? I don't really know. 4. There's not a good supported way to build "plugin" style shared libraries where you can refer to symbols that exist in the program that loads the library. You can hack the build flags in, but none of the testing infrastructure works. 5. While C integration is great, there's not a good way to catch a longjmp() from C without some undefined behavior. 6. The culture of rust seems to favor dependencies a bit too much. The decision to take a dependency is an important one with trade-offs, and the rust culture seems to be always to take a dependency, even if doing it yourself would be little code, and the dependency transitively includes a ton of code that seems to churn a lot. This plays to rusts strengths around tooling, but goes to far in my opinion. But after all of that, there's still one huge reason to pay attention to rust: if you are a systems programmer, there aren't a lot of options for most projects, so having a new option is a big deal. In many cases, the practical options go from "C/C++" to "C/C++/Rust".
- EugeneOZ 5y ago
  This is a much better level! I think you really should write an article about that. Criticism like this is no pressure, I think - it's an essential part of discussions and the evolution of language.
davidkunz 5y ago
I really want to love Rust. The resulting programs written in it are fast, memory efficient and safe. Something which usually isn't the case in other programming languages. But here and there I see how simple problems require complicated solutions, for example when you want to create a logger middleware for a web service: https://youtu.be/16sU1q8OeeI https://youtu.be/16sU1q8OeeI Something I could have written in 3 lines of JavaScript. In Rust, it requires knowledge of poll, pin, boxpin, ... and even third-party crates (if you yourself are not enough of a magician). I'm not sure if Rustaceans are okay with that additional complexity, but it really scares me off to dig deeper into that language. I would appreciate if some experienced Rust programmers could comment!
matesz 5y ago
Interesting note - when it comes to compile times, the most optimized Rust codebase in that aspect I believe is makepad.dev [1]. It is compiling from scratch on mac m1 in around 7.5s [2] and that's +100k lines of Rust. However there is close to none dependencies, so this +100k is all there is to compile pretty much. Still, this is impressive feat! [1] https://makepad.dev/ https://makepad.dev/ [2] https://twitter.com/rikarends/status/1467529091284934666 https://twitter.com/rikarends/status/1467529091284934666
Klasiaster 5y ago
> modern managed languages like Kotlin or Go offer decent speed, enviable time to performance, and are memory safe by virtue of using a garbage collector for dynamic memory management Take this with a grain of salt: Go data races can still lead to memory corruption and security vulnerabilities (no one uses the inbuilt data race detector in production, few use it while testing).
viktorcode 5y ago
> Rust is a systems programming language. It offers precise control over data layout and runtime behavior of the code, granting you maximal performance and flexibility. I'm nitpicking, but it's due to considering the difference important for some unsuspecting programmers: having control over data layout and runtime behaviour doesn't grant you maximal performance. It grants you capability for achieving minimal overhead, which is connected to, but a different thing from performance.
- kaba0 5y ago
  Thanks, it’s a really great way to put it!
ithkuil 5y ago
> But, for example, some runtime-related tools (most notably, heap profiling) are just absent — it’s hard to reflect on the runtime of the program if there’s no runtime! Yeah; I felt that pain too. I tried to write something to address some parts of the missing space. It's still in the early stages but you may be interested: https://github.com/mkmik/heappy https://github.com/mkmik/heappy
sally1620 5y ago
The most important argument is that not all programming is systems programming. A lot of projects choose C, C++ or Rust only because they need performance: * Backend services * Numerical computation * Game development * Rendering engines, e.g., browser engines System programming is usually needed for what we consider Operating Systems, e.g. kernel, system libraries, and shell. In my career as a C++ programmer I have worked on a lot of projects that I would otherwise write in C#, Java, Julia, or Go.
singularity2001 5y ago
One of the main benefits of Rust, memory safety, becomes much less significant when compiling to the wasm sandbox. Thus in this setting I prefer to use modern C++ over the (at times horrible) verbosity of Rust.
- kaba0 5y ago
  Catching those at compile time is still much better than some obscure runtime bug. If the latter would be enough, valgrind would suffice for testing c/c++ programs, but you can’t really execute every code path all the times.

235 points by spekcular 5y ago

I've been prototyping a little program to manipulate disk image files. I chose Rust, because I wanted to see for myself what the big deal was. It's not a good language for prototyping. I think Rust will always be known as "that language you rewrite your code in once you know exactly what you want, and need to make it secure"

benibela 5y ago

I wrote all my code in Pascal to have fast compilation With reference counted strings/arrays, it has solved almost all memory safety issues for me.

formerly_proven 5y ago
Memory safety is easy if you use GC (so don't have to define lifetimes) and mandatory bounds checking (unless compiler/JIT can convince itself that it is not necessary). Arguably these tradeoffs are the correct choice for a large majority of all applications — developers agree, looking at the popularity of Python, Java, .NET, Go, PHP, Perl, ...
- BenFrantzDale 5y ago
  The biggest leak I’ve seen was in the JavaScript (qml) side of a C++/qml app. You can still leak in GC languages by inadvertently holding on to things you are done with. The GC encourages you to not think about it, which is a problem.
  - aww_dang 5y ago
    Agreed. At a certain point thinking about garbage collection becomes more burdensome than just handling allocation explicitly.
    - benibela 5y ago
      There reference counting has an advantage of being deterministic, so it is easier to reason about than full garbage collection
  - valenterry 5y ago
    I disagree. Just because there is a GC, it doesn't mean one does not have to be aware of the existence of memory. OOM errors are thing even without leaks in GC languages. Besides, leaks are only a small part of memory safety anyways. And I'm not surprised that you find the biggest leak in Javascript, the language that probably the biggest percentage of amateur/inexperienced developers are working in. (which is not generally a bad thing, but increases the chance for these bugs)
  - formerly_proven 5y ago
    I don't consider memory leaks a memory safety issue since all they do use use up memory and cause failing allocations, which has to be handled one way or another regardless whenever you use dynamic memory.

srcreigh 5y ago

This was written in 2020

ncmncm 5y ago
Nothing mentioned in it is any different now. That Pimpl is not practical in Rust is interesting news to me. The author's blithe unconcern about Cargo dependency trees looks unwise just now.

bumblebritches5 5y ago

Ugly ass syntax.

quincunx 5y ago

| keep in mind that picking Java over Cobol for banking software in 90s retrospectively turned out to be the right choice Is the Java written in the 90's still the same Java written today? I feel the mentioned Lindy effect equally applies to dialect. C++ today is radically different to C++ from the 90's. I'd venture COBOL from the 90's is likely quite similar to COBOL today.

exdsq 5y ago
Looking at the Wikipedia page for Cobol 2002 and 2014, the last two major releases, it looks like they've gained features such as Object Oriented Programming, Recursion, data types like Booleans, pointers, and user-defined functions. So I'm going to bet modern COBOL looks totally different to that of the 90's!
- IainIreland 5y ago
  I spent ~5 years working on a COBOL compiler. In practice, production COBOL compilers pick and choose which parts of the standard they choose to implement based on customer demand, and there's not a lot of demand for most of the new stuff. To a first approximation, almost all COBOL code is legacy code in maintenance mode, and I would guess that a significant fraction of COBOL running today has barely been touched since the 90s, if not earlier.
- atrn 5y ago
  I'm still waiting for concurrent COBOL... PERFORM x CONCURRENTLY WITH y BUT NOT WITH z.
  - erik_seaberg 5y ago
    000100 MOVE 4 TO reference-count ATOMIC IF reference-count EQUAL TO 3.

srer 5y ago

There's a statement that Rust is a systems programming language, but that in most cases one doesn't need this, and that Go or Kotlin are thus in most cases better alternatives. This image of Rust as lower level than Go isn't one I agree with, but I can certainly see how people end up there. Go has it's garbage collector and userspace threading model, one gives up a lot of control to a runtime that you don't have to in Rust. But as the author mentions if we're after good enough speed these details aren't important. So I don't most of the time care if there's a GC or not. What I care about is the code I have to write, and Rust IMHO offers me nicer abstractions and more features. The Go world in their desire for simplicity, use a for loop for everything, but in Rust we have the excellent iterator trait. The Go world offers me product types, the Rust world offers product and sum types. The Go world offers some mechanisms for codegen, but it is a far cry from Rust's macros. Go I consider a modernized C, that is notable more for what you can't do than what you can, and how fast it can be learned - owing to a minimal and already familiar feature set. I confess that I have a bit of a chip on my shoulder, I have for the last few years been working as a Go developer and in the last few months it's started really started to grate me how much work things are. I really miss things like '#[derive(...)]'.

moldavi 5y ago
The author could have recommended Scala, which has all of Rust's type system benefits, plus garbage collection (and of course, minus the low level control over performance). YMMV though, as everyone uses Scala differently. A lot of Scala code goes in a more abstract direction, but if you use it in a more imperative Kotlin-esque way it's a very nice language.
ncmncm 5y ago
Go, like Java, was designed by people who intended never to write any code in the language, themselves. Both are languages which those individuals designed for use by people less intelligent, careful, and thoughtful than themselves. The case of Java demonstrates they were mistaken: their estimation of their own understanding was grossly outsized. I don't know enough about Go to say whether that is true of Go's designers.
- 5y ago

moldavi 5y ago

I'm also curious about the architectural consequences of Rust. It seems to force us into a very procedural or functional style, and sometimes makes us use parallel collections for things in a way reminiscent of relational databases... which is often a good thing, but not always. I'd love to read others' opinions on the topic.

epage 5y ago
One of the things I valued in the C++ community is the idea of expressing underlying complexity more explicitly through language / API constructs to help steer people in the right direction (Pit of Success type of stuff). I feel like Rust is taking that further and helping show how nasty most of our GUI (at least) architectures are. I eagerly watch the progress of GUIs and other architectural work in Rust because they are helping to raise the popularity of solutions we've been ignoring because things have been "good enough".
- moldavi 5y ago
  React and Polymer seemed like an okay balance of of OO and functional... are our current GUI architectures really that nasty?
  - epage 5y ago
    I'm speaking of more traditional GUI architecture where everything is a bidirectional graph of statically defined widgets. From my understanding, Elm and react style GUIs are some of the models people are looking to in Rust.
  - rackjack 5y ago
    GUI in Rust specifically is very unpleasant, from my limited experience.
rackjack 5y ago
Rust is just a (pretty opinionated) tool. When it works, it really works, and the architecture rises smoothly. When it doesn't work, it really doesn't work, and there's some teeth gnashing and maybe a little praying Zig reaches 1.0 soon. People want a be-all-end-all tool, but Rust is just not that, so you get tons of arguments about this or that use case. You wouldn't use a saw to hammer in a nail. Just treat it like a tool.

outerspace 5y ago

A programming language that offers no mechanism to handle memory allocation errors is not a system programming language. I have yet to come to a conclusion on the merits of Rust, but this claim about system programming always ticks me off.

epage 5y ago
First, I feel that is a bit of gate keeping. I've done a lot of systems work where Rust today would have been perfectly fine. We originally tried to track memory allocation errors but we gave up because we didn't test allocation failures and likely had large gaps in it and just found it wasn't worth the code bloat. We still checked for allocation failures for data transfer buffers but thats it. Second, Rust doesn't stop you from handling memory allocation errors. The standard library might fully support failable allocations but that doesn't stop you from using your own collections for that type of work. Third, this has been an item of interest for a long time in the Rust community and is actively being worked on as part of introducing Rust into Linux.
- ncmncm 5y ago
  It does not take much sophistication to end up with multiple allocation arenas, any one of which might be exhausted without indicating general system failure. Being ill-equipped to use or recover from allocation failures in such arenas bodes poorly for a systems language.
  - johncolanduoni 5y ago
    If you’re allocating from multiple arenas, you’re not going to be using `new` in C++ or `Box` in Rust. Nothing stops you from writing an arena allocator that can return an error code in Rust any more than C++ does.
    - ncmncm 5y ago
      Hint: nobody uses "new" in C++ anymore. All the C++ containers, and make_unique etc. know how to use local arenas. I gather there has been some effort to get Rust library components aware of such things. Handling exhaustion in them is an interesting research topic.

synergy20 5y ago

Since life is short and time is not unlimited and I'm not a talent programmer, I have decided to stick with c/c++ plus some python/golang/javascript/sql for my software career all the way until it ends. Those are already more than enough for me to handle in fact. best luck to rust programmers, it's just too much for me and too late for me. I do use quite a few nice rust utilities(fd,rg,etc) daily.

kitkat_new 5y ago
if c/c++ really includes having good C++ knowledge then Rust will be kindergarten, promise

ferdowsi 5y ago

A previous workplace experimented with Rust for internal services and the feedback was almost uniformly negative. Commonly cited reasons were the long compile times, limited standard library, and generally unstable best practices. One interesting quote was "why are you forcing me to waste a bunch of time doing needless bookkeeping when I create and pass around a string?" The blog post about "Why strings seem hard in Rust" was not met with excited reactions.

spekcular 5y ago
What language did the workplace decide to use instead?
ostenning 5y ago
Internal services? What problem were you trying to solve with Rust exactly? Personally I wouldn't be writing web services with Rust, I don't think the language was really designed with that problem set in mind.
- jrib 5y ago
  Which problem sets would you say rust excels at?
  - zarzavat 5y ago
    As a replacement for C or C++ (except 3D games where the choice of language is dictated by the engine). Kernels, databases, CLI programs, toasters, native code Python modules, etc. As a replacement for Go if you want a comprehensive type system instead of a skinny one.
    - FpUser 5y ago
      I use C++ for backend business servers and web services in particular with stellar results performance wise. Modern C++ along with the STL and loads of 3rd party libs makes rapid development of servers piece of cake.

smasher164 5y ago

My heuristic nowadays is if the workload is I/O bound, use Go. Otherwise, use Rust.

EugeneOZ 5y ago

The first “point” made me read the whole article skeptical. 1) Rust is a “general-purpose programming language”, not “system programming language”. 2) Performance is not even the most important reason. Syntax, features, guarantees - much more important.

deleted 5y ago

[deleted]

tayo42 5y ago

I wish there was more stuff like this out there about rust, something, anything to counter what feels like blind optimism and fanboy-ism for the language. For me its hard to get a good sense of the language being worth it. People really do hype it up, but i do know there are valid criticisms out there. IDK if they're all blog writers. My own recent experience trying to write a server kind of left me unsure about how practical using the language is after being pretty excited about it. I think the author wrote off "dependencies" to quickly. I'm kind of unsure about the state of dependencies. A lot of libraries seem to be peoples hobby/free time projects. I ran into strange comments in libraries where people don't actually seem to understand the domain they're writing the library in. Like I think all of the http frameworks are pet projects? My feeling after using rust and async was that it kind of tricks you into writing sub optimal code often. Like what could be solved with a singleton ends up needing a lot of boilerplate, new data structures, complex code so you end up writing in some other way, or burning your self with mutex.(aside note, everybody recommending a faster mutex that's not in the stdlibrary seems odd). I also dont know why npm and node get so much shit for needing so many libraries but rust and cargo get a pass for these small libraries everywhere.

choeger 5y ago
The state of the ecosystem is concerning, but natural. It always takes some time until the best/standard libraries become visible amongst the noise. Lastly, I was looking for Parser combinators and the first three hits and no commits for years. That's definitely a red flag for me.
adamnemecek 5y ago
What did you get stuck on? > I also dont know why npm and node get so much shit for needing so many libraries but rust and cargo get a pass for these small libraries everywhere. Because cargo is a better package manager in every aspect.
- zozbot234 5y ago
  Because Rust is a `cargo` cult. /s

WalterBright 5y ago

The trouble with "why not" questions is it implicitly omits the reasons why.

CraigJPerry 5y ago

In my limited experience the compile speed issues are often overblown. The biggest rust project i compile regularly is deno. It doesn’t feel that slow. Cargo is great but it’s not continued to evolve fast enough. For example, there’s not enough defence against supply chain attacks yet. >> Rust’s price for improved control is the curse of choice The annoying unstated side effect of this is that on average, developers will choose the easiest option. E.g. quite a few blogs and tutorials wastefully use clone because it’s easier than wrangling with lifetimes (which admittedly have an developer-unfriendly habit of being quite virulent through your code) - or whatever other approach you fancy to avoid pointless copying. They do it just to get around the borrow checker. You don’t need to be processing that many strings with this approach before Python’s (lack of) speed is giving you a run for your money.

nsonha 5y ago

I'm glad to see this article, every week I roll eyes at people on HN claiming that rust targeting wasm will replace javascript. I'm not against replacing js, it just won't be a language that's made on the complete opposite side on the spectrum of PLs.

jamil7 5y ago
Or appearing in every other language discussion to bring up Rust.

johnisgood 5y ago

> Ada is memory safe if you don’t use dynamic memory (never call free). Take a look at https://docs.adacore.com/live/wave/spark2014/html/spark2014_ug/en/source/access.html#deallocation https://docs.adacore.com/live/wave/spark2014/html/spark2014_.... You can prove the absence of memory leaks, too. :)

pitaj 5y ago
Leaks are permitted in rust, and are not a memory safety concern. I don't think that's what he was talking about.
- johnisgood 5y ago
  I just added that as an extra. The point is that you can have memory safety even if you do free. It may not have been the case with Ada (without SPARK) in the past.
  - johnisgood 5y ago
    I would also like to add these: > Values of such an access type can be deallocated safely. GNATprove generates verification conditions to ensure that no memory can be leaked. So... you can deallocate safely AND verify that no memory is leaked. Is it not wonderful? - https://docs.adacore.com/live/wave/spark2014/html/spark2014_ug/en/source/access.html#pointer-support-and-dynamic-memory-management https://docs.adacore.com/live/wave/spark2014/html/spark2014_... - https://docs.adacore.com/live/wave/spark2014/html/spark2014_ug/en/usage_scenarios.html#prove-absence-of-run-time-errors-aorte https://docs.adacore.com/live/wave/spark2014/html/spark2014_... > SPARK builds on the strengths of Ada to provide even more guarantees statically rather than dynamically. As summarized in the following table, Ada provides strict syntax and strong typing at compile time plus dynamic checking of run-time errors and program contracts. SPARK allows such checking to be performed statically. In addition, it enforces the use of a safer language subset and detects data flow errors statically.

ComputerGuru 5y ago

This is why I don’t understand why people insist on creating web frameworks in rust. It’s one thing to write a proxy server or load balancer in rust, it’s another thing to write your actual CRUD app in rust. And the community has bent over backwards to support this use case and expended enormous resources to that end. I write embedded firmware, replacements for GNU coreutils, system services, and more in rust and I love it. But I write my web apps in C# and I wouldn’t change that.

cmrdporcupine 5y ago
Fair enough, and I think I mostly agree. But it's worth pointing out that large amounts of the web facing services from FAANG companies that we all use daily ... are written in C++. They could just as easily be done in Rust.
- valenterry 5y ago
  For these things, languages with gc should really be used.
valenterry 5y ago
I agree. Rust is not the right language for this, unless performance is the #1 concern (but mostly it is not). I'm looking forward to have something like Linux written in Rust though.
Jnr 5y ago
If people want to write things in Rust, let them write things in Rust. Hanging out at community Discord I see that there are a lot of new guys, students. They just want to experiment, and I am all for it. Yes, maybe it's not the most efficient thing from "business perspective", but maybe, eventually something new and exciting will come out of it. Programming is evolving, we had a lot of the same functionality available in older languages, using older paradigms, but eventually those stay in the past for a reason. I'm staying open minded and I am excited for the future.

cletus 5y ago

I'm in the camp that is long-term bullish on Rust. Memory safety is simply too important. I also consider C++ an unsalvageable mess at this point. Just a couple of thoughts reading this. > Compile Times This is (IMHO) the biggest problem with Rust as the article mentions. Apparently, this was due to some early unfortunate design decisions that resulted from the tight coupling with early Rust and Servo. Rust at this point is heavily tied to LLVM (I'm aware there's a gcc version in the works). If you don't know, the general structure is LLVM is to have a frontend and a backend. The frontend translates whatever your language is into LLVM-IR (intermediate representation), a sort of abstract assembly language. This isn't tied to any particular architecture (eg IIRC there are infinite registers in LLVM-IR). The backend translates that to a particular architecture. This is good because it's easier to get a compiler off the ground but gcc's performance is still second-to-none. Rust expands macros and the likes by producing a godawful amount of LLVM-IR and lets the backend strip out what's not needed. This works but impacts compile times. More details here [1]. > Complexity Yes and no. It's a bit like how dynamic programming languages originally rose to prominence because of the speed you could do things, or at least that was the argument. Static typing was seen as getting in the way or being too complex. I've come to the conclusion that this is a false economy. The best way I can put it is in Python you end up writing unit tests for spelling mistakes. The hierarchy of programming errors is IDE errors are better than compiler errors which are better than runtime errors. In an ideal world there's no difference between IDE errors and compiler errors but almost always there is. So Rust is actually forcing you to move runtime multithreaded issues into being compiler errors. This feels like more work (because it is) but it is infinitely preferable. Opponents will say, for example, that C++ has smart pointers to denote ownership. This is true but they have a runtime cost. Rust doesn't. And the effect of a runtime error in C++ is typically a core dump or just weirdly inconsistent behaviour (which is often worse). People routinely underestimate just how complex multithreaded code really is, particularly when they try and write lock-free abstractions (as is popular in C++) especially given the complexity of how processors actually work (eg out-of-order execution, branch prediction). There are various tools that are written to identify some of these issues (eg valgrind, asan, tsan, etc). While I was at Google I remember reading about how a bug had been found in an in-house written lock-free abstraction with some new tool that had been >7 years in production. But yet, even on HN, I too often hear "what's so hard about just putting a mutex on it". [1]: https://pingcap.com/blog/rust-compilation-model-calamity https://pingcap.com/blog/rust-compilation-model-calamity

skwirl 5y ago

I am very nervous about Rust. My team recently started on a Rust project because we had a need to build something that would compile to WebAssembly. Without getting into too much detail, the WebAssembly runtimes for memory managed languages wouldn't work for what we're doing. We are not a company that does a lot with C/C++ and those of us who have used C/C++ do not particularly enjoy it, so we decided to go with Rust. I do like Rust and it has worked well for this particular project. The problem, though, is that now there's a Rust mania that has set in and a desire to write/rewrite lots of stuff with Rust. Based on what I've seen out there on the web, this seems like a common thing. While Rust offered a clear benefit to us for the WebAssembly work, for every other case the benefits of Rust are mostly absent or minimal but the drawbacks around losing a garbage collector, losing a large healthy package ecosystem, losing use of our existing internal libraries and tooling, etc. loom large. So I am in an unhappy position where I keep telling enthusiastic Rust advocates no. Another interesting thing is that people tell their friends that we are using Rust and now they want to apply to work for us. We have a hard time recruiting and there's part of me that wonders if we'd just be flooded with applicants if we started advertising Rust jobs. This is somewhat tempting - we might be able to easily hire teams of enthusiasts to churn out Rust but for how long? How long will it have this magic aura and following? I certainly don't want to be left with tons of crappy Rust code in a few years that nobody wants to maintain. I feel like HN has mostly been very enthusiastic about Rust. A thread critical of Rust is rare and I feel like it is refreshing.

pingsl 5y ago
I have the same opinion. The best thing about rust is that rust attracts more people to learn systems programming languages. And thus, there will be more system programmers. Nowadays, young people favor application programming far more than system programming. But the problem is there are not that many system programming opportunities. Then they decided to rewrite the existing systems with rust. We can find a lot of these examples on GitHub. Who knows if it is just a moment of enthusiasm, and how long will it last?
- jmatthews 5y ago
  As someone who mostly enjoys cpp, for me the math just didn't seem worth it to really get fluent in rust. I agree there are less system jobs than app jobs kind of prima facie, but there's not exactly a lack of systems jobs for cpp programmers at the moment.

ajxs 5y ago

> Rust is a systems programming language. It offers precise control over data layout and runtime behavior of the code... It really doesn't. It doesn't even have native support for bitfields. When I tried doing low-level programming in Rust, this immediately struck me. Rust's semantics don't really offer much of an improvement over what already existed in this area. In addition to presenting all kinds of new, frustrating challenges. I've used Ada extensively in this area, and I just don't see what Rust has to offer that Ada didn't already address. I'm all too aware that string operations in low-level programming languages are always going to be prickly. Ada's standard library, even in its 80s incarnations, is light-years ahead of Rust in this area. Interoperability with other languages is another area where Ada beats Rust hands-down. The first thing I tried to do was integrate C and Rust, and realised immediately that it was a nightmare. In Ada, it really couldn't be simpler.

zozbot234 5y ago
> It really doesn't. It doesn't even have native support for bitfields. Many people would consider C bitfields half-baked in the first place, given that the feature is well-known to be underspecified in a way that leads to compatibility/portability concerns. Is this really the kind of stuff that Rust should concern itself with?
- pitaj 5y ago
  Yeah I agree with rust's decision to not go there yet. They're only really used often in very low-level niches like mmio registers, where autogenerating handlers with svd2rust works great and provides a little bit of safety along with it. This is coming from someone who uses C bitfields every day on an embedded MCU.
  - ajxs 5y ago
    > They're only really used often in very low-level niches like mmio registers ... which are actually an incredibly common, totally everyday problem encountered by tens of thousands of developers everyday? > autogenerating handlers with svd2rust works great and provides a little bit of safety along with it. I don't think that requiring third-party tooling to implement something so basic is a suitable solution to this problem. What if the manufacturer of the device I'm working with hasn't released an SVD file? What if I'm not actually working on an MCU at all, but a peripheral driver?

pitaj 5y ago

(2020)

deleted 5y ago

[deleted]

deleted 5y ago

[deleted]

scythe 5y ago

>However, in many (most) cases, one doesn’t need ultimate performance or control over hardware resources. For these situations, modern managed languages like Kotlin or Go offer decent speed, I feel like D really deserves to be mentioned more often when talking about Rust alternatives. It's sort of the anti-Rust: improving on C++ by focusing on ergonomics rather than raw efficiency. It's likely more familiar to the C++ native than Kotlin and Go, and more directly comparable to Rust in that it has an expressive type system, compiles to native code, and interfacing well with C. I would say D is the best answer on average to the question "I like all those things Rust can do but I find it annoying to work with, what can I use instead?" whereas Kotlin or Go will not always be a great stand-in.

pjmlp 5y ago
The community is great, but D itself kind of suffers from lack of direction where they want to be, every couple of years there is this next big that is going to bring people into the community, none of them fully done to completion ironing all bugs out. So it remains a very nice language, but you need to be willing to get hands dirty fixing bugs and contributing back, if you feel going into production with it. All D success stories had their of fork of the D toolchain, or standard library, to certain extent.
- mhh__ 5y ago
  If you consider Symmetry investments a D success story, we do not do that - we do have a fork of LDC but I've never needed to use it, as far as I'm aware it's just an early release in effect, no new features.
  - pjmlp 5y ago
    Good to know, although the point was not about new features, more like bug fixes and the alternative runtime as Sociomantic used to have. More than a sucess story, I consider Symmetry the very last hope to keep D relevant actually.

code_biologist 5y ago

The linked presentation deck "High Performance Managed Languages" is great! Deck PDF: https://qconlondon.com/london-2017/system/files/presentation-slides/highperformancemanagedlanguages.pdf https://qconlondon.com/london-2017/system/files/presentation... Video: https://www.youtube.com/watch?v=Pz-4co8IaI8 https://www.youtube.com/watch?v=Pz-4co8IaI8

dang 5y ago

Discussed at the time: Why Not Rust? - https://news.ycombinator.com/item?id=24536645 https://news.ycombinator.com/item?id=24536645 - Sept 2020 (319 comments)

pse_pan2233 5y ago

I'm someone who likes to write Rust and wants to use it all the time, but for my professional work I only choose it when I really need it, which is very seldom - actually it was only once for a CAD data converter where memory usage must be as low as possible. The reasons not to use it always for everything are: 1. The mental overhead is larger than most want to admit. It's not about the syntax, but about memory management of course. The time and effort spend there should be spend to solve the problem at hand. 2. Depending on a lot of third party libraries which are maintained by just 1 person.

jeff-davis 5y ago

The main reason I don't complain about rust is because complaints feel like a way to pressure developers to address my specific wish list, which feels wrong. But, this thread feels like an opportunity, so here goes: 1. It lacks a good way to control memory in different ways for different data structures. The allocator_api is still experimental. This feels strange for a systems language. 2. It's a complex language. There's no way around that. The developers have done a great job avoiding unnecessary complexity, but the benefits rust offers do have a complexity cost and you should really evaluate whether rust enables you to make up for it with simplicity elsewhere in the stack. 3. The sync/async situation feels like a division to me. Maybe that's inherent and not rust's fault, but it does feel like some kind of a divide. For instance, if you want a postgres driver, rust-postgres is great, but it follows the async approach and that means zillions of dependencies and long fresh-compile times. If it used a synchronous style, it would only depend on the standard library, and compilation would be very fast. Should there be two libraries? I don't really know. 4. There's not a good supported way to build "plugin" style shared libraries where you can refer to symbols that exist in the program that loads the library. You can hack the build flags in, but none of the testing infrastructure works. 5. While C integration is great, there's not a good way to catch a longjmp() from C without some undefined behavior. 6. The culture of rust seems to favor dependencies a bit too much. The decision to take a dependency is an important one with trade-offs, and the rust culture seems to be always to take a dependency, even if doing it yourself would be little code, and the dependency transitively includes a ton of code that seems to churn a lot. This plays to rusts strengths around tooling, but goes to far in my opinion. But after all of that, there's still one huge reason to pay attention to rust: if you are a systems programmer, there aren't a lot of options for most projects, so having a new option is a big deal. In many cases, the practical options go from "C/C++" to "C/C++/Rust".

EugeneOZ 5y ago
This is a much better level! I think you really should write an article about that. Criticism like this is no pressure, I think - it's an essential part of discussions and the evolution of language.

davidkunz 5y ago

I really want to love Rust. The resulting programs written in it are fast, memory efficient and safe. Something which usually isn't the case in other programming languages. But here and there I see how simple problems require complicated solutions, for example when you want to create a logger middleware for a web service: https://youtu.be/16sU1q8OeeI https://youtu.be/16sU1q8OeeI Something I could have written in 3 lines of JavaScript. In Rust, it requires knowledge of poll, pin, boxpin, ... and even third-party crates (if you yourself are not enough of a magician). I'm not sure if Rustaceans are okay with that additional complexity, but it really scares me off to dig deeper into that language. I would appreciate if some experienced Rust programmers could comment!

matesz 5y ago

Interesting note - when it comes to compile times, the most optimized Rust codebase in that aspect I believe is makepad.dev [1]. It is compiling from scratch on mac m1 in around 7.5s [2] and that's +100k lines of Rust. However there is close to none dependencies, so this +100k is all there is to compile pretty much. Still, this is impressive feat! [1] https://makepad.dev/ https://makepad.dev/ [2] https://twitter.com/rikarends/status/1467529091284934666 https://twitter.com/rikarends/status/1467529091284934666

Klasiaster 5y ago

> modern managed languages like Kotlin or Go offer decent speed, enviable time to performance, and are memory safe by virtue of using a garbage collector for dynamic memory management Take this with a grain of salt: Go data races can still lead to memory corruption and security vulnerabilities (no one uses the inbuilt data race detector in production, few use it while testing).

viktorcode 5y ago

> Rust is a systems programming language. It offers precise control over data layout and runtime behavior of the code, granting you maximal performance and flexibility. I'm nitpicking, but it's due to considering the difference important for some unsuspecting programmers: having control over data layout and runtime behaviour doesn't grant you maximal performance. It grants you capability for achieving minimal overhead, which is connected to, but a different thing from performance.

kaba0 5y ago
Thanks, it’s a really great way to put it!

ithkuil 5y ago

> But, for example, some runtime-related tools (most notably, heap profiling) are just absent — it’s hard to reflect on the runtime of the program if there’s no runtime! Yeah; I felt that pain too. I tried to write something to address some parts of the missing space. It's still in the early stages but you may be interested: https://github.com/mkmik/heappy https://github.com/mkmik/heappy

sally1620 5y ago

The most important argument is that not all programming is systems programming. A lot of projects choose C, C++ or Rust only because they need performance: * Backend services * Numerical computation * Game development * Rendering engines, e.g., browser engines System programming is usually needed for what we consider Operating Systems, e.g. kernel, system libraries, and shell. In my career as a C++ programmer I have worked on a lot of projects that I would otherwise write in C#, Java, Julia, or Go.

singularity2001 5y ago

One of the main benefits of Rust, memory safety, becomes much less significant when compiling to the wasm sandbox. Thus in this setting I prefer to use modern C++ over the (at times horrible) verbosity of Rust.

kaba0 5y ago
Catching those at compile time is still much better than some obscure runtime bug. If the latter would be enough, valgrind would suffice for testing c/c++ programs, but you can’t really execute every code path all the times.