9 ms·

I Hope Rust Does Not Oxidize Everything

99 points by gavinhoward 2y ago

bpbp-mango 2y ago
What does Yao look like? edit ah I found some examples https://rigbuild.dev/yao-tutorial/ https://rigbuild.dev/yao-tutorial/
- gavinhoward 2y ago
  You can also look at the example file. [1]: https://git.yzena.com/Yzena/Yc/src/branch/master/src/yao/example.y https://git.yzena.com/Yzena/Yc/src/branch/master/src/yao/exa...
noelwelsh 2y ago
Rust is certainly not the last word in systems programming languages, but it's an huge leap forward from C and C++. To be honest, it's a sad reflection of our industry that it's taken this long to get basic safety + ML circa 1975 language features into this niche. If things had turned out a little bit different we could all have been using OCaml for the past few decades.
- fire_lake 2y ago
  People reject OCaml for these use cases due to the GC, but I wonder if this actually matters in practice. The optimizations that can be applied to ML languages (see MLTon for example) are very advanced and the ability to do multi core with ease (I know this is more recent to OCaml) can be a big performance unlock that is very hard to get right in C.
  - pornel 2y ago
    GC is perfectly fine for ~99% of applications, which is why all the languages in the last few decades adopted it, and eliminated themselves from being direct C/C++ competitors. Lack of GC isn't a requirement for most programs. However, it is a requirement for a language meant to actually replace C and C++, because these two are mostly used in the remaining fraction of programs and libraries where any GC or any fat runtime is undesirable. Even where some GC could be made to work, it makes it a tough sell for C/C++ users.
  - dgrunwald 2y ago
    The GC does matter. Most applications are completely fine with having a garbage collector, but they are not fine with having multiple garbage collectors! Mixing multiple garbage collected languages is a recipe for complex bugs. At a minimum, reference cycles across the languages will result in memory leaks. Thus every garbage collected language tends to grow its own ecosystem of libraries, with the whole world having to be re-implemented in that language. The only exception are the C/C++/Rust libraries, as these can be used (through C FFI interface) by almost every other language. This is precisely because these languages do not introduce their own heavy-weight runtime (especially: no GC), allowing them to be combined with another language's runtime. Thus widely used libraries must be written in one of the non-GC languages, even if 100% of the applications using them are fine with having a garage collector.
    - bryanlarsen 2y ago
      I see this same situation playing out with async executors. tokio is taking over, but it doesn't play well with other async executors. I just wrote a program that mixed tokio & glib and it wasn't fun. This does feel like a soluble problem, so I hope they do figure it out. I think the first step might be something like without.boats' proposal to add something like https://github.com/zesterer/pollster https://github.com/zesterer/pollster to the standard library to establish a minimum common denominator.
- begueradj 2y ago
  > it's a sad reflection of our industry that it's taken this long to get basic safety + ML circa 1975 language features into this niche. That's true. Could it be that's because we are expert at nitpicking every programming language, every framework and stack which appears to the point it takes time to make steps forward ? Some sort of paralysis, insecurity and confusion ?
- jltsiren 2y ago
  My favorite hypothesis here is that programming language enthusiasts are too different. They are incapable of convincing the average programmer of the merits of their favorite language, because their way of thinking is different. Arguments they find convincing are not convincing to the average programmer. Progress happens incrementally with small steps. Existing languages get new features. New languages get popular, because they look familiar but contain some small meaningful improvements. And familiarity is important. Languages like OCaml never become popular, because they are too different. Even the syntax looks unfamiliar.
  - DEADMINCEDOS 2y ago
    I think you're right. The same way people have strong preference for Systemd, MacOS, KDE, Gnome, I3, Nix, Debian, Gentoo, Arch, etc. So many different solutions. Most are preferred because of subjective reasons (although sometimes just poor reasoning period), because people think so drastically differently.
  - throwawaymaths 2y ago
    > Existing languages get new features That's how you wind up with C++
    - jltsiren 2y ago
      Or English. A lot of people used to advocate for using their favorite ancient / artificial languages in international contexts and for communicating important matters. But somehow the C++ of natural languages became dominant.
  - falcolas 2y ago
    > Arguments they find convincing are not convincing to the average programmer I think one problem is believing there exists an "average programmer". It's easy to think in averages (or medians), but the reality is that there is no average person, and exactly one median person. Realizing that every single person is different is important, because you then start to work in more discrete niches. It's going to be much easier to appeal to "programmers who write X in Y with the following constraints" than it will ever be "programmers who write in Y". Or to bring this closer to the topic of discussion, you'll never convince game developers to drop C++ in favor of rust using the same arguments as you'd use to convince a service developer to drop C++ for rust.
- fxtentacle 2y ago
  Sadly, Rust is only a "huge leap forward from C and C++" for some use-cases. Simple things like returning a const reference to a slot in an immutable array are easily 10x the amount of source code in Rust when compared to C. And all the standard libraries for embedded systems are C, so to get into embedded development, you definitely need to be good at reading C code. Rust is an additional skill, but if you only know Rust and no C, you're of no use in embedded land. I think that's the main reason why we don't move away from C: You still need a firm grasp of C if you want to be a capable higher-level developer. C++ is then the logical upgrade because it's compatible with C and looks very similar. Java also did OK because it looks and feels very similar. And there's good automated C to Java converters. So you get the benefits of Java over C almost for free. Rust, on the other hand, throws away most of the C conventions and that makes it feel foreign and "incompatible". Rust also suffers from a serious "not invented here" problem, in my opinion. It's super easy to re-use C code in C++ or Java. It's significantly more difficult to re-use C in Rust unless you go unsafe and abandon most of the Rust advantages. That means most dependencies need to be re-implemented in Rust if you want to have all the advantages that Rust offers. Go had the same problem, but they had Google's weight behind them to push out tons of libraries. Who is doing that for Rust? In the end, I agree with the article: Rust is great! when it fits. But there are still plenty of situations left where Rust is worse than old-school C.
  - goku12 2y ago
    > Rust also suffers from a serious "not invented here" problem, in my opinion. It's super easy to re-use C code in C++ or Java. It's significantly more difficult to re-use C in Rust ... It feels like a mischaracterization of Rust and I strongly disagree. Both the language and tooling are designed from the beginning for interop with C code. It isn't very hard to do if you have tried it. > ... unless you go unsafe and abandon most of the Rust advantages. That means most dependencies need to be re-implemented in Rust if you want to have all the advantages that Rust offers. This 'Rust is useless if you use unsafe' is a stance that is well debunked, but still gets repeated like this. Ensuring safety using Rust semantics across an FFI with a language like C is impossible - making unsafe necessary. But just because you use unsafe doesn't mean that the language lost most of its advantages. In fact, almost every Rust program uses unsafe code, if you care to look at the code in the standard library. Yet, that never seems to be a problem. What unsafe does is to cordon off a small code area where certain invariants have to be asserted manually, instead of relying on the borrow checker. You still get the safety for the rest of the code. In case you do get safety violations, there is much less code to debug. This is a significant advantage over languages like C++, considering that unsafe blocks are usually less than 5% of the code, even in the worst case. But to take it further, C libraries often have corresponding Rust wrapper libraries that create safe wrappers over C FFI calls. In addition to the small unsafe blocks to verify manually, these wrappers have the additional advantage of being widely used and debugged by a wider community. There are innumerable such wrappers on crates.io and it's uncharitable to accuse the language of NIH syndrome.
WhereIsTheTruth 2y ago
Projects adopting rust makes contributing less fun and more painful I tried to work on bug fix for Zed, waiting 30 seconds everytime you change a value was _very_ painful
- Klonoar 2y ago
  I feel like you could stand to qualify "fun" more here. I don't share your experience - I'll take a Rust project any day - but I'm curious to know what you feel is missing. (Outside of compile times, which are a well known point)
