What are /r/rust's favorite Products & Services?

From 3.5 billion Reddit comments

>The programming language that empowers everyone to become a systems programmer.

>everyone to become a systems programmer.

Umm, am I the only one who thinks this is overly dramatic? Look at D's website

It's modern, yet not full of overwhelming colors or styling, doesn't turn you into a systems programmer, conveys just enough information.

IDK, maybe I'm getting old.

Relevant quote:

> Facebook is writing a Mercurial server in Rust. It will be distributed > and will support pluggable key-value stores for storage (meaning that we > could move hg.mozilla.org to be backed by Amazon S3 or some such). The > primary author also has aspirations for supporting the Git wire protocol on > the server and enabling sub-directories to be git cloned independently of > a large repo. This means you could use Mercurial to back your monorepo > while still providing the illusion of multiple "sub-repos" to Mercurial or > Git clients. The author is also interested in things like GraphQL to query > repo data. Facebook engineers are crazy... in a good way.

See also: https://www.mercurial-scm.org/wiki/4.0sprint, "New HG server at Facebook"

I'm one of the Alacritty maintainers and Version 0.3.0 has just been released, since this is a slightly bigger release I've decided to write up what has changed for people who haven't been following the project.

If you have any questions, please let me know. I'm happy to answer all of them.

The source of the project can be found here: https://github.com/jwilm/alacritty

(disclaimer: I am not the author of this article)

Ran across this uncharacteristically high-quality post on DEV.to today, and thought I'd share it here. It is a nice aggregation of the state of different UI crates.

25 years from now we'll be looking back to remark how this reddit post was the spiritual equivalent of Linus' original Usenet post. :)

(No pressure.)

My favorite is rust-analyzer: https://opencollective.com/rust-analyzer

It's critical tooling that I use when writing and reading in Rust. When it doesn't work (which occasionally happens and it's not always RA's fault), I notice right away because it's so central to my workflow.

And then there are also folks that work on critical libraries that accept contributions, like /u/dtolnay: https://github.com/sponsors/dtolnay

First, if you statically link against musl, you have to do that for all your dependencies, which prevents things like:

• Using Rust to write cdylib libraries that can be loaded by other things on the system. (eg. GStreamer plugins, Python/Ruby/Node.js/etc. extensions, etc.)
• Sharing the system versions of huge and/or hard-to-bundle dynamic library dependencies like Qt and the user's selected Qt theme. (Yes, like in GTK+ 2.x, Qt themes are dynamic libraries... and do the libre releases of Qt even support static linking? I think I heard somewhere that they didn't.)
• Using things that are only offered as glibc-built dynamic libraries, like the free version of Sciter.

It's basically the same situation as using the MinGW builds of Rust on Windows that way.

Second, apparently musl's allocator has major flaws in multi-threaded situations.

> We laid out an actionable plan for advertising our success stories, including a specific direction for whitepapers and our blog. Thanks, @carols10cents and @shepmaster, for helping us figure out how to make Rust "boring" in the way that companies want!

Particularly excited about this. I've personally had a hard time selling Rust as a viable solution at work because of this. Friends of Rust has been a great start, but there is more work we can do on this front to make it easier for us to convince tech leads that Rust is something they can bet confidently on.

> In searching for case studies all I've found

There's also https://www.rust-lang.org/friends.html

> mozilla only feels comfortable using a few lines of rust in firefox so far.

The way that this is phrased implies some sort of lack of confidence in Rust, but it's not that: it's that changing things in a codebase that's millions of lines long takes time.

> While I'd like to ask why Rust has yet to see serious adoption despite Go and Swift seeing significant uptake, that's the wrong question.

Go has been stable for four years, Swift is pretty much the native language of a platform. Rust has only been stable for a year.

Speaking of literate programming, the reason that Knuth has been taking so long to finish The Art of Computer Programming is because he's been secretly reimplementing the entire book, and all of LaTeX, in Rust! Fearless publishing!

In case anyone is wondering, this is happening because the Rust Borrow Checker has become self-aware and started coming up with new and novel UTF-8 characters that your browser might not be able to display properly.

https://stackoverflow.com/questions/6579844/how-does-zalgo-text-work

I'll just point out that my first internal-presentation slide deck on "project Servo" referred to it as "technology from the past come to save the future from itself"; and a year later Brendan's update deck starts with a Sarah Connor quote ("no fate but what we make").

Nobody involved in the project has ever conducted temporal displacement experiments though. Categorically. Definitely not. (Yet).

Because there is some understandable confusion regarding the role that the foundation plays, please note that the foundation doesn't design the language or determine what gets into it. The design of Rust (the language, the stdlib, the tools, etc.) is determined by the respective teams (listed at https://www.rust-lang.org/governance/ ). All moderate-to-major changes to an area of Rust must be approved by a near-unanimous vote by the members of relevant team ("near-unanimous" in the sense that members who are absent for a long time without casting a vote can be ignored), and the foundation doesn't have any say on team membership.

PLEASE. Especially after the (small amount of) drama that happened with <code>alacritty</code>'s claim to be the fastest terminal emulator, it'd be great if one could lead their marketing with at least cursory benchmarks. We're not ALWAYS going to avoid things like users on HN looking for ways to criticize whatever gets noticed, but we can at least do a defensible amount of homework before making claims of superiority!

Please don't do this. There's a reason that every public site (twitter, facebook, etc) on the Internet immediately converts GIF to MP4s (gifv) and then throw the GIFs away.

Case in point, the first GIF on the page, converted back to an mp4 is a smaller file size: https://ezgif.com/gif-to-webm/ezgif-4-4efe89cb18f1.gif

I think there are other ways of helping on-board people from other backgrounds, especially with something like Go's tour. If you give people the path of least resistance to trying the code, it can feel much more doable. D's sample code selector https://dlang.org/ is pretty cool as well.

I feel as though this web design is less comfortable because I don't know where I am going. There is a TON of information on the front page, is there a link to the documentation in the middle of the page? How do I install? Is the install button behind "Get started" or is it on this front page? What does the Rust book look like? Is it the Rust book that Marcus told me about? etc.

When someone is completely new to the site, there is a lot to look at, and it feels a bit overwhelming.

Algolia would probably allow you to use their search platform, similar to what they did for the yarn website. It's super fast, probably better than what you could reasonably build as a side project.

If you used Rust with MSVC ABI on Windows, you probably noticed this sentence on the Rust download page:

>MSVC builds of Rust additionally require an installation of Visual Studio 2013 (or later) so rustc can use its linker. Make sure to check the "C++ tools" option.

Now it's no longer true! Full Visual Studio installation is not necessary anymore, more lightweight Visual C++ Build Tools can be installed instead.

> There are not TOO many languages to choose from though, because for practical reasons, you need a language that can has no runtime, no gc, and can more or less pretend to be C.

I'm sorry to barge into the r/rust subreddit like this but I'm curious. (Disclaimer I am one of the core developers of Nim).

By the way, I love Starbound and my SO is absolutely in love with Stardew Valley (Myself and her are both excited about your upcoming game).

So my question is related to your "no gc" requirement. The Nim programming language itself is a GC language, but despite that it found a little niche for itself in game development. The GC in Nim is rather special as it has been specifically designed for games, you can control when it runs and for how long incredibly easily (https://nim-lang.org/docs/gc.html#realtime-support). I'm basically wondering two things:

• have you evaluated Nim for your project?
• what is your experience with GCs in games? Have you ever used one with real-time support?

I feel that apart from this requirement, Nim would fit your use case perfectly (and perhaps even more so than Rust, as it compiles directly to C/C++).

Thanks for taking the time to answer these questions and I hope you have a nice day :)

Not really. Given the responsibility of the mod team, it would make sense to apply "accountability" to the frame of reference of the mod team: The Code of Conduct.

I would say with reasonable confidence that was/were likely issue(s) regarding member(s) of the Core team not abiding by the CoC, where the Moderation team attempted enforcement/direction/guidance and was ignored/rebuked.

I know Postgres and Mongo are like apples and oranges when it comes to many things but I do have some more faith in Mongo since version 3.4 passed the Jepsen test. This is a scrupulous test ensuring that the distributed nature of the database being tested handles various scenarios. More information about Jepsen can be found on that link.

With that being said, Postgres is wonderful and would be what I reach for 99% of the time.

