Hacker Newsnew | past | comments | ask | show | jobs | submit | brinker's commentslogin

Glad that the soundness bug was caught so quickly, and that the new version has been put out so quickly. Thanks Rust team!


I don't think they were offering up Go as an alternative to C, but rather giving an example of an OpenSSL implementation in a language that isn't C. Rust is mentioned because the prior comment called for the creation of a pure-Rust OpenSSL library as proof that Rust can be used in this context. No such things exists, but they were trying to offer up a similar example to prove the same point.


Thank you so much for saying this. I agree wholeheartedly and think this is a very important point to make. Really, the whole pattern of Why Don't You Know This Already is nothing but harmful. When someone learns something new and shares it, we shouldn't look down on them or demean them for not knowing it already. We all learn different things at different times, and not every CS program teaches the same things. Some are more math focused, some are more engineering focused, and even within those bounds there's space for a huge degree of variation. Let's not put people down because their degree didn't happen to teach something. Let's appreciate their excitement for learning that thing now.


Rust by Example was actually not originally a Rust team project. It was an independent work that was handed over to the Rust team for maintenance by the original author.

As I understand, it received basic polishing and updates to make sure it was correct, but hasn't been edited much beyond that.


This history is accurate. RBE is pretty low on my priority list; finishing up the book and the standard library docs are much more important right now. I to try to keep up on PRs.


Hey, author here! Happy to answer any questions people have, and happy to hear any feedback.


String (the “owned” sort of string type) is a wrapper for a heap-allocated buffer of unicode bytes. str (the “slice” sort of string type) is a buffer of unicode bytes that may be on the stack, on the heap, or in the program memory itself.

"unicode bytes" aren't a thing; bytes implies encoding (and subscripting yielding <=0xff), otherwise it's "codepoints" (and subscripting yielding an int somewhere on the unicode planes).

Further down:

String and str are guaranteed to be valid UTF-8 encoded Unicode strings. If you’re wondering why UTF-8 is the standard encoding for Rust strings, check out the Rust FAQ’s answer to that question.

That's spot on. Please add this to the first part, too; "... buffer of UTF-8 encoded unicode bytes". or even just "encoded unicode string." It will be clear what is (and is not) meant.

Otherwise nice article! Even understandable for someone with no Rust experience.


Sure, no problem.

As a kinda funny aside, I also wrote the linked-to FAQ answer. Took a number of drafts to get all the fiddly Unicode terminology right.


Maybe consider a word other than 'sort'.

When I see 'sort' collocated with 'string' my mind immediately jumps to the verb meaning of 'sort', not the noun meaning of 'sort', so it was a bit confusing.


Yes I had that too. I would have used "variety", as in this "variety" of string. Or "kind" maybe.


Yeah, the word you look for isn't "sort", but "kind".


I shied away from the word "kind" simply because that has a specific meaning in type theory that doesn't fit here. Higher-kinded types are a must-requested feature for Rust, and I didn't want to confuse readers into thinking this has some connection to Rust's string types.


The word "sort" isn't free of alternate associations either, and "kind" seems less likely to confuse people, seeing as Rust doesn't have any concept called "kinds" right now and won't have HKT for years, if ever.


"sort" also has a specific meaning in type theory - it's a class of kinds.

Also the type-theoretic meaning of "kind" is accurate here, no? Owned vs slice really are two different kinds - it's just that Rust can't represent kindedness in general (it has specialized support for tracking ownedness, but you can't reuse that system to track other properties).


> The package system for the rust language actually relies on github, as many found out during outage.

This is not quite correct (although close to it). Cargo doesn't rely on GitHub, but it expects that there is some publicly-accessible git repository from which it can pull the source for any crate, and most crates use GitHub. So it's not a particular choice of Cargo, but a side-effect of GitHub's popularity in the community, and the fact that Cargo does not host source code itself.


You're mixing up cargo features and the crates.io package system. Cargo does allow git dependencies but primarily you're supposed to use versioned crates.io packages, which are indeed provided by crates.io (even if they are actually hosted on S3 or whatever) not GitHub.


The crates.io index is in a GitHub repository. Does Cargo fetch it directly from GitHub or from a set of redundant mirrors?


If crates.io hosted the content themselves, it would just be the same problem, only with a service potentially less reliable than GitHub.


Unless you set up a system of mirrors. There are plenty of examples[1] to draw from.

1: http://mirrors.cpan.org/


Not if they acted like a mirror. Put it on GitHub, Bitbucket, and crates.io


Did you try using rust-gdb or rust-lldb? They're wrappers for gdb and lldb respectively that make working with Rust code a lot nicer. They ship with the Rust compiler.


Yes. I couldn't single step through a simple program without delving into assembly code. Couldn't list the program. Breakpoints weren't working. I think part of the problem was working on OSX. I was reading some Rust issue related to the debug info generation. Although the issue was closed I think it's still a problem. Oh well.


  > Although the issue was closed I think it's still a problem
Please leave a comment if this is true! Opening old issues that come back is good.


These types of articles are always frustrating, in that they very rarely provide an even halfway decent explanation of the math or science involved (if they do, it is buried deep), and are instead little more than a repetitive explanation of the importance of the work, judged by quotes from as many people as humanly possible. This article (which says very little) is still probably too long with all the fluff added around the actual discovery.


If only there were a way to check the accuracy of a long article by scrutinizing it in only a few spots...


Unfortunately, there is only a way to check the accuracy of a long article by scrutinizing a complicated mathematical transformation of it in a few spots.


Flipboard Engineering published a blog post on solving this problem http://engineering.flipboard.com/2014/10/summarization/


This was the textbook in my file systems class a couple years ago. Great book that really does a good job of explaining how file systems work.


Here (http://www.slate.com/articles/news_and_politics/explainer/20...) is an interesting article about this issue from 2009. It says that while some states require the availability of information like name and badge numbers, many do not. However, some police department's will still implement policies requiring it be provided if requested. This is out of date and not terribly detailed, so I'd be curious to hear from someone with more complete or up-to-date information.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: