Rust 1.1 Stable, the Community Subteam, and RustCamp | Hacker News Reader

Rust 1.1 Stable, the Community Subteam, and RustCamp

blog.rust-lang.org

287 pointssteveklabnik140 comments

The 1.1 release came out a day earlier than I expected, I suppose we're releasing on Thursdays now. :P Note that 1.1 is a relatively small release, since, due to launching the train release model, it was in development for just three weeks prior to 1.0 (rather than the usual six weeks that all subsequent releases will have spent in development), and during that time we were all understandably in a tizzy preparing for a post-stability world. :)

However, despite that short and distracted development window, we still managed to squeeze out compiler performance improvements that should result in 30% faster compiles for crates in the wild. You can expect even more progress on the compilation speed front for 1.2, due to be released August 6, along with a slew of stabilized and much-demanded stdlib APIs.

Let me also mention that tickets have just gone on sale for the first official Rust conference, a small one-day event in Berkeley: http://rustcamp.com/ We'll be using the experience from this proto-conference as a guide for larger events in the future, so even if you can't go we'd love to get your feedback as to what you'd like to see from a Rust conference.

If I wasn't going to be on vacation during that conference, I would be strongly tempted to go, and I haven't written a line of rust. I get excited about every rust submission I see on HN though, and greedily gobble up as much information as I can. I can't help it, Rust just excites me.

So, whatever you guys are doing, WRT marketing, you are doing something right.

What I like about rust is how I think it will go together really well with a language like idris. The idea is, whatever rust cannot guarantee an idris-to-rust transpiler can. People should have a much easier time making solid low-level code in the future.

Idris is already more safe than Rust. What would this give you?

Unfortunately safety is not the only concern. Idris' tooling is severely limited. There are very few executables written in Idris (and even fewer that aren't bit-rotted), the build tooling and package management are very simple, the runtime is heavily optimized, concurrent or parallel (like GHC's) and the single-threaded performance is far from Rust's.

I want to be clear that I'm not hating on Idris I love the goals of the project and am probably one of the few people outside the core contributors who has written a backend for the compiler, but you can't really compare a production quality compiler with a full time team of 10 or so to a research compiler worked on by researchers (who have different goals) and volunteers.

Edit: To clarify for this reason I could see why it would be cool to be able to write some critical code in Idris and extract to Rust where you could get performance and tooling for the rest of your application.

What about Rust and Idris make them go together? Or how would they go together?

https://hackage.haskell.org/package/atom

Imagine atom, written in idris, and compiling to rust. Things like that.

I can't really imagine rust being a better target than C-- or something at that point, as you've got an infallible machine managing your memory already. If you output code that is rejected by the rust lifetime checker, you've still got a problem.

Rust as a target for projects like atom instead of C could lead to easier/safer/faster atom development.

Sorry, it took us a while to find a venue and pull together initial sponsorship funding (ultimately provided by Jane Street, Skylight, and Mozilla), which resulted in us only announcing the date of the conference about a month ago. Next year we should be able to announce much further in advance, so maybe you'll be able to schedule your vacation around it. :)

1.2 (which was stabilized today) is also a mostly-quality release (`const fn` and associated constants landed behind a feature gate, but are still not-really-done).

Indeed, the 1.2 development cycle was relatively sleepy as the preceding six months were spent in crunch mode preparing for 1.0, and everyone was eager for a bit of summer vacation. :) A lot of this cycle has also been spent prioritizing for future language development and organizing the new subteams. But I'd still say that 1.2 managed to get a lot done, since there's just so much low hanging fruit wrt stdlib APIs to stabilize.

I'm happy things are moving along, but I would still like to see the documentation be more polished. I still don't know how to write a task queue (ie queue of closures) that executors can concurrently read and run from.

I don't feel like the docs empower me enough to write multi threaded code comfortably without the borrow checker spitting at me. Is it just me, or does anyone else feel this way?

When you start documenting a language from scratch, you have to start at the beginning. A language is a huge project as well. The current book is about ~250 pages when rendered as a PDF. I've finally gotten to the point where the basics of almost everything have been documented, and am starting to move on to more intermediate style things.

In addition, we've only had a stable Rust for six weeks: there just hasn't been enough time to write more advanced things. Nobody wants to invest in stuff while things are still changing. As an example of this, I know there's an O'Reilly book coming out in the fall which covers advanced topics exclusively.

A basic task pool isn't too many lines of code: https://github.com/rust-lang/threadpool/blob/master/src/lib.... Hopefully that can help for that case, though obviously, this isn't just a comment about threadpools :)

I love the rust docs, but I do agree that the intermediate/advanced stuff is missing. I won't feel like I truly understand until I can implement a bunch of different datastructures, and it turns out that that is exactly the kind of code that throws up lifetime issues that as a beginning rust programmer I'm not really prepared to deal with.

I'd love a 'learn to write rust with datastructures' style intermediate tutorial.

You may also be interested in this post[1] by nrc for a couple of strategies for implementing graphs. And this companion[2] by Niko Matsakis.

[1] https://github.com/nrc/r4cppp/blob/master/graphs/README.md [2] http://smallcultfollowing.com/babysteps/blog/2015/04/06/mode...

You might be interested in https://internals.rust-lang.org/t/the-unsafe-rust-programmin...

I don't want to make you rewrite this if you've already answered this elsewhere, but...

Could you provide some pointers about how to begin with contributing to the Rust documentation? What are the areas that need the most help or have received the most complaints/confused reactions? I actually like writing docs but I'm not sure where I'd begin. (And of course not super confident in my understanding of Rust in the first place since I'm still learning it myself. But I know a lot more than someone looking at it for the first time.)

I'd love to have some contributions! One easy way to contribute is to find something that doesn't currently have any examples, and add some. http://doc.rust-lang.org/stable/book/documentation.html is a basic guide to writing docs, and I'm quite happy to workshop a PR with some basics into something more.

Currently, the areas that need most help fall into two categories: intermediate/advanced docs, and API documentation. The latter is an easier place to get started, I'd imagine. Hence my suggestion of examples.

We also have the A-docs tag: https://github.com/rust-lang/rust/issues?q=is%3Aopen+is%3Ais... Some of these are actually pretty easy, I tend to let the pile up and then knock out 10+ in a day if nobody else gets them first.

I can get more specific than that if you'd like, but I think that's a pretty decent high-level overview.

One thing you can do if you'd like to help with docs is to flesh out Rust By Example: https://github.com/rust-lang/rust-by-example . It began as a community project but was then adopted by the core developers at the behest of the community, but it's seen much less love than the official docs. If you're interested you'd be largely free to make it your own. :)

Thank you, you're doing a great job!!

Thank _you_ :)

I have another exciting documentation-related announcement in the pipeline, but I'm currently waiting on some lawyers...

You need a non-blocking lawyer queue.

i.e. a cliff?

Better call Saul!

I really love that you can (have?) put tests in the same file as the threadpool implementation. I think I will start doing this myself...

Rust convention is to put unit tests in the same file. I like it too :)

Also, doc comments run as tests too, so https://github.com/rust-lang/threadpool/blob/master/src/lib.... will actually get executed as a test.

I hope the Rust team also starts prioritizing compiler crashes.

I started using Rust exclusively for hobby projects after the 1.0 release, to force myself to learn the language, but I found myself running into compiler panics on nearly a daily basis.

Admittedly, the code the compiler tended to crash on was very macro-heavy, but a goal of rust is safe macros. (And even if the macro-expanded code was invalid, the compiler should just report an error, not crash).

There are currently 207 open issues regarding ICE (Internal Compiler Error): https://github.com/rust-lang/rust/labels/I-ICE

It's definitely something to work on, but note that the Rust compiler tries hard to eagerly crash rather than possibly generate broken code. I'm very pleased at how few codegen-related bugs have been found since 1.0.

It's not perfect, but https://github.com/rust-lang/rust/issues?page=1&q=is%3Aissue... seems to indicate that we closed 81 issues tagged ICE between 1.0 and now. Not all of those made it into 1.1, bunches are in 1.2, and some of them are duplicates...

If you're running into ICEs or any other bug, please either open up a ticket or :+1: the ticket that exists. It helps to know which things are biting people more often.

Just to note that by far and away, the most common cause of an ICE is a missing error message. Others are related to unstable features, which isn't particularly fair, since they're unstable for a reason. The remainder tend to be caused by odd combinations of features we didn't think of (which more often than not tend to be constructions with simple, working equivalents), often they become a question of "do we want to support this or not".

Trust me, there are far worse things lurking in the compiler than a few improperly-handled error cases.

I've seen this complaint about the Rust compiler a number of times now, here and at other sites. Isn't one of the main selling points of Rust that it's supposed to make it much harder to write code that crashes? It is my understanding that the Rust compiler is mostly written in Rust. While maybe these ICEs aren't traditional segfaults that can be exploited, they're still unexpected crashes none the less! The software stops working without warning. If the best Rust experts around have so much trouble avoiding those kinds of crashes, then how is an average Rust user, or even a complete beginner like me, supposed to write Rust code that's any less susceptible to crashing?

Steve has hit this on the head, there are lots of places where we are using older abstractions that we have had to slowly refactor out of the compiler and like all other software development this won't be instantaneous. We definitely have some less then optimal code in the compiler from a design standpoint.

I think it is also important to recognize that all compilers have this problem and they all stabilize over time. It is an issue orthogonal of safety. These aren't segmentation faults or some kind of memory error but the compiler signaling an internal invariant was violated.

This can happen easily because we are writing a very large program that reads user input, interprets it, and tries to emit a program.

This can happen in multiple situations. One example is the compiler may have a logic bug that violates an internal invariant resulting in an ICE (instead of emitting incorrect code).

Other times it is as simple as the code we have been given is invalid and the error wasn't properly handled, and you end up seeing it in a non-user friendly way (as an ICE).

We are working hard to move the compiler to a more modern, robust design as soon as possible but even with a great design it will be an iterative process that we continue to do over the lifetime of the language, just like everyone else.

TL;DR: don't underestimate the power of technical debt.