- amenghra 2y ago
  There’s no reason you couldn’t have a rust jit for development then compile the code for production (or stick with a jit for prod too).
  - h4x0rr 2y ago
    Honestly it would probably be even faster than unoptimized aot compolation
    - amenghra 2y ago
      Some developers need/are used to a fast edit-compile-run loop. The JIT doesn't even need to be optimized, just good enough to improve the developer experience.
  - nindalf 2y ago
    There's no reason? Are you sure about this? I think you mean there could theoretically be an interpreted Rust, but I don't think anyone has ever made a prototype of a Rust interpreter. The closest is probably rust-analyzer (the official language server), that maintains internal state and reacts to changes you make, but it doesn't create an executable artifact. The other is probably the Cranelift Backend (https://github.com/rust-lang/rustc_codegen_cranelift https://github.com/rust-lang/rustc_codegen_cranelift), which can produce debug builds quickly.
usrnm 2y ago
Within Rust is a smaller, simpler, safer language struggling to get out
- consp 2y ago
  Readable would be a nice benefit.
  - Guthur 2y ago
    This, I don't understand why we have to load these languages up with so much syntax, it's mind boggling to think that some how we feel it's beneficial to have so much. I'm admittedly biased to the symbolic expression but surely we could have come up with some middle ground.
    - Ygg2 2y ago
      Two things: - It was made to be approachable for C++ experts - The idea was that language could be effortlessly greppable.
      - Ragnarork 2y ago
        Coming from C++, and I would have loved Rust to not pick up C++-y things to make it look like it...
      - Guthur 2y ago
        So legacy baggage from the get go. This is what I'm lamenting, it's objectively a syntax soup.
  - v9v 2y ago
    Not sure about smaller or simpler, but Ada is definitely more readable in my opinion.
- rapsey 2y ago
  Without a GC? No there is not. You are welcome to try of course, but unless you have a PhD in type theory I doubt your chances.
deleted 2y ago
[deleted]
oDot 2y ago
This is my current mental model for picking a language, considering just the language itself: - Backends: Gleam or other BEAM - Web frontend: Gleam - Mobile apps: Dart + Flutter - Specialized mobile apps: Swift and Kotlin - Blazing fast: Zig - Blazing fast and safest: Rust - Fast performance and iteration: Go Would love to hear additions and corrections. My only problem with this is I'm not a fan of Go's syntax and I wonder what's a good alternative. Heared good things about OCaml but didn't check it out yet.
- styluss 2y ago
  Nim fits a lot of Go's use cases. It is way more niche though.
- fire_lake 2y ago
  OCaml could almost replace all of those. I don’t think there is a BEAM compiler backend yet. I’m not very experienced with BEAM, but could its features be delivered with a framework on top of a different stack? I know Akka is popular.
  - deathtrader666 2y ago
    >>> don’t think there is a BEAM compiler backend yet I think there's something close - https://caramel.run/manual/ https://caramel.run/manual/
    - cassepipe 2y ago
      The project has been abandonned : https://github.com/leostera/caramel/discussions/102 https://github.com/leostera/caramel/discussions/102
  - ubercore 2y ago
    GC precludes OCaml from replacing a chunk of those.
  - fredrikholm 2y ago
    Actor model is a small component of the BEAM. Even then, it guarantees yields to the scheduler. This is practically impossible to retrofit on to an existing language, esp. in the presence of loops.
Jyaif 2y ago
I mostly agree. Compile times are the worst in the industry, and async is a mess.
olalonde 2y ago
Maybe that will sound banal to some but C would be so much more enjoyable to me if it had a "cargo" system and no implicit imports.
- rational_indian 2y ago
  That's the problem with C. It cannot have a sane cargo like system. The language is not built for writing libraries. There is a reason why everyone keeps reinventing the wheel when it comes to datastructures in C. Where is STL for C?
  - Ragnarork 2y ago
    The closest is GLib and it's absolutely not fun to work with.
  - simon_void 2y ago
    you could use the Zig build system as your C build system. See https://zig.news/kristoff/make-zig-your-c-c-build-system-28g5 https://zig.news/kristoff/make-zig-your-c-c-build-system-28g...
    - rational_indian 2y ago
      Cargo is just half the story. The other half is rust itself. It is an excellent language for writing abstractions.
- dragonelite 2y ago
  That's why i like zig it has at least the very basic with build.zig for build script. You have build.zig.zon for build.zig dependencies.
davidhyde 2y ago
My personal take on this subject is that Rust turns experts back into beginners and some devs react with hatred because of the fear this induces. For me it was the opposite. I was getting bored with my industry and thinking of a move to something else like management. Rust came along 6 yeas ago (for me) and threw me a lifeline. I love getting good at something that is hard, it’s just very satisfying. I do get why some people can’t stand the language. It is ugly to look at with its genetics and lifetime annotations and when a project is so large that it begins to lag rust-analyser then my joy turns to rage too.
- DEADMINCEDOS 2y ago
  > My personal take on this subject is that Rust turns experts back into beginners and some devs react with hatred because of the fear this induces. Those people are probably poor devs. Anyone who doesn't have the attitude and mindset to continue learning in something like software development which keeps advancing isn't cut out for that field.
  - deleted 2y ago
    [deleted]
  - anonymoushn 2y ago
    Maybe it wouldn't be reasonable to say this about people who dislike programming in Malbolge, and maybe there are aspects of Rust that are more like programming in Malbolge and less like the field advancing.
- Const-me 2y ago
  You could have spend that time learning something which is actually useful and helps finding interesting jobs. For example, GPU programming or SIMD intrinsics. What annoys me about rust is the complexity just for the sake of it, lots of pain for minimal gain compared to alternatives. If you need async/await you'll do better in modern .NET despite the GC, if you need the highest CPU performance you'll do better in C++ despite the unsafety.
  - 2y ago
dgb23 2y ago
The post is a bit of a rant and all over the place. Async infecting everything, ugly syntax (who cares?), slow compile times etc. What stood out to me: > In other words, if compilation is fast, the tooling is easy. Andrew Kelley said something similar in a recent talk. Compiler performance seems to be the number one priority at the moment for Zig. The rationale seems to be: fast compilation leads to more productivity, which leads to more bugfixes. This claim seems almost bruteish, but it makes sense. Tight feedback loops (think things like devops, REPL, TDD, light processes etc.) can help us to iterate more and stay in the zone. To be fair a sophisticated type checker like Rust‘s also helps with that. But of course any added friction and sluggishness can be an indirect hindrance to the overall correctness and even performance of a program.
- Timshel 2y ago
  Fast compilation is nice and I believe stuff like incremental compilation are essential. But at the end of the day I'll prefer slower compilation every time if it means advanced checking. And speaking of the zone I prefer writing Scala code for like 1h while fixing compiler errors and then you run and it just works TM vs Java where you'll waste your time tracking NPE ...
  - dgb23 2y ago
    > But at the end of the day I'll prefer slower compilation every time if it means advanced checking. I don't think that's a large issue in Rust. Type checking is quite fast in comparison to code generation. Generics, traits, macros etc. seem to be the culprit. Turning complex language features into code and not runtime safety lead to these slow compile times.
- JodieBenitez 2y ago
  > ugly syntax (who cares?) I'm a nobody of course, but I do. Ugly is subjective, and by "ugly" a lot of people probably think "alien", as not what they are used to. Less syntax cruft is good for cognitive load and more common syntax is good for adoption. But I'm sure the problem fades away with practice.
- 2y ago
ceronman 2y ago
The author seems very anxious because Rust is getting traction and they don't like Rust. They're afraid that one day Rust will become a "monoculture" and everything will be written in it. I like Rust, but I consider this very, very unlikely. Rust has actually brought more choice to the programming language scenario. If we're talking about monoculture, let's talk about C/C++. For decades this was the only viable option for systems programming. All new languages were focusing on a higher lever. Languages for lower level stuff were rare. There was D, but it never got enough traction. Then Rust appeared and there is finally an alternative. And not only that, I because of that, other language designers decided to create new systems languages, and now we have Zig, and Odin, and Vale, etc. So if anything, Rust is helping in breaking the monoculture, not creating it. C and C++ are not going away, but now we have alternatives. And I think it's important to acknowledge that even if you don't like a language, if you see a bunch of software being written in such language, it's because the language is useful. I don't like C++ but I admit it's damn useful! People are writing interesting software in Rust because they find it useful.
- ajross 2y ago
  FWIW it was LLVM that catalyzed the modern florescence of programming language innovation. Rust is just another result of that shift, not its cause.
  - deleted 2y ago
    [deleted]
