Turing.jl: A Fresh Approach to Probabilistic Programming in Julia - <AUTHOR> http://turing.guru/ <comment><AUTHOR> Link to introductory video from JuliaCon 2017 talk:

JuliaCon 2017 | Turing: a Fresh Approach to Probabilistic Programming | Kai Xu

[https://www.youtube.com/watch?v=DJWNQg7uuCg](https://www.youtube.com/watch?v=DJWNQg7uuCg)

</comment><comment><USER2> Does anyone knows the difference to other languages like STAN?

Both use Hamiltonian Monte Carlo. As far as I know STAN cannot model factors but can restrict a variable to integers. In this case, Turing.jl and STAN do the same and switch back to slower MCMC.

So why should I switch to turing.jl?

Their wiki shows that turing.jl is about 10 times slower than STAN:

      Results
      Model 	Turing 	Stan 	Ratio
      Simple Gaussian Model 	1.2 	0.06 	20.24
      Bernoulli Model 	1.53 	0.05 	32.73
      School 8 	2.34 	0.1 	24.41
      Binormal (sampling from the prior) 	0.88 	0.11 	8.37
      Kid 	32.66 	4.72 	6.92
      LDA-vec 	23.94 	3.78 	6.34
      LDA 	72.78 	3.78 	19.28
      Mixture-of-Categorical 	22.28 	6.41 	3.48
      NOTE 1
      Numbers here are inference time in second - smaller number   indicates better performance.

<comment><USER3> We're setting up parameter estimation in DifferentialEquations.jl with both Stan.jl and Turing.jl as separate but connected projects. For generated data from the Lotka-Volterra equations, Turing.jl seems to be able to recover the four parameters well in minutes, whereas Stan was running for a few hours and didn't get it right. It's hard to know if it's because of the difference in the ODE solver and the accuracy there (Stan has to use its internal solvers, whereas Turing.jl gets to use our whole stack. For testing we chose Tsit5 which should be to some extent equivalent to their rk45, but without knowing the details of their solver it's hard to know how different it truly is) or due to the chosen method for MCMC method. One major advantage of Turing.jl though is it lets us use our full stack: Distributions.jl, all of JuliaDiffEq (ODE/SDE/DAE/DDE/etc. solvers), whereas Stan requires you use their two ODE solvers. So we're going to finish up this DiffEq->Stan automatic generation bridge for testing and benchmarking purposes, but the Turing.jl route looks much more promising. They have done a really good job.

<comment><USER4> I'm surprised you're able to get Turing to run faster, to be honest. I looked at Turing and was impressed by it, but in general my experience with MCMC libraries in Julia is similar to what the OP posted, being much slower than Stan (MAMBA and Turing being the two Julia libraries I've tried--both have seemed nice but have run significantly slower on the tasks I've used them for).

Incidentally, I haven't been able to get Turing to run on Julia 0.6, and am not going to reinstall an earlier version just for Turing. I've been waiting for a little while now.

My experience with Turing and MAMBA have kind of diminished my enthusiasm for Julia. Both libraries kind of represent what I was looking for in Julia (similar to what you mention about using your Julia stack), but the speed was a kind of a rude awakening. I'm kind of coming to the opinion that LLVM-based languages need to demonstrate much more consistent performance before they're really ready to replace C (Rust, Nim, and Crystal seem like they might be on their way, though).

I recommend someone thinking about Julia pay attention to these benchmarks:

[https://github.com/kostya/benchmarks](https://github.com/kostya/benchmarks)

Yes, Julia is really fast with some things, but for other things it's much slower, and those slow parts become the lowest common denominator.

Hopefully things improve, though, because I do like Turing and MAMBA on paper.

<comment><USER5> > Yes, Julia is really fast with some things, but for other things it's much > slower

No sane person would deny this :) Regarding those benchmarks, however, I would note that:

a) They are two major Julia versions old, many of the benchmarks Julia appears in are string-centric, and since then Julia's string handling has been improved.

b) Glancing through I see a few pretty basic ways in which the Julia code could be sped up without doing anything convoluted

<comment><USER4> The benchmarks are based on old Julia--something I've wondered about--but they still are consistent with my experience (and with the benchmarks the OP posted).

I really like Julia, so I don't want to come across as a hostile critic, more of a friendly one. I'm someone who has, and continues to try, Julia for lots of things. But repeatedly I've bumped into this phenomenon where Julia is maybe 3-5x slower than what you'd see in C, maybe more, and am faced with what that means in practice. It's not just Turing, and it's not just a single version of Julia. It's a heck of a lot better than Python or R, but when I realize it's still significantly faster to do something in C, and you're going to wrap something around C anyway, maybe Python or R would be better just because of the resource base associated with them.

Maybe there's some fundamental issue I haven't grappled with, like Julia will never actually be as fast as C, and I just need to be aware of what that means, practically speaking... I don't know. Maybe it will eventually hit that performance range, and it's just a matter of optimizing algorithm choice and whatnot. But I get the sense that the way I was hoping to use Julia isn't actually doable, at least at the moment.

I do think many people are coming to Julia because of some sense they can get the performance of C with the expressivity of Python, and at the moment I think that's an unrealistic expectation for a lot of things. I think the parent post in this subthread exemplifies that quite well: for many, many reasons, it shouldn't be surprising that Stan outperforms Turing. If this was any other language, it would be a matter of course. But because of the expectations set up for Julia, you see discussions like this.

<comment> one-more-minute If you can turn one of those trials into a small example and post it on the forums, it'd be well worthwhile. We've often helped folks squeeze the last few bits of performance out of their code – and really, anything past 2x of C is considered a bug.

</comment></comment></comment></comment></comment></comment><comment><USER6> Am I missing something here, or is there zero content about this project linked from the landing page?

<comment><USER7> I think the wiki is the documentation: [https://github.com/yebai/Turing.jl/wiki](https://github.com/yebai/Turing.jl/wiki). It's linked in the upper right corner. I agree that the fact that the three big items on the page are not links is a bit confusing.

<comment><USER6> Ah, thank you. Apparently dividing my screen vertically made my web browser too narrow, and thus the links disappeared entirely.

<comment><USER8> Yep, it looks like there's a CSS @media query which completely hides those navigation links on screen sizes < 992px. That's not very useful responsive design.

</comment></comment></comment></comment><comment><USER9> Why name this particular library after that particular mathematician?</comment>


Rust vs. C++: Fine-grained Performance - <AUTHOR> http://cantrip.org/rust-vs-c++.html <comment><USER2> Most insightful part for me was this one:

> Many variations [he's talking about Rust] that seemed like they ought to run > the same speed or faster turned out slower, often much slower. By contrast, > in C++ it was surprisingly difficult to discover a way to express the same > operations differently and get a different run time.

This is an insidious pitfall that may earn Rust the "slow" label, akin to what happened to Common Lisp.

<comment><USER3> > This is an insidious pitfall that may earn Rust the "slow" label, akin to > what happened to Common Lisp.

This doesn't match my experience at all with Rust, for what it's worth. Not having copy constructors makes up for any difference in that regard: in C++ it's way too easy to accidentally deep copy a vector and the entire object graph underneath it--all it takes is "auto a = b" as opposed to "auto& a = b"\--with very bad performance consequences. Rust, on the other hand, doesn't let you deep copy unless you explicitly ask it to.

<comment><USER4> I got so worried about accidentally deep-copying stuff that I ended up with an ugly C++ hack:

        C(const C &) = delete;
        C &operator=(const C &) = delete;
        C(C &&) noexcept = default;
        C &operator=(C &&) noexcept = default;

        struct MakeCopy {
            const C &src;
            MakeCopy(const C &src) : src(src) { }
        };

        MakeCopy make_copy() const { return *this; }
        C(MakeCopy src) : field1(src.src.field1), (blah blah) { }

Then, when you really want to copy stuff, you have to say "a = b.make_copy();".

This isn't really clean, because it's too easy to add a field to C and then forget to add it to the "manual copy constructor", but so far I found it good enough for me.

<comment><USER5> In Rust, if you want a deep copy you (IIRC) implement the Clone trait, which allows you to explicitly clone everything. Many collections in the standard library already implement this, so you get it by default :).

Edit: I should point out that deep copies can only be explicit in Rust -- there's no implicit deep copy AFAIK.

<comment><USER6> There is no implicit deep copy, Clone is usually how a deep copy is implemented, but not all Clones are deep copies. Rc, for example, bumps a reference count on Clone.

</comment></comment></comment></comment></comment><comment><USER7> The author compares gcc vs rustc.[1]

I'm curious if the author considered comparing clang vs rustc since both use the LLVM backend. (I'm guessing the more mature C++ code generation would still win the benchmark but one could study the intermediate code emitted by clang/rustc instead of the final machine code emitted by gcc.)

