llogiq

Then perhaps the bstr crate (https://docs.rs/bstr/0.2.12/bstr) might be what you want.

What arena types do you use?

If you need to store pointers and want to conserve a bit of memory, perhaps my compact_arena crate can help you.

> Sometimes it seems like Rust afficionados think that buffer overflows etc. are the main kind of bugs.

Have you looked at the CVE stats of the last decade recently? Memory errors make up around 3/4 of that. Even if Rust would make the last quartile harder (which in my experience it doesn't), it could still be worth it for many applications where you cannot afford full verification, but want to avoid your users being pwned.

One thing the linked ripgrep post doesn't tell you is that line counting is also done with SIMD since it started using bytecount (https://github.com/llogiq/bytecount) some months ago, which sped up some workloads with line numbers considerably.

I'm doing all my development on a HP Chromebook 13 G1. While the CPU is low-powered, and I since ditched the ChromeOS for a custom Linux, it's a fairly capable machine, and very cheap for what it offers.

My recent 1-year review is on https://llogiq.github.io/2018/03/02/chromebook.html

One of clippy's authors and maintainers here (though I didn't choose the name); why would you name such a program "lint"?

For me clippy evokes the image of a well-meaning, if at times clumsy helper that tries to nudge you in the right direction. I find that very fitting for a tool that...well...tries to nudge you in the right direction of writing good, fast, idiomatic code.

Data scientist/engineer here. I write Java by day, Rust by night and in both I embrace a data-driven design, where I first carefully lay out the data so that it's easy to use within the code. In hot loops, I avoid dynamic dispatch for its runtime cost.

I don't embrace the FP style either because while I generally limit mutation (`final` almost everywhere), I use mutation where it leads to code that is easy to understand, which would be exceedingly "clever" in FP style.

No, that's cache invalidation. And naming things.

As I monologued elsewhere:

If C is like playing with knives and C++ is juggling chainsaws, Rust is like parkour suspended from strings&wearing protective gear. It'll look ridiculous at times, but you'll be able to do all sorts of cool moves that would otherwise be damn scary or outright impossible. You'll have so much fun you'll start trying to do it in other languages, too. And many of us never look back.

Especially when we hear stories about knife players ending up with a bleeding heart, and that one chainsaw juggler who lost their poodle. At the beginning, you fear the padding will hinder you, but by now you learned that its clever design allows you to move as fast as without it. A bit faster, actually, since you're no longer on the lookout for ledges you might stumble over.

Also you get new improved gear every six weeks, and between this and your newly built muscles, you start feeling like a super hero. This feeling is amplified by the community, which simultaneously does awesome feats and is really humble and open about it (you're by now accustomed to people being good at concurrency, and get slightly annoyed that your snake-charming friends insist on doing everything one step at a time).

You also met some folks you wouldn't have expected here, from a number of dynamic languages, braving the learning curve to descend into low-level programming, usually singing Rust's praises with unreal sounding benchmark comparisons.

You start looking with pity at your knive- and chainsaw-wielding friends. You see both their bruises and denial about said bruises. You'd want to offer them some of that awesome protective gear (by now you no longer feel the strings, because they seldom get taut), but you know the answer already. Poor folks.

We are super heroes. We are legion. Join us!

Last time I checked, the race detector could only find a certain percentage of data races – those easier to detect .

The crux with such systems is you tend to rely on them...

The problem is that safety doesn't sell. If you're getting a new IoT heat lamp you look at the price and not the firmware's code. To your surprise, the first hacker coming along toasts your cat.

I'm a polyglot programmer and for me Rust is mostly about the awesome abstractions and the great community.

I'd really love to be there. My third child will probably be about 3 or 4 weeks old by that time, so I at least have good reason to miss out.

This percentage includes people using explicitly unstable things (e.g. me).

Doctests were employed in languages far older than Rust, e.g. python and Lua (full disclosure: I wrote doctest.lua), and there are doclets for Javadoc that give it the same functionality.

I just call it a lint because it uses the rustic::lint API. And I posited that such analysis belongs in the compiler.

However, lints no longer need to be lightweight; I've seen full-program analysis passes called lints. And in rust, lints usually don't complain about tabs/spaces (though we could write one), but rather certain idioms which are exacerbating readability, flexibility, performance or any combination of the above.

By the way, I recently tried to get rid of some `vec!`s in the benchmarksgame entries (well, to see if I could), but got into trouble with IntoIterator implementations, so an extension of EscapeAnalysis would be great!

Yes, but Rust lints cannot currently access LLVM pass information.

So is there some documentation on the "behavioral problems" their checker finds? If we know what to look out for, we can simply write some clippy lints to replicate the checks.

(https://github.com/Manishearth/rust-clippy)

From the README:

> Thanks rust-clippy. We do love the great project.

This just made my day. :-)

I blogged about that some time ago: https://llogiq.github.io/2015/07/09/cow.html

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

If you want to add IO into Java's mix, you can also use StringWriter.

Also I personally don't consider paths as strings, nor URLs – both are types for specific purposes with specific invariants, which are distinct from strings'.

Note that this was the first thing that came to mind, after some discussion with other Rustaceans I think I found a way to allow for more mutations with only little overhead.

It depends very much on the language, e.g. common Java tools work with byte code at runtime (so no 'recompilation' is necessary), and tools for scripting languages have no option but to generate source.

Actually the approach has a weakness: The code may have hidden state that could change test results between runs. As mutations need to run the code many times, this can skew the results.

Am I the only one who thinks this looks just a bit creepy?

Here's a (IMHO) better proposition: Program with me and I'll teach you how to program. It's called Open Source and you don't need to move to get there.

It is so popular because it elegantly solves a set of problems that plague systems-level programming (use-after-free, dangling pointers, data races).

It is so controversial because there are system programmers who have lived for so long with those problems that they now refuse their existence.

TL;DR: Java is awesome, Rust is awesome, let's code even more awesome stuff!

Note that this has little to do with hill-climbing algorithms and much with A/B testing. Though there is an overlap in the problems both face.

I wonder if algorithmic solutions like randome restart or simulated annealing could improve the outcome of A/B testing, too.

Not necessarily – you can chain iterators and skip elements on the hare.