- pjc50 2y ago
  Rust is challenging people because it declares several long-inadequate things about C/C++ to be inadequate (security issues, dependency management), and provides alternatives which show that it doesn't have to be like that. The rewrites will inevitably be long and painful. Rewrites always are. But the onus on anti-Rust people is now to demonstrate a better language to rewrite in first, rather than just sitting in the status quo waiting for the steamroller driven by a crab to very slowly run them over. D is interesting but seems to be a solo project, I'm not sure why it's not had traction. Maybe it's not different _enough_.
zkldi 2y ago
I'll bite: What specific parts of rust syntax do people find so ugly? I keep hearing this from decent chunks of people who don't write rust, but the language doesn't seem that far off C to me. It's certainly no haskell.
- GardenLetter27 2y ago
  Lifetime bounds on a trait object argument can be confusing. I have to look up how to write the where part properly every single time.
- Avamander 2y ago
  Fishtail, lifetime and closure syntaxes are rather ugly. Just specifically when combined in practice, not alone in isolated examples.
  - estebank 2y ago
    For what is worth, the turbo fish falls from the decision to use <> for generics (for familiarity for C++ and Java developers) and a desire to make the syntax non-ambiguous (side stepping the C++ problem of having to delay determining if something is a type path or a comparison, mixing parsing and name resolution).
- sebstefan 2y ago
  >I keep hearing this from decent chunks of people who don't write rust That's exactly the people you want to hear from if you're trying to improve adoption.
- K0nserv 2y ago
  The more interesting follow up question is: "How would you express the same semantics with a different syntax?" Too often discussions about Rust's ugly syntax lack this crucial component.
  - ReleaseCandidat 2y ago
    > How would you express the same semantics with a different syntax? This isn't the problem, the problem is "... and keep the syntax C++-like?".
K0nserv 2y ago
The author makes the best argument for Rust in the linked post[0] Rust is great for teams because it removes many things that make working on team code dangerous. The items mentioned above are some. I work alone, however, because I like to keep my code in my head and working with people means parts of the code are only in their head. This also means that the bigger the language is, the less space I have in my head for the code. Rust is too big for my small brain, unfortunately. Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down. Besides this I disagree with the author's assertion that Rust is not well suited for them, in fact I think it's strictly better than C because it often obviates the need to keep stuff in your head. Take lifetimes, in C you have to keep track of pointers and their lifetime in your head, and by definition all other maintainers have to do the same, in Rust the compiler does that for you, less to keep in your head. In fact I think the ability offload things from your head to the compiler is one of Rust's great strength. This ties in with compile times too, yes Rust is very slow to compile, but the compiler also does a whole lot more work than the C compiler. Obviously we want rustc to be as fast as possible given the work it's doing, but it will never be as fast as a C or Go compiler. 0: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...
- fxtentacle 2y ago
  "Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down." I strongly disagree! My experience is this: 1. Sole developer builds useful thing 2. Team takes over maintenance 3. Feature bloat, sluggishness, bugs ignored, Agile initiative, "Product owners" 4. Company goes bankrupt or gets acquired I don't think you can have the clarity of vision that a single person will produce if you're working on it with a big team. That's why so many useful things start with a single person or a very small team, like Linux, Android, curl, ffmpeg, Quake engine, the 2 ppl Firefox "Phoenix" team, the original 3 ppl JetBrains team, the 2 original Photoshop devs.
  - K0nserv 2y ago
    > That's why so many useful things start with a single person or *a very small team*, You subtly shifted the goal posts here. But even if you start out with a single person you eventually have to have new maintainers, if only because of human mortality. Software is a young field so we haven't had to contend much with this fact yet, but it's inevitable. Personally I think something like Rust is helpful for large solo programs too, keeping everything in your head past 10kCLOC is hard so why not have a language and compiler that helps you?
GardenLetter27 2y ago
The compile times are the only real issue mentioned here. I still think it's better than C++ but for large projects the compile times and crate splitting, etc. become a real pain.
sebstefan 2y ago
>the syntax. It’s ugly. [...] I would prefer something that is less sigil-heavy. That's also one of my gripes with Rust. Very sigil heavy makes it hard to google syntax elements. What's the name of the `|` glyph? Especially challenging if you know the name of the glyphs in your language but not in necessarily in english. Double challenging for glyphs with several accepted names But in the end, I'm big enough to realize that this is not a very important aspect of the language If it's ugly so be it. I'll still learn it Also for once Bing Copilot pretty much solved this for me since unlike google search, it's semantic + it doesn't ignore special characters
- SushiHippie 2y ago
  FYI Wikipedia has pages for every ascii character I think, if you just search for `|` in wikipedia it would redirect you to https://en.wikipedia.org/wiki/Vertical_bar https://en.wikipedia.org/wiki/Vertical_bar Which lists all the common names used for this symbol Here is also a table with all symbols with direct links to the wikipedia pages https://en.wikipedia.org/wiki/ASCII#Character_set https://en.wikipedia.org/wiki/ASCII#Character_set
- rascul 2y ago
  This might be useful https://doc.rust-lang.org/reference/tokens.html#punctuation https://doc.rust-lang.org/reference/tokens.html#punctuation
  - yencabulator 2y ago
    That doesn't seem to explain 'lifetimes or turbo::<Fish>, though.
    - steveklabnik 2y ago
      The page linked for :: explains the turbofish. That said, you're right that it could use a row for the lifetime syntax.
      - 2y ago
dtquad 2y ago
I have seen a lot of criticism of async Rust. In C# most APIs expose both sync and async versions of the same methods. Why is that not more common in Rust? Sure some 3rd party C# libraries probably do some ugly sync to async conversion internally but most don't and use the .NET standard libraries sync/async versions of the same APIs.
- pornel 2y ago
  Rust's async is in some places more difficult to use, because Rust is obsessed with avoiding allocations and dynamic dispatch. Languages like C# and JS allocate a new object for every Promise and every listener. Rust bends backwards to avoid that, and make inlined strongly typed state machines instead. It creates limitations where you wouldn't expect, e.g. recursive calls need special handling, and abstract interfaces don't fully support async. As for supporting both, it's just inconvenient to do, because many small syntactic and semantic differences mean it's hard to automate and cumbersome to maintain.
  - neonsunset 2y ago
    Not every await and new task produces an allocation in C#: ValueTask only allocates a state machine box if it yields asynchronously, plain task objects are pooled for common values and state machine box itself can also be pooled for frequently called methods (is opt-in), for example socket.SendAsync does not allocate thanks to this. This will change further as "Runtime Handled Tasks" implementation comes along which will replace Roslyn-generated explicit state-machine code with runtime-provided suspension mechanism which will only yield/suspend the execution at true yield points, with further improvements to how the captured state that needs to persist across them is stored.
dana321 2y ago
I'm hoping this rust fad goes away soon
weinzierl 2y ago
> First, the syntax. It’s ugly. TO MY EYES! Beauty is in the eye of the beholder, you can't please everyone and you should not exceed your weirdness budget[1]. The decision to please the C++ crowd so much (mainly manifested in later syntax related decisions) would not have been my preference, but it makes sense and there could have been worse decisions. > Second, Third, Fourth, Fifth I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community. > Sixth, Rust doesn’t go far enough in static analysis. Rust had a chance to go much further, and the team blew it. I am not qualified to judge that, but I am curious of other opinions. > Seventh, Rust compile times are a joke True, but this is actively tackled on multiple fronts. One is cranelift, which I find highly fascinating. [1] https://steveklabnik.com/writing/the-language-strangeness-budget https://steveklabnik.com/writing/the-language-strangeness-bu...
- anonymoushn 2y ago
  > I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community. No, this is a language design issue. In Lua or Zig the easy way to write a library that speaks websockets produces a library that works with synchronous or asynchronous i/o and with the user's choice of read and write primitives. In Rust, after many years of unnecessary suffering, we finally have the ability to ship one library that can use either kind of i/o.... unless the user wants to use both in the same workspace, in which case they are screwed. You may enjoy this tale of a user trying to get Rust to do what Lua and Zig do by default, for a single library: https://nullderef.com/blog/rust-async-sync/ https://nullderef.com/blog/rust-async-sync/
  - weinzierl 2y ago
    This is being worked on: https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...
mmaniac 2y ago
A lot of this author's complaints about Rust remind me of similar historical complaints about C++, but amplified. Hijacking and overtaking new projects? C++ and Rust both do that. C++'s compile times were a joke, Rust is even worse. Complex semantics and syntax? Both have those. Rust is trying to be everything to everyone? C++ has always been criticised as design by committee. And yet C still exists and is widely used. Once the smoke cleared, people simply hated C++ and what it brought. After all was said and done, C became regarded as much more tolerable and usable for lack of those headaches. C++ still exists and there is certainly not a C++ monoculture. I hope and expect that the same story will play out for Rust.
- Ragnarork 2y ago
  Do you mean that once the Rust smoke clears, people will see C++ as much more tolerable and usable? :')
- K0nserv 2y ago
  What are some examples of the complex semantics? The things I can think of(lifetimes, generics, traits) exist and are modelled in C too, but just with less(or no) support from the language and compiler.
GuB-42 2y ago
People complaining about Rust... As Bjarne Stroustrup says: "There are only two kinds of languages: the ones people complain about and the ones nobody uses" This is actually the kind signal I wanted to see. A language everyone likes isn't right. In production, programmers have to follow customer requirements, not the other way around, and customers don't care about your pretty code, they want their things to work, and at some point it is going to get ugly, and people will complain. As time goes on, there will be more and more of that ugly legacy code, and you have to keep it, because people are using it, and people will complain more, and they will blame everything that relates to it: the language, customers, management, previous devs, etc... It is actually a good thing, it means the language is used to do real work, you will never get these complains when all people do with it are toy projects or a few precise, programmer driven programs.
- throwawaymaths 2y ago
  Worse is better in programming languages. You decide "I'll use python because everyone else uses it" and then you waste a week of your life debugging when some asshole on your team has mutated a dict that you passed into a critical function and you didn't notice.
quectophoton 2y ago
The post doesn't seem to mention certain parts of the community, which is basically my main issue with Rust. You can't even mention that bootstrapping the compiler is a process that's way too convoluted, because you get buried to oblivion ("why would you need that"). Thankfully there are some already, though incomplete because (I'm guessing) Rust being mostly defined as "whatever rustc outputs" doesn't help reduce the pain of checking if your implementation is correct. I appreciate the efforts that are going on to write informal non-spec documentation about the language though, better than nothing. Also can't mention that alternative compilers would be nice (e.g. to make bootstraping easier, see previous point), because you also get buried to oblivion ("don't fragment the ecosystem", "the Rust council/teams/etc will always be composed of trustworthy people now and forever"). Like, yes, but chill a bit and try to consider other use cases instead of reading those topics as attacks to the language just because you think you don't need them. A small minority being very loud in rejecting any attempt at healthy discussion is not good optics for the ecosystem. This stuff also happens with other languages' communities, but somehow I seem to find them happening a lot more frequently with Rust. (P.S.: Changing the topic a bit, I'll invoke Cunningham's Law and say there's no easy way to read Rust documentation offline that doesn't require a web browser of some kind or parsing HTML output. Some equivalent to `go doc` or Python's `help()` function.)
- gavinhoward 2y ago
  > The post doesn't seem to mention certain parts of the community, which is basically my main issue with Rust. Mine too, but my post implied it, and it was already too ranty.
1vuio0pswjnm7 2y ago
Not to author: The URL for the "incomplete list" hyperlink is incorrect.
- gavinhoward 2y ago
  Ack! Thank you, fixed.
amenhotep 2y ago
I just cloned the Starship repo and cargo --release built it and it took six minutes and 30 seconds (which did feel interminable). The author says it takes him 15 minutes "for building just the main.rs", 10 minutes for "lib.rs" and an unspecified time for "everything else". My CPU is from 2012. What on earth is he doing this on, a TI-83? Or am I missing some intricacy of whatever Gentoo is doing that would inherently inflate build times by an order of magnitude?
- nindalf 2y ago
  Just another data point. I cloned and ran `cargo build --release`. It took 2 mins and 2 seconds (M1 Pro, 2021). Just want to say, creating a release build is really unusual! You'd do that relatively rarely. Most of the time you'd create a debug build, which took 29.56 seconds on my machine for a clean build and 1.45 seconds for an incremental build with one line changed. I sympathise with the author's running on underpowered hardware, but it might not reflect the experience of the average Rust developer.
- rascul 2y ago
  5m 39s here on a 2017 CPU: Intel(R) Pentium(R) CPU G4560T @ 2.90GHz
- timw4mail 2y ago
  Rust doesn't play quite as nicely with Gentoo's packaging system as C/C++, but yes, that seems excessively long. Then again, I'm fairly sure I have starship installed via `cargo install`, not via portage (Gentoo's packaging system). I'm a Rust and Gentoo lover :D
- saati 2y ago
  > The author says it takes him 15 minutes "for building just the main.rs", 10 minutes for "lib.rs" and an unspecified time for "everything else". That's weird, cargo displays the current crates under compilation, not files as that's not the compilation unit in Rust, the author seems to be fibbing.
  - TheDong 2y ago
slackfan 2y ago
Be the change you want to see. I refuse to use rust for a multitude of reasons.
throwawaymaths 2y ago
[flagged]
- deleted 2y ago
  [deleted]
deleted 2y ago
[deleted]
opheliate 2y ago
@gavinhoward Just FYI, a couple of links in the article are broken: * The "incomplete list" of C UB currently points to the Rust spec vision * The link labelled "unreasonable programming language" currently points to the Gentoo Wikipedia page * The "Starship" link points to the House Wiki page on Vicodin
- gavinhoward 2y ago
  Ack! That is what I get for writing a post quickly while drunk on sleep fatigue late at night. And the rantiness comes as a side effect of that. Fixed, Thank you!
multimoon 2y ago
This argument is always so divided into very thoroughly mine-protected trenches it’s insane. The anti-rust crowd treat the language like it has more boilerplate than JavaScript and that it’s the most complex language out there while offering no benefits, which just isn’t true. It’s a great language with a lot of features that are huge advantages over C/C++. The rust evangelists treat it like it’s the second coming and that you’re literally killing babies if you aren’t letting the language enforce its paradigms on you. The forced safety the language offers is a great feature in 2024, but it is not a be all end all thing - there are plenty places where it just isn’t necessary and creates more work for the programmer. The argument is also usually “everything should be rust” but the moment you point out a use case where its advantages don’t matter, they say “well the rewrites only need to happen for <x critical direct networked service>” - that then means everything doesn’t need to be rust, no? Like most things, the correct path is somewhere in the middle. I personally don’t like Rust’s syntax, generics, not being object oriented, etc - but that’s just my opinion and is no more valid or invalid than the next. At the end of the day, use the language you like most and are comfortable with, as long as you understand the benefits and drawbacks of each. - Signed, a Kotlin evangelist
1vuio0pswjnm7 2y ago
"I like small programs with few dependencies. I will write my own I/O to avoid dependencies. And tokio is to dependencies what god objects are to object-oriented programming." This is what is preventing me from using Rust. It is so tightly integrated with a package manager for libraries that trying to avoid crates.io and dependencies is like paddling against the current.
prmph 2y ago
Rust is a systems programming language. It forces you to think about computer architecture as you are writing code. The language is a tool expressing how logic should execute safely and performantly on actual hardware. That is both its strength and weakness. I agree with the article in so far as the hope that people will not start pushing Rust as the cool language for pretty much everything. For many development endeavors, the language is a tool purely for expressing logic, and for that Rust is a poor choice IMO.

99 points by gavinhoward 2y ago