I was under the impression that Alacritty's claims were about throughput, not latency. That being said, there isn't any hard benchmarks to back this up (https://github.com/jwilm/alacritty/issues/289), although the posted benchmarks that Alacritty does well in do seem to be throughput focused.

The real benefit of a REPL isn't a plain REPL on its own. It's being able to work on top of a partial program (even one that blows up somewhere on startup), akin to a powerful debugger (but not for debugging per se). If I run python -i myscript.py I can immediately start running and introspecting my values, yet the basic script is still very much inside my editor.

In fact, I've moved the REPL into my editor to get something akin to Light Table.

> Arguable. I would say they are almost the same.

I'm a fanatic rustacean and I'd be very wary of describing the strengths of the language to newcomers in this way. Go's approach to stdlib and Rust's are day and night, it's a consciously-made, well-known design choice.

I feel a comparison of the form "it's basically the same except for X and Y" is a bit misleading and disingenuous. I don't have any significant Go experience, but just perusing through https://golang.org/pkg/ I can see support for data compression, random numbers, misc. data formats (json, xml, etc.), image processing, etc.

Personally, I try to explain that "Rust is a lean-stdlib language, for reasons X and Y".

One big change to point out is the change of the community page and the switch from IRC to Discord.

Even though many teams were officially experimenting with Discord it was nowhere to be found on https://www.rust-lang.org/en-US/community.html

With the new beta look on the other hand IRC got completely removed and replaced with Discord on https://beta.rust-lang.org/community. It's also in the footer on every page.

I was actually thinking that experimenting with Discord while having no easy way to discover it seemed extremely awkward. I was planning to reach out in this regard once the 2018 edition was out, I imagine people are busy right now.

To take a step back and not involve namespaces...

A more charitable interpretation of crates without code is that people had the intention of creating a library but they haven't gotten it to a state in which they're comfortable releasing it yet. Perhaps life got in the way, or the problem was harder than they thought.

Should these people have their crate names taken away? I am of the opinion that no, they should not. If we agree on that point, then you'd have to be able to distinguish between a well-intentioned reservation of a name and a malicious "landgrab" of a name, and in general the core team has decided to not spend time on monitoring this and making those judgment calls, so that they can work on Rust instead.

I'm sure if there was an egregious, obviously malicious attempt to grab infinite names, or, say, an attempt to harass someone through creating crates or otherwise use names against Rust's code of conduct, you could report it to the core team or moderation team and they would handle it on a case-by-case basis.

One thing that is stable is #[cold]. Any branch that would lead to a cold function is considered unlikely, so you could consider splitting the unusual path into a separate function.

>Please support bjorn3 at https://liberapay.com/bjorn3/

It's weird that you can't do a one time donation, if I donate I will forget about it and I'll be paying him for the next 20 years, long after he has stopped working on this.

Haha. I'll also plug one of my tiny crates: <code>tabwriter</code>. It provides a type that implements io::Write and automatically replaces output with \t in it to an aligned table padded with spaces. It's based on the package with the same name in Go's stdlib.

> EDIT: formatting because old reddit site can't display markdown

It can display Markdown just fine. It can't display Commonmark.

Rust was used a little internally at my old job. At my new job, it's a lot more core to the business.

You might also take a look at the friends of rust page.

> […] reviews say that it is a programming language that runs crazy fast, that prevents segfaults, and that guarantees thread safety.

Yes, reviews! Very professional article.

Straight off Amazon for paperback

This title will be released on June 30, 2021. Pre-order now.

As an alternative, the Kindle eBook is available now and can be read on any device with the free Kindle app.

Dispatched from and sold by Amazon.

Free delivery for Prime members

Edited: removed personal data

Which exact bit? The Code of Conduct does indeed say

>We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

&#x200B;

So, no discrimination of people based off of gender identity. Keep in mind that flamewars are explicitly banned (rules 3,4), so as long as you are polite and respectful, you shouldn't end up with too much of an issue.

&#x200B;

Not sure if that's exactly what you were asking about, but eh, I tried. ¯\_(ツ)_/¯

> Superficial politeness stifling discussion of real issues.

None of this, please. A foundational premise of this community is that it's possible to be professional without being an asshole, and ideally while remaining courteous. I have made the mistake before of turning a blind eye to assholes on account of the quality of their technical contributions, and each time I have eventually regretted it. I'm sure that you can name both of the aforementioned; you of all people should appreciate this.

There do exist times when dire circumstances call for immediate action. For security-related issues, the private Rust Security mailing list is actively monitored ( https://www.rust-lang.org/en-US/security.html ), and accepts tips even for projects in the broader ecosystem (especially well-known and highly-used ones). Meanwhile, contacting those with commit access to reqwest would be the next productive course of action; AFAIK this group does not include carols10cents, so this thread here does not strike me as especially productive. If all else fails, I believe you remember where the Rust developers hang out, and in the hypothetical event of a truly world-endingly sky-is-fallingly extreme circumstance I'm sure they could be convinced to blackhole a crate on crates.io until a problem is resolved.

That is because orgmode is a lot of things. It is first and formost a markup language (similar to markdown) and an emacs-mode to work with the markup language. It can be used for literate programming, managing TODOs and a lot more.

Since everything is stored in plaintext files (with .org extention) it should be really portable. Unfortunatelly there is only really one library that deals with all the aspects of org-mode: the emacs-mode itself.

I know it's somewhat controversial, but I wouldn't consider putting lots of comments into a code base a good practice. Reading "Clean Code" by Robert C Martin really opened my eyes to the issue. Comments rarely reflect the state of affairs if the code they refer to is changed. This is where they become misleading. Having lots of comments in a code base is definitely a code smell if you ask me.

Well named variables, function names and classes, together with an occasional comment about non-obvious side effects should be preferred.

I'm new to Rust and I don't think I will stay too long with it. There are some major problems with it:

• lack of proper IDE with debugger
• questions/answers on SO very quickly become useless. Recently I saw a few question where people said "it worked before upgrading rustc/cargo". It has to stop. Code that is 6 months old, HAVE TO compile on latest cargo/rustc and on one that will be released in 3 years.
• doc.rust and rustbyexamples provide snippets that... don't compile or trigger compilation warnings. Those sites should at least tell that warning is expected and describe or link how to fix it properly.
• Problems on SO become tagged, &quot;how to in rust 1.1&quot;. I have to make more searches now... is the answer is still up to date? is there a better way of doing it one year later? two years later?
• existence of some creates that claimed "important"/easy googlable name, that say to deliver functionality, but the functionality was never finished or crate is buggy and support was dropped over a year ago. On my example, there is no reliable .properties file reader. Two most popular are buggy and no longer supported, so it was easier for me to write own parser.

If the described goals won't be reached asap, people like me will just get bad taste of Rust (it's my second approach after 2 years break).

Also, minor thing, but cargo used to compile on freebsd 32, it doesn't compile any more...

I'm reminded of functional reactive programming. That would normally necessitate a communication channel of some kind between the UI and the code doing the work.

Could a UI be designed as top-down updates in response to events in an event queue? Would that be too slow?

edit: I found a white paper describing the FRP design in ELM.

If I recall correctly there is a misoptimization in LLVM that led to temporarily disabling sending all this aliasing information to LLVM. In addition, I don't think annotating pointers as non-aliasing is currently possible except for function arguments (see here).

This might not be the answer you want: I would suggest learning other languages to appreciate Rust's design better.

Some exposure to Haskell would help you understand some of the functional things in Rust: iterators, immutability. And the type system thing -- Haskell's type system is regarded as one of the best! A good introductory (yet not that easy!) book is Learn You A Haskell.

Some exposure to Go might help you understand this composition/inheritance thing, because it forces you to use composition only. Go will also make you think sanely about concurrency: you will value channels and message passing instead of shared state + locks.

As for language-agnostic books, popular recommandations are: "Code Complete" and "Pragmatic Programmer: From Journeyman to Master".

I would also say that it's not a matter of CS degree because most degrees don't teach you those things anyway. You're on the right track for the real education: be curious and learn by yourself :)

It should also be noted that while this is true, it's immaterial to the discussion here, since we're trying to figure out why Rust and Swift have differing performance characteristics on this naive Fibonacci.

You could do it in "constant time" too. See https://stackoverflow.com/questions/6037472/can-a-fibonacci-function-be-written-to-execute-in-o1-time for details (though look at the second answer)

Welcome! Head over to #rust-beginners on irc if you ever need help. It works best if you ask with a simple example of your problem posted on https://play.rust-lang.org/ :)

It appears to be a GUI design tool (sort of a middle-ground between Visio and Inkscape. See also Pencil) with a real-time collaboration backend similar to Google Docs or Etherpad.

Learning to read LLVM IR is a must - even after we start doing our own optimizations, we'll still be using LLVM primarily for at least one or two years.

The most important thing is probably to figure out what you can remove: the LLVM IR has lots of extra information, but is a RISC at heart, with pseudo-infinite registers.

Once you learn to scan through it for information you need, and maybe do diffs to see the effect of a code change in the IR, it can be easier than x86 assembly.

The LLVM &quot;language reference&quot; docs are good enough for understanding almost all of it, especially the more common bits.

I should write a blog post about this sometime, but at least three things...

Relying on external crates is tough, because we don't want to be perceived as biasing the ecosystem. Imagine a parsing project. Do we pick nom? pom? pest? combine? Is picking one fair? This requirement is really tough, given how much of the Rust experience relies on using external crates.

There's a higher degree of obligation to be thorough. We cover 99.99% of the language in the book. This means space is at a serious premium; TRPL is 520 pages already, and it's often pretty light on explanations. Consider a book like Step Ahead With Rust. It pretty explicitly states that it's not covering everything, but its goal is to get you to the point of literacy where you can understand other resources. This means it's much lighter, and therefore, a bit faster paced.

Related, I can't assume anything about the background of readers, which means it has to be pretty broad. I could write a very different book if C programmers were the only audience I cared about, and same if it were only Ruby/Python/JavaScript programmers. That balance is really tough.

> All the software engineers I know, myself included, generally change projects after a couple years (say, 3 to 5). At some point you need a change of scenery, you wish to explore new challenges, ...

While this is true of most developers, I feel like in some of the bigger, broader reaching projects, core developers tend to stay on for a long time. Linus Torvalds has been involved in Linux for more than 25 years. Larry Wall and Perl. Guido van Rossum and Python. Matz and Ruby. Bjarne Stroustrup and C++.

With Rust now having lost two former project leaders, Graydon and Brian, I wonder a bit about whether something about the project structure and community is more prone to burnout than other projects.

Of course, the project is in plenty good hands; I just hope that the project can continue to retain, and attract new, contributors as welcoming and inspiring as they have been.

True, but there is a case to be made for non-full-fledged browsers. Simple browsers like links or dillo, where users are happy to trade assured website compatibility for very low resource usage or simple UX. Or quickly displaying known-reasonable pages, like a user manual or generated rust docs. Lots of software embed an overkill rendering engine for those tasks.

This is a proprietary editor. Also from https://code.visualstudio.com/License

For this pre-release version, users cannot opt out of data collection.

I don't know why people are so hyped on this, seems really stupid compared to existing editors.

Hey! I got to chat with Bryan Cantrill, and we got to chat a lot about Rust, embedded systems, and our experiences at Ferrous Systems and Oxide Computer using embedded Rust in production.

Most of my episodes mention Rust, but this one really focused on it, so I wanted to share it here. I'm happy to answer any questions, and if anyone else is interested in chatting with me about Rust or anything else, my calendly is always open!

Go did recently acquire type aliases in the same sense as Rust's type aliases, in that they are purely syntactical aliases and do not correspond to separate and distinct types. Type aliases in Go (type Foo = Bar) are not often used, and IIRC, the original motivation for adding them was as a tool for refactoring.

As far as I can tell, the OP is using "type alias" incorrectly in Go land. Type aliases in Go (type Foo = Bar) have the same semantics as type aliases in Rust. The probable source of confusion is that since type aliases were added somewhat recently and rarely used, I believe folks have often referred to Go's newtype pattern (type Foo Bar) also as "type aliases." But they are not aliases and are indeed new types (in type Foo Bar, Foo is a distinct type from Bar). Go also has some additional rules around assignability that can blur this line a bit more, but usually Do The Right Thing.

In my experience, neither language really "wins" on this particular and specific front, but there are definitely some interesting differences in expressibility when it comes to encapsulation, which is something you often want to do with newtyping.

for those that aren't familiar, note that Nix (the package manager) can be easily and safely installed and used on Ubuntu, MacOS, Arch Linux, etc. - it has no dependency on NixOS (the linux distro). So you can try this out! Start here https://nixos.org/nix/

Just going off of this test, it looks like Alacritty supports truecolor/millions of colors. Which is awesome. Can we add it to https://gist.github.com/XVilka/8346728?

Yes it does (support virtualization) and yes docker will (very soon) work on those.

It’s still unclear if it will support x86 containers (through emulation) in addition to arm64.

https://www.docker.com/blog/apple-silicon-m1-chips-and-docker/

for anyone who don't know what GNOME Builder is,

https://wiki.gnome.org/Apps/Builder

https://github.com/chergert/gnome-builder

please help him to integrate Rust in to Linux App development

Rust is actually better than most languages in that respect. If you want to hack on a browser, there is Servo. If you want to hack on an operating system, there is Redox. Not many languages can claim that.

Malicious eslint packages were published that stole your NPM credentials. If eslint were run in a sandbox disallowing HTTP requests, this wouldn't be as problematic. https://eslint.org/blog/2018/07/postmortem-for-malicious-package-publishes

One are that hit me late in the game with a "traditional" web app of mine is how insufficient is the whole auth/authorization support. I even consider move to https://auth0.com just for this.

The thing is that security is not the forte of many, and you need someone with the proper skills to vet decision, but I think a "pluggable" auth flow is a necessary thing on the ecosystem.

Bragging time. I've worked on a Arm64 hypervisor implementation before Qemu could support the virtualization extension or any actual hardware was available for it (there was one Arm FPGA prototyping board but it was too expensive for us). I wrote it entirely by looking up things in Arm ARM, and was only able to run it after we've got our hands on a first consumer-grade Arm64 board. IIRC it required couple of fixes but was running smoothly afterwards.

From The Pragmatic Programmer, Tip #8 "Invest Regularly in Your Knowledge Portfolio":

> Learn at least one new language every year. Different languages solve the same problems in different ways. By learning several different approaches, you can help broaden your thinking and avoid getting stuck in a rut.

Rust makes different tradeoffs than other languages-- for example, I come from primarily using Ruby and I'm enjoying the brain-stretch I get from Rust's static typing, ownership, and lifetimes. It's also teaching me about lower-level systems programming, which will enable me to write faster code than Ruby does, and its safety means I'm not terrified like writing C makes me :)