Longer answer: The Rust compiler was written in Rust before the Rust language was even what it was today. As one particular example, the AST used to be garbage collected! And when you have a codebase that's 320,000 lines long, you don't update the entire codebase to the latest idiom, because if you did, you'd never actually ship the language.

Basically no other Rust program will ever have to contend with this kind of situation. As such, while I can sympathize with this line of argument, I don't think it's representative.

EDIT: I previously had 750,000 but it's actually 323,326 LOC as of right now. Whoops!

Legacy code and inexperience with new technologies are not problems that are unique to Rust and the Rust compiler. And presumably Rust will continue to evolve, will it not? If my team starts a large, multi-year project using Rust 1.1 today, does Rust offer anything that will help us avoid the sorts of crashes that the Rust compiler suffers from?

Just to expand on what Steve said.

An evolving language is one thing. Pre-1.0 was more like many stages of violent metamorphasis. Some changes to the language required changing almost every line of code in the tree. Normal technical debt is when you find an old approach doesn't work any more and you need to fix it. Much of rustc's technical debt is from things like features disappearing from underneath it, or things designed before the features that you would use now even existed.

Looking at rustc as a regular large Rust project is unfair. A new project can at least assume that the features you are using today will exist tomorrow and design with that in mind. Your designs may become obsolete due to new features, but you aren't going to have to pick between a hacky workaround and a redesign/rewrite of 1000's of lines of code.

Your language changing literally every other day is a problem unique to a pre-1.0 language. You're right that technical debt in general is not.

> And presumably Rust will continue to evolve, will it not?

Right, but it will evolve in a backwards-compatible way, rather than in a "the fundamental semantics of the language have changed Yet Again" kind of way.

Sure, Rust will continue to evolve. But many changes that happened in the past were on the scale of "Java 10 decides to get rid of classes".

ICEs are not crashes due to memory unsafety, they are logical errors in the compiler code.

For example, here's about the worst rustc crash I've found: https://github.com/rust-lang/rust/issues/21946. It doesn't even give you an ICE, it terminates with a stack overflow.

So no, Rust cannot magically fix logic errors in large, complicated codebases, but that's not something that a complete beginner needs to worry about thankfully.

That's just a vanilla "divergence" stack overflow - an essentially harmless consequence of the type-system's Turing-completeness.

You don't even need Turing-completeness, just any form of recursion will do.

Most crashes are in type inference, associated types handling, and error recovery, which are very complicated things, especially in combination. We also basically rushed features in for 1.0.0 (1.1/1.2 should be much better in terms of these).

1.2 is much less ICE-ey than 1.0 (the annoying "capacity overflow" macro ICE is no longer an ICE - it still prints "internal compiler error: unprintable span" but doesn't crash).

Have there been documentation improvements? For instance http://doc.rust-lang.org/nightly/std/str/ is still quite obscure: it talks about the traits returned by certain methods, but there isn't an obvious way to get to the documentation for those methods, if you'd like to know how .lines() is different from .lines_any(), for example. Compare with https://docs.python.org/3/library/stdtypes.html#str where all the methods are listed, along with what they do.

You probably want this page for str:

http://doc.rust-lang.org/nightly/std/primitive.str.html

It's unfortunate that most of the links navigate you to the less useful doc.

I'm getting bizarre rendering errors in chrome for whatever character prefixes "self" in all those (I assume &?)

If you have an old version of "Source Code Pro" on your computer, it will WRECK that page in a lot of fun and interesting ways.

You can either remove "Source Code Pro" from your box, or use Tampermonkey / Greasemonkey to remove it from the markup.

People were hitting that a few months ago, is this the first time that you've visited the docs in a while? In their case it was due to a problem with the page's font file itself, and it may be that your browser still has that version of the font cached. Maybe try a force-refresh?

Hmmm. Force refresh did nothing. It's possible I have Source Code Pro like the other commenter suggests. Dunno

I'd like to mention that I've been happy with the docs, once I learned to find them.

To take the given example, I would start at http://doc.rust-lang.org/std/ and hit `s` to start a search. Searching for `str::lines` gives http://doc.rust-lang.org/std/primitive.str.html#method.lines as the second result, which has the two methods conveniently next to each other, succinctly explains them, and shows an example of using each one.

I've had good luck with docs for the few third party libraries I've tried so far too. The recommended doc generation creates pages in the same format as the std docs, so as you get comfortable navigating them you get comfortable navigating many third party docs as well.

There have been a number of doc fixes, but they've largely been polish more than brand new things. I've had about ~50 PRs in this release myself, after a quick look, and we had a bunch of community stuff as well.

The specific issue you're talking about is due to using Markdown rather than ReST, basically. We didn't manually link those methods, but probably could.

In general, the API docs could use a lot of work. There's always so much more to do.

I'm glad to see Rust's progress. I'm still very interested in Rust, and incrementally learning the language. I do appreciate the documentation, IMO the developers have done a tremendous job in that respect.

One question though. When is Cargo going to be available on FreeBSD (and other BSD's)? I think these platforms are significant in the server space where Rust would be highly relevant. Having Rust usable there would likely augment uptake of the language.

I've heard progress on this front recently (it's mostly about the automation infrastructure), and I might expect official nightlies of both rustc and cargo for FreeBSD by the end of summer.

Don't hold me to that.

There are community builds to several of the BSDs, but we don't have CI running at the moment. We're working on ways to possibly provide infrastructure for community members to hook into to help make sure that the build is always green...

What exactly does MSVC support entail? For example, will one be able to debug Rust programs with WinDbg or the Visual Studio debugger? IIUC, that would require LLVM to output PDB files.

In addition to not interacting with the GNU toolchain at all (through MinGW), MSVC support will indeed enable native Windows debug info (as you mentioned) so native tools can be used to debug Rust code. Note that this isn't 100% implemented yet, but it's coming soon! Additionally you'll get interoperation with MSVC-compiled libraries. Libraries compiled with MinGW don't interoperate well with MSVC (and vice versa), so this enables Rust code to link against an MSVC-compiled native library.

(HN readers, note that alexcrichton is the one spearheading the MSVC effort.)

Will MinGW still be supported, or will that be dropped?

There's no plan to drop it.

https://github.com/rust-lang/rust/pull/25350 was the PR with the initial support.

    > The tl;dr; of this change is that there is a new target of the compiler,
    > x86_64-pc-windows-msvc, which will not interact with the MinGW toolchain at
    > all and will instead use link.exe to assemble output artifacts.

We're very interested in improving support so that you can use VS's features fully. These are just first steps.

MSVC support primarily means that Rust programs link with the MSVC toolchain, and use structured exception handling for unwinding. There are no GNU components involved and no need to install MinGW.

Impressed daily by the amount of stuff being done to advance Rust as an incredibly useful language.

OOh and there's a rust podcast out as well. You can find it in the new section of hacker news.

Just providing the direct link http://rustyrad.io/

Thanks for the heads-up. Here's the link to the story:

https://news.ycombinator.com/item?id=9779676

So I assume 1.x.x won't break features from 1.0? Is Rust using proper semantic versioning?

Basically, no, it won't. Rust still reserves some rights to break the existing code if the found issue is considered to be "severe" (e.g. type system soundness issues), but those cases should be extremely low. In most cases workarounds will be introduced rather than breaking changes. More details at https://github.com/rust-lang/rfcs/blob/master/text/1122-lang...

Also note that the Rust team tests all the crates before making a (minor) breaking change to see the impact of the breakage to the ecosystem. (possibly "popular crates only", when the ecosystem grows huge in the future)

Rust core team has taken the approach of breakage without major version increments being acceptable as long as they deem the breakage "minor" (based on crates.io and companies they have close relationships to).

I don't want to relitigate this issue again, but that's not an accurate description of the policy. If you tell us that one of the changes in a point release broke your code, then appropriate action will be taken, regardless of who you are. No organization is given special privileges regarding breaking changes based on "close relationships" to the developers.

It is true that Rust, like all actively-maintained languages, can make changes that are theoretically breaking if all evidence strongly suggests that no code is actually going to break.

Qualifying with "close relationships to" is misleading, as every company using Rust is welcome to sign up to receive new versions of the compiler to run against their codebases to test for regressions. See the email address in my profile if you'd like to add your company to our list!

OK -- replace "close relationships to" to "have emailed kibwen at his gmail address to get on a list".

If I could go back and edit I would -- but it has been too long.

Given Steve Klabnik's recent actions to suppress people who hold political opinions he does not like, I have a considerable amount of trepidation knowing he has a leadership position in the community sub-team.

Freedom of expression does not entitle you to freedom from consequences of your expressions.

My freedom to dress as I want does not mean it is reasonable to demand to be treated equally when I am wearing a garbage bag to a meeting.

My freedom to not shower does not mean it is reasonable to demand to be treated equally when I stink up the place. Instead it is entirely reasonable to ask me to leave.

If a community manager asks people who express toxic opinions to leave, that is entirely reasonable. It's their job in fact. And make no mistake, the opinions of others you have linked to as being "suppressed" are toxic, so much so that in many countries [1] they would be considered illegal.

[1] And I am talking about countries that rank significantly higher than the US on the press freedom index:

https://en.wikipedia.org/wiki/Press_Freedom_Index#Rankings_a...

And outscore the US on the freedom house report on both civil liberties and political rights:

https://freedomhouse.org/report/freedom-world/2015/germany#....

https://freedomhouse.org/report/freedom-world/2015/united-st...

So please save your "Europeans don't care about freedom of expression" tropes.

You'll get downvoted when you make seemingly opinionated statements with no context.

Downvotes don't bother me. Being ostracized from the Rust community would, however, hence the throwaway.

This attack on Steve with only tweets taken out of context as evidence seems pretty unfair to me.

Steve's been nothing but extremely polite and helpful in every interaction I've seen him have in the Rust community. He's only ever fought for inclusiveness and respect. How about giving him the benefit of the doubt, and admitting he's good for the community.

I believe he's already contributed a lot to the culture of inclusiveness and friendliness in the community that you mention you'd be bothered to be "ostracized" from.

Sorry Steve, I only have one upvote for this comment. Your help with sheparding the Rust community should be held as an example for other communities to follow. Many thanks.

If you feel as though any member of the Rust team is failing to uphold the principles of the project then you may contact the moderation team at rust-mods@googlegroups.com . Note that that is a private mailing list and that Steve is not on the moderation team (nor is any member of the Rust core team, by design).

Interesting, how was the mod team picked? I think it is a good check to have it be separate from the Rust team (assuming it wasn't picked by and answers to the Rust team).

The moderation team was conceived and designed by Manish Goregaokar, an experienced moderator from Stack Overflow and a volunteer for the Servo project. The original roster for the mod team was picked by Manish and the core team, though moving forward the mod team can expand its ranks on its own. Also notice that the moderation team has no formal leader, every member has the same amount of authority. One of their explicit goals is to police the other teams, including the core team, hence the requirement for disjoint membership between the mod team and the core team.

Uh, the team wasn't picked by me :)

(I also think part of the design of the mod team was done by Aaron, based off of my sketch of a design)

(I'm also not a stack overflow mod, I'm a mod on a couple of stack exchange sites -- though I have observed how stack overflow is moderates)

What exactly is the goal of the group? What does it mean that they "police the other teams"? This is just out of pure curiosity, I find the idea of having a mod team for a large, public project interesting but a bit strange.

Well, policing the other teams is just part of the mod team's responsibilities.

The design of the mod team can be found in the RfC[1].

The driving philosophy is to try and deescalate any situations which may crop up, either in situ or by privately discussing with the involved parties. It's easy to forget that the People on The Internet are humans too, so a technical discussion that gets heated sometimes needs a reminder to keep civil.

The purpose is to make sure that the code of conduct[2] is upheld online. Rust has had a CoC for a while now, but it wasn't enforced. This meant that users violating it in reality were free to continue violating it without much repercussions. And this had happened a couple of times; users were warned after being abrasive but no action was ever taken and it just got worse. The mod team can enforce the CoC by temporarily blocking a user from the project if warnings are ignored. Deescalate whenever possible, and if it doesn't work out, warn/act on the warnings.

Policing other teams is a part of it; the core team and subteams are also subject to moderation; which is why no core team member is on the mod team. In case of an ugly dispute between a core team member and some other user the mod team is a more impartial way of resolving it. Though in practice I don't think the core team would ever be in such a situation.

People often say that technical communities should stay technical and not worry about civility or other social issues. In my experience this rarely turns out well, aside from Rust I've seen this idea cause problems in other technical communities. Technical communities are, in the end, communities, and community health is something that needs tending. Maintaining civility and avoiding the exclusion (active or passive) of other users is a part of it, and that's something the mod team handles.

[1]: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust...

[2]: http://www.rust-lang.org/conduct.html

That seems... less good honestly, but gotta start some where I guess. Friends-network effect should grow weaker with time (or at first big drama blowup).

Would you like to cite a source?

https://gist.github.com/steveklabnik/7cd3267a631c4847c34d

amongst more

It is especially troubling to have a community leader who equates speech with violence, even "hate" speech, which in that gist is clearly demonstrated to be completely subjective.

That is troubling, but I don't see how that equates to him "suppressing" anyone, if all he's done is voice his own opinions about those people. I haven't really followed the story, but was Steve part of the group that demanded Curtis be removed from StrageLoop?

Worse even.

https://archive.is/BtDaA

I wasn't going to respond to this thread at all, but since you went to the trouble of using 100% of your comments on this account to post in this thread, and you're spreading this shenanigans, I'll copy what I said over at Lobste.rs:

--------------

[This link] takes a thing I said on Twitter and uses it to say something I don’t mean.

My twitter reply re: violence is based on the tweet it’s replying to: general activity by groups who call themselves ‘antifa’. I thought my parent was making a false equivalence, but rather than arguing with them about this false equivalence, I decided to just say ‘cool’ and bow out, hence my response. I believe “antifa are just as violent as the fascists” is wrong on multiple levels, but I don’t really care to get into it here, to be honest.

--------------

... and I still don't. That's all I'll be saying here about this.

Dude, you explicitly said you're "100% okay with [violence] personally"

You then said, "the only things fascists respond to is violence. Ignoring them or letting them attack you doesn't help."

You then linked to a Woody Allen video where he confidentially states a Nazi march in NYC should be attacked with "bricks and bats" rather than taking a civilized approach against them.

You explicitly endorsed violence against political groups you dislike several times, don't try to pretend like you didn't now..

It's the paradox of tolerance. Should a tolerant society tolerate intolerance? The fact that many think: "No we should not tolerate intolerance" is the apparant paradox.

Yeah first they came for the fascists, and I said nothing, 'cos I'm not a fascist... or wait, maybe I am by their far loco definition!

I'd be suspcious of anyone who wasn't ok with violence against Nazis...

Of course "Nazi" being anyone who doesn't go along with your bullshit.

Do you seek out KKK marches and assault them with bricks and bats then?

https://www.youtube.com/watch?v=CHChPftGDQ0

https://www.youtube.com/watch?v=IJ55KyNrO6A

It's not troubling at all, if you stop and look at it for a second - people aren't automatons.

Fascism is horrible thing in all it's form and sizes. Even if Steve blurted out that he agrees that the only way to fight fascism is with force (which I haven't divulged from the context, twitter is horrible for conveying meaning), it makes sense once you stop and consider it an emotional response and not an ideology of person that said it.

The troubling part is the equivalence between speech and violence. I fundamentally don't believe that information can be violent in any way. It can facilitate violence, surely (the plans to a nuclear bomb come to mind,) but it is never inherently violent because information in itself can do nothing.

   > I fundamentally don't believe that information can be violent in any way.

Then congrats on never suffering verbal abuse. Words can hurt and information in itself can do a lot of things in a right(or wrong) context.

For example. You arrive in a communist hating community (let's pretend it's during the Red scare). Someone accuses you of being a communist. Witch hunt ensues.

> Then congrats on never suffering verbal abuse.

define: violence "behavior involving physical force intended to hurt, damage, or kill someone or something."

It's clear that the meaning of "violence" is physical, not emotional.

> Someone accuses you of being a communist. Witch hunt ensues.

As I said: "It can facilitate violence, surely".

Listen, downvote all you like, but it seems you never were on the wrong end of verbal abuse. Trust me a well sharpened remark, can be waaaaay more painful than a gut punch.

I never said witchhunt needed to end with violence. You can become black sheep, losing job, family, friends without a single follicles of your hair being torn. Your freedom could be taken, without you suffering any violence, e.g. house arrest.

Looks to me like you'll be fine as long as you don't try to legitimize slavery, nazism, or harassment? Is that a problem? /s

Do you feel that mentioning the existence of slavery legitimizes it? Please do let me know. I won't bother with the rest as it had literally nothing to do with the topic, those examples were brought in as a rhetorical device to bolster what, on examination, was a totally unsupported accusation.

Moldbug did not simply "mention the existence of slavery."

He explicitly celebrated it. He talked about it being a natural order. He argued that "the innate character and intelligence of some is more suited to mastery than slavery."

This is pure, racist drivel. This is an evil way of thinking. There is a reason that racism, genocide, slavery are so abhorred in the modern world; they are poisonous ideas that have caused some of the largest atrocities history has known.

He also explicitly argues for a dictatorship beholden only to landowners: http://unqualified-reservations.blogspot.co.uk/2009/07/seces.... He admits that his influences and design are similar to those of the Nazism and Stalinism.

He is a fascist, arguing for a violent dictatorship, and arguing that slavery is a natural order. These are not mere rhetorical devices; this is the core of his argument. His entire argument is steeped in violence.

> Thus we may charge Carlyle not only with Hitler, but also with Stalin. Both dictators! You see what these dictators do.

> Of course, we are on equally safe ground in noting that both Hitler's party and Stalin's originated as political parties, and reading both genocidal maniacs as accidents of democracy.

I read Moldburg and I see an intelligent guy exposing the hypocrisies of politics left and right in an erudite, reasoned manner. I read yours and I see outright dumb slurs and lies.

Let's extend this to people who try to legitimize gulags, communism, and online mob action. Ban all Rust related shit.

Lovely. I have a problem with "communists in tech". Perhaps I should organize with my buddies on twitter and write angry emails to corporations that employ them, 'cos, durr hurr, it offends me!

And btw, this "legitimizes slavery" is bullshit. This is the article in question.

http://unqualified-reservations.blogspot.co.uk/2009/07/why-c...

While I find Rust interesting, how exactly will Rust deal with a 900lb gorilla that's about to get released from a cage?

Opensource Swift is only few months away and it already has a much bigger user base and is backed by the biggest company in tech. Rust & Swift share many common traits and kinda look alike as well.

Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do and is also positioned as a systems programming language? And Swift will also be a full-stack programming language and you will be able to program apps and backends with it.

I feel like Rust is about to get killed. And killed quickly.

Swift is an applications programming language where the runtime is non-optional (at least AFAICT) and memory is managed dynamically. It will be competing with .Net and Java, not with C and C++ (though, as ever, there are surely plenty of C++ projects that don't actually need C++'s level of control and could benefit from a rewrite in Swift).

Swift isn't going to penetrate to the bottom of the stack with pervasive reference counting. You'd either have to start managing memory manually (as per C) or implement a borrow checker (as per Rust), and even then your entire ecosystem is still going to use reference counting pervasively due to the language's defaults. One of the benefits of Rust defaulting to linear types and borrowed references is that it creates an entire package ecosystem where dynamic memory management is the exception, not the rule.

For the record, I think Swift is super fantastic as a language and I'm thrilled that it's going open-source. I think the two languages will work swimmingly together. :)