What does Yao look like? edit ah I found some examples https://rigbuild.dev/yao-tutorial/ https://rigbuild.dev/yao-tutorial/

gavinhoward 2y ago
You can also look at the example file. [1]: https://git.yzena.com/Yzena/Yc/src/branch/master/src/yao/example.y https://git.yzena.com/Yzena/Yc/src/branch/master/src/yao/exa...

noelwelsh 2y ago

Rust is certainly not the last word in systems programming languages, but it's an huge leap forward from C and C++. To be honest, it's a sad reflection of our industry that it's taken this long to get basic safety + ML circa 1975 language features into this niche. If things had turned out a little bit different we could all have been using OCaml for the past few decades.

fire_lake 2y ago
People reject OCaml for these use cases due to the GC, but I wonder if this actually matters in practice. The optimizations that can be applied to ML languages (see MLTon for example) are very advanced and the ability to do multi core with ease (I know this is more recent to OCaml) can be a big performance unlock that is very hard to get right in C.
- pornel 2y ago
  GC is perfectly fine for ~99% of applications, which is why all the languages in the last few decades adopted it, and eliminated themselves from being direct C/C++ competitors. Lack of GC isn't a requirement for most programs. However, it is a requirement for a language meant to actually replace C and C++, because these two are mostly used in the remaining fraction of programs and libraries where any GC or any fat runtime is undesirable. Even where some GC could be made to work, it makes it a tough sell for C/C++ users.
- dgrunwald 2y ago
  The GC does matter. Most applications are completely fine with having a garbage collector, but they are not fine with having multiple garbage collectors! Mixing multiple garbage collected languages is a recipe for complex bugs. At a minimum, reference cycles across the languages will result in memory leaks. Thus every garbage collected language tends to grow its own ecosystem of libraries, with the whole world having to be re-implemented in that language. The only exception are the C/C++/Rust libraries, as these can be used (through C FFI interface) by almost every other language. This is precisely because these languages do not introduce their own heavy-weight runtime (especially: no GC), allowing them to be combined with another language's runtime. Thus widely used libraries must be written in one of the non-GC languages, even if 100% of the applications using them are fine with having a garage collector.
  - bryanlarsen 2y ago
    I see this same situation playing out with async executors. tokio is taking over, but it doesn't play well with other async executors. I just wrote a program that mixed tokio & glib and it wasn't fun. This does feel like a soluble problem, so I hope they do figure it out. I think the first step might be something like without.boats' proposal to add something like https://github.com/zesterer/pollster https://github.com/zesterer/pollster to the standard library to establish a minimum common denominator.
begueradj 2y ago
> it's a sad reflection of our industry that it's taken this long to get basic safety + ML circa 1975 language features into this niche. That's true. Could it be that's because we are expert at nitpicking every programming language, every framework and stack which appears to the point it takes time to make steps forward ? Some sort of paralysis, insecurity and confusion ?
jltsiren 2y ago
My favorite hypothesis here is that programming language enthusiasts are too different. They are incapable of convincing the average programmer of the merits of their favorite language, because their way of thinking is different. Arguments they find convincing are not convincing to the average programmer. Progress happens incrementally with small steps. Existing languages get new features. New languages get popular, because they look familiar but contain some small meaningful improvements. And familiarity is important. Languages like OCaml never become popular, because they are too different. Even the syntax looks unfamiliar.
- DEADMINCEDOS 2y ago
  I think you're right. The same way people have strong preference for Systemd, MacOS, KDE, Gnome, I3, Nix, Debian, Gentoo, Arch, etc. So many different solutions. Most are preferred because of subjective reasons (although sometimes just poor reasoning period), because people think so drastically differently.
- throwawaymaths 2y ago
  > Existing languages get new features That's how you wind up with C++
  - jltsiren 2y ago
    Or English. A lot of people used to advocate for using their favorite ancient / artificial languages in international contexts and for communicating important matters. But somehow the C++ of natural languages became dominant.
- falcolas 2y ago
  > Arguments they find convincing are not convincing to the average programmer I think one problem is believing there exists an "average programmer". It's easy to think in averages (or medians), but the reality is that there is no average person, and exactly one median person. Realizing that every single person is different is important, because you then start to work in more discrete niches. It's going to be much easier to appeal to "programmers who write X in Y with the following constraints" than it will ever be "programmers who write in Y". Or to bring this closer to the topic of discussion, you'll never convince game developers to drop C++ in favor of rust using the same arguments as you'd use to convince a service developer to drop C++ for rust.
fxtentacle 2y ago
Sadly, Rust is only a "huge leap forward from C and C++" for some use-cases. Simple things like returning a const reference to a slot in an immutable array are easily 10x the amount of source code in Rust when compared to C. And all the standard libraries for embedded systems are C, so to get into embedded development, you definitely need to be good at reading C code. Rust is an additional skill, but if you only know Rust and no C, you're of no use in embedded land. I think that's the main reason why we don't move away from C: You still need a firm grasp of C if you want to be a capable higher-level developer. C++ is then the logical upgrade because it's compatible with C and looks very similar. Java also did OK because it looks and feels very similar. And there's good automated C to Java converters. So you get the benefits of Java over C almost for free. Rust, on the other hand, throws away most of the C conventions and that makes it feel foreign and "incompatible". Rust also suffers from a serious "not invented here" problem, in my opinion. It's super easy to re-use C code in C++ or Java. It's significantly more difficult to re-use C in Rust unless you go unsafe and abandon most of the Rust advantages. That means most dependencies need to be re-implemented in Rust if you want to have all the advantages that Rust offers. Go had the same problem, but they had Google's weight behind them to push out tons of libraries. Who is doing that for Rust? In the end, I agree with the article: Rust is great! when it fits. But there are still plenty of situations left where Rust is worse than old-school C.
- goku12 2y ago
  > Rust also suffers from a serious "not invented here" problem, in my opinion. It's super easy to re-use C code in C++ or Java. It's significantly more difficult to re-use C in Rust ... It feels like a mischaracterization of Rust and I strongly disagree. Both the language and tooling are designed from the beginning for interop with C code. It isn't very hard to do if you have tried it. > ... unless you go unsafe and abandon most of the Rust advantages. That means most dependencies need to be re-implemented in Rust if you want to have all the advantages that Rust offers. This 'Rust is useless if you use unsafe' is a stance that is well debunked, but still gets repeated like this. Ensuring safety using Rust semantics across an FFI with a language like C is impossible - making unsafe necessary. But just because you use unsafe doesn't mean that the language lost most of its advantages. In fact, almost every Rust program uses unsafe code, if you care to look at the code in the standard library. Yet, that never seems to be a problem. What unsafe does is to cordon off a small code area where certain invariants have to be asserted manually, instead of relying on the borrow checker. You still get the safety for the rest of the code. In case you do get safety violations, there is much less code to debug. This is a significant advantage over languages like C++, considering that unsafe blocks are usually less than 5% of the code, even in the worst case. But to take it further, C libraries often have corresponding Rust wrapper libraries that create safe wrappers over C FFI calls. In addition to the small unsafe blocks to verify manually, these wrappers have the additional advantage of being widely used and debugged by a wider community. There are innumerable such wrappers on crates.io and it's uncharitable to accuse the language of NIH syndrome.

WhereIsTheTruth 2y ago

Projects adopting rust makes contributing less fun and more painful I tried to work on bug fix for Zed, waiting 30 seconds everytime you change a value was _very_ painful

Klonoar 2y ago
I feel like you could stand to qualify "fun" more here. I don't share your experience - I'll take a Rust project any day - but I'm curious to know what you feel is missing. (Outside of compile times, which are a well known point)
amenghra 2y ago
There’s no reason you couldn’t have a rust jit for development then compile the code for production (or stick with a jit for prod too).
- h4x0rr 2y ago
  Honestly it would probably be even faster than unoptimized aot compolation
  - amenghra 2y ago
    Some developers need/are used to a fast edit-compile-run loop. The JIT doesn't even need to be optimized, just good enough to improve the developer experience.