[1][https://github.com/ncm/nytm-spelling- bee/blob/master/Makefil...](https://github.com/ncm/nytm-spelling- bee/blob/master/Makefile)

<comment><USER8> On my Macbook Pro, the rust version seems consistently faster (20% or so) than the c++ version compiled with clang.

<comment><USER8> As a followup, if I use __builtin_expect as recommended by the article, the situation reverses, with c++ being significantly faster.

</comment></comment></comment><comment><USER9> _Curiously, most variations of the C++ version run only half as fast as they should on Intel Haswell chips, probably because of branch prediction failures_

I haven't looked at the code yet (time for bed) but this note from Agner seems like it might be relevant:

      3.8 Branch prediction in Intel Haswell, Broadwell and Skylake

      The branch predictor appears to have been redesigned in the
      Haswell, but very little is known about its construction.

      The measured throughput for jumps and branches varies
      between one branch per clock cycle and one branch per two
      clock cycles for jumps and predicted taken branches.
      Predicted not taken branches have an even higher throughput
      of up to two branches per clock cycle.

      The high throughput for taken branches of one per clock was
      observed for up to 128 branches with no more than one
      branch per 16 bytes of code. If there is more than one
      branch per 16 bytes of code then the throughput is reduced
      to one jump per two clock cycles. If there are more than
      128 branches in the critical part of the code, and if they
      are spaced by at least 16 bytes, then apparently the first
      128 branches have the high throughput and the remaining
      have the low throughput.

      These observations may indicate that there are two branch
      prediction methods: a fast method tied to the μop cache and
      the instruction cache, and a slower method using a branch
      target buffer.

[http://www.agner.org/optimize/microarchitecture.pdf](http://www.agner.org/optimize/microarchitecture.pdf)

At a glance, the symptoms seem like this might match. Separately, I think there is still a limit of 3 branches per 16B before the branch prediction starts to fail. It's rare to hit this in normal code, but something this optimized might.

<comment><USER10> I've recently experienced what I believe was likely branch predictor failure. I rewrote essentially the same algorithm, with the same complexity, in a completely new way, to reduce constant factors. The new code was beautiful, and I was expecting perhaps 15-20% performance improvement. (40% of the runtime in the old version was in one function, the new version should, and did, call that function with less data to grind on average). Memory access patterns should be identical. Grand.

So what happened with my standard benchmark on Haswell (GCC 5.3, -march=native -O2)?

Old version, without PGO: ~8 minutes (baseline)

Old version, with PGO on: ~9 minutes (yes, PGO made it slower)

New version, without PGO: 11 minutes (60% slower)

New version, with PGO on: 7 minutes (~15% faster)

All of these benchmarks were replicated with a common set of functions tagged noinline, and I inspected the assembly to see if there was a difference with regard to loop unrolling. Nope, no unrolling. Afaict it appeared to be entirely to do with the way GCC had laid out code with respect to branches. The differences were minor in key areas and seemed like arbitrary compiler choices.

I eventually narrowed this down with callgrinds branch-predictor simulator to a few hot spots. I added a redundant if-statement to check for and short- circuit a common case, even though it shouldn't have mattered, and a few __builtin_expects, and suddenly I was getting the 15% speedup without PGO.

</comment></comment><comment><USER11> I'm surprised by the small warts in the Rust code. In this line:

      let fname = &*env::args().nth(1).unwrap_or("/usr/share/dict/words".into());

Neither the &* not the .into() add much to the meaning for me as a reader. Why are they necessary for the compiler?

Why is there an .unwrap() on writeln! ? To force a panic if the write failed?

<comment><USER6> They used `into()` because it's the shortest. The more idiomatic options are all of the other ones: String::from, .to_string(), and .to_owned() (Strings implement a lot of generic interfaces.)

The &* converts a String to a &str. I would have done it in the match rather than here, personally.

      > Why are they necessary for the compiler?

Rust does not heap allocate things automatically nor convert types automatically. This is the side effect: you can see exactly how much allocation is going on, and know exactly how stuff is being converted.

(We do have a very small and very specific set of conversions that will happen, they don't here, though.)

      > Why is there an .unwrap() on writeln! ? To force a panic if the write failed?

Yes. The compiler will warn you that you're ignoring the errors on the write, and panicking is one way of handling it.

<comment><USER11> So the string literal is a str, but it gets turned into a String with the .into(), and then back into a str (well, &str) on the same line. That seems like a lot of travelling to go a short distance.

Is this because args() ultimately gives you a String, and you need to get that and the string literal out of a single expression?

Why does args() give you String rather than str? Couldn't command-line arguments be static more-or-less constants?

Would there be any way to turn the output of args straight into a &str, so you didn't need to .into() the literal?

Why are String and str separate types, rather than different uses of a single type? Are there any other examples of pairs of types with the same relationship? Arrays and slices? Any others? Is there something like this for maps/dictionaries/hashes?

I realise i've asked a lot of basic questions about strings here, and that you (and any other knowledgeable people reading this) are probably pretty tired of explaining this over and over again. I would be equally grateful for a link to some relevant documentation or whatever as for a detailed answer!

<comment><USER6>
      > Is this because args() ultimately gives you a String

Correct.

      > Why does args() give you String rather than str?

Because the command-line arguments to the program are dynamically created. To be a &'static str, like a literal, they would have to be baked into the binary. &str is a pointer, it doesn't own any backing store.

      > Would there be any way to turn the output of args straight into a &str, so you didn't need to .into() the literal?

Well, so that is what this code is doing. It's just also handling error cases: What if the argument isn't passed in, as the primary one.

      > Why are String and str separate types, rather than different uses of a single type?

Because String actually owns the data it's attached to, and is heap-allocated. &str is a pointer; it can only point at some other string type, since it doesn't store its own data.

      > Are there any other examples of pairs of types with the same relationship?

Arrays/Vectors and slices are a great example: String is wrapper around Vec<u8>, and &str one around &[u8]. But any owned/pointer variant with some sort of restriction on the type of data is going to be like this, it's a pretty common pattern.

Don't forget other string types too: There's OSString, CString, and external crates provide other types as well. Strings are not simple.

      > Is there something like this for maps/dictionaries/hashes?

Slices point to _contiguous_ spots in memory, so these data types don't really have slices, because that property isn't true.

      > I would be equally grateful for a link to some relevant documentation or whatever as for a detailed answer!

Hehe, no worries. It's hard to say what _specifically_ would be the best docs, but if you're interested in the _future_ docs about this, [http://rust- lang.github.io/book/understanding-ownership.html](http://rust- lang.github.io/book/understanding-ownership.html) is an explanation of Rust's ownership system through String and &str that will become the next version in the official docs. There's still some rough edges, as it's a draft, though!

</comment></comment></comment></comment><comment><USER12> I need to learn Rust again. I haven't used it in a year, and the language has changed a lot. Everything now seems to require a closure or some ".into()" idiom. Like this:

         let file: Box<Read> = match fname {
                "-" => Box::new(stdin.lock()),
                 _  => Box::new(fs::File::open(fname).unwrap_or_else(|err| {
                         writeln!(io::stderr(), "{}: \"{}\"", err, fname).unwrap();
                         process::exit(1);
                     }))
            };

Type Result has its very own set of control flow primitives.[1] So does type Option.[2] Any type can have its very own flow control primitives. Are we going to see

        date.if_weekday(|day| { ... })

and similar cruft for every type? I hope not.

Hopefully the setup of closures that probably won't be executed isnt't too expensive. Do those require a heap allocation and release when not used, or is this all on the stack? The run time variation for small changes indicates that some constructs are more expensive than others, but it's hard to know which ones are bad.

I understand the rationale behind the Rust approach to error handling, but it's just painful to look at. After seeing the gyrations people go through in Go and Rust to deal with the lack of exceptions, it looks like leaving exceptions does not make a language simpler. From a compiler perspective, the compiler can generally assume that exceptions are the rare case, and can optimize accordingly. Rust has no idea which closure a function will call, if any.

[1] [https://doc.rust-lang.org/std/result/enum.Result.html](https://doc.rust- lang.org/std/result/enum.Result.html) [2] [https://doc.rust- lang.org/std/option/enum.Option.html](https://doc.rust- lang.org/std/option/enum.Option.html)

<comment><USER13> _> Hopefully the setup of closures that probably won't be executed isnt't too expensive. Do those require a heap allocation and release when not used, or is this all on the stack?_

Creating a closure with |...| { ... } is literally as expensive as creating a tuple containing (references to) the variables it captures. That is, they're on the stack by default like everything else in Rust, and there's no implicit heap allocations. For more details, see, for instance, [http://huonw.github.io/blog/2015/05/finding-closure-in- rust/](http://huonw.github.io/blog/2015/05/finding-closure-in-rust/) .

 _> Rust has no idea which closure a function will call, if any._

It does. As my link above discusses, each closure has a unique type, allowing monomorphisation to kick in and hence the compiler can easily optimise and inline calls to closures (as long as the author of the closure-taking function doesn't opt-in to only allowing virtual dispatch).

</comment></comment><comment><USER14>
        Incidentally, I don't know why I can write
            let (mut word, mut len, mut ones) = (0u32, 0, 0);
        but not
            (word, len, ones) = (0, 0, 0);

Marking variable declarations with _let_ is a good thing and makes it clear if something is an assignment or a variable declaration. It also leads to cleaner code when you use nested functions (I always hated the "nonlocal" keyword in Python)

<comment><USER15> I think the author was indicating that while you can use that syntax to declare and initialize variables, you can't use it later to assign new values to them. I don't think they had any problems with the concept of `let`.

And it does strike me as a little weird as well to only be able to take advantage of the pattern match destructuring on initialization, but I'm sure there's a good technical reason.

<comment><USER16> I read it the same way. There's an open issue for it:

[https://github.com/rust-lang/rfcs/issues/372](https://github.com/rust- lang/rfcs/issues/372)

I think one of the main reasons this isn't done is because of the grammar issue. I dimly remember that one of the goals of Rust was to be parseable with a LL(1) grammar.

<comment><USER6> There are grammar issues, yes. We unfortunately have one tiny case that's context-sensitive though, so we didn't quite get there :/ that vast majority of the grammar is very straightforward though. There's a lot of benefit to it.

</comment></comment></comment></comment><comment><USER17> If you want to compare the verbosity of both languages, why not use 'using namespace std' ?

Why write:

> std::vector<unsigned> counts; counts.resize(sevens.size());

When you can write:

> auto counts = vector<unsigned>(sevens.size());

Doesn't seem like a fair comparison to me.

<comment><USER18> I don't agree on the general usage of "using namespace std", so that part does not bother me.

For an even shorter init:

> std::vector<unsigned> counts(sevens.size());

<comment><USER19> Bringing namespaces into scope is perfectly idiomatic C++, just don't do it in your headers.

<comment><USER20> IIRC, importing an entire namespace into scope is a feature that was added exclusively for backwards compatibility and is not idiomatic modern C++.

What _is_ idiomatic is explicitly importing individual symbols into a name peace.

        #include <iostream>
        #include <vector>
        #include <string>

        using std::cout;
        using std::vector;
        using std::string;

        int main() {

          vector<string> v {"explicit ", "is better ", "than implicit\n" };

          for (auto p: v) cout << p;

          return 0;

        }

I'm on mobile so please forgive errors.

<comment><USER21> Wow, I never knew about that. I always hated having std:: everywhere, just so I could have "correct" C++. But I also hated referencing to std implicitly. This is the perfect tradeoff: explicitly state intentions in the beginning, then implicitly reference them as you go. (works until you use eighty five billion lines just to import your symbols)

</comment></comment></comment></comment></comment><comment><USER22> I think one thing of note here is that the author did _not_ want to make the program parallel. One of the benefits touted by Rust is "fearless concurrency." If this feature was introduced this is where # lines or performance may have diverged.

<comment><USER23> Parallel is of course very important. But if serial speed isn't in the same range, go parallel will be the same perf crutch as the Python folks who say drop to native. Rust programs shouldn't be parallel to beat a single threaded C++ program.

<comment><USER24> >Rust programs shouldn't be parallel to beat a single threaded C++ program.

I don't write code in either language, but as an outsider my impression is that rust was created to make programming for parallel execution, easier.

If that's the case, why are we comparing a use case c++ is optimized for against a use case rust isn't optimized for?

<comment><USER6> We do want Rust to be excellent at parallel execution, but that does not mean that we don't pay attention to single-threaded performance either. The way that we make paralell/concurrent code better has no negative impact on single- threaded performance. In fact, sometimes you can use more efficient data structures when you know that you're not using multiple threads, like Arc<T> and Rc<T> for example.

<comment><USER23> Exactly. Most C++ codebases lean too heavily on `shared_ptr` because they don't/can't know when something will cross a thread boundary.

</comment></comment></comment></comment></comment><comment><USER25> To my knowledge std::ifstream is pretty slow, I think the author should load the whole file in memory with a cache friendly layout and try the benchmark again.

</comment><comment><USER26> >but I'm amazed that Intel released Haswell that way. I don't know yet if it Intel fixed it in Broadwell or Skylake.

I would love to know more about this; how curious indeed.

</comment><comment><USER27> This is really fantastic to get an understanding of how Rust works in a real world environment. As a non-systems developer I am finding the Rust language to be a little cryptic though in particular the many new syntax elements that don't exist in other languages.

I would be curious to know if there are plans like Swift to simplify the language syntax in the future or if it is just something to get used to.

<comment><USER6> It depends on what you mean by "simplify". We've just accepted an RFC for ?, for example, which should make certain code more concise, but it is an additional feature, so is that more simple?

<comment><USER28> General notes: \- Semicolons inconsistent usage makes Rust harder to process. Is that semicolon extra? Is it not? Will that be a compilation error? Saving single keystrokes will be paid in cognitive load. Programming is already a demanding task, this isn't helping. \- Chaining multiple statements on a single line is bad for various reasons.

Dependencies / headers / modules: \- C++ is better precisely because it's more grained on the initialization side. The paragraph starting with 'Rust wins, here', is just a general turnoff to read the rest of the article. When I read the title 'Rust vs. C++: Fine-grained performance' I was honestly expecting either a table with performance times across various algorithms, or a savvy optimization guide. I wasn't expecting a LoC duke-it-out.

Input file processing \- Both are conceptually boilerplate code. There is more for Rust apparently. \- There is an interesting &⊛env:: in there that makes the language looks like it needs a bit more work. Three operators just to do something with the first object? \- Are they intentionally trying to copy C++ with the :: operator but removing visually arbitrary semicolons? Just replace the :: with something else.

Data structure and input setup \- Remove the 'let' from the language, and it does look cleaner than the C++.

Input state machine \- Why isn't "(0..7).rev()" "(7..0)" \- On the bottom part, lamba-like usage will makes in less comprehensible (and probably undebuggable the way it's written)

General lack of performance numbers \- _" I found that iterating over an array with (e.g.) "array.iter()" was much faster than with "&array", although it should be the same..." "Curiously, changing scores to an array of 16-bit values slowed down (earlier versions of) the C++ program by quite a large amount – almost 10% in some tests – as the compiler yields to temptation and forces scores into an XMM register. The Rust program was also affected, but less so."_

Edit: Unicode

<comment><USER6> I didn't write this blog post, though I did help the author optimize their Rust code when they dropped by #rust, so I'll respond to the generic Rust stuff rather than those details.

      > Semicolons inconsistent usage

You've asserted this, but not demonstrated it: semicolon usage is consistent in Rust. Rust is not C++, so it doesn't necessarily follow the same rules, but it is consistent, even though it may be different.

      > C++ is better precisely because it's more grained on the initialization side.

Can you elaborate on this? I'm not exactly sure what you're saying.

      > There is an interesting &⊛env:: in there that makes the language
      > looks like it needs a bit more work.

See above: this kind of thing is about how Rust views coercion and heap allocation: explicit, not implicit.

      >  Just replace the :: with something else.

We tried that. We still ended up with :: as a scope operator.

      > Remove the 'let' from the language, and it does look cleaner than the C++.

`let` has a few advantages, in that it allows you to take advantage of patterns, and makes initialization explicit.

      > Why isn't "(0..7).rev()" "(7..0)"

Because ranges always iterate forward, from start to end. rev() reverses the direction.

      > On the bottom part, lamba-like usage

I'm not sure what you're referring to here.

<comment><USER28> I get the feeling that Rust design is concerned more about write-ability of the code than readability. Code has to be maintained, read by random people, comprehended. It will grow up in hundreds of megs on large projects, and it will take time to compile.

With the above in mind:

> You've asserted this, but not demonstrated it: semicolon usage is consistent > in Rust. Rust is not C++, so it doesn't necessarily follow the same rules, > but it is consistent, even though it may be different.

Writing code is consistent and unaffected, code comprehension (debugging, integration efforts, etc) by third parties will be hampered.

>Can you elaborate on this? I'm not exactly sure what you're saying.

Not importing the entire library will result in faster compilation. Unless rust has a concept similar to precompiled headers, etc. I apologize at this point. I'm not sure what Rust does in that respect, but my initial thoughts were that as the project grows, the parser will slow on includes. The internal symbol resolver will slow on lookups because too many things are included.

All of the above is only if you are trying to match what C++ does for large teams. I guess it's up to the developers of the language what direction they want to take it in. More agile or more enterprise oriented.

(From personal experience: I was on a team looong time ago, where codebase took 12 hours to compile on a powerful cluster. Any gains, even by few hours, changed schedules drastically)

>See above: this kind of thing is about how Rust views coercion and heap allocation: explicit, not implicit.

I understand your viewpoint, however three operators on a single object still seems conceptually excessive to me.

>Because ranges always iterate forward, from start to end. rev() reverses the direction.

Since both are supported, maybe the parser can be made smarter?

> I'm not sure what you're referring to here.

Well this piece of code:

      let scores = words.iter()
                .filter(|&word| word & !seven == 0)
                .fold([counts[count];7], |mut scores, &word| {
                    for place in 0..7
                         { scores[place] += (word >> bits[place]) & 1; }
                    scores
                });

Is not easily read or debugged ( on which line do you set the breakpoint, etc).

Outside of minor things like this, I like what Rust is trying to do. I think it's a great effort and I do look forward to where it will lead.

<comment><USER13> _> Not importing the entire library will result in faster compilation. Unless rust has a concept similar to precompiled headers, etc. I apologize at this point. I'm not sure what Rust does in that respect, but my initial thoughts were that as the project grows, the parser will slow on includes. The internal symbol resolver will slow on lookups because too many things are included._

The compilation time problems associated with headers are problems with headers: avoiding headers makes it easy to avoid the problems. The crate system of Rust is somewhat similar to precompiled headers, and C++ is in fact in the process of putting something similar (modules) into the standard.

Interestingly, this makes the Rust compiler easier to work with: the basic things of lexing, parsing, name resolution etc. are not at all bottlenecks (any particular file is only parsed once, there's not megabytes and megabytes of headers to parse for every invocation). This means these parts don't have to be micro-optimised, and hence don't get hit by an increase in complexity due to those optimisations.

Concerns about internal symbol resolution aren't a problem: hashmaps give (expected) O(1) access no matter how many elements they hold, and even using a tree has O(log n) access (i.e. going from 1_000 symbols to 1_000_000 only doubles the time for a look-up, and the next doubling happens at 1_000_000_000_000 symbols).

 _> Since both are supported, maybe the parser can be made smarter?_

Not sure what this has got to do with the parser (7..0 _parses_ fine, it just creates an empty iterator), but implicitly reversing ranges are on of the most annoying features of R: it makes it annoyingly hard to do things like `x..y - 3`.

 _> Well this piece of code:_

Two things: the author is effectively golfing here (they say they want the code to fit on a single page), and, the Rust version can be written just like the C++ version, with a loop:

      let scores = [counts[count]; 7];
      for &word in words {
          if word & !seven == 0 {
              for place in 0..7 {
                  scores[place] += (word >> bits[places]) & 1;
              }
          }
      }

<comment><USER6> Can LLVM lift the bounds check out here?

<comment><USER13> Yeah, it should be able to handle that easily, since both bits and scores have static length 7. Note, however, that the loop version does no more or less [] indexing than the iterator/fold version.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> It seems Rust sacrifice too much for the sake of safety. If Swift will evolve to truly cross-platform language, I think it is in the golden middle of safety vs usability trade-off (without requiring non-deterministic GC like D).

<comment><USER20> I think after about Swift 4.0, if you're writing a native application in [systems language] and you're using Arc/Rc/shared_ptr all over the place you need to seriously take a step back and ask yourself why you're not using Swift.

If Swift had structural references (for all intents and purposes in Swift, all structs are value types and all classes are automatically reference counted pointers) and move semantics Swift would absolutely kill it.

It's an exciting time to be a PL nerd.

<comment><USER30> I'm a Rust fan, but I'll still be excited if Swift manages to add some sort of borrow checker to the language in a future revision (C++, D, and Nim have all also at least alluded towards such a direction, but only C++ has made any progress so far). From what I've seen though, I'm still not sure that Chris Lattner has given serious thought to such an addition. I'm waiting for a concrete proposal before getting my hopes up, because Rust had to make put significant effort into tailoring the base language to borrow checking and implementing such an analysis after the fact runs the risk of serious divergence (or worse, breakage) in the ecosystem.

(There's also the fact that, as of the hypothetical Swift 4k, none of the library ecosystem will be leveraging the borrow checker and so Rust will still have a substantial head start for people who want thoroughly static ownership.)

Other than that I'm a bit dismayed that Swift just punts concurrency to GCD, given how many other new languages make concurrency such a major focus (especially Rust).

</comment></comment></comment><comment><USER31> Rust = c syntax with Erlang conventions

<comment><USER32> You would've hit closer to home if you'd said "ML" or "Haskell" instead of Erlang, though you'd still be shooting wide.

Rust's borrow checker is its single most distinctive feature, and that is inspired by the work done in the Cyclone language.

</comment></comment><comment><USER33> Do you want C++ compiler to also prevent data races? Then use const functions by default, seriously.

[http://youtu.be/Y1KOuFYtTF4](http://youtu.be/Y1KOuFYtTF4) (starts at 29:00)

C++ template meta programming language is such a powerful and expressive tool for writing libraries and safe abstraction. Imagine if all the effort of 8 years of Rust team went into a modern C++ safety library.

Such a library would have been more useful contribution and more people would have benefited.

<comment><USER6> Using const does not prevent data races.

We made Rust because you can't actually retrofit it's guarantees on C++ without breaking backwards compatibility. The CPP Core Guidelines are an example of this: Herb said that data race prevention is a non-goal, and in general, how it interacts with concurrency is not yet understood.

<comment><USER33> Did you watch the video?

Curious why you think using const _functions_ doesn't prevent data races after watching

at 29:00 he says the C++ standard guarantees const member functions are data race free.

<comment><USER6> I mean, data races need mutability, so something that's const can't have a race, sure.

What I meant was something like "const itself is not a panacea against data races generally." It is a useful tool.

<comment><USER33> Don't get me wrong I respect Rust core team as theorists and think rust is an important research project.

But in C++ if you have a const member function F() then F() can only change member variables that use the "mutable" key word.

If you default to all methods are const you have much much safer C++. As safe as rust? not probably but combined with liftimes proposal and static analysis rules we have a language good engineers can sufficiently work with.

        struct Foo
        {
             mutable auto a = 4;
             auto increment() const -> void
             {
                  this->++a;
             }
        };

If we train engineers to use const member functions, then the programmer is forced to think about state and mutation.

As C++98 PTSD begins to fade and C++17 becomes the cultural mental image of the language, the argument for switching to rust will become less and less compelling.

Eventually, the only "advantage" will be ML influenced syntax.

The reason is there are only three languages that can easily call into C++ code. Objective-C (swift by proxy), D, and of course C++.

Why rust didn't prioritize compatibility with C++ like C++ did with C boggles my mind. Why do you think C++ became so popular? Near perfect C compatibility (until recently) is literally the only reason. Instead of focusing on pragmatisim Rust focused on language purity.

At what cost?

<comment><USER3> > But in C++ if you have a const member function F() then F() can only change > member variables that use the "mutable" key word.

This is not nearly enough. See the examples I gave in my other post.

Besides, all "const" means is "I won't mutate 'this'". It doesn't mean someone _else_ who has a non-const reference to your object won't mutate your object. That makes it largely useless for reasoning at a local level.

> If we train engineers to use const member functions, then the programmer is > forced to think about state and mutation.

The programmer may think about it, but the compiler doesn't enforce it at all.

> As C++98 PTSD begins to fade and C++17 becomes the cultural mental image of > the language, the argument for switching to rust will become less and less > compelling.

Only if you don't understand how Rust works.

> Why rust didn't prioritize compatibility with C++ like C++ did with C > boggles my mind.

Because C++ compatibility is impossible without being a derivative of C++, and C++ is hopeless in the safety department. I believe it is impossible to make C++ memory safe without making it not C++ anymore.

> Instead of focusing on pragmatisim Rust focused on language purity.

No, Rust focused on what is _possible_.

<comment><USER20> > Because C++ compatibility is impossible without being a derivative of C++, > and C++ is hopeless in the safety department. I believe it is impossible to > make C++ memory safe without making it not C++ anymore.

Do you consider D to be a derivative of C++? I don't. They have a near perfect C++ interface. D can even catch C++ exceptions. It's pretty sweet. You can hear about the black magic Andrei used to get that to work here:

[http://cppcast.com/2015/10/andrei- alexandrescu/](http://cppcast.com/2015/10/andrei-alexandrescu/)

Side note: I'm actually thinking the Rust and C++ comparison misses the mark. First of all, C++ cannot be obsoleted by rust, it's economically impossible. Secondly, I don't even think they compete in the same domain space. Rust is actually lower level than C++, in that it does lower level stuff in a more natural way. It's C, that Rust makes obsolete; which is something C++ totally failed to do (because of it's RTTI, exceptions, and other runtime features -- all things you and the rest of the Rust team intelligently scrapped). After trying embedded Rust, I'm completely done using C (and the C parts of C++).

IMO the advantages C++ still has over Rust are:

\- libraries, libraries, libraries

        - C++ has so many great libraries

        - *writing* C++ libraries with SFINAE sugar is the bees knees.

\- much better support and tooling, but this is for sure a temporary advantage.

\- template meta-programming feels like a different language, it's dynamic, functional, and the difference is refreshing. I like the mental switch you have to do to go from writing a C++ template to writing a C++ model.

\- as much as header files suck, they let you skim an API much more easily than Rust or Swift.

\- performant, memory safe data structures:

For example, it's trivial to write a low overhead pointer that can't dangle, throws an exception on nullptr deference, and that safely points to an object it doesn't own (even if that object is its owner). With this and a unique_ptr composed with similar safety mechanisms you now have the primitives needed to write any data structures or algorithm so that it is protected from undefined and unsafe behavior, yet remains performant. This solution has significantly less overhead than using reference counted pointers like shared_ptr derivatives or Rc. The performance tradeoff over using raw pointers is minuscule and totally dwarfed by the gain in safety guarantees. From what I've observed, you can't do this in Rust, if you try to write a doubly linked list you either have to use C-pointers that can dangle inside unsafe blocks, or eat the Rc overhead.

EDIT: How could I forget to mention the glory that is constexpr?

Advantages of Rust over C++ (again, IMO):

\- the correct defaults (aka opposite of C's insanity)

\- best C++11 features built in and defaulted (move semantics, unique_ptr is Box<T>, Rc is shared_ptr etc..)

\- Bad ass embedded capabilities. You don't nearly feel as crippled like you do in C++ without the STL.

\- the safety guarantees are real, and they're awesome

\- move semantics into closures looks so goddamn elegant. I love it

\- inline assembly doesn't feel like a hack

\- modules and cargo rock

\- secretly and surprisingly similar to ruby in a lot of places :)

\- it wants you to think functionally, and unlike Swift, it means it. This is a good thing.

<comment><USER5> > as much as header files suck, they let you skim an API much more easily than > Rust or Swift

Just to reply to this individual point, rustdoc is _fantastic_. Personally I much prefer having an HTML-rendered "header file" for a crate's API. Even if they aren't hosted, it's trivial to generate one yourself using `cargo doc`. To be maximally useful, the author needs to have made doc comments, but at least there's a standard format for that, and you might not have anything like that in a header file anyways.

<comment><USER34> You can try crates.fyi for hosted docs, e.g.

[https://crates.fyi/crates/itertools/0.4.7/](https://crates.fyi/crates/itertools/0.4.7/)</comment></comment></comment></comment></comment></comment></comment></comment></comment>


Road Tolls Vulnerable to Manipulation - <AUTHOR> http://www.technologyreview.com/Infotech/21301/?a=f

<comment><USER2> _"Every modern system requires a public security review to be sure there aren't different but related problems," he says. Indeed, in recent weeks, researchers announced flaws in another wireless identification system: the Mifare Classic chip, which is used by commuters on transport systems in many cities, including Boston and London._

Practical systems security, as practiced on/against web apps, operating systems, server software, and network clients, has evolved to the point where it is leading the entire discipline of information security. The work being done to reverse engineer, break, reinforce, and refresh web browsers is --- at a quick guess --- 4-5 years ahead of any other work being done in securing any other information system --- tolls, building security, financial markets, utilities, and large parts of the military.

So, of course someone as smart as Nate can bust up FasTrak. You'd be surprised if he couldn't.

What's interesting and worrisome to me is that the efforts of just one company (Microsoft) to engage the market to secure their own general-purpose code probably singlehandedly boosted the bill rates of every security consultant by 20-30%. How is this work going to trickle down into the rest of industry? My guess is, it won't. We should be more hesitant to wire things up that we depend on.

<comment><USER2> Oh, and on a less preachy and more relevant note: the way Nate did this is pretty cool. He didn't break the RF protocol; he reversed the board, the microcontroller (a very common one), and the firmware of the transponder. In RF work, we don't have to get the radio details right if we can get the existing equipment to do that job for us.

</comment></comment><comment><USER3> FasTrak lanes already have license-plate cameras, and may already be photographing every plate -- not just those whose transponder fails to respond.

So it should be relatively easy to estimate how much fraud is occurring, and invest more in enforcement if it is nontrivial.

(Unless of course fraudsters steal or counterfeit license plates to match their make/model, too. But that puts the threat even further into the realm of "anyone competent enough already has their time filled with more profitable activities".)</comment>


Warren Buffett: "Stop Coddling the Super-Rich" (2011) - <AUTHOR> http://www.nytimes.com/2011/08/15/opinion/stop-coddling-the-super-rich.html <comment><USER2> > I have worked with investors for 60 years and I have yet to see anyone — not > even when capital gains rates were 39.9 percent in 1976-77 — shy away from a > sensible investment because of the tax rate on the potential gain

I've been in finance long enough to believe that this is true.

The problem is that the rich have the ability to take their income in alot of different ways.

Tax income more, they'll take it as dividends.

Tax dividends more, they'll take it as capital gains.

Tax capital gains, they won't realize their capital gains until they can offset them with realized losses or they'll just get bank loans again't their stock holdings.

Tax assets on death and they'll pass them o n in trusts.

Some will move money off shore if they think they can get better returns that way.

The problem is that no tax code can close all loop holes because you just can't foresee the creative ways people will out maneuver the tax code.

Who would have thought 25 years ago that companies would buy other companies in different countries, not to acquire their products or markets, but to acquire their headquarters address to lower the tax paid in the US.

<comment> guard-of-terra How about taxing net worth of an individual? Calculated by market participants like they do today.

Tax 0,1% of net worth of those whose net worth exceeds say $10 million. Such people have to get assessment of their net worth and then pay their tax.

Of course they have incentive on doing slightly funny things with their net worth, but it is difficult to race them to the bottom in view of very large fines for crossing the line.

Of course people will skip citizenship then; but as long as they do business within country it is solvable too.

<comment><USER3> Net worth, as in property value - mortgages? Most 'middle class' people have most of their net worth in their principal residence, so you'd be adding quite a shocking tax bill to a lot of seniors on fixed incomes who own their own house. That's the problem with Mark-to-market taxing.

You could start added loopholes to your "block loopholes" law, like "If you reside in the property, it's tax free", but then you hit problems like parents given their kids properties as tax shelters, and the like.

<comment><USER4> What's wrong with seniors getting hit with a slightly larger tax bill? Besides, you could alwaysexclude the primary residence from the wealth tax to lessen the burden.

It would either generate additional revenue or have them move to an area with cheaper houses/properties to avoid paying it, which would make space for young professionals who otherwise would not be able to afford it.

I'm also venturing to speculate that a lot of seniors are NIMBYs, facilitating the lack of affordable development and re-zoning, in which case that's another argument to get them the hell out of their expensive suburbia.

<comment><USER5> Mostly because the seniors have spent their working lives building their savings (hopefully) to be able to retire, and have a very fixed income -- they can't look forward to getting another job, getting a raise, etc. Seniors as a whole are a very vulnerable group, which I think is one of the reasons that their voter turnout is so high.

Think about what that'll do to your retirement. Presumably you're saving and such, and want to get to a point where you can live comfortably (not extravagantly) when you retire: a trip a couple times a year, the ability to take your grandkids to get ice cream, etc. A tax bill can be devastating to your retirement savings & therefore lifestyle.

<comment><USER6> Think of Europeans, mathematically the idea that Europeans will ever retire doesn't make sense. It'd require 80% or 90% income tax, maybe even more, because there aren't enough kids to split the burden on.

Even in the US this is true, except to a less extreme extent. The systems the current seniors have put in place make sure few of the current workers will retire.

So why do they deserve it ? They voted in governments that fucked us, so why wouldn't we get to fuck them ?

</comment></comment></comment></comment></comment></comment><comment><USER7> Good counter-argument at the time from Michael Arrington from TechCrunch:

[http://techcrunch.com/2011/08/15/screw-the-rich-heres- how/](http://techcrunch.com/2011/08/15/screw-the-rich-heres-how/)

"Buffett calls for an increase in all types of taxes – income, dividend and capital gains. That would be a nice triple layer of protection against any newcomers, and still preserve all – 100% – of the $47 billion he's accumulated until now."

<comment><USER8> Arrington nails it.

If Buffett was really willing to pay more taxes, he could just stop using loopholes to avoid paying hundreds of millions every year. Or stop litigating with the IRS to get to pay less. He doesn't want "the rich" to pay more taxes. He wants other (less) rich people to pay more taxes.

</comment></comment><comment><USER9> Of course the super-rich are going to get coddled. If you are in a position of influence they can throw $100,000 to a million dollars your way to make sure you enact the policies they want. This can be in the form of consulting gigs or speaking fees or what have you.

Point is, the money is literally chump change to them.

<comment><USER10> a lot of the loops holes are for the "jobs" they are going to create.

</comment></comment><comment><USER11> How about "stop soaking the working class and spending like drunk sailors?"

</comment><comment><USER12> In the United States there are about 500 billionaires. There are also 150 million U.S. gun owners in a declining middle class where dead end temp work is a lifestyle for a large part of the population and basic social well-being and security is an "issue". I can tell you from first hand experience, when you are in that state ... you are not in your right mind. If I was one of those 500 people I would be very paranoid.

<comment><USER13> My understanding is that there's a few uber-rich that push for reform specifically because of this (or at least they use this argument on their less agreeable brethren). Being rich is only useful if there's enough stability to allow that fortune to be used.

</comment></comment><comment><USER14> Lets not forget the rebuttal, too.

[http://www.forbes.com/sites/paulroderickgregory/2012/01/25/w...](http://www.forbes.com/sites/paulroderickgregory/2012/01/25/warren- buffetts-secretary-likely-makes-between-200000-and-500000year/#3e547f7b18b8)

Edit: maybe that source isn't as good as I remember, but other sources seem suspicious over the factual accuracy of Buffet's claims.

[http://www.politifact.com/truth-o- meter/article/2011/sep/21/...](http://www.politifact.com/truth-o- meter/article/2011/sep/21/does-secretary-pay-higher-taxes-millionaire/)

[http://www.factcheck.org/2011/10/shes-no-buffetts- secretary/](http://www.factcheck.org/2011/10/shes-no-buffetts-secretary/)

<comment><USER13> _Buffet himself declares that he pays a 17.4 percent rate on taxable income. His staff, like Bosanek, pay an average of 34 percent. The IRS publishes detailed tax tables by income level. The 2009 results show that the average taxpayer paying Buffet's 17.4 rate earns an adjusted gross income between $100,000 and $200,000. But an average taxpayer in Bosaneck's rate (after downward adjustment for payroll taxes) earns an adjusted gross income of $200,000 to $500,000. Therefore Buffett must pay Debbie Bosanke a salary well above two hundred thousand._

Is it me, or does that not make any sense? The average tax payer of that percentage makes that amount, therefore she must make that amount? Am I supposed to believe this man doesn't know how averages work? Because the alternative is he's being _very_ disingenuous.

<comment><USER15> The way the progressive tax rates work in the US, you truly have to get to a pretty high level of adjusted gross income to average 34%. In 2011 the highest tax bracket was 35%, so you couldn't even pay 34% until you earned $379,151 or more.

Given that you'd only pay 35% tax on the money earned above $379,151, so it'd take a pretty darned high income to bring your total tax rate up to 34%.

<comment><USER13> For _federal_ taxes, yes. Was there a distinction by Buffet that he was referring to her federal tax burden, and not her combined federal and state burden? Nebraska's and New York (the places I figure she's likely to live/work out of) both seem to have state income tax rates between 6-7%. It's significantly easier to hit the 28% federal tax rate.

<comment><USER16> California tax payer here--FML.

<comment><USER17> don't forget NYC wage tax...

<comment><USER13> Sheesh, the worksheet[1] to compute your tax burden if you make more than $106k is annoying. I was just looking for an algorithm of some sort. From the under $106k table, it looks to be about 5%. That plus NY state taxes seems to put it on par with CA as a whole. That said, San Francisco appears to have an additional 1.5% flat income tax rate, which can raise the tax rate for high earners (well over $200k) in SF to close to 15% for combined state and local taxes.

1: [https://www.tax.ny.gov/pdf/current_forms/it/it201i_nys_tax_c...](https://www.tax.ny.gov/pdf/current_forms/it/it201i_nys_tax_computation_wkshts.pdf)

</comment></comment></comment></comment></comment></comment></comment><comment><USER18> on taxation, I always believe that "you" should make the tax reasonable enough to render its avoidance obsolete. Close all loopholes with flat laws and just force them. On the other hand there will always be some corrupted official to create another loophole in the process...

<comment><USER4> Unfortunately, this always runs into the problem of the elites influencing politics and policy, so all the loopholes will never be closed and there never will be 100% effective enforcement (as the Panama papers shed some light on).

I bet there were people in the 1850s saying the exact same thing.

</comment></comment><comment><USER19> Warren, shut your hypocrite mouth until you start writing checks to the US Treasury that cover the gap between whatever you're taxed and whatever you think you should be taxed.

Even then, STFU. You have no right to dispose of the lives of others.

</comment><comment><USER20> Not possible due to [https://en.wikipedia.org/wiki/Stockholm_syndrome](https://en.wikipedia.org/wiki/Stockholm_syndrome)

</comment><comment><USER21> How about not bailing out private enterprises with public money? That'd cost Buffet a few tens of billions.

<comment><USER22> They could of done and allowed the banking system to collapse and cost all Americans billions instead of making a profit for the public on the bailout. That said I can see an argument for what they did in Norway where if the government has to bail out a bank, they get to own it.

</comment></comment><comment><USER23> Are there similar statements by any of Russian oligarchs?</comment>


Python is a voluntary language - <AUTHOR> http://www.johndcook.com/blog/2011/10/26/python-is-a-voluntary-language/

<comment><USER3> Programming tastes evolve over time. At one point, and for at least a few years, I believed Python was the one true language revealed mystically to GVR. Up until that point, I'd done most programming in C++, so you can imagine how much fun Python was, in comparison. After further development and discovery of other programming languages, the shortcomings of Python have become obnoxious, much like torturing someone by dripping water on their forehead incessantly. Part of the problem is that I have to use Python for my professional work now. Using a language for your day job is a sure way to reveal all the issues.

Here's what rubs me raw day-in and day-out:

1\. Lack of immutable/persistent data structures. 2\. Lack of multi-line anonymous functions/lambda. 3\. Variable scoping fail, causing hacks like the new `nonlocal` keyword. 4\. worst_possible_variable_name_convention. 5\. Python evangelism. (community issue, mostly) 6\. Hypocritical "explicit is better" and "flat over nested" values with insane amounts of magic built into language and class system. 7\. No switch. 8\. GIL. (Actually the CPython runtime in general) 9\. No macros. 10\. the insane way "unicode" is supported. 11\. and on and on...

At this point I write Python code, but not generally by choice. Mostly my coworkers can't even imagine writing code in another language, given that we have been allowed to choose our implementation language(s) as a team.

<comment><USER4> I went through a similar progressions, or I guess I'm still in it. I have found multiple languages to replace aspect sof what I liked about Python but not one that addresses all of it. I think if F# existed on *nix in strong way I'd consider it a Python replacement.

<comment><USER5> What about OCaml/SML, or is .NET/Mono the thing that really sells it for you?

<comment><USER4> Ocaml, as a language, is amazing. But it's implementation isn't much better than Python's. No parallelism for example. And its ecosystem is worse than Python's in many ways, such as building code. I love the language, it's just the implementation that makes it an incomplete solution for me.

</comment></comment></comment></comment><comment><USER6> _I wonder whether the increasing popularity of Ruby for web development has created pressure for Ruby to compromise its original philosophy._

I don't think it has. The original philosophies, as much as they exist, oriented around ease of use, programmer happiness, and pure OO - <USER2> Rubyists still enjoy. But Ruby has missed the boat on being a popular, general programming language in the way Python is _big time_. _Most_ Ruby jobs are related to building Rails apps in some way or another and the majority of the Ruby ecosystem (in the West, at least) orients around Web development (and not gaming, scientific programming, education, or the many niches Python has found a home in).

Ruby is an interesting language and one that's worth learning and using IMHO, but in the West, Ruby has become "typecast" as a life support system for Rails essentially. (Before people note the non-Rails things they're doing with Ruby, I said _most_ Ruby jobs and the _majority_ of the Ruby ecosystem. Reporting on Ruby developments has been much of my job for the last 6 years but I am more than happy to be swayed :-))

<comment><USER7> I'm curious though, what was the uptake on Ruby before Rails?

I wasn't aware of Python/Ruby back in those times, but my impression now is Python was widely used prior to Rails existence... in academia, science, mathematics, etc, but Ruby was not much on the map until Rails came along.

I'm not saying this is how is was - I honestly don't know, just my impression as someone fairly new to this stuff. I would appreciate if someone who was familiar with the Ruby community prior to Rails could shed some light on this. Doing some google searches turns up minimal clues. The wikipedia on Ruby says "Around 2005, interest in the Ruby language surged in tandem with Ruby on Rails, a popular web application framework written in Ruby. Rails is frequently credited with making Ruby "famous""

<comment><USER8> While I wouldn't quite recommend the TIOBE index in general, it's still useful for attempts to identify significant events in the history of a language's popularity. Here's its historical graph for Ruby:

<http://www.tiobe.com/index.php/paperinfo/tpci/Ruby.html>

According to this, Ruby really exploded in 2006 after holding steady for quite some time in relative obscurity. Now you just need to figure out when Rails became hugely popular to check for a correspondence.

<comment><USER9> I believe it was this presentation in November 2005: <http://www.youtube.com/watch?v=Gzj723LkRJY>

</comment></comment></comment></comment><comment><USER10> I definitely wish I was writing something other than python. I did choose it, but it's not the language I want to be writing in. It's just the language that happens to have numpy, django, etc.

While writing it, I often wish it were statically typed with pattern matching. The write/test/type error or undefined variable cycle is very frustrating to me. The lack of pattern matching makes my code verbose and also makes it harder to spot edge cases I missed.

I also wish functional programming in it were as easy as in Javascript. I often find myself writing a bunch of front end code, finding it elegant, then thinking "damn, back to python to update the api". (This includes multiline lambdas.)

It's still my go-to language for most purposes, but I constantly feel that it could be a lot better. I'm looking forward to the day when javascript completely subsumes the niche python occupies.

<comment><USER11> I agree with you on static typing and functional style being strongly preferable, and that Python makes that style of programming irritatingly difficult, but it's not like JavaScript has static typing or pattern matching either, so it seems odd that it would be your preferred replacement. Why not wish for a replacement that actually has all of the features you want?

<comment><USER10> Haskell is my preferred replacement, but I don't really expect Haskell to replace Python. It might replace C++ or Java, however, or form it's own new niche.

People seem to want a simple, dynamically typed scripting language. Javascript can fill that niche while being a big improvement on Python. (Particularly if we accept some breakage of backwards compatibility, add a module system, and clean up the warts.)

<comment><USER12> I'm going to try and say this carefully, because I don't want to start a language war. Quite the opposite: I desperately want to change my views on programming languages.

I've only recently started in Javascript, so I'm probably missing something, but I've been finding it a large step backward from Haskell when compared to Python. Specifically, list comprehensions and generators give Python a more functional feel. Meanwhile, the object system in Javascript has had me generating far more state than I ever would have in my Python code, while also requiring more manual type checking than I ever needed in Python.

I'm new to the language, so I'm sure that I'm missing something. I've read _Javascript: The Good Parts_ and it's helped me grow less frustrated, but I'd love to find out that this language is better than Python.

So, how do you write functional code in Javascript?

<comment><USER10> I wrote poorly, I wasn't meaning to imply js is haskell-like. It's scheme like.

I write js using underscore and backbone, so while I have state, it's pretty well encapsulated.

So I've got a few stateful backbone models. The inside of their methods tends to be primarily functional, followed by a stateful update:

        var intermediateResult1 = _.map( input, function (ss) {...});
        var intermediateResult2 = _.map(input, function(ss) {...});
        var intermediateResult3 = _.intersect(intermediateResult1, intermediateResult2);
        ....
        this.setState({ "my_attribute" : result })

My views are almost entirely functional - take a model as input, create some dom elements as output, and one side effect when updating the view.

They may be just syntax, but multiline lambdas certainly help. And some of this is just library support. But all put together, it makes my js code far more functional than my python code.

<comment><USER12> Thanks for the response. As I told Kibwen, the underscore library looks pretty neat. Also, my problems may have just been some brain damage on my part. I'd gathered that object hierarchies were the more idiomatic way to code javascript.

I've been trying to write Javascript and then make it functional. I think I need to start writing functionally and just fit that into the Javascript. From what you've written, that looks pretty doable.

</comment></comment></comment></comment></comment></comment><comment><USER13> Nice point, and really, how many folks actually find writing code in Python cumbersome or "work" like some languages? It's not perfect and of course if you need really fast computing, it's obviously not (even close to) the best for speed, but it's expressiveness & readability are a pretty big step up from most other languages.

Also, I hadn't seen this essay by PG before (from the comments); a bit old, but interesting take:

<http://www.paulgraham.com/pypar.html>

</comment><comment><USER14> Just for the record: I used Python at work because I had to; I'd rather have been writing Java.

The titanic investment bank that I used to work for started a major rewrite of its entire set of booking and risk systems in which everything was to be written in Python. It immediately assigned hundreds of programmers to the task, shepherded by a "core team" eager to use every feature of the language. The result was a perfect example of the problems with Python in the large. Enormous type hierarchies mingled with copious use of eval; there was no structure at all to much of the code.

It's possible to write terrible code in any language, of course, but using Java would have been one way to curb some of the worst impulses of the low- quality programmers.

<comment><USER15> It seems that it would be much better to hire less and better programmers.

</comment></comment><comment><USER16> In terms of imperative languages, python is #2 for me. And really I haven't done much python in the last couple of years mainly because anything I would want to do in python I'd rather do in ruby. Of course you will definitely hear me say, "I'd rather use python than Y" but I'd also say, "I'd rather use ruby than python"

I don't even get what he's trying to get at in paragraph three. From looking at jobs for startups and jobs in the Bay Area I can see that a large majority of them are using python over ruby. So python compared to ruby is relatively more popular at least from a job-seekers perspective.

So even though this is true, he singles out that ruby may possibly have compromised it's original philosophy with rails because of its popularity but yet python hasn't been affected at all by its mass popularity from most startups and science/academia companies using it? Python also has a pretty popular framework in django yet I don't really see any pressure by Guido to change python because of it.

Really this article is a pretty ignorant view of ruby since he himself admits he does not know much about ruby. So why bother writing that last paragraph other than for the sole purpose of putting down ruby? The last paragraph feels pretty tacked on and seems to be a nice jab at ruby for no reason other than he likes python.

Let me just end by saying, I love python, but I love ruby more. I don't have any ill-will towards python. But consider if this article was written about ruby and dhh wrote it. How much vitriol do you think dhh would get from writing an article like that?

</comment><comment><USER17> > I don't know much about the Ruby world, but I wonder whether the increasing > popularity of Ruby for web development has created pressure for Ruby to > compromise its original philosophy. And I wonder whether Ruby's creator > Yukihiro Matsumoto has "dictatorial" control over his language analogous to > the control Guido van Rossum has over Python.

This is a some what irritating speculative musing, given the fact that it is a question that could easily be answered by talking to any number of Rubyists who are available and interested in answering such a question.

One of the major points of tension in the Ruby community is the extent to which the non-Japanese Ruby community has input and control over the destiny of Ruby as a language. Given a number of alternative implementations of Ruby (JRuby, Rubinius, MacRuby just to name the popular ones), alternative implementors have gone well out of their way to ensure conformance with the mainline Ruby implementation.

In fact they went so far out of their way to build a spec suite to characterize the behavior of Ruby the programming language from it's actual implementation. And on top of that there's even a new ISO spec for Ruby.

So, yeah. Matz does have control of Ruby, and Ruby does resemble Python in its voluntariness.

<comment><USER8> Agreed, but I confess that I'm also a bit unclear as to Matz's active involvement with the language. Every "Ruby expert" post on HN seems to originate from either Yehuda Katz or DHH... is it just that Matz prefers to communicate in Japanese, on Japanese mailing lists?

<comment><USER6> Matz is deeply involved with the language's design and a couple of its implementations but as a _community_ leader, in the West, at least, he doesn't do much or have much impact IMHO. This is part of the reason people, rightly or wrongly, have seen the well known Rails developers as figureheads for both Ruby and Rails and then poured scorn on Ruby for their actions.

</comment></comment></comment><comment> sasha-dv >People who write Python choose to write Python.

People who write X choose to write X.

There's virtually no language that can't fit the bill. It may surprise some, but there are people who choose to write Java, Perl, C, and even C++.

edit: Didn't realize that people who choose a language different than Python aren't actually people.

<comment><USER12> The following statement is false:

        People who write LabTalk choose to write LabTalk.

It is false because I am a person who writes LabTalk and I did not choose to write LabTalk. I hate LabTalk with a passion. However, I am forced to write LabTalk to interface with one of the systems at work. The following statement is also false:

        People who write Tcl choose to write Tcl.

I had a coworker who was forced to learn Tcl to maintain a legacy system. He hated Tcl, mostly because it wasn't Fortran. Honestly, though, I have a soft spot for Tcl, so the following statement is true:

       Some people who write Tcl choose to write Tcl.

Now that statement is trivially true and most of your original argument applies to it. In fact, I'll even agree with you that

        Some people who write X choose to write X

applies to virtually every language. All people who write a language different than Python are people. The original statement does not make that claim. It makes the claim that the set of people who write python does not contain any elements from the set of people who did not choose to write python. That claim is not true for Java, Perl, C, C++, LabTalk, or Tcl. It may not even be true for Python. However, it is a meaningful claim.

<comment> sasha-dv >That claim is not true for Java, Perl, C, C++, LabTalk, or Tcl.

Sure, it's not true for any of them, _even_ Python, but it's _meaningful_ for any language including Java, Perl, C, C++,...

It's easy to forget that computing is a huge field and that hackers diverse in their tastes and fetishes.

</comment></comment></comment><comment><USER18> I use Python at work because I have to, but I'd rather be writing JavaScript.

</comment><comment><USER19> I use Python at work because I have to, I would really rather not.

</comment><comment><USER20> EDIT: Python is my favorite language. But I wish a LOT more very lazy people or people who can't apply algorithms to solve their own problems (and hopefully in all the same domains that I work in) used it, discussed and asked questions, etc.

It is in this vein that I write...

"Python is popular enough to have a critical mass of users" - on this point unfortunately I have to disagree.

Often the way I write a script is to put in a little extra effort up-front: I do three or four Google searches with the hard part of the task + Python, Perl, PHP, etc -- just to see if someone has already done this for me. I must say that if it's something hard and remotely web-related, the Python part is usually not even worth trying. Either I can do it off of the top of my head, or some fool is asking how to do this thing they can do in PHP in Python and, well, not really getting an answer. (It's not that it's wrong to code things up the long way, it's just that, like I said, it's not even worth doing the Google search).

In this sense there is not a 'critical mass' of users. Let me give you a simple example. Say you want to do fancy appointment-matching like people saying "next friday"...you want to try to pick up on that and offer to set an appointment. So, Google "appointment regular expression next friday php" "apppointment regular expression next friday python" "appointment regular expression next friday perl". You can go ahead and do it, I don't even have to check. If you don't find anything, play around for less than 15 seconds with alternate search terms (more general, more specific, or just different.)

I did the above search just now, and in my case I went off on this tangent and within a couple of minutes had an answer that was satisfactory for me.

I would say, well, there are simply lots of fast scripts that you KNOW can take you 2-3 days of head-scratching to get right _OR_ that the community already has bumped their heads against. Which do you do? If you're NASA, of course you go through scratching your head and getting the RIGHT answer. If you're trying to get a demo out the door, then you go for the low-hanging fruit, with as much leaning on the community as possible. Of course, if its creation, trajectory calculations, whatever, involve a scripting language in any way, would I want a _rocket_ to use Python over PHP. But if I need a script that creates a GIF file of a rocket blasting off off-screen, based on a static image of the rocket that I have? (Forget whether the gif is the correct solution, I just want to see what it looks like, maybe as part of investigating lots of possible ways to do this). Well, then I would do a couple of minutes of Googling first... (As above, though I didn't try this one). Usually, I'm sorry to say, Python doesn't win.

If this get smore downvotes I'll try the Python search on creating a gif file programmatically.

<comment><USER21> I am having difficulty figuring out your point. Is it that, when you Google for examples for how to do something in Python, you usually don't find satisfactory results? But that other languages (Perl, PHP) do provide such results?

If that's the case, then what particular task you're asking about is going to impact how successful you are. People write much more than just "web-related" things in Python. And, personally, I don't consider that to be important for what I consider a critical mass of users. Rather, what I think is important is that there is enough of a community to provide good online documentation, plenty of technical books, maturity of the toolchain, and integration in most systems.

<comment><USER20> I'm sorry my point was unclear. Often I place speed (i.e. time-until-I'm-not- doing-this-anymore) at an incredible premium to the point where I don't care what the language is! For example, say that you want to attach a process to monitor a logfile of your web-server(apache, say) and SEND YOU AN EMAIL when a string enters that logfile.

Hopefully, you should be able to complete this task in every single programming language that appears on your resum, including javascript if you have put it there.

In practice, if you are a one-man show trying to get a whole startup off the ground (including all of the biz dev, all of the back-end, all of the front- end, all of the customer e-mails, EVERY SINGLE THING YOUR COMPANY IS DOING) then you don't have the luxury to scratch every itch. There are itches that you can scratch if someone has done it and you can find this out in 15-20 seconds, otherwise, you just don't have the time.

In this sense PHP wins where Python has not yet won.

<comment><USER21> I understand what you're saying, but I still don't feel that its relevant. Your example is the sort of thing that I would expect myself and other developers to be able to produce a more reliable solution on their own than what they could copy-and-paste from the web. In other words, I wouldn't do it myself because I felt like I "had to scratch that itch." I would do it myself because otherwise I would have no trust that it would work.

<comment><USER20> Right, I think your final sentence gets at the crux of what I'm talking about. I have 0 trust in PHP that my script really 'works' -- however, very often I have a lot more confidence in being able to get to something that 'seems to work' within 30 seconds. Whereas, in Python I am pretty much guaranteed to spend 5-15 minutes on it.

As for web work. I actually just did try "how to tail a file in php" and "how to tail a file in python". On the PHP side I instantly saw this stackoverflow question [http://stackoverflow.com/questions/1102229/how-to-watch-a- fi...](http://stackoverflow.com/questions/1102229/how-to-watch-a-file-write- in-php) which links to this:

<http://code.google.com/p/php-tail/>

 _Ability to tail small and big files for updates using PHP and AJAX. Includes the ability to grep results for a specific keyword.

\- Fully documented

\- Fully customizable

\- Updates the page with new information without a page refresh

\- Change GREP keyword / invert on the fly without a page refresh

\- Uses JQuery / JQueryUI libraries

\- Simple to use UI

\- Automatic scrolling when required (if a user scrolls up, the automatic scroll is disabled until the user scrolls to the bottom again)_

Wow, that is pretty amazing. If someone just HAPPENS to be looking for a quick tail through a web-browser, with grep functionality, this is a drop-in solution. It's not what I needed, but this is my whole point about community- size. As it gets larger and larger, there is a greater and greater possibility that just what you need is 30 seconds away. It would literally take you hours to do all of the above in Python.</comment></comment></comment></comment></comment>


Get Started with GPU Compute on the Web - <AUTHOR> https://developers.google.com/web/updates/2019/08/get-started-with-gpu-compute-on-the-web <comment><USER2> > Think of this adapter as the graphics card. Once you have the GPU adapter, > call adapter.requestDevice() to get a promise that will resolve with a GPU > device

what's the difference between a gpu adapter and a gpu device?</comment>


Intel details 14 dual-core Ivy Bridge processors ahead of Computex - <AUTHOR> http://www.engadget.com/2012/05/31/intel-dual-core-ivy-bridge/ <comment><USER2> Why do I care about dual-core? I want a reasonably priced six core i7.. or 12 cores would be better.

<comment><USER3> Paralleling is only going to net so much performance increases, you can't increase cores exponentially and expect performance wins. Better efficiency in single threaded performance will have the most effect for most people.

I think much of the performance increases we will see in the near future will come from better coding, for example Windows 8 is supposed to run faster on older hardware compared to Windows 7(also consider the simplicity of the ui of Windows phone and the resulting snappiness and speed on older hardware), combined with the influx of SSDs we may have reached or are nearing the plateau of performance that the average person would ever care for.

<comment><USER4> Most users won't get any effect at all unless they're playing top-end video games.

Anyway, I thought by now we would have 16-core processors.... I don't understand why the "default" one is still two cores.

<comment><USER5> _"Most users won't get any effect at all unless they're playing top-end video games."_

I have 14 browser tabs open.

Safari is currently using 17 threads. Webprocess is using 10, Pluginprocess is using 22.

I shudder to think what those numbers would be if I wasn't running AdBlock.

I believe most users would see the effect of more cores.

<comment><USER4> Actually, I was talking about the single-threaded performance - I agree wholeheartedly that more cores would be a better experience.

</comment></comment></comment></comment></comment><comment><USER6> As far as I can every cpu is labeled mobile or ultra mobile except for one (which also has has a significantly lower TDP compared to the quad cores).

</comment><comment><USER7> I see 5 quad core and 9 dual core CPUs in the list.

<comment><USER8> Yup... no 14 core chips here</comment></comment>


Ask HN: Top 10 Hacks of All Time - <AUTHOR> http://slashdot.org/features/99/12/13/0943241.shtml

<comment><AUTHOR> The Slashdot article is old (year 1999) but still lists some cool hacks such as CC, Perl, and even AK-47.

Am wondering which all hacks would you rate as top 10 hacks of all time? Mine would be:

Karma System, Python, Hacker News, Y Combinator, Electric Guitar, Google, Firefox, Hotmail (it was a pioneer in web-based email), APIs, Wikiepdia

</comment><comment><USER2> One of the best hack stories was that of the Direct TV smartcard. They slowly uploaded updates to the card to create a dynamic programming interface. The first 8 computer bytes of all hacked cards were rewritten to read "GAME OVER".

Full story:

<http://slashdot.org/articles/01/01/25/1343218.shtml></comment>


Heart-Stopping Marketing - <AUTHOR> http://www.youtube.com/speakhumanbook#p/u/0/ya91piq0_JE

<comment><AUTHOR> Of all the stories I included in my book Speak Human, this is the one that continues to make folks smile.

"Dr" Jon Basso has done something that few marketers will ever do: crafted a story that will get people talking. (Truth be told, most marketers are way too scared to do something this bold.)

When you work on your start-up, ask yourself: what story can we tell that will get others to share it?</comment>


NationalSecurityAgency wants to merge 5 commits into yiisoft:master - <AUTHOR> https://github.com/yiisoft/yii/pull/2623

<comment><USER2> I think it's a bad idea to lose focus on the important topics in the NSA scandal with little jokes like this.</comment>