It will be competing with .Net and Java, not with C and C++

I would formulate this a bit milder: many desktop applications are written in C++ and many system applications (e.g. UNIX command-line tools) could be written in Swift or Go. So, there are certainly areas where C++, Rust, Go, and Swift are or will be in competition.

Of course, if you require strong safety guarantees and the absence of a garbage collector, Rust is probably the only modern option.

>Swift is an applications programming language where the runtime is non-optional (at least AFAICT) and memory is managed dynamically.

No, it's optional if you don't need to interact with Obj-C frameworks (ie. Cocoa). And memory is not managed dynamically. Swift uses ARC.

Like I said, I just don't see Rust sticking around for long. Swift will suck all the developers out of it since you'll be able to actually get a job programming in Swift.

We'll need to see how useful Swift is without Cocoa (still waiting for details on what's actually being open-sourced), but GCD is a runtime component as well. And as Manish has said, ARC is dynamic memory management, just like shared_ptr in C++ and Rc in Rust, though pervasive and implicit. If you'd like to convince me that Swift is suitable as a systems programming language, then you'll first have to show me an example of Swift code that can be compiled into a standalone binary that can be called from C, and then describe how many features of the language and standard library this disables. After that you can demonstrate how to run Swift code on a memory-constrained platform that doesn't allow dynamic memory allocation whatsoever.