- nindalf 2y ago
  There's no reason? Are you sure about this? I think you mean there could theoretically be an interpreted Rust, but I don't think anyone has ever made a prototype of a Rust interpreter. The closest is probably rust-analyzer (the official language server), that maintains internal state and reacts to changes you make, but it doesn't create an executable artifact. The other is probably the Cranelift Backend (https://github.com/rust-lang/rustc_codegen_cranelift https://github.com/rust-lang/rustc_codegen_cranelift), which can produce debug builds quickly.

usrnm 2y ago

Within Rust is a smaller, simpler, safer language struggling to get out

consp 2y ago
Readable would be a nice benefit.
- Guthur 2y ago
  This, I don't understand why we have to load these languages up with so much syntax, it's mind boggling to think that some how we feel it's beneficial to have so much. I'm admittedly biased to the symbolic expression but surely we could have come up with some middle ground.
  - Ygg2 2y ago
    Two things: - It was made to be approachable for C++ experts - The idea was that language could be effortlessly greppable.
    - Ragnarork 2y ago
      Coming from C++, and I would have loved Rust to not pick up C++-y things to make it look like it...
    - Guthur 2y ago
      So legacy baggage from the get go. This is what I'm lamenting, it's objectively a syntax soup.
- v9v 2y ago
  Not sure about smaller or simpler, but Ada is definitely more readable in my opinion.
rapsey 2y ago
Without a GC? No there is not. You are welcome to try of course, but unless you have a PhD in type theory I doubt your chances.

deleted 2y ago

[deleted]

oDot 2y ago

This is my current mental model for picking a language, considering just the language itself: - Backends: Gleam or other BEAM - Web frontend: Gleam - Mobile apps: Dart + Flutter - Specialized mobile apps: Swift and Kotlin - Blazing fast: Zig - Blazing fast and safest: Rust - Fast performance and iteration: Go Would love to hear additions and corrections. My only problem with this is I'm not a fan of Go's syntax and I wonder what's a good alternative. Heared good things about OCaml but didn't check it out yet.

styluss 2y ago
Nim fits a lot of Go's use cases. It is way more niche though.
fire_lake 2y ago
OCaml could almost replace all of those. I don’t think there is a BEAM compiler backend yet. I’m not very experienced with BEAM, but could its features be delivered with a framework on top of a different stack? I know Akka is popular.
- deathtrader666 2y ago
  >>> don’t think there is a BEAM compiler backend yet I think there's something close - https://caramel.run/manual/ https://caramel.run/manual/
  - cassepipe 2y ago
    The project has been abandonned : https://github.com/leostera/caramel/discussions/102 https://github.com/leostera/caramel/discussions/102
- ubercore 2y ago
  GC precludes OCaml from replacing a chunk of those.
- fredrikholm 2y ago
  Actor model is a small component of the BEAM. Even then, it guarantees yields to the scheduler. This is practically impossible to retrofit on to an existing language, esp. in the presence of loops.

Jyaif 2y ago

I mostly agree. Compile times are the worst in the industry, and async is a mess.

olalonde 2y ago

Maybe that will sound banal to some but C would be so much more enjoyable to me if it had a "cargo" system and no implicit imports.

rational_indian 2y ago
That's the problem with C. It cannot have a sane cargo like system. The language is not built for writing libraries. There is a reason why everyone keeps reinventing the wheel when it comes to datastructures in C. Where is STL for C?
- Ragnarork 2y ago
  The closest is GLib and it's absolutely not fun to work with.
- simon_void 2y ago
  you could use the Zig build system as your C build system. See https://zig.news/kristoff/make-zig-your-c-c-build-system-28g5 https://zig.news/kristoff/make-zig-your-c-c-build-system-28g...
  - rational_indian 2y ago
    Cargo is just half the story. The other half is rust itself. It is an excellent language for writing abstractions.
dragonelite 2y ago
That's why i like zig it has at least the very basic with build.zig for build script. You have build.zig.zon for build.zig dependencies.

davidhyde 2y ago

My personal take on this subject is that Rust turns experts back into beginners and some devs react with hatred because of the fear this induces. For me it was the opposite. I was getting bored with my industry and thinking of a move to something else like management. Rust came along 6 yeas ago (for me) and threw me a lifeline. I love getting good at something that is hard, it’s just very satisfying. I do get why some people can’t stand the language. It is ugly to look at with its genetics and lifetime annotations and when a project is so large that it begins to lag rust-analyser then my joy turns to rage too.

DEADMINCEDOS 2y ago
> My personal take on this subject is that Rust turns experts back into beginners and some devs react with hatred because of the fear this induces. Those people are probably poor devs. Anyone who doesn't have the attitude and mindset to continue learning in something like software development which keeps advancing isn't cut out for that field.
- deleted 2y ago
  [deleted]
- anonymoushn 2y ago
  Maybe it wouldn't be reasonable to say this about people who dislike programming in Malbolge, and maybe there are aspects of Rust that are more like programming in Malbolge and less like the field advancing.
Const-me 2y ago
You could have spend that time learning something which is actually useful and helps finding interesting jobs. For example, GPU programming or SIMD intrinsics. What annoys me about rust is the complexity just for the sake of it, lots of pain for minimal gain compared to alternatives. If you need async/await you'll do better in modern .NET despite the GC, if you need the highest CPU performance you'll do better in C++ despite the unsafety.
- 2y ago

dgb23 2y ago

The post is a bit of a rant and all over the place. Async infecting everything, ugly syntax (who cares?), slow compile times etc. What stood out to me: > In other words, if compilation is fast, the tooling is easy. Andrew Kelley said something similar in a recent talk. Compiler performance seems to be the number one priority at the moment for Zig. The rationale seems to be: fast compilation leads to more productivity, which leads to more bugfixes. This claim seems almost bruteish, but it makes sense. Tight feedback loops (think things like devops, REPL, TDD, light processes etc.) can help us to iterate more and stay in the zone. To be fair a sophisticated type checker like Rust‘s also helps with that. But of course any added friction and sluggishness can be an indirect hindrance to the overall correctness and even performance of a program.

Timshel 2y ago
Fast compilation is nice and I believe stuff like incremental compilation are essential. But at the end of the day I'll prefer slower compilation every time if it means advanced checking. And speaking of the zone I prefer writing Scala code for like 1h while fixing compiler errors and then you run and it just works TM vs Java where you'll waste your time tracking NPE ...
- dgb23 2y ago
  > But at the end of the day I'll prefer slower compilation every time if it means advanced checking. I don't think that's a large issue in Rust. Type checking is quite fast in comparison to code generation. Generics, traits, macros etc. seem to be the culprit. Turning complex language features into code and not runtime safety lead to these slow compile times.
JodieBenitez 2y ago
> ugly syntax (who cares?) I'm a nobody of course, but I do. Ugly is subjective, and by "ugly" a lot of people probably think "alien", as not what they are used to. Less syntax cruft is good for cognitive load and more common syntax is good for adoption. But I'm sure the problem fades away with practice.
2y ago

ceronman 2y ago

The author seems very anxious because Rust is getting traction and they don't like Rust. They're afraid that one day Rust will become a "monoculture" and everything will be written in it. I like Rust, but I consider this very, very unlikely. Rust has actually brought more choice to the programming language scenario. If we're talking about monoculture, let's talk about C/C++. For decades this was the only viable option for systems programming. All new languages were focusing on a higher lever. Languages for lower level stuff were rare. There was D, but it never got enough traction. Then Rust appeared and there is finally an alternative. And not only that, I because of that, other language designers decided to create new systems languages, and now we have Zig, and Odin, and Vale, etc. So if anything, Rust is helping in breaking the monoculture, not creating it. C and C++ are not going away, but now we have alternatives. And I think it's important to acknowledge that even if you don't like a language, if you see a bunch of software being written in such language, it's because the language is useful. I don't like C++ but I admit it's damn useful! People are writing interesting software in Rust because they find it useful.

ajross 2y ago
FWIW it was LLVM that catalyzed the modern florescence of programming language innovation. Rust is just another result of that shift, not its cause.
- deleted 2y ago
  [deleted]
pjc50 2y ago
Rust is challenging people because it declares several long-inadequate things about C/C++ to be inadequate (security issues, dependency management), and provides alternatives which show that it doesn't have to be like that. The rewrites will inevitably be long and painful. Rewrites always are. But the onus on anti-Rust people is now to demonstrate a better language to rewrite in first, rather than just sitting in the status quo waiting for the steamroller driven by a crab to very slowly run them over. D is interesting but seems to be a solo project, I'm not sure why it's not had traction. Maybe it's not different _enough_.

zkldi 2y ago

I'll bite: What specific parts of rust syntax do people find so ugly? I keep hearing this from decent chunks of people who don't write rust, but the language doesn't seem that far off C to me. It's certainly no haskell.

GardenLetter27 2y ago
Lifetime bounds on a trait object argument can be confusing. I have to look up how to write the where part properly every single time.
Avamander 2y ago
Fishtail, lifetime and closure syntaxes are rather ugly. Just specifically when combined in practice, not alone in isolated examples.
- estebank 2y ago
  For what is worth, the turbo fish falls from the decision to use <> for generics (for familiarity for C++ and Java developers) and a desire to make the syntax non-ambiguous (side stepping the C++ problem of having to delay determining if something is a type path or a comparison, mixing parsing and name resolution).
sebstefan 2y ago
>I keep hearing this from decent chunks of people who don't write rust That's exactly the people you want to hear from if you're trying to improve adoption.
K0nserv 2y ago
The more interesting follow up question is: "How would you express the same semantics with a different syntax?" Too often discussions about Rust's ugly syntax lack this crucial component.
- ReleaseCandidat 2y ago
  > How would you express the same semantics with a different syntax? This isn't the problem, the problem is "... and keep the syntax C++-like?".

K0nserv 2y ago

The author makes the best argument for Rust in the linked post[0] Rust is great for teams because it removes many things that make working on team code dangerous. The items mentioned above are some. I work alone, however, because I like to keep my code in my head and working with people means parts of the code are only in their head. This also means that the bigger the language is, the less space I have in my head for the code. Rust is too big for my small brain, unfortunately. Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down. Besides this I disagree with the author's assertion that Rust is not well suited for them, in fact I think it's strictly better than C because it often obviates the need to keep stuff in your head. Take lifetimes, in C you have to keep track of pointers and their lifetime in your head, and by definition all other maintainers have to do the same, in Rust the compiler does that for you, less to keep in your head. In fact I think the ability offload things from your head to the compiler is one of Rust's great strength. This ties in with compile times too, yes Rust is very slow to compile, but the compiler also does a whole lot more work than the C compiler. Obviously we want rustc to be as fast as possible given the work it's doing, but it will never be as fast as a C or Go compiler. 0: https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-in-memory-safety/ https://gavinhoward.com/2023/02/why-i-use-c-when-i-believe-i...

fxtentacle 2y ago
"Most code is written in teams and even software with a single author needs a plan for when the maintainer steps down." I strongly disagree! My experience is this: 1. Sole developer builds useful thing 2. Team takes over maintenance 3. Feature bloat, sluggishness, bugs ignored, Agile initiative, "Product owners" 4. Company goes bankrupt or gets acquired I don't think you can have the clarity of vision that a single person will produce if you're working on it with a big team. That's why so many useful things start with a single person or a very small team, like Linux, Android, curl, ffmpeg, Quake engine, the 2 ppl Firefox "Phoenix" team, the original 3 ppl JetBrains team, the 2 original Photoshop devs.
- K0nserv 2y ago
  > That's why so many useful things start with a single person or *a very small team*, You subtly shifted the goal posts here. But even if you start out with a single person you eventually have to have new maintainers, if only because of human mortality. Software is a young field so we haven't had to contend much with this fact yet, but it's inevitable. Personally I think something like Rust is helpful for large solo programs too, keeping everything in your head past 10kCLOC is hard so why not have a language and compiler that helps you?

GardenLetter27 2y ago

The compile times are the only real issue mentioned here. I still think it's better than C++ but for large projects the compile times and crate splitting, etc. become a real pain.

sebstefan 2y ago

>the syntax. It’s ugly. [...] I would prefer something that is less sigil-heavy. That's also one of my gripes with Rust. Very sigil heavy makes it hard to google syntax elements. What's the name of the `|` glyph? Especially challenging if you know the name of the glyphs in your language but not in necessarily in english. Double challenging for glyphs with several accepted names But in the end, I'm big enough to realize that this is not a very important aspect of the language If it's ugly so be it. I'll still learn it Also for once Bing Copilot pretty much solved this for me since unlike google search, it's semantic + it doesn't ignore special characters

SushiHippie 2y ago
FYI Wikipedia has pages for every ascii character I think, if you just search for `|` in wikipedia it would redirect you to https://en.wikipedia.org/wiki/Vertical_bar https://en.wikipedia.org/wiki/Vertical_bar Which lists all the common names used for this symbol Here is also a table with all symbols with direct links to the wikipedia pages https://en.wikipedia.org/wiki/ASCII#Character_set https://en.wikipedia.org/wiki/ASCII#Character_set
rascul 2y ago
This might be useful https://doc.rust-lang.org/reference/tokens.html#punctuation https://doc.rust-lang.org/reference/tokens.html#punctuation
- yencabulator 2y ago
  That doesn't seem to explain 'lifetimes or turbo::<Fish>, though.
  - steveklabnik 2y ago
    The page linked for :: explains the turbofish. That said, you're right that it could use a row for the lifetime syntax.
    - 2y ago

dtquad 2y ago

I have seen a lot of criticism of async Rust. In C# most APIs expose both sync and async versions of the same methods. Why is that not more common in Rust? Sure some 3rd party C# libraries probably do some ugly sync to async conversion internally but most don't and use the .NET standard libraries sync/async versions of the same APIs.

pornel 2y ago
Rust's async is in some places more difficult to use, because Rust is obsessed with avoiding allocations and dynamic dispatch. Languages like C# and JS allocate a new object for every Promise and every listener. Rust bends backwards to avoid that, and make inlined strongly typed state machines instead. It creates limitations where you wouldn't expect, e.g. recursive calls need special handling, and abstract interfaces don't fully support async. As for supporting both, it's just inconvenient to do, because many small syntactic and semantic differences mean it's hard to automate and cumbersome to maintain.
- neonsunset 2y ago
  Not every await and new task produces an allocation in C#: ValueTask only allocates a state machine box if it yields asynchronously, plain task objects are pooled for common values and state machine box itself can also be pooled for frequently called methods (is opt-in), for example socket.SendAsync does not allocate thanks to this. This will change further as "Runtime Handled Tasks" implementation comes along which will replace Roslyn-generated explicit state-machine code with runtime-provided suspension mechanism which will only yield/suspend the execution at true yield points, with further improvements to how the captured state that needs to persist across them is stored.

dana321 2y ago

I'm hoping this rust fad goes away soon

weinzierl 2y ago

> First, the syntax. It’s ugly. TO MY EYES! Beauty is in the eye of the beholder, you can't please everyone and you should not exceed your weirdness budget[1]. The decision to please the C++ crowd so much (mainly manifested in later syntax related decisions) would not have been my preference, but it makes sense and there could have been worse decisions. > Second, Third, Fourth, Fifth I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community. > Sixth, Rust doesn’t go far enough in static analysis. Rust had a chance to go much further, and the team blew it. I am not qualified to judge that, but I am curious of other opinions. > Seventh, Rust compile times are a joke True, but this is actively tackled on multiple fronts. One is cranelift, which I find highly fascinating. [1] https://steveklabnik.com/writing/the-language-strangeness-budget https://steveklabnik.com/writing/the-language-strangeness-bu...