There is an extremely elegant solution in the hacker news comments on this story, if anyone hasn't taken a look at it:

for i in range(1i, 101) { match (i % 3, i % 5) { (0, 0) => println!("Fizzbuzz"), (0, ) => println!("Fizz"), (, 0) => println!("Buzz"), _ => println!("{}", i), } }

Credit: https://news.ycombinator.com/item?id=8447267

TypeScript has a sophisticated system of <em>type guards</em> and <em>narrowing</em> that allow it to type-check common dynamically-typed patterns in JS code.

An example from that documentation page:

function padLeft(padding: number | string, input: string) { if (typeof padding === "number") { // padding has type number here return new Array(padding + 1).join(" ") + input; } // padding has type string here return padding + input; }

Notice that the type of padding is not just narrowed within the if body, but also in the subsequent code (because the if body always returns).

To write the equivalent in Rust you would need to be more explicit about introducing enums and pattern-matching, which has its relative merits and demerits.

Congratulations on introducing Rust in your workplace! That's definitely an example I'd like to follow :)

I see that Avast isn't listed on the Users of Rust page: https://www.rust-lang.org/production/users

Since from your post it appears it's using Rust in production; maybe it should get its entry?

https://www.rust-lang.org/en-US/faq.html#project

> What are some non-goals of Rust?

> 4. We do not intend to be 100% static, 100% safe, 100% reflective, or too dogmatic in any other sense. Trade-offs exist.

Of course, to align incentives properly we wouldn't penalize the discoverer of a severe safety bug if they helpfully disclosed the bug prior to the contest (here's a regular reminder of our security disclosure policy: https://www.rust-lang.org/en-US/security.html ). I would encourage the authors of any such underhanded submissions to note their disclosed discoveries in the submission explanation, as I wouldn't expect our judges to have perfectly memorized the discoverers of individual memory safety bugs.

I think there's a bit too much whitespace, it's a bit too spread out and feels poorly balanced. In particular the space under the heading blurb looks too big, like there's something missing.

Not a fan of the typography. The coloured half-height backgrounds on the headings makes already fairly annoyingly wide-fonted text even more difficult to read by adding additional unwelcome noise for my eyes to work to ignore.

There's an annoying mix of text that seems too small (the blurb in the Why/Build it in Rust sections) and text that seems too big (Rust in Production). Ironically the small bits have a better argument for being big than the big bits do (they have lower-contrast backgrounds to overcome).

The garish background colours don't help (and most of it seems to turn into a dirty grey colour for colourblind users). Looking at the beta site in comparison to the old one it's noticeable how my eyes relax on the more conservative design. Blasting big chunks of green and red at me does not make me want to point my eyes at what you've written.

The lack of code examples up-front is bit of a show-stopper too. A good example is worth a million breathless "Rust has great $x" sentences. And I don't mean the terrible example on the existing site - oh boy, this language makes it easy to match on magic numbers. The D site is more like what I want to see.

Some of the alt text looks superfluous. Like the WebAssembly icon having "gear with puzzle piece elements" - a good rule of thumb is to write what you'd put there if images weren't a thing. In this case it's just a bit of visual style to support a heading, so the alt text should almost certainly just be "".

Please don't target="_blank" me. I'm more than capable of opening a tab all by myself.

The get-involved section has an unclosed div in the header - some HTML validation probably wouldn't go amiss.

I really wish they'd not make the same mistakes Unix made - especially with respect to naming. Naming things tcpd and /sbin is just awful. I imagine everyone reading this is very familiar with Unix and can probably barely remember the first time they read /etc and thought "WTF is that? Why isn't it called /config?" and they you would find out that the only reason is for compatibility with punch cards and teletype (or some rubbish like that) and think "Oh I hope one day someone will write a new operating system and give it sane names like Apple did."

You don't have any compatibility concerns. Please name things clearly and sensibly!

There are other mistakes that look like they are being repeated - reliance on environment variables like PATH, overuse of text based config files.

Sorry to be negative - this really looks like a great effort but I doubt there is going to be more than one new Rust based OS so I think it is important to not just make "Unix written in Rust" along with all its mistakes.

It took a few tries for me to pick up Rust to stick. The resources on https://www.rust-lang.org/learn helped tremendously, along with some on https://cheats.rs/#links-services and the feedback I received by showing my code to friends and chats.

I gotta ask.

Why does everyone keep reinventing the RSS feed? I've seen dozens of people working on this exact project, but never figured out what the benefits are over already built, tested, and deployed solutions like FreshRSS.

tmux deals with this by waiting for x milliseconds - if another key is pressed within that time it is interpreted as <Alt-key> otherwise <Esc> then <key>

https://github.com/tmux/tmux/issues/131#issuecomment-145853211

People that would be scared off by Rust's CoC are people that would have scared off other people.

You have to make a choice -- adopt and enforce a CoC and scare off jerks, or don't adopt a CoC and scare off people who don't like jerks.

Rust is the only programming-related community I've been able to participate in for longer than a month, and a big part of that is the CoC.

>they perceive the political and social agenda of the community as being inherently bigoted, racist, and toxic.

Just to be clear, we're talking about this Code of Conduct. Can you help me understand what in that CoC could be considered "inherently bigoted, racist, and toxic"?

If your colleagues like numbers, I love this one: one of the devs of Servo wrote a very interesting blog post about using Rust at Mozilla. She analyzed all the critical bugs that ever occurred in the styling component of Firefox, and found out that 51 out of 69 of them (that's 74%!) would not have been possible, had Rust been used since the beginning.

> In the end, I want working on the frontend to feel like working on a web app, so that it's familiar to web developers, follows best practices, etc. We already have, as a project, many ties to Ember, and so I chose it mostly because it feels like a solid, default choice.

I don't particularly enjoy working on web apps so that's probably part of my objection :)

>One thing that this could enable is a mode wherein you run rustdoc in the background, and as you tweak your code and the docs, it automatically updates in your browser. It won't do that today, but the way it's built fundamentally makes this possible.

I don't see any reason that would be incompatible with static pages. Hugo has "hot blog reload" and it generates static pages.

Please don't take my comment the wrong way. I'm very, very happy rustdoc is getting some much needed love and decoupling it from the compiler will make it massively better! I just don't think that rendering static documentation warrants the technical complexity of a web-app framework. It seems to me that using an existing Rust templating library would be sufficient for rustdoc.

For those of you who only read the comments, here's a link to the Google group:

https://groups.google.com/forum/#!forum/rust-networking

And you can also find us on #rust-networking over on irc.mozilla.org.

If you're using IntelliJ, I'd say use Windows. If you're using VSCode, I'd say install it in WSL then use the WSL Remote plugin.

IntelliJ's Rust plugin is probably better than VSCode's for pure Rust development, but with VSCode + WSL you get the more generally polished Linux development experience.

You're going to need a certificate, which you can get for free from Let's Encrypt.

Unfortunately I can't help you with hyper because I've never used it, but in general you'd tell your server to enable TLS and point it to your certificates. This might just be what you need.

N.B. Unless I've missed one, there are four C++ submissions for regex-dna, and none of them use glibc. Two of them use RE2 (where one is parallel and one is not), one of them uses Boost.Regex and the other uses Boost.Xpressive. Rust's regex engine has a similar implementation as RE2 (but does better on this benchmark because of more aggressive literal optimizations). IIRC, Boost's regex implementation uses backtracking, but I'm not familiar with the kinds of optimizations it does.

C++ overload resolution can be used to perform compile-time pattern matching on types. It can also perform arbitrary compile-time calculations as part of this pattern matching. For example, a different overload can be selected based on whether an integer type parameter is prime. Since C++11, the calculations can now be performed via compile-time function evaluation, rather than instantiating types recursively. C++14 (which clang implements) relaxes the restrictions on CTFE quite a bit too, so it no longer requires strict adherence to recursive algorithms.

The power of templates can be used to encode complex invariants like arbitrary combinations of units with arbitrary dimensions, type-safe generic tagged unions and even features like pattern matching. Rust is explicitly designed to deny this kind of power by forcing the usage of trait bounds. It has more features baked into the language itself to make up for this (sum types, pattern matching), but libraries have much less power.

Rust will likely gain support for neat features already in C++ like compile-time function evaluation, associated types, associated constants and integer type parameters. It will never have the same kind of power in the type system though, because it's not going to have this kind of type pattern matching via template instantiation and overload resolution.

As a C and C++ programmer myself, I always feel the need of something more from C and a lot less from C++.

Rust fill that niche pretty well.

The object system is amazing and one of my favorites so far, because it forces you to think on terms of data and the behaviour you attach to that data.

Also favours composition over inheritance. Which is a huge deal. No more those huge multi-layer objects that makes your head spin.

You also have _amazing_ projects like Tokio! which gives you an asynchronous future based multi-threaded non-blocking I/O engine. Which leaves Java, Go and Node.js on the dust.

It is also made for the long future. The world is shifting from bulk processing loads to low latency micro loads. Where everything should have the least amount of lag and customised per user. That is where GC languages don't perform very well.

And last, Ryan dahl, the creator of Node.js (which is one of the most popular software development framework on US and EU markets) choose Rust and Tokio to build the runtime of his current project and Node.js successor Deno (https://deno.land/)

Just as many people consider unique_ptr sufficient, I found many people consider something like ThreadSanitizer and Go's Data Race Detector sufficient. These people don't deny that Rust's guarantee is stronger, but they think it doesn't matter much in practice.

Source code is here.

Note that Acronymy speaks Cap'n Proto, not HTTP. It connects to the outside world through the Sandstorm platform.

With those requirements, I'd recommend Jekyll generated and hosted by GitHub Pages.

You just push your markdown to a repo and it'll update your site, they handle hosting and you can still use a custom domain if you have one.

Mullvad, the VPN provider, also uses Rust for at least their new client. No idea if they also use it at their servers.

I also use Rust at my company but I do not want to out my identity on Reddit since we are just a three man shop.

I don't think you really need to support the whole own PKI infrastructure for this. For testing purpose, you can create some self-signed chain easily, using openssl for example.
If you want your server to be public, letsencrypt.org is the first place to look for the certificate, It's free and relatively easy depite some domain validation dancing.

> Go is better

Oh no. Go is not better. I've tried porting Go to FreeBSD/aarch64. Go is terrible for portability. The "use syscalls directly" approach requires huge effort to port to a new platform. The custom assembler is just bad.

I thought it was a nice read! Even though I sort of knew a bit of the concepts you talked about, I definitely learnt something with the way conversions and traits could be used, and how everything worked together. Now I'll end up keeping that in mind for any future Rust code, thanks :)

If you plan to write more, I would second the use of gists, or maybe even better, just markdown files in the repo instead of creating issues. Not that it really matters. You could also make use of github pages.

>I disagree, I have no problem with them choosing proprietary tools for their jobs. I don't care where you buy a hammer from if you're building a house.

It depends for me. In most cases I don't care because often it is only for some small part of the development, e.g. some part of the build system or documentation, or whatever.

In this case I care more because the quality of the open-source chat software is not as good as the proprietary ones, so I think it's important for rust to set the precedent. Additionally I think community engagement is very important and I do not think it's okay to exclude people who have privacy and freedom concerns.

Recall from OP that the Discord terms of service has this in it:

>By uploading, distributing, transmitting or otherwise using Your Content with the Service, you grant to us a perpetual, nonexclusive, transferable, royalty-free, sublicensable, and worldwide license to use, host, reproduce, modify, adapt, publish, translate, create derivative works from, distribute, perform, and display Your Content in connection with operating and providing the Service.

I think that's pretty strong, and you are giving over a lot of rights to Discord. I can't blame anyone for not wanting to hand that kind of control over.

>Especially considered the focus on inclusion in the development process.

Yes actually this is directly against the code of conduct https://www.rust-lang.org/policies/code-of-conduct

>We are committed to providing a friendly, safe and welcoming environment for all, regardless of level of experience, gender identity and expression, sexual orientation, disability, personal appearance, body size, race, ethnicity, age, religion, nationality, or other similar characteristic.

> As we are based in a regional town (in Oz), we find it very difficult to find good developers

I get the impression that many of the people in here may be overlooking the sheer difficulty of finding experienced developers in small urban areas (though maybe your area is not so remote as you make it seem?). I grew up in rural Appalachia, and my first programming job was in Middle-Of-Nowhere, Pennsylvania, at a company that had spent a year trying to find any candidates with prior programming experience, any at all, without luck. I was fresh out of a CS degree (fortunately for me, no employers realize that computer science != programming) and my resume wasn't on the market for eight seconds before it was snapped up by a recruiter who ~~begged~~ asked me to interview for this firm. (The job involved writing RPG-LE, a legendarily arcane language that hasn't been taught in schools since the early 90s, but the only pertinent interview question was "have you ever heard of, or--be still, my heart--used HTML before?". Their expectations could not have been lower.)

My point is, OP, if you really live in a place where you can't hire experienced devs, then you can ignore the arguments in here about finding good Rust devs in a pinch. Teaching a fresh new programmer Rust is going to be an order of magnitude easier than teaching that same programmer C++, even if that Rust codebase uses unsafe code liberally, which I assume any embedded project will.

Of course, there are still plenty of other persuasive arguments against using Rust, especially if your domain is safety-critical (though I'm not sure that specific argument is in favor of C++ either).

I feel like I've linked this page about a thousand times this week, but if you're still looking for testimonials of companies that have had positive experiences using Rust, see https://www.rust-lang.org/friends.html (you can mouse over each logo for links to various blog posts and code repositories).

In Python, it'd be the core of Twisted that would be most like Tokio... though you could also look at Tornado in case its docs make something click for you.

In-browser JavaScript, Node.js, Go, and Erlang are fundamentally built around async programming in various forms.

I never had a need to do async in Perl, PHP, Java, C, or C++, so I can't help you there.

After 3 months of working as a complete beginner with Rust and GTK, I must say that this combination is quite pleasant to use.

I use Glade to set up graphical elements(just drag and drop) and then code them which really decrease amount of work with GUI.

So far I've only created one application with about 4000 lines of code using GTK https://github.com/qarmin/czkawka/tree/master/czkawka_gui/src.

> In particular, I wonder what would have happened if I tripped one of the things described here.

Undefined behavior in Rust is pretty much as undefined as it is in C/C++.

I just happened to fix a bunch of it in a project.

The program seemed to behave correctly ever since these were introduced (more than a year), up until today, when compiled with the new rustc nightly, it started doing nonsensical things. Not even valgrind could detect the dangling pointer accesses.

Agree, nothing personal here.

Ogre3D sadly not part of GSoC 2014 (but they're part of GSoC 2015)

Also Blender3d been rejected as well.

I actually have to use Scala at $dayjob, after all this time with Rust...

Overall the FP stuff translates quite well, and because of that I enjoy it overall. But there is plenty of smaller problems.

Scala embraces FP and wants to have all the complexity possible included. This sometimes comes with total disregard for real-life practicality. Eg. implicits. Stuff can start misbehaving because of some random import. Plus AFAIK, the compilation time suffers because everything can interact with everything else.

First, the Java ecosystem is annoying. Things are always slow, JVM is running out of heap, and it's hard to just get stuff done with Vim. And xml ... xml everywhere...

Documentation and UX is nothing like Rust. The tooling is much worse with the exception of the IDE. Too bad for me, that I don't like IDEs, and would like to stick with Vim... :D

The null is still there...

Tiny thing that infuriates me is that

foo( bar, x, )

won't work (trailing comma).

Trying to have a DSL everywhere... nope. I don't want to. http://www.scala-lang.org/api/rc2/scala/sys/process/package.html

import scala.sys.process._
"ls" #| "grep .scala" #&& "scalac *.scala" #|| "echo nothing found" lines

IMO, terrible idea.

As the author of the original brainfuck interpreter, I just tried to port it to latest Rust using associated types, but I keep running into what I think are bugs. For example, my latest version seems to have sent rustc into an infinite loop :)

EDIT: I got a slightly modified version of the original version (with no associated types) working. Just need to add dummy type parameters:

https://ghostbin.com/paste/vnjmh

I gave up on the associated type version.

Very nice! The implementation seems to be by Trevor Perrin, who designed Noise and the Axolotl/double ratchet protocol as well, which is being used by Signal and Whatsapp.

Edit: Whatsapp does use the Noise protocol, see their whitepaper.

The online Rust book is available as a good old-fashioned dead-tree edition. Note it obviously won't be as up-to-date as the online version, but for learning the fundamentals of Rust, it should be just fine.

Interesting, based on stack overflow my interpretation of the paterson conditions is that they make blanket impls illegal. I also learn that Haskell essentially doesn't look at any where clauses when checking coherence.

Both of these seem like very important features for the way Rust uses traits, and I wouldn't think of trading them away for decidable typechecking.

Hello people,

I am the site's author. First of all, thank you a lot for your feedback. I have updated the site copyright regarding your suggestion :) Thank you!!!

Story: I remember I purchased the "BuiltwithRust.com" domain at the night Rust Alpha 1.0 release (after spending half of the day browsing and looking for Rust projects just for fun). My intention is just trying to collect as much as projects that I think it is useful and cool and put them on the site to showcase the Rust lang. And to make it look more "formal", I thought I should write something "about" the site and arbitrarily put the Copyright footer-redirect to Rust-lang.org (I really thought it all means to credit the Rust-lang site's authors), I am so sorry for the confusion guys. I'm sorry.

I wake up this morning and checked my email, oh wow, I got 3 first submissions which makes me want to put some more time on the site. Thank you sanxiyn for introducing the site. I welcome for new submissions and I promise I will continue searching for more Rust projects frequently. P/s: thanks for your submissions and feedback.

Something like this?

The arg_object argument takes an object spec, so you can cat it straight out of the git repo.

millicores are one of the standard ways of specifying CPU resource limits in kube, so that is indeed where they got it