If anything, Rust is the only modern language that's not threatened by Swift, by virtue of existing at a level of the stack that's so low as to be out of Swift's reach. I agree that Swift is going to be huge, but you're mistaken as to who its competitors are. :P

C++14 isn't a modern language? Aw, you killed a dream there :P

ARC is dynamic memory management. Is the decision to run destructors in an if block at run time? If so, that's dynamic.

Rust provides dynamic memory management too, but you aren't forced to use it and most use it for a few variables only.

So far nothing I've seen about Swift tells me that it will be able to be used for things like Servo and other perf-critical applications. Yes, it might edge out Rust webdev, but not much more.

"You cam get a job in swift" is largely due to its iOS backing. I'm not so sure how that's going to apply to other OSs especially if Cocoa and co aren't made open source.

All destructors in Rust are also decided at runtime, fwiw. Even without any allocation or anything:

    let foo = Moves::new(); 
    if condition { mem::drop(foo) }
    // should foo be dropped here?

In practice many destructors can probably be scheduled statically at compile time.

Dynamic drop is something that will go away for all but the strange deferred-let case (It's not a language restriction). So that's okay.

Swift is fully garbage-collected. Reference counting is a form of garbage collection. It's in a different space.

(And I like Swift and think their development team is really cool.)

Rust will deal with it by being swifter than Swift. Significantly so: Rust's unique feature is safety without requiring reference counting or GC for all pointers, which makes it a viable replacement for C and C++ in many situations where other languages would be considered unacceptable, and close enough to viable in others that future versions of Rust have a decent chance of making up the difference. Plenty of applications don't need that, and I look forward to competition between Rust and Swift in those arenas. But the enduring popularity of C++ in the face of the many newer, safer languages out there is testament that Rust's performance advantage is likely to be attractive to a lot of people.

>Rust will deal with it by being swifter than Swift.

By how much? Will extra language codebase justify the speed increase (if any)?

Say you're developing some mobile app, why wouldn't you want to use a single unified codebase for front & backends instead of splitting it across Rust and Swift?

Straw man. Not all applications are mobile apps on platforms on which Swift is king. On most platforms you can just as easily write it as a single unified Rust codebase. Perhaps even easier.

You might be interested in http://benchmarksgame.alioth.debian.org/u64/performance.php?... and http://benchmarksgame.alioth.debian.org/u64q/performance.php...

Have you seen the new Swift 2.0 benchmarks that they discussed at WWDC 15? It's now getting extremely fast. It won't be long before it surpasses Rust.

Anyway, if 5% improvement is all that Rust will have over Swift, it's as dead as Lisp.

When Swift is finally open-sourced, there will be a huge exodus from Rust community and move to Swift. This is not survivable. Rust will quickly lose the little momentum that it has right now and it will be game over.

Personally I believe that any investment into codebases using Rust is a huge mistake and a waste of money at this point in time.

Well, I certainly wish Swift well, and think they're doing cool stuff.

I personally disagree, there is little chance that Swift will be as fast as Rust and its runtime precludes it from a whole class of use that Rust has.

Swift also is annoyingly special-cased, with things like Options being special in the language, and if let only working on options (if i understand correctly). Rust took syntax like if let from swift, and then made it general.

Swift also has to deal with Obj-C interop which is not great. I imagine Swift being as popular as Objective-C in terms of non-mobile apps.

I think that this is a good question, but poorly phrased; you assume in the phrasing that it's possible for the existence of one language to "kill" another.

I was somewhat disappointed when Apple shipped Swift; I feel like Rust has considerably more potential as a general purpose language, and it would be nice to have less dilution of effort in fairly similar space.

However, I don't think that the existence of Swift is an existential threat to Rust.

> Swift will be able to do everything Rust can do and is also positioned as a systems programming language

Swift is an interesting language, with some good ideas, and in many ways easier to use for application programming than Rust; but I still, on balance, think that Rust is more interesting and versatile.

Swift is not really a systems programming language. You can't write a kernel in Swift, nor target embedded platforms, nor write a library that could be called from other languages like Ruby or Python (at least, without bringing in the whole runtime as well). It's closer to the space of Go, a more systems-y application language.

Furthermore, open source Swift does not mean you will be able to use the whole ecosystem on other platforms. I highly doubt that Apple will port Cocoa/Cocoa Touch to other platforms; so Swift on other platforms will likely only be viable for back-end code.

Objective-C has been open source for years, and until the introduction of Swift was the dominant language of choice for writing code on one of the most popular smartphone platforms, but Apple canned cross-platform OpenStep when they bought NeXT, and Objective-C has never made serious inroads on other platforms (I know exactly one person who writes production, server-side code in Objective-C on Linux).

So, I could see Swift becoming popular for writing backends for iPhone applications, but I can't imagine that it will make serious inroads in other spaces, unless Apple makes a dramatic change in strategy and starts shipping their UI libraries on other platforms as well.

Swift is still (and will always be) automatically reference counted. Rust lets you closer to the metal. Rust also has much stronger safety guarantees – it's pretty easy to write Swift crashers that would just never compile in Rust. That's a big deal for the kind of software Rust is pitching itself at.

They do feel like quite similar languages; I'd think of them as a complementary Systems/Applications pair.

"systems programming" is a vague term which means different things for different people. Swift isn't systems by the definition used for Rust and C++.

Go has to contend with Swift. Rust does not.

(Also, there are concerns about Swift's usefulness on non-apple platforms if the libs aren't completely open source.)

>Go has to contend with Swift. Rust does not.

During the WWDC 2015 opening keynote, Federighi explicitly stated that Swift's a "systems programming language" and they even say it in the documentation:

> It is the first industrial-quality systems programming language that is as expressive and enjoyable as a scripting language.

https://developer.apple.com/library/ios/documentation/Swift/...

You missed my point, systems is a vague term. Go was also initially labelled as a systems language.

Swift calls itself a systems language. Rust/C++ call themselves systems languages. The two sets use those words to mean different things.

Right. People should just drop the term 'systems language' and project languages along useful dimensions:

A: Garbage collected vs. not garbage collected. B: Generics vs. no generics. C: Algebraic datatypes vs. no algebraic data types.

Even with these three dimensions, it's easy to separate major languages

Rust: A-B+C+, Swift: A+B+C+, Go A+B-C-, Java: A+B+C-, C++: A-B+C- (discounting union types)

tl;dr: Swift is not in the same space as Rust.

> Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do and is also positioned as a systems programming language?

Well, honestly, that's just what I thought about C/C++ in comparison to some 'newer' programming languages like Go, Rust (and also Swift, maybe? I don't know enough about Swift yet).

Personally, I would only use Swift if there was an easy way to write cross-platform (mobile) software with it. It's as simple as that.

> Why should anyone pick Rust over Swift when Swift will be able to do everything Rust can do

Because Swift can't do everything Rust can do. It's missing its biggest features.

>It's missing its biggest features.

Like what? Please do enlighten us.

Safe lightweight references. Arc is garbage collection, and Swift is totally garbage collected. Rust is not. It's a rather important distinction. Because allocations must be thread safe, Swift references are also all atomic. If you do choose to use reference counting in Rust (it is nearly always avoidable), bumping a reference count with Rc is very cheap.

It also means that, like other managed languages, Swift objects that have references taken to them (classes) must in general be allocated on the heap. This means that, unlike Rust but like many higher-level languages, controlling allocations can be difficult and heavily dependent on the whims of the optimizer. Some of Swift's implementation decisions (like copy on write arrays) also suffer. The inability to avoid allocations, combined with much less efficient allocations than are possible with tracing GC, are among the reasons that reference counting is uncommon in production languages (though the Immix collector does very well).

You can certainly write code in the unsafe dialect of Swift that is just as fast as Rust, C, or any other language. But like unsafe mode in Rust, this won't be the common mode of use in Swift.

Zero cost abstractions. Memory safety without overhead. Etc etc.

Eh, at the end of the day, they're different languages and are following different paths. Sure they're superficially similar, but that's not all to it.

Python and Ruby are pretty similar languages overall, but neither has "killed" the other. Why? Because despite their similiarities, they offer different things. I generally prefer to use Python over Ruby, no real reason for it, I just prefer the language. With Rust and Swift, there are some pretty major differences that can't be waved away as personal preference, Rust's borrow-checker isn't something Swift can integrate overnight (and wouldn't likely do) and Rust can't just grow some ARC equivalent (and almost certainly won't).

And hey, some of my favorite minor features for Rust are cribbed from Swift. Namely `if let` and `while let`. I'm not scared of a little competition, keeps us on our toes and makes sure we keep looking for ways to improve the language and ecosystem.

While I generally agree with the sentiment it's worth mentioning that Rust preceded Swift and any similarities are the result of the Swift designers being influenced by Rust, not the other way around.

Rust also has the equivalent of ARC in the form of the Rc and Arc containers, Rc does reference counting without atomics, Arc with atomics (for when you need to do reference counting with thread safety).

The feature in question (`if let`) was added pretty recently. The RFC even mentions Swift! ;-) https://github.com/rust-lang/rfcs/blob/master/text/0160-if-l...

Yup, we hard stole if-let from Swift ;). We even made it better!

Reply on news.ycombinator.com