anonymoushn 2y ago
> I feel a lot of this async criticism has more to do with how async is used than with Rust itself. Maybe it would be good to have more crates that don't used async or even depend on tokio, but in the end this is on us as a community. No, this is a language design issue. In Lua or Zig the easy way to write a library that speaks websockets produces a library that works with synchronous or asynchronous i/o and with the user's choice of read and write primitives. In Rust, after many years of unnecessary suffering, we finally have the ability to ship one library that can use either kind of i/o.... unless the user wants to use both in the same workspace, in which case they are screwed. You may enjoy this tale of a user trying to get Rust to do what Lua and Zig do by default, for a single library: https://nullderef.com/blog/rust-async-sync/ https://nullderef.com/blog/rust-async-sync/
- weinzierl 2y ago
  This is being worked on: https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-generics.html https://blog.rust-lang.org/inside-rust/2022/07/27/keyword-ge...

mmaniac 2y ago

A lot of this author's complaints about Rust remind me of similar historical complaints about C++, but amplified. Hijacking and overtaking new projects? C++ and Rust both do that. C++'s compile times were a joke, Rust is even worse. Complex semantics and syntax? Both have those. Rust is trying to be everything to everyone? C++ has always been criticised as design by committee. And yet C still exists and is widely used. Once the smoke cleared, people simply hated C++ and what it brought. After all was said and done, C became regarded as much more tolerable and usable for lack of those headaches. C++ still exists and there is certainly not a C++ monoculture. I hope and expect that the same story will play out for Rust.

Ragnarork 2y ago
Do you mean that once the Rust smoke clears, people will see C++ as much more tolerable and usable? :')
K0nserv 2y ago
What are some examples of the complex semantics? The things I can think of(lifetimes, generics, traits) exist and are modelled in C too, but just with less(or no) support from the language and compiler.

GuB-42 2y ago

People complaining about Rust... As Bjarne Stroustrup says: "There are only two kinds of languages: the ones people complain about and the ones nobody uses" This is actually the kind signal I wanted to see. A language everyone likes isn't right. In production, programmers have to follow customer requirements, not the other way around, and customers don't care about your pretty code, they want their things to work, and at some point it is going to get ugly, and people will complain. As time goes on, there will be more and more of that ugly legacy code, and you have to keep it, because people are using it, and people will complain more, and they will blame everything that relates to it: the language, customers, management, previous devs, etc... It is actually a good thing, it means the language is used to do real work, you will never get these complains when all people do with it are toy projects or a few precise, programmer driven programs.

throwawaymaths 2y ago
Worse is better in programming languages. You decide "I'll use python because everyone else uses it" and then you waste a week of your life debugging when some asshole on your team has mutated a dict that you passed into a critical function and you didn't notice.

quectophoton 2y ago

The post doesn't seem to mention certain parts of the community, which is basically my main issue with Rust. You can't even mention that bootstrapping the compiler is a process that's way too convoluted, because you get buried to oblivion ("why would you need that"). Thankfully there are some already, though incomplete because (I'm guessing) Rust being mostly defined as "whatever rustc outputs" doesn't help reduce the pain of checking if your implementation is correct. I appreciate the efforts that are going on to write informal non-spec documentation about the language though, better than nothing. Also can't mention that alternative compilers would be nice (e.g. to make bootstraping easier, see previous point), because you also get buried to oblivion ("don't fragment the ecosystem", "the Rust council/teams/etc will always be composed of trustworthy people now and forever"). Like, yes, but chill a bit and try to consider other use cases instead of reading those topics as attacks to the language just because you think you don't need them. A small minority being very loud in rejecting any attempt at healthy discussion is not good optics for the ecosystem. This stuff also happens with other languages' communities, but somehow I seem to find them happening a lot more frequently with Rust. (P.S.: Changing the topic a bit, I'll invoke Cunningham's Law and say there's no easy way to read Rust documentation offline that doesn't require a web browser of some kind or parsing HTML output. Some equivalent to `go doc` or Python's `help()` function.)

gavinhoward 2y ago
> The post doesn't seem to mention certain parts of the community, which is basically my main issue with Rust. Mine too, but my post implied it, and it was already too ranty.

1vuio0pswjnm7 2y ago

Not to author: The URL for the "incomplete list" hyperlink is incorrect.

gavinhoward 2y ago
Ack! Thank you, fixed.

amenhotep 2y ago

I just cloned the Starship repo and cargo --release built it and it took six minutes and 30 seconds (which did feel interminable). The author says it takes him 15 minutes "for building just the main.rs", 10 minutes for "lib.rs" and an unspecified time for "everything else". My CPU is from 2012. What on earth is he doing this on, a TI-83? Or am I missing some intricacy of whatever Gentoo is doing that would inherently inflate build times by an order of magnitude?

nindalf 2y ago
Just another data point. I cloned and ran `cargo build --release`. It took 2 mins and 2 seconds (M1 Pro, 2021). Just want to say, creating a release build is really unusual! You'd do that relatively rarely. Most of the time you'd create a debug build, which took 29.56 seconds on my machine for a clean build and 1.45 seconds for an incremental build with one line changed. I sympathise with the author's running on underpowered hardware, but it might not reflect the experience of the average Rust developer.
rascul 2y ago
5m 39s here on a 2017 CPU: Intel(R) Pentium(R) CPU G4560T @ 2.90GHz
timw4mail 2y ago
Rust doesn't play quite as nicely with Gentoo's packaging system as C/C++, but yes, that seems excessively long. Then again, I'm fairly sure I have starship installed via `cargo install`, not via portage (Gentoo's packaging system). I'm a Rust and Gentoo lover :D
saati 2y ago
> The author says it takes him 15 minutes "for building just the main.rs", 10 minutes for "lib.rs" and an unspecified time for "everything else". That's weird, cargo displays the current crates under compilation, not files as that's not the compilation unit in Rust, the author seems to be fibbing.
- TheDong 2y ago

slackfan 2y ago

Be the change you want to see. I refuse to use rust for a multitude of reasons.

throwawaymaths 2y ago

[flagged]

deleted 2y ago
[deleted]

deleted 2y ago

[deleted]

opheliate 2y ago

@gavinhoward Just FYI, a couple of links in the article are broken: * The "incomplete list" of C UB currently points to the Rust spec vision * The link labelled "unreasonable programming language" currently points to the Gentoo Wikipedia page * The "Starship" link points to the House Wiki page on Vicodin

gavinhoward 2y ago
Ack! That is what I get for writing a post quickly while drunk on sleep fatigue late at night. And the rantiness comes as a side effect of that. Fixed, Thank you!

multimoon 2y ago

This argument is always so divided into very thoroughly mine-protected trenches it’s insane. The anti-rust crowd treat the language like it has more boilerplate than JavaScript and that it’s the most complex language out there while offering no benefits, which just isn’t true. It’s a great language with a lot of features that are huge advantages over C/C++. The rust evangelists treat it like it’s the second coming and that you’re literally killing babies if you aren’t letting the language enforce its paradigms on you. The forced safety the language offers is a great feature in 2024, but it is not a be all end all thing - there are plenty places where it just isn’t necessary and creates more work for the programmer. The argument is also usually “everything should be rust” but the moment you point out a use case where its advantages don’t matter, they say “well the rewrites only need to happen for <x critical direct networked service>” - that then means everything doesn’t need to be rust, no? Like most things, the correct path is somewhere in the middle. I personally don’t like Rust’s syntax, generics, not being object oriented, etc - but that’s just my opinion and is no more valid or invalid than the next. At the end of the day, use the language you like most and are comfortable with, as long as you understand the benefits and drawbacks of each. - Signed, a Kotlin evangelist

1vuio0pswjnm7 2y ago

"I like small programs with few dependencies. I will write my own I/O to avoid dependencies. And tokio is to dependencies what god objects are to object-oriented programming." This is what is preventing me from using Rust. It is so tightly integrated with a package manager for libraries that trying to avoid crates.io and dependencies is like paddling against the current.

prmph 2y ago

Rust is a systems programming language. It forces you to think about computer architecture as you are writing code. The language is a tool expressing how logic should execute safely and performantly on actual hardware. That is both its strength and weakness. I agree with the article in so far as the hope that people will not start pushing Rust as the cool language for pretty much everything. For many development endeavors, the language is a tool purely for expressing logic, and for that Rust is a poor choice IMO.