Why the developers who use Rust love it so much - <AUTHOR> https://stackoverflow.blog/2020/06/05/why-the-developers-who-use-rust-love-it-so-much/ <comment><USER2> I love this quote from a friend of mine who was learning Rust:

"It's hard but I love it. Dealing with the compiler felt like being the novice in an old kung fu movie who spends day after day being tortured by his new master (rustc) for no apparent reason until one day it clicks and he realizes that he knows kung fu."

<comment><USER3> Sounds a lot like programming in Haskell. Applying higher-order functions or condensing a parser into a oneliner just makes me _feel smart_ in a way that generating a new Rails controller never does.

My personal theory is that a lot of Rust and Haskell (and many other "advanced" languages) usage is caused by people chasing that feeling. The publicly expounded benefits like memory and type safety are true, but the real reason is that people want to use the language for their own reasons and "I really like it" usually does not have enough weight in a business context.

<comment><USER4> Unlike Haskell, Rust offers a unique combination of safety and runtime performance, which does provide real business value in sone domains.

<comment> UK-Al05 Algebraic data types, monads, and things based around those have tons of business value for writing correct business logic for non-performance critical code. You get that in haskell.

Though admittedly you can get them other functional languages that are not quite as different. Like Ocaml.

<comment><USER5> Monads are so cumbersome to implement and consume in OCaml that they are not very commonly used. Jane Street Core has monadic abstractions for things like async but it's a pain without syntax extensions.

<comment><USER6> That was true until 4.08. OCaml now supports monadic let bindings, and more generally, user defined let bindings [1].

You get the benefits of ppx_let (Jane Street) but in a more general and syntactically nicer form. I still wouldn't call it as nice as do notation in Haskell but it makes monads highly usable in OCaml without the need for an external dependency.

[1]: [https://github.com/ocaml/ocaml/pull/1947](https://github.com/ocaml/ocaml/pull/1947)

<comment><USER5> Wow, I completely missed this! Nice.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Coding in Rust isn't easy, but where it is hard it is hard in a good way. It is like being on a journey with a good friend, who deeply cares about not letting you shoot yourself into the foot and explains you why without judging you.

Even if Rust would be wiped off the face of the earth tomorrow, thr things I learned from it have definitly made me a much better programmer.

<comment><USER8> >explains you why without judging you

Yep, the compiler doesn't judge you, that role is left to the community when they discover you posted a library on Github that uses more unsafe code than they'd like.

<comment><USER9> for anyone not following Rust, the drama around the (popular) Actix web framework was a prominent instance of this. iirc people opened issues and PRs re: the project's (significant) usage of `unsafe`, but the maintainer (Nikolay Kim) wasn't receptive; then some folks got nasty about it on reddit, escalating into full-blown drama. sadly, it ended with Kim posting he's "done with open source" and quitting the project.

a more detailed (and probably more accurate) account: [A sad day for Rust]([https://words.steveklabnik.com/a-sad-day-for- rust](https://words.steveklabnik.com/a-sad-day-for-rust))

<comment><USER10> By no means is it _only_ about Actix; that's just one of the more notable times that something like that has happened. The eminently reasonable criticism boils down to baulking at people undermining Rust's safety guarantees with _demonstrably wrong_ unsafe code, while publishing said code in such a way that you're suggesting that others use it ( _i.e._ it's not just private code). It is also then often taken further to a general unease at gratuitous use of unsafe code, which I consider fairly reasonable because it's so hard to get right (it's unsafe for a reason). Then sometimes a _few_ people take it beyond what might be considered socially reasonable.

<comment><USER11> It is a mistake to marginalize what a small number of people achieved. An organized team successfully "cancelled" the Actix project and smeared its author after repeated attempts-- three distinct episodes over 12 months. This was a campaign that spanned social media and github.

It is worth noting that to this date, none of the members of the anti-actix effort have contributed towards a viable alternative, nor have they attempted to resolve their concerns in the actix ecosystem. It turns out that the patrons who complained about free beer never intended to brew their own.

<comment><USER10> I never followed the matter _closely_ , but from the parts that I _did_ follow or investigate, your comment doesn't feel particularly accurate.

• I don't believe there was any organised team; it arose organically.

• In each case the complaints were of concrete problems that incorrect usage of unsafe caused. _After that_ , people did then tend to pile on and baulk at other unsafe code that was probably OK, _because the author had been proven untrustworthy in using unsafe code_. ("Unsafe" says "trust me, it's OK", and that trust had been broken.) And there _were_ one or two people that made it more direct personal attacks—but probably only one or two.

• Your final paragraph just seems _completely_ wrong. Various of those that complained _did_ offer alternatives, _some of which were turned down_. And people _did_ go with viable alternatives, switching to competitors to Actix. Even apart from all that, if you can prove that by some metric a piece of software is bad, why would the burden lie with you to fix it? ( _Especially_ if your patches are rejected.) If the problem won't be fixed, recommending that others avoid it seems perfectly reasonable. You're presenting a common logical fallacies, that you can't criticise something unless you can provide an alternative. I don't need to be able to build a better bridge to be able to point out that it's falling down.

Feel free to correct me if I'm wrong, but I intend to engage no further on this. The points have been hashed out before and there is nothing new to say; things just tend to get heated. Have an enjoyable day. :)

<comment><USER11> Have a great weekend

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Money quote: "Rust benefits here that very few people are being forced to use Rust."

Probably more people pick up C++ for the first time, in any given week, than the total who use Rust in production today.

Rust also benefits from the limited historical baggage that comes with being new and incompatible. Unlike Java, which was in the same position, Rust adopted very few old mistakes, and especially unlike Java made few new ones. But as the language approaches industrial maturity (possibly within 10 years) early mistakes will become evident, and cruft will be seen to accumulate.

Rust designers have consciously chosen to keep the language's abstraction capacity limited, which makes it more approachable, but reduces what is possible to express in libraries. Libraries possible, even easy in C++ cannot be coded in Rust. The language will adopt more new, powerful features as it matures, losing some of its approachability and coherence. But Rust has already passed a key milestone: there is little risk, anymore, that it could "jump the shark".

The language is gunning for C++'s seat. Whether it becomes a viable alternative, industrially, is purely a numbers game: can it pick up users and uses fast enough? The libraries being coded in C++ today will never be callable from Rust.

Go proved that the world will make room for a less capable language (in Go's case, than Java) if it is simpler. Rust is much more capable than C, Go, or Java, and the world would certainly be a better place if everybody coding those switched to Rust. So, my prediction is that Rust and C++ will coexist for decades. The most ambitious work will continue to be done in C++, but a growing number will have their first industrial coding experience in Rust instead of C, and many will find no reason to graduate to C++.

<comment><USER13> > and the world would certainly be a better place if everybody coding C or Go > switched to Rust

Perhaps. Let's engage in a thought experiment. Sorry for moving slightly off- topic, but the line I quoted made me think about this.

Someone fashions a magic wand, which you can wave over C, C++, and Go programs / libraries to instantly re-materialize them as idiomatic Rust, while preserving all of the "good" output they produce, and simultaneously removing the "bad": all memory safety and data race related bugs they exhibit.

You get to use this magic wand on any program you like, instantaneously. You do so, creating linux-rs, glibc-rs, chromium-rs, etc. in the process. You cargo build all of this new software and replace the old C / C++ versions with it, in-place.

In the brave new Rust-powered software world, does your day-to-day computing experience change? It is materially better?

Speaking for myself, the answer is "no", unfortunately. Perhaps this message is coming from a place of frustration with my own day-to-day computing experience. Most software I use is much more fundamentally broken, in a way in which doesn't seem to be dictated the programming language of choice. The brokenness has to do with poor design, way too many layers of absolutely incomprehensible complexity, incompatibility, and so forth. I don't remember the last time I saw a Linux kernel oops or data corruption on my machine, but I am waiting _seconds_ to type a character into Slack sometimes.

I like most of the ideas behind Rust (I don't like the language itself and some of the choices the authors made, but that is another discussion). However, I think there is only so much you can fix with the shiny and sharp new tools, because it seems to me that most issues have little to do with low level matters of programming language or technology, but with higher level matters of design, taste, tolerance for slowness / brokenness / incompatibility, etc.

<comment><USER14> Part of the reason your Slack is so slow is that a lot of stuff is built to protect from problems that Rust might eventually solve.

Slack builds the UI on web technology that got widespread in part because it solves awkward problems with deployment (self-contained and consistent graphic libraries, so you don't have to worry about how your DE compiled this or that other toolkit) and safety (web tech is heavily sandboxed so that crashes and executions won't open doors to bad actor). In the long run, Rust will definitely make the latter less cumbersome (less worrying about crashes -> simpler, lighter, faster sandboxes) and possibly help with the former a bit (desktop environments and their libraries could shed some complexity when moving to Rust and make it easier for programs to access them safely).

I think it's a noticeable step forward. Will it solve everything? No, some of the problems with Slack-like situations are due to economic factors (browsers sticking to JS will forever continue to make JS programmers cheaper and more plentiful than basically any other type of programmer) that Rust is unlikely to affect. But perfect is the enemy of good in this sort of thing: incremental progress is better than no progress.

<comment><USER15> But I think Rust is also quite vulnerable to the layering problem the previous commenter is speaking about. One of the best things about Rust is how easy Cargo makes it to include 3rd party code in a project, but this is also one of Rust's biggest risks. It's already common for Rust projects to have massive lists of dependency, and that's something which generally gets worse as time goes on rather than better.

Rust as a language may have favorable properties with respect to speed and safety, but programs which run on top of a massive tree of third party code which has been written by god-knows-who tend not to be very fast or very secure.

NPM has already shown that dependencies can be used as an attack vector, and unless Rust can solve this problem, I don't think it's going to bring us some brave new world where we don't have to sandbox anymore.

<comment><USER16> > programs which run on top of a massive tree of third party code which has > been written by god-knows-who tend not to be very fast or very secure.

You have a point about security, but not about the speed. I can probably link 5 "we rewrote in Rust and it was much faster" articles. All of these used third party libraries. ripgrep for example, is faster than grep, despite having more dependencies. In reality, it just promotes better code reuse without impacting run time speed. If anything, separating your code into crates improves incremental compilation times.

It's possible that you might pull in a large dependency with many features. Compiling all of this and removing the unused code will cause a compile time penalty and no run time penalty. In practice, Rust crates that expose multiple features have a way to opt-out/opt-in to exactly what you need. No penalty at all. In any case, most rust crates err towards being small and doing one thing well.

Examples

\- [https://blog.mozilla.org/nnethercote/2020/04/15/better- stack...](https://blog.mozilla.org/nnethercote/2020/04/15/better-stack-fixing- for-firefox/)

\- [https://hacks.mozilla.org/2018/01/oxidizing-source-maps- with...](https://hacks.mozilla.org/2018/01/oxidizing-source-maps-with-rust- and-webassembly/)

<comment><USER15> I agree that Rust has very favorable characteristics when it comes to performance. My argument would be that language choice is not a panacea. It's certainly possible to write performant code which leans on dependencies, but the style of development which relies heavily on piecing together 3rd party libraries and frameworks without knowledge of their implementation details is not a recipe for optimal performance.

</comment></comment></comment></comment></comment></comment><comment><USER17> Rust is a fantastic language, and once past the borrow checker level, it can be quite productive. One interesting compatriot of Rust is Swift, which also ticks most of the checks in that list. Also Swift has IMO a better development experience, due to Apple's initiatives. I wonder what Rust developers think about swift.

<comment><USER18> Fun fact: several early Rust developers, including the initial author Graydon Hoare, switched to Apple and started working on Swift.

The languages have a shared legacy and feel quite similar in certain aspects, with Swift being a higher level adaptation.

Swift is a lot easier to use, with automatic reference counting, quite a bit more convenience and syntax sugar, and a class system.

It's a lovely language.

It lacks what are the defining features of Rust (for me) though: low level control available when required but usually hidden behind nice abstractions, borrow checker, concurrency safeguards (Send/Sync in Rust), trait system over classes, and a good macro system.

The biggest conceptual downside for me is the class system with inheritance, overrides, etc: Rust has traits that are somewhat similar to Haskell type classes, and are much nicer and more coherent to use in many domains. (it's far from perfect, especially around the severely limited trait objects and dynamic dispatch, but that is a longer topic)

The biggest practical downsides are Apples disregard for other platforms (Linux/Windows are very much second/third class citizens) and the Objective-C compatibility baggage, which makes the language a bit messy.

But overall I think it is easy to like and appreciate both languages.

<comment><USER17> Yes, there's a lot of cross-pollination between Rust and Swift, and Swift devs pragmatically use features from Rust ecosystem. IMO Rust has much better FFI than Swift, but that's primarily due to Apple. I'm really stoked up for both languages to gain a larger space in developer ecosystem.

> The biggest practical downsides are Apples disregard for other platforms.

This is unfortunately true, but I see Swift committee making serious efforts to overcome that. I hope it gets better with time. Swift on Backend (vapor/Kitura) are simply ages behind Actix.

Another language that's syntactically close is Kotlin/native, even though it has quite different goals. These 3 languages have brought much excitement to development in the past few years.

<comment><USER19> > IMO Rust has much better FFI than Swift, but that's primarily due to Apple.

How so? Swift has a stable ABI that, among other things, enables it to expose FFI bindings to many other languages. Rust has made the pragmatic choice of having no stable FFI beyond the C one, so if you want to setup FFI to a Rust library you'll have to write C-compatible wrapping code in Rust and expose that.

<comment><USER17> Swift got stable ABI in version 5, that's bit late IMO. Also the community efforts to improve Rust interop (e.g. Rustler/Elixer) are way ahead when compared to Swift. That being said, I personally am happy that both languages to have first class FFI

<comment><USER15> > that's bit late IMO

It's pretty rare for a language to have a stable ABI, no? I mean Rust still doesn't have one.

</comment></comment></comment></comment></comment></comment><comment><USER20> Also: almost everyone who uses rust does so by their own choice.

<comment><USER21> I don't get this comment, rust is a new language that isn't widely embraced by employers yet.

How would rust have a significant number of users forced to use it?

<comment><USER22> It's discussed in the article but that quality kind of 'games' the metric SO are using - what % of people using it want to keep using it? If people were forced to use it for work then you'd likely see a lower number regardless how good it is just because it wouldn't be every single person's preference.

It's not a bad thing - a new language that doesn't reach that point probably dies - but it does make it easier to score highly on their metric.

</comment></comment></comment><comment><USER23> "In type checking, only the signature of functions are considered. There's no relying on the implementation for determining if callers are correct (like you can do in Scala, or Haskell)"

What does this mean?

<comment><USER24> You can know the exact parameter and return types of a function by reading its signature. You can't do that in Scala, because of type inherence. This is legal Scala:

      def twice(x: Int) = { x * 2 }

But you can't know the return type without reading the function body. That example is not so bad. I routinely used to confront things like:

      def applyComputation(x: Int) = { determineComputation().compute(x) }

And now you're off on an adventure to work out the return type.

EDIT There's sort of a deviation from this with "impl trait" returns. There the signature says that the function returns some type which implements a certain trait, but you can't tell exactly what.

<comment><USER25> It's been a while since I've written any Scala, but if I recall correctly it's frowned upon to use type inference for return values in method signatures.

<comment><USER26> > it's frowned upon to use type inference for return values in method > signatures

The language shouldn't allow it in the first place. Its a symptom or not balancing power with complexity and shows up elsewhere in Scala. They "were so preoccupied with whether or not they could that they didn't stop to think if they should."

<comment><USER8> OCaml also does global type inference like this, and it generally works out fine (unlike Haskell, it's not idiomatic to write a type signature for every single top level function in OCaml). Maybe because the type system is more principled compared to Scala.

<comment><USER27> Ocaml and the MLs have a very strong commitment to global type inference, much stronger than Haskell's. Scala has no commitment.

That said, you do see a lot of types in Ocaml code. Ocaml source files typically have an accompanying signature file (with extension ".mli" rather than ".ml"). The signature file gives explicit types for all of the definitions (fields) in the structure file. Often, you need to write these signature files because you want to hide implementation details from the user and so give narrower types than the ones inferred by the compiler.

You can and do write Ocaml without ".mli" files, and there, you are relying heavily on global type inference, and built-in Ocaml tools to tell you what your most general ".mli" file would look like. You can and do get the compiler to write them for you and then add your restrictions and documentation. As such, Ocaml programmers are very used to reading these signatures as the entry point to understanding a library.

This doesn't work so well in Haskell, because Haskell doesn't have global type inference, and annotations are sometimes mandatory. Consider the expression

       show (read "1")

Without saying what type "read" is supposed to return here, there's no way to know what this code is supposed to do.

<comment><USER8> >because Haskell doesn't have global type inference

I'm curious what you mean by that. Is it because Haskell's additions mean that its version of Hindley-Milner type inference is not able to infer types for all expressions?

Is this also why the OCaml Emacs mode is much better, even though Haskell has more developers?

<comment><USER28> I'm curious what about Ocaml's Emacs mode is better. I use dante for Haskell in Emacs which is good, but I'm always interesting in hearing about better technologies.

<comment><USER27> I'm not the parent, but thanks for the link to Dante.

One of the main things I like about Ocaml and merlin is how robustly it can tell you the types of expressions by hitting "C-t". It usually works on incomplete code, and it will tell you the type of arbitrary subexpressions (not just identifiers) in your selected region.

It will do automatic destructuring of an identifier (producing a match/case expression with the patterns in the ADTs filled in for you). It's not perfect, but I use it a lot for complex ADTs.

The autocompletion is great too. It will complete for local variables in scope, and it must be having to do some fairly complex stuff in the background, since it'll autocomplete for local modules applied to functors. For example, you can write

       let foo x =
         let open Foo(Bar) in
         ...

and when you autocomplete inside the "...", it will bring in completions from the module generated by applying Bar to Foo.

I'd be interested to hear how dante compares.

<comment><USER28> Thanks!

> I'd be interested to hear how dante compares.

> it can tell you the types of expressions

dante has flaky support for this

> It will do automatic destructuring of an identifier

dante does support this. It's a bit hokey because the code it inserts doesn't match pre-existing indentation, but it is useful.

> The autocompletion is great too. It will complete for local variables in > scope

That sounds very cool. I don't think dante does that, although I've never tried it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> Rust is great but it could gain from explaining itself with memory and pointers or else why a String has the Clone trait and a u32 the Copy trait? I tried to learn it as a first language and it was hard until I started learning C, groking the stack the heap and pointers. I think all the tutorials out there are ill suited since they hide away so much. It's harder to remember stuff if you don't understand why it is that way, well at least it stands true for me. So I would love to see a Rust for beginners tutorial for C beginners. Maybe I'll write it someday. I really got discouraged when it got into the ugly lifetime syntax. But I will definitely come back to it. (Unless Zig shows to be just as safe and less verbose)

<comment><USER30> Fair point.

The Copy on u32 and lack of Copy on String _is_ confusing until you've grasped that things containing heap allocations are ineligible for Copy, and that Copy is primarily intended for data types the same size as or smaller than a pointer.

</comment></comment><comment><USER31> It feels like being part of a village that learns to love the dragon it battles.

</comment><comment><USER32> It's the only production-ready language that is both memory safe and has zero- cost abstractions (i.e. for any C code you have Rust code that compiles to equivalent assembly, and using more abstractions in Rust does not make the assembly less efficient unless the abstraction can't be implemented otherwise).

Also as long as you accept not having dependent types (at least for the short and mid-term) and several currently unimplemented features, Rust is the optimal way a programming language can be designed other than assorted minor warts.

<comment><USER11> Batteries are very much already included. The missing features you are referring to are likely not show stoppers.

</comment></comment><comment><USER33> It's a niche language that dominates its niche.

I wouldn't write a LoB application in Rust, for example. But if I wrote programs with really tight speed and memory requirements for a living, I would pick Rust for the task.

If people were forced to write their website backends in Rust (or even their frontends in Rust targeting WASM) they would hate it. Its performance is overkill for 99.9% of backends, but the means of getting this performance kill your productivity.

<comment><USER34> My current side project has a frontend in Rust via WASM, and I love it. Way better than the huge mess that is the JS ecosystem.

<comment><USER11> Rust WASM is still very bleeding edge. Let's not give anyone the false impression about what anyone can manage to build today.

</comment></comment></comment><comment><USER35> I've been casually playing with Rust for a few years now. Wrote a few small things in my previous job that still run a large part of their business, which is pretty satisfying, but only very recently have I found a couple of hobby projects where it just feels like the right tool for the job (for me). Web stuff I'd still much rather write in Ruby, if I'm honest, but for playing around on systems Rust is super fun. I ended up making [https://git.sr.ht/~robotmay/amdgpu- fancontrol](https://git.sr.ht/~robotmay/amdgpu-fancontrol), of which there's already an equivalent in Python, but the lack of dependencies when installing a piece of Rust software makes it feel very portable and neat.

My favourite metaphor for Rust is that it's like a friendly bare-knuckle fist- fight with the compiler. It's not as user-friendly as, say, Elm, but it's streets ahead of Haskell's errors.

<comment><USER36> Can I just say, I really appreciate the Community reference

Edit: Btw, if you have to ask what I mean you're streets behind

</comment></comment><comment><USER37> A newbie question.

As a seasoned C#, Python and JS programmer, what conceptual foundations in CS will make me use rust more effectively?

Say I want to create a new database service, on top of Postgresql, using rust. Would the design of rust help me in a specific way?

I want to learn and use rust, for systems programming, the kind where I build a high performance underlying system, called by other languages, but it always feels I need to learn quite a bit of theory to _effectively_ use rust.

I never felt the same with C# or python. A bit of OO stuff was usually enough to be productive with them.

</comment><comment><USER38> Where's a good place to start with Rust? Which domains is it particularly good in ?

</comment><comment><USER39> Also the same reason why ppl love c++: Stockholm syndrom.

<comment><USER16> 86.1% of people using Rust love it. For C++ it's 43.4%. [1] You'd have to explain the disparity in the two numbers if you think they're loved for the same reason.

Further, Rust is mostly used by people who choose to do so. There are very few people out there forced into maintaining shitty, legacy codebases in Rust because there aren't very many such code bases ... yet.

[1] - [https://insights.stackoverflow.com/survey/2020#technology- mo...](https://insights.stackoverflow.com/survey/2020#technology-most-loved- dreaded-and-wanted-languages-loved)

<comment><USER40> "It occurs when hostages or abuse victims bond with their captors or abusers." [1] The stories speak of abuse and an unwillingness to leave. This does not detail how they came to be abused or captives. I'm not saying they were asking for it, dressed that way, but maybe these Rust victims' behavior led them to entrapment. That doesn't mean it's not real. This seems a lot like Stockholm syndrome.

[1} [https://www.healthline.com/health/mental-health/stockholm- sy...](https://www.healthline.com/health/mental-health/stockholm- syndrome#definition)

</comment></comment></comment><comment><USER41> I don't believe that rust solves the right problems in the right ways. This is specifically with respect to the single-owner raii/lifetime system; the rest of the language is imo pretty nice (aside from the error messages, which are an implementation problem).

For starters, ATS[1] and f-star[2] both provide much stronger safety guarantees, so if you want the strongest possible guarantees that your low- level code is correct, you can't stop at rust.

      _____________________________________________

Beyond that, it's helpful to look at the bigger picture of what characteristics a program needs to have, and what characteristics a language can have to help facilitate that. I propose that there are broadly three program characteristics that are affected by a language's ownership/lifetime system: throughput, resource use, and ease of use/correctness. That is: how long does the code take to run, how much memory does it use, and how likely is it to do the right thing / how much work does it take to massage your code to be accepted by the compiler. This last is admittedly rather nebulous. It depends quite a lot on an individual's experience with a given language, as well as overall experience and attention to detail. Even leaving aside specific language experience, different individuals may rank different languages differently, simply due to different approaches and thinking styles. So I hope you will forgive my speaking a little bit generally and loosely about the topic of ease-of-use/correctness.

The primary resource that programs need to manage is memory[3]. We have several strategies for managing memory:

(Note: implicit/explicit below refers to whether something something is an explicit part of the type system, not an explicit part of user code.)

\- implicitly managed global heap, as with malloc/free in c

\- implicit stack-based raii with automatically freed memory, as in c++, or c with alloca (note: though this is not usually a general-purpose solution, it can be[4]. But more interestingly, it can be composed with other strategies.)

\- explicitly managed single-owner abstraction over the global heap and possible the stack, as in rust

\- explicit automatic reference counting as an abstraction over the global heap and possibly the stack, as in swift

\- implicit memory pools/regions

\- explicit automatic tracing garbage collector as an abstraction over the global heap, possibly the stack, possibly memory regions (as in a nursery gc), possible a compactor (as in a compacting gc). (Java)

\- custom allocators, which may have arbitrarily complicated designs, be arbitrarily composed, arbitrarily explicit, etc. Not possible to enumerate them all here.

I mentioned before there are three attributes relevant to a memory management scheme. But there is a separate axis along which we have to consider each one: worst case vs average case. A tracing GC will usually have higher throughput than an automatic reference counter, but the automatic reference counter will usually have very consistent performance. On the other hand, an automatic reference counter is usually implemented on top of something like malloc. Garbage collectors generally need a bigger heap than malloc, but malloc has a pathological fragmentation problem which a compacting garbage collector is able to avoid.

This comment is getting very long already, and comparing all of the above systems would be out of scope. But I'll make a few specific observations and field further arguments as they come:

\- Because of the fragmentation problem mentioned above, memory pools and special-purpose allocators will always outperform a malloc-based system both in resource usage and throughput (memory management is constant-time + better cache coherency)

\- Additionally, implicitly managed memory pools are usually easier to use than an implicitly managed global heap, because you don't have to think about the lifetime of each individual object.

\- Implicit malloc/free in c should generally perform similarly to an explicit single-owner system like rust's, because most of the allocation time is spent in malloc, and they have little (or no) runtime performance hit on top of that. The implicit system may have a slight edge because it has more flexible data structures; then again, the explicit single-owner system may have a slight edge because it has more opportunity to allocate locally defined objects directly on the stack if their ownership is not given away. But these are marginal gains either way.

\- Naïve reference counting will involve a significant performance hit compared to any of the above systems. _However_ , there is a heavy caveat. Consider what happens if you take your single-owner verified code, remove all the lifetime annotations, and give it to a reference-counting compiler. Assuming it has access to all your source code (which is a reasonable assumption; the single-owner compiler has that), then if it performs even _basic_ optimizations—this isn't a sufficiently smart compiler[5]-type case—it will elide all the reference counting overhead. Granted, most reference- counted code isn't written like this, but it means that reference counting isn't a performance dead end, and it's not difficult to squeeze your rc code to remove some of the rc overhead if you have to.

\- It's possible to have shared mutable references, but forbid sharing them across threads.

\- The flexibility gains from having shared mutable references are not trivial, and can significantly improve ease of use.

\- Correctness improvements from strictly defined lifetimes are a myth. Lifetimes aren't an inherent part of any algorithm, they're an artifact of the fact that computers have limited memory and need to reuse it.

To summarize:

\- When maximum performance is needed, pools or special-purpose allocators will always beat single-owner systems.

\- For all other cases, the performance cap on reference counting is identical with single-owner systems, while the flexibility cap is much higher.

      _____________________________________________

1\. [http://www.ats-lang.org/](http://www.ats-lang.org/)

2\. [https://fstar-lang.org/](https://fstar-lang.org/)

3\. File handles and mutex locks also come up, but those require different strategies. Happy to talk about those too, but tl;dr file handles should be avoided where possible and refcounted where not; mutexes should also be avoided where possible, and be scoped where not.

4\. [https://degaz.io/blog/632020/post.html](https://degaz.io/blog/632020/post.html)

5\. [https://wiki.c2.com/?SufficientlySmartCompiler](https://wiki.c2.com/?SufficientlySmartCompiler)

<comment><USER42> > then if it performs even basic optimizations—this isn't a sufficiently smart > compiler[5]-type case—it will elide all the reference counting overhead. > Granted, most reference-counted code isn't written like this, but it means > that reference counting isn't a performance dead end, and it's not difficult > to squeeze your rc code to remove some of the rc overhead if you have to.

This is only the case if the compiler can effectively inline all functions. When compiling a function on its own, the compiler has no idea if the function incrementing a reference count is the first to do so or not. In rust the type signatures of the called functions are all that is needed to verify the type and lifetime correctness of a given function implementation.

> Correctness improvements from strictly defined lifetimes are a myth. > Lifetimes aren't an inherent part of any algorithm, they're an artifact of > the fact that computers have limited memory and need to reuse it.

Rust's lifetime analysis and 'mutability xor shared' semantics are also useful for correctness, both in threading (as you mention), but also in the case of unexpected mutation in the same thread: iterator invalidation is probably the most obvious case of this (and it's not just because 'computers have finite memory', it's intrinsic to how a lot of datastructures work).

What's more, Rust's lifetime and ownership system works neatly with pools and other special-purpose allocators, and implementing such patterns in a safe manner is frequently done in rust (in some cases Rust lets you get away with patterns which would be so wildly unsafe in C++ as to be impractical). If Rust didn't care for allowing such control over memory allocation it probably would not have much of the features it does have.

<comment><USER41> > > rc elision is super trivial

> no it's not

Fair enough.

It's still not a very difficult problem, though. You don't have to inline all functions (which you don't want to do anyway); you can infer lifetime attributes for each function.

RC has another benefit: it's easier to make a naïve compiler; it'll just produce slow code. Whereas a naïve single-owner compiler implementation (e.g. mrustc) will allow bad code.

</comment></comment></comment><comment><USER43> Never before has a programming language received so much marketing. It's very odd.

<comment><USER2> I take it you weren't programming when Java was the new hotness?

<comment><USER44> or Ruby, or Haskell, or elixir... Rust so happens to appeal the front-end crowd as much as the backend people and they are leveraging those windows of opportunity much better than any other language or community. Wasm bindgen is a bliss of fresh air, it even works very well with TypeScript.</comment></comment></comment>


Reddit/HN clone in Clojure - <AUTHOR> http://bestinclass.dk/index.clj/2011/01/building-a-social-media-site.html

<comment><USER2> I know this is a toy example, but really, people should not be storing passwords in plaintext in a database. jBCrypt has a simple API, and can be used from Clojure.

<http://www.mindrot.org/projects/jBCrypt/>

Also, the password authentication finishes early if it detects a mismatch between the given password and the one in the database. This makes it fairly easy for an attacker to get people's passwords with a straightforward timing attack. To fix it, always go through all the characters in the strings to compare them.

Fantastic article otherwise, though.

<comment><USER3> _"Also, the password authentication finishes early if it detects a mismatch between the given password and the one in the database. This makes it fairly easy for an attacker to get people's passwords with a straightforward timing attack. To fix it, always go through all the characters in the strings to compare them."_

The password check is a database query that, since there are no indices on the users table, will check for string equality in every row of the table. Timing the response tells you a lot about the number of users, and the instantaneous server load, not so much about how closely the latest guess matches someone's password.

Even with a more optimized program, I'd be surprised if _"fairly easy"_ were an accurate characterization of the effort to separate timing of comparing one extra character of a password from all the other stuff going on during a request: database access, routing, parsing query parameters, load from other requests, garbage collection pauses, network latency... The signal-to-noise ratio is just too low.

<comment><USER4> > Even with a more optimized program, I'd be surprised if "fairly easy" were > an accurate characterization of the effort to separate timing of comparing > one extra character of a password from all the other stuff going on during a > request: database access, routing, parsing query parameters, load from other > requests, garbage collection pauses, network latency... The signal-to-noise > ratio is just too low.

Timing attacks are possible over networks, even when the timing differences are minuscule. [1]

[1] [http://www.usenix.org/events/sec03/tech/brumley/brumley_html...](http://www.usenix.org/events/sec03/tech/brumley/brumley_html/)

<comment><USER3> That's an interesting article. While I feel less certain of my original position, I am still skeptical about a timing attack based on the time required to compare two password strings for equality.

Note that while the article deals with similar sources of noise, it also deals with a larger signal. They are trying to time a decryption process, which has a high computational complexity by design. We are talking about timing the difference between checking for equality of the first few characters of a string, versus checking for equality between all characters of strings that are unlikely to be more than 20 characters long.

Chrome tells me that it took 109 milliseconds to load a 50-line stylesheet on my personal website.

<http://ericlavigne.net/>

A quick and dirty experiment showed that the following comparison of short strings takes between 3.5 and 5.9 milliseconds for 10,000 runs.

(def partial-password "abra")

(def guess1 "abrab")

(time (dotimes [i 10000] (= partial-password guess1)))

Whereas a similar comparison of longer strings takes between 5.8 milliseconds and 6.0 milliseconds.

(def password "abrakadabra")

(def guess2 "abrakadabl")

(time (dotimes [i 10000] (= partial-password guess1)))

So the operation we are trying to time shows a lot of variability even if you can isolate it by running that code directly in a terminal, and a typical small HTTP response takes up about a million times more runtime.

Yes, these are very crude estimates. Good profiling is much harder than this. Still, if I knew this was the only security hole in my application, I'd be feeling very safe.

</comment></comment></comment></comment><comment><USER5> The way enliven works is really neat and interesting.

One thing that jumped out at me though. The author talked about how he changed the login/logout text from being plan HTML in his template, to being what looks like a tokenized representation, a pre parsed format, f or performance reasons.

If this is something people are tempted to do whenever they use large sequences of static text in enliven templates, then it seems like there's maybe room for an improvement in enliven here. Since it's lisp, couldn't enliven somehow detect that this is the first time a template is used, and scan through the code looking for opportunities to make these kinds of speed optimizations automatically before first use?

Still, really impressed with the whole setup.

<comment> cgrand-net Enlive already performs some caching on static parts of the template (and will do more as soon as I get enough time in a row to work on it). Lau's way of handling login/logout is rather unusual and goes against the grain of Enlive: he puts html in program code! A way to do that in enlive is to put both login form and logout text in the html template and then to make Enlive remove the one which doesn't apply.

<comment><USER5> Aha! Thanks for letting me know! Fwiw, Enlive looks brilliant, seriously.

</comment></comment></comment><comment><USER6> I did a rough translation of the templating part to slice (<http://github.com/scottjad/slice>)

<http://pastie.org/1444730>

Normally of course I'd split it out in to many smaller functions/slices.

<comment><USER7> I think the whole slice thing is great too. I didn't have time to look at slice or enlive but I will evaluate both of them for my next project.

</comment></comment><comment><USER8> Someone should deploy this.

<comment><USER9> And write a post about how the did the deployment (incl. server setup)

<comment><USER2> Here's an article I think you'll like:

[http://jeroenvloothuis.blogspot.com/2010/07/deploying- clojur...](http://jeroenvloothuis.blogspot.com/2010/07/deploying-clojure-web- application.html)

It walks you through taking a Clojure web app that uses the Ring middleware -- similar to WSGI in Python, or Rack in Ruby -- and deploying it as a WAR file that runs under Tomcat, behind Apache. Since the OP uses Ring, this should work.

It's also possible to run the app from a REPL on your server, with a Swank connection to emacs for remote hot-patching and debugging, with something like nginx in front of the built-in Jetty HTTP server, but that's not really something I'd feel good about.

<comment><USER10> The lein-ring plugin provides a slightly easier way of generating war files from Ring handlers:

<https://github.com/weavejester/lein-ring>

<comment><USER2> Nice! That looks like the Right Thing.

</comment></comment></comment></comment></comment><comment><USER11> Damnit, stop making it look easy.

I've been relearning <s>programming</s> Java and trying out the Play! framework, and a slashdot/HN clone is to be my first project of substance. I want a few more features, sure, but man... way to make me feel slow.

/Honestly, learning the ins and outs of a web framework of Rails caliber is very time-consuming.

<comment><USER3> The difficulty of programming depends a lot on your tools. I haven't used Play!, but I've had more experience with Java, Java frameworks, and Java libraries than is healthy. They tend to make programming a lot harder than it should be.</comment></comment>


The Xerox Alto Struts Its Stuff on Its 40th Birthday - <AUTHOR> https://www.spectrum.ieee.org/view-from-the-valley/tech-history/silicon-revolution/the-xerox-alto-struts-its-stuff-on-its-40th-birthday <comment><USER4> These things are great. There was a little kid playing on one at the Living Computer Museum in Seattle, where they've got a couple networked together - <USER2> had no trouble operating it.

That place is worth a visit if you have a chance - they've got working machines going back to the 50s that you can play around with.

<comment><USER5> Seconded, that place is incredible and anyone with a tangential interest in computers should do themselves a favor and check it out.

<comment><USER6> Not to get too far off track, but I'm heading there tomorrow and the Alto is at the top of the list of computers to check out followed by the PDP-10. As someone who came into the industry way after these devices were in use, I'm pretty excited to check them out.

<comment><USER7> The PDP-10, sadly, isn't on display at the moment (or wasn't as of the night of the talk).

<comment><USER7> There is, however, a rarer PDP-1

</comment></comment></comment></comment></comment><comment><USER8> There is lots of Alto restoration info (and videos) here: [http://www.righto.com/](http://www.righto.com/) [https://www.youtube.com/user/mverdiell/videos](https://www.youtube.com/user/mverdiell/videos)

<comment><USER9> Indeed, this sounds like the Alto that Ken Shirriff (author of the right.com posts), Marc Verdiell, Carl Claunch and Luca Severini have been working on, though no explicit mention in the article.

> _These demos used an Alto that had been restored to working order over the > past eight months._

<comment><USER10> Correction: "righto.com"

</comment></comment></comment><comment><USER11> The greatest engineering creates a blank canvas. Modern devices are all about possibility, what does technology allow you to do? And on a deeper level, what does technology allow you to become?

</comment><comment><USER12> I've always been fascinated by the Alto, and the people who designed and built it, and how many of them went on to help make the Macintosh successful. And by how much work it took to make the Mac actually work.

The Alto had to be one of the greatest design prototypes ever made. It wasn't ever made for sale, AFAIK, even though supposedly hundreds got shared with universities. But they built over a thousand and actually used them on an actual network. Every part of the system was continually developed in real world use.

Even so, the performance, cost, and other rough edged impediments were too far away to commercialize it. The Star and the Lisa were failures.

The Mac team had to hand code high performance graphic algorithms to get a GUI running in 128k, and a cheap one button mouse so they could make an affordable GUI computer for the masses. They had to come up with the Finder, the Desktop and Trashcan so that users never had to be exposed to a CLI. Even Bill Atkinsons invention of regions might have been key to making the Mac UI expressive enough to succeed with the general population.

[https://web.stanford.edu/dept/SUL/sites/mac/parc.html](https://web.stanford.edu/dept/SUL/sites/mac/parc.html)

</comment><comment><USER13> This was a fantastic event and it was truly an honor to be there!

If you haven't visited the Computer History Museum in Mountain View, I highly recommend it.

</comment><comment><USER14> Video of the live demos from the event: [https://news.ycombinator.com/item?id=15710264](https://news.ycombinator.com/item?id=15710264)

</comment><comment><USER15> Except that the Alto came out in 1973. [https://en.wikipedia.org/wiki/Xerox_Alto](https://en.wikipedia.org/wiki/Xerox_Alto)

<comment><USER16> True, but FTA:

> Most of this vision of the "office of the future" was first unveiled at a > meeting of Xerox executives held on 10 Nov 1977, which was 40 years ago last > week.

</comment></comment><comment><USER17> > The Xerox Alto, widely recognized as the first modern personal computer

It it wasn't available for personal use, this is a delusional claim. Maybe the first _prototype_ of a personal computer. But that's all it was - <USER3> (impressive) technical prototype.

<comment><USER18> Good heavens, I'm a bit astounded by this dismissal. I think it's fair to say that you can simply consider yourself not covered by "widely recognized" rather than drop supercilious nit-picks here and we'd all be better for it.

[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)</comment></comment>


The $300 Million Button - <AUTHOR> http://www.uie.com/articles/three_hund_million_button/ <comment><USER2> The original reasoning that went into the design of the first form is (I think) the classic perspective taken from someone that has never had to use their own product.

"Why wouldn't someone want to create an account? Ship it!"

Then as soon as you are in a rush, shopping for some tents online for a camping trip (something you rarely do) and REI is forcing you to create an account just to order the clearance tents you found, you want to yell at somebody.

I think this story is valuable if for no other reason to make sites realize how much of a road block registration is.

<comment><USER3> Agreed. Another roadblock I hate is requiring me to enter my full name and address before they give tax & shipping info. A simple zip code field & calculate price button should not be that hard.

Does anybody publish some decent design guidelines for online shopping sites? So many sites try to follow Amazon without realizing Amazon can get away with terrible design choices because they are so massive.

<comment><USER4> And speaking of "a simple zip code field"...

If you're going to require a zip code to ship, because you only ship to the US, wouldn't it be nice if you said so up-front, so I could avoid wasting half an hour comparing your totally effing useless-to-me products to retailers that actually want to sell to me?

</comment></comment></comment><comment><USER5> I actually LOVE LOVE website that let you shop as a guest. No, I do not want to sign up.

<comment><USER6> Brilliant. I'm amazed that more sites don't let you do this.

</comment></comment><comment><USER7> Why don't ecommerce sites just create an account for users on the fly? Why do they require the extra step?

<comment><USER8> That doesn't help the customers who come back later for a second purchase and then have to fumble to find their account info.

<comment><USER9> it would help, because users who don't want to be bothered can just create a new account on the fly.

you're already collecting all the information necessary to create an account when somebody completes a purcase, so just make an account for them. include a temporary account password on the email receipt, with a message telling users they can use that pw to log in to the site to check the status of the order. once a week, run a cron to clean up all the accounts of people whose orders have completed and haven't changed the password.

<comment><USER8> That's better, but I still don't like it because you're forcing a relationship upon the user, regardless of whether or not they want one.

</comment></comment></comment></comment><comment><USER10> Any idea what site this article refers to?

<comment><USER11> It's Amazon.com.

<comment><USER12> Apparently not:

<http://news.ycombinator.com/item?id=434850>

<comment><USER13> Well then Best Buy has lapsed. Canadian site requires you to register in order to check out.

</comment></comment></comment></comment><comment><USER14> I know from a couple months ago hearing the founder of omniture Josh James talk about changing a button and color to a homepage. He said it caused his client to grow significantly and caused sales to go up 15-20% almost overnight creating tens if not hundreds of millions of dollars in revenue.

The website they helped fix was still in its beginning years. Their client was ebay. I wouldn't be suprised if this was the website he's talking about.

</comment><comment><USER15> I love this article because it nicely allows C-level execs to understand the ROI of usability and design. So often at larger companies, these areas lack budgets purely for the fact that it is so hard to quantify the returns i.e. with just general "positive" user experience. Here we can see a pure a before/after A/B type situation that had far-reaching consequences.

<comment><USER16> "But my organization is different because..."

</comment></comment><comment><USER17> I have seen lots of companies add that button, and I have never seen a company remove it!</comment>


Is TheSixtyOne a YC Startup? - <AUTHOR>

I'm just wondering if TheSixtyOne.com is a product of YCombinator?  I recently discovered it (and work for a media startup myself), and I find it fascinating. <comment><USER2> This is one of my favorite sites. As someone who makes websites for a living, I'm very impressed by what they've put together. One of the better music sites that I've used (and I've seen a lot of them)

</comment><comment><USER3> I believe it is Sam Hsiung's project (YC alum - YouOS) with probably with James Miao? I wanted to donate so they could get a Mac and build an iPhone app but I'm in the hole a few grand myself. I love the 61, it has one of the best incentives/reputation systems I know - points with levels and each level gives you different abilities, like bumping up songs more.

<http://www.thesixtyone.com/stammy/collection/>

</comment><comment><USER4> Despite going there and poking around briefly, I have absolutely no idea what this site does. I guess in that respect it is like iilwy, except with iilwy you can poke around for a day and still have no clue.

</comment><comment><USER5> Wow, it is indeed pretty cool. It's like a combination of YC companies iJigg and iilwy.

<http://www.thesixtyone.com/#/static/about/>

Founded by at least one YC alum

<comment><AUTHOR> strangely enough.. i find myself addicted to this site

</comment></comment><comment><USER6> it would be nice if there was a recent playlist so that i can re-play again the songs i played.

it should be automatically added in the temporary playlist if it was played it for more than 1/2 of the time of the song.

update: i see they playlist is the results of the current page. So i suppose the order of the playlist could be re-ordered in the way i play it.

maybe the best solution is to add two buttons more for previous/next within my playlist and not the results of the current page.

<comment><USER7> If you have an account, you can access your recently played history by going to your profile and then hitting the music tab. We're also working on an easier way to access your play history from the mini-player at the bottom left.

</comment></comment><comment><USER8> What a cool concept, but what a frustrating site!

I think I'm addicted in spite of the navigation/functional issues, but definitely I'm looking forward to improvements.

<comment><USER9> what's bothering you? if you would be so kind: james at thesixtyone dot com

<comment><AUTHOR> for some reason, i'm not able to load the site in firefox anymore. shortly after i posted this, it throws back "failed to connect" errors.

i tried in a CGI proxy, works fine, so i know it's not my internet connection. i cleared my cache too. i'm using latest version of ff and ie.

adding the "www" prefix doesn't help either (i know some DNS setups are picky about that)</comment></comment></comment>


Discrimination has its new name: Diversity - <AUTHOR> https://medium.com/@troyhua/discrimination-has-its-new-name-diversity-63c85ecc20e4 <comment><USER2> "I could write more, but I need to find diversity candidates on my LinkedIn as a task per company's diversity hiring goal. It is not easy as LinkedIn search does not have filters such as gender or race, which I believe it will be illegal to be implemented."</comment>


Google Glass Snoopers Can Steal Your Passcode With a Glance - <AUTHOR> http://www.wired.com/2014/06/google-glass-snoopers-can-steal-your-passcode-with-a-glance/ <comment><USER2> The comments in the Wired article are pretty ridiculous and it seems as if the article title is pretty sensational. The article also mentions that a Samsung smartwatch is just as accurate and an iPhone 5 camera caught the PIN every time. According to the article, a person with a $700 Panasonic camcorder can steal your PIN from 4 stories up and across the street. You don't, however, see any of the commenters in the article calling people with camcorders pedophiles and asking for them to beaten up. The hysteria is ridiculous.

I think the solution given by the article researchers that randomizes the locations of the numbers on the PIN entry is a much more effective solution than wantonly destroying people's property or assaulting them because of a perceived, imaginary threat.

<comment><USER3> Unfortunately, randomizing the button locations would be an accessibility nightmare.

<comment><USER4> Security and accessibility are pretty much inherently opposed.

<comment><USER5> That brings to mind this tweet by Eleanor Saitta on a specific instance where they actually are directly opposed.

[https://twitter.com/Dymaxion/status/464457530677420034](https://twitter.com/Dymaxion/status/464457530677420034)

(It's a case where _physical_ security and _physical_ accessibility come in pretty direct conflict!)

</comment></comment></comment></comment><comment><USER6> It seems like any video enabled device can steal your passcode if it sees you enter it. The phone they used did even better in glass from 10 feet away.

I hope this makes a push for more/better biometric locks on every day devices.

<comment><USER7> >>It seems like any video enabled device can steal your passcode if it sees you enter it. The phone they used did even better in glass from 10 feet away.

The difference is that when you record someone with a non-wearable device, it's pretty obvious. In the phone example, you have to hold it up a certain way, which will immediately alert the target (as well as anyone in the vicinity) if they are paying attention.

With Glass though, who knows if you are recording or not? AFAIK there isn't a red "recording" light that comes on, right? So as far as people are concerned, you might just be casually glancing in their direction, except you aren't.

<comment><USER8> From the article, they were able to capture the PIN code from across the street and two stories up using a camcorder. You're not even going _see_ that person.

</comment></comment></comment><comment><USER9> Funny I've always worried about the mobile keypads because on top of that they "echo" the character you typed. I'm paranoid and often try to shield the screen when I type in my password. That said there are so many cameras everywhere it's hard not to think that somewhere they got a good clean shot and could figure out my password.

I don't use the same password on any two things so it's less useful to get my mobile lock password then it might be for some but if you have a lock screen pin or password you do get an amazing amount of stuff for free on a person's mobile device...

</comment><comment><USER10> I'm not sure what I expected from comments on Wired, but that is pretty amazing that all the most highly-upvoted comments are calling Glass users "glassholes", pedophiles, and encouraging violence against them and/or their Glass devices.

<comment><USER11> hopefully they are consistent and have the same comments about anyone having their phone out of their pocket

<comment><USER11> Can someone explain why "phones" should not be considered a treat to privacy if you think Google Glass is?

<comment><USER12> You can see what people are doing with phones.

<comment><USER13> Really? More than with a device that has a LED on when it is recording?

If you can see what is done with an smartphone how is there are such a number of subreptitious videos and pictures taken with smartphones

<comment><USER12> Google Glass does not have an LED on it when it is recording.

And yes, it is possible to make a surreptitious recording with any camera, but there is no comparison.

With other cameras including cellphones, it takes a tricky and intentional effort, with the risk of social consequences if discovered.

Glass is designed to make it ubiquitous and effortless to record people, with no indication to those being surveilled.

</comment></comment></comment></comment></comment></comment><comment><USER14> > "I think of this as a kind of alert about Google Glass, smartwatches, all > these devices,"

Why is it that its always a fault with the _new_ tech? I'm not a glass esplorer but still I take offense to this kind of idiocy. The problem is with passcodes/passwords in general, they have always been susceptible to this kind of attack, adding in a video recorder doesn't change this.

</comment><comment><USER15> We'll have to adjust to a world where everyone has perfect visual memory and superhuman time perception.

<comment><USER5> This brings to mind the plot of Isaac Asimov's story "Lest We Remember".

[https://en.wikipedia.org/wiki/Lest_We_Remember](https://en.wikipedia.org/wiki/Lest_We_Remember)

That title was also the inspiration for the title of a paper I worked on:

[https://citp.princeton.edu/research/memory/](https://citp.princeton.edu/research/memory/)

</comment></comment><comment><USER16> Another anti-Google propoganda with highly offensive comments (pedophile, glasshole etc.) with high upvotes and not a single downvote.

You can do the exact same thing by hiding a camera in anywhere your body, and they won't even be spotted like Google Glass. There are cameras as tiny as: [http://youtu.be/CgtTg62GDfs?t=2m19s](http://youtu.be/CgtTg62GDfs?t=2m19s) and I'm sure many intelligency agencies around the world have better cameras than this on their agents, and some one might be actually using them. Additionally, almost all the stores has security cameras, which are on top of you and potentially can do the same thing, and you won't even notice.

<comment><USER12> Which giant corporation is trying to popularize the daily use of these other cameras?

<comment><USER17> You mean a big startup creating new projects in many different directions, automated cars, wifi balloons, space elevator, open source os for mobile devices, and smart spectacles?

<comment><USER12> Do space elevators make it ok to invade people's privacy?

</comment></comment></comment></comment><comment><USER18> I think it's a little odd that screens on _personal_ devices are going in the direction of super-high viewing angles and brightness, as if letting everyone else besides you see what you're doing is a good thing... even the unbranded low-end Android I have has a screen with nearly 180 degrees of viewing angle.

However, this with a randomised button layout solve the problem quite well:

[http://solutions.3m.com/wps/portal/3M/en_US/SDP_NaturalView/...](http://solutions.3m.com/wps/portal/3M/en_US/SDP_NaturalView/screenprotector/cell- screen-protector/mobile-privacy-film/)

</comment><comment><USER17> It is weird to not see a single comment calling for the long due death of passwords as authentication.

They have so many drawbacks, they are annoying each and every employee that works with a computer on earth, we have weekly massive password leakage posts on HN (only tip of the iceberg), and apart from fingerprints there is no contender?

Guys, startup creators, hackers, engineers: wake up! Find something, anything!

In 30 years, when passwords will be past, our future selves will be amazed to read stories about passwords: how could we bear this skyscraping level of stupidity and annoyance.

</comment><comment><USER19> You know what else can steal your passcode with a glance? My eyeballs.

<comment><USER7> Yeah, but there is something to be said about Glass making it possible (and trivial) to record the sensitive information. Not only that, you can also be recording the person, and can later look up their face, potentially figure out their identity, and then proceed with identity theft.

You can't do that with just your eyeballs.

<comment><USER20> > Yeah, but there is something to be said about Glass making it possible (and > trivial) to record the sensitive information.

Google glass didn't make that possible, the invention of the video camera did. Plenty of those around -- often in compact form -- with or without Glass.

<comment><USER21> But you'd look pretty damn conspicuous holding up a camera while someone was entering passwords or accessing sensitive info.

<comment><USER20> > But you'd look pretty damn conspicuous holding up a camera while someone was > entering passwords or accessing sensitive info.

Not at the distance from which a decent camera (as discussed in the article) can capture it, you wouldn't -- what Glass can do from 3 meters away, the camera they tested in the article could -- with greater reliability -- through a window 44 meters away (four stories up and across a street).

<comment><USER21> Unless something gets between you and the target 44 metres away and blocks your view. Then your master plan is foiled.

</comment></comment></comment></comment></comment></comment><comment><USER22> Seems like an easy solution: randomize the PIN keypad layout with every key press.

<comment><USER23> If you wanted to take it a step further, the touch screen could have a very narrow viewing angle, have the angle of the screen automatically or manually rotate to the users eye level, and then someone standing next to you would just see a blank screen. With random keys on top of that, someone would literally have to poke their head over your shoulder to see.</comment></comment>


Why Orwell Endures - <AUTHOR> http://www.nytimes.com/2010/02/14/books/review/Wheatcroft-t.html?ref=review <comment><USER2> A very interesting article on the impact of Orwell's writings. I had occasion to reread 1984 last year, the first time I had read the book since before the year in its title, and it is still striking how vivid its imagined future era --fortunately not realized in the year of the title--is. I have more than tripled my years on earth since the first time I read through 1984, but it continues to have an unmatched ability to disturb with real-life observations of human capacity for evil, while retaining just an ever-so-slight glimmer of hope in the appendix on Newspeak, carefully written in the past tense and including a quotation from the Declaration of Independence. Not a literary novel, but a great novel nonetheless. And Animal Farm and many of Orwell's essays are also must-reads.

</comment><comment><USER3> Because he succinctly and clearly captured the dangers of the modern age in a voice the modern ear can recognize and understand.

</comment><comment><USER4> "In certain kinds of writing, particularly in art criticism and literary criticism, it is normal to come across long passages which are almost completely lacking in meaning." - George Orwell (<http://www.mtholyoke.edu/acad/intrel/orwell46.htm>) :)

<comment><USER5> Well, it's an easy argument to use against people you don't like. The article's point is true though. As a novelist he really wasn't that outstanding, his prose is repetitive---it's not as if 1984 wouldn't have benefited from another editing round.

<comment><USER6> More than that, his characters and societies in 1984 are so one-dimensional as to be completely unrealistic, and therefore frankly pretty boring. In the real world (even in the worst totalitarian dictatorship, or in e.g. prison torture camps) motivations and relationships are always complex and usually confusing. 1984 is much more of a fairytale than "great literature"; the latter requires sympathetic human characters. (For instance, compare with Shakespeare's heroes and villains.) I think one of the reasons that _1984_ and _Animal Farm_ have been so enduring is that their simplicity allows people to ignore Orwell's actual intentions or message.

 _Down and Out in Paris and London_ and _Homage to Catalonia_ are much more rewarding reading than _1984_ or _Animal Farm_.

</comment></comment></comment><comment><USER7> Christopher Hitchens gave a fascinating interview on the topic of Orwell for the Econtalk podcast:

[http://www.econtalk.org/archives/2009/08/hitchens_on_orw.htm...](http://www.econtalk.org/archives/2009/08/hitchens_on_orw.html)

<comment><USER8> Hitchens has also written a nice book on Orwell - [http://www.amazon.com/Why- Orwell-Matters-Christopher-Hitchen...](http://www.amazon.com/Why-Orwell- Matters-Christopher-Hitchens/dp/0465030505)

</comment></comment><comment><USER9> The first time I read "1984" was during the "smoking gun" talks that congress was having about Iraq. I was amazed that in a classroom of thirty people I was the only one that was drawing the parallels between the novel and the then current political climate. That's when I realized that very few people have meta-cognitive abilities and are able to learn from past mistakes whereas others are doomed to constantly repeat the same mistakes over and over again. Orwell was in tune and aware of political thought like no other and it is a shame there aren't more like him during modern times.

<comment><USER10> What was more disturbing was the realization that there were folks around that did, and that were willing to seek and create and use those parallels.</comment></comment>


SourceClear Raises $1.5M Seed Round For Its Software Security Platform  - <AUTHOR> http://techcrunch.com/2014/06/11/sourceclear-raises-1-5m-seed-round-for-its-software-security-platform/ <comment><USER2> Does this just look for library versions with known vulnerabilities, or does it do source code analysis?</comment>


Dutch-Russian cyber crime case reveals how the police tap the internet - <AUTHOR> http://electrospaces.blogspot.com/2017/06/dutch-russian-cyber-crime-case-reveals.html <comment><USER2> "during a meeting with FBI and FSB, a Russian official came to a member of the Dutch police team, pointed at someone from the FBI and said "he is copying your data". An investigator went looking and saw that indeed the American had a thumb drive in a police laptop and was copying Dutch information"

Funny, but slightly depressing too. I wonder how it's like for security professionals working internationally when you always have to consider that your international partners are likely looking to stab you in the back. Would probably be too frustrating for me.

</comment><comment><USER3> I don't understand why the ICQ traffic would go through the servers. Were they running ICQ on the servers for some strange reason?

<comment><USER4> Perhaps ICQ comms servers or proxies are located at Leaseweb? The AMS-IX is I think the largest connection between Europe and the US, it makes sense as a central location for a messaging service, or as pass through for messages between Russia and the U.S. (not sure what the lines are like the other way around the world).

<comment><USER5> > AMS-IX is the largest connection between Europe and the US

An IX (Internet eXchange) is not a connection, but is more like a giant switch, where internet access providers send local traffic, so they don't have to send it through their bandwidth providers, to cut bandwidth costs.

The AMS-IX is more or less the largest internet exchange in the world.

</comment></comment></comment><comment><USER6> Private Interne Acceess¹ uses Leaseweb quite a bit. I wonder if people using their services got intercepted, too.

[1] [https://www.privateinternetaccess.com](https://www.privateinternetaccess.com)

<comment><USER7> [https://www.privateinternetaccess.com/forum/discussion/24134...](https://www.privateinternetaccess.com/forum/discussion/24134/private- internet-access-is-temporarily-discontinuing-its-german-exit-gateway)</comment></comment>


Free software for freedom, surveillance and you [video] - <AUTHOR> http://media.libreplanet.org/u/zakkai/m/free-software-for-freedom-surveillance-and-you/

<comment><USER2> I also liked the fact that this is hosted using Mediagoblin.

<comment><AUTHOR> It's free software all the way down.

<comment><USER3> It's actually very difficult to completely use free software, cf. Richard Stallman's setup:

[http://richard.stallman.usesthis.com/](http://richard.stallman.usesthis.com/)

You run into problems with binary blobs such as bios and firmware/drivers for hardware.

<comment><USER4> Living based on ethical rules is always a daunting task if one want to do it "completely".

People who are vegetarians by ethical choice can easy find themselves eating meat. Be it from candy, to supplements to medicine. Then there is bioplastics, which while should be eaten, qualify as something a vegetarian might found unethical to use.

It is good that someone sacrifice so much to try living by their believes. It would be so much worse if ethics did not exist at all.

</comment></comment></comment></comment><comment><USER5> I'm very excited for bunnie's open laptop.

[http://www.bunniestudios.com/blog/?p=3597](http://www.bunniestudios.com/blog/?p=3597)

<comment> TD-Linux This is absolutely amazing. Especially the high speed FPGA. I'm currently working with the Xilinx Zynq which is the same idea but with an FPGA on the same chip and it's amazing for a lot of things. In particular, stuff you'd do with only an FPGA is made so much easier with a Linux SoC on board to handle Ethernet, USB, and the like.

</comment></comment><comment><USER6> Helpful utilities and documentation for Free Software live audio/video streaming

[https://github.com/ioerror/freenote/](https://github.com/ioerror/freenote/)

<comment><AUTHOR> Wow, that's awesome! I wasn't expecting it to be just a single shell script. A very complicated one, but still simpler than I was expecting.

</comment></comment><comment><USER7> I agree with what Jacob says about Jitsi. It's great, but just isn't user- friendly enough.

I assume that all my convos and cam chats on Skype are recorded [1] - so i try to push my contacts to jitsi. But every time it's so hard to walk people through setting it up correctly.

[1] [http://www.theguardian.com/world/2014/feb/27/gchq-nsa- webcam...](http://www.theguardian.com/world/2014/feb/27/gchq-nsa-webcam- images-internet-yahoo)

</comment><comment><USER8> I have to say this was my favorite talk this year at LibrePlanet, it was interesting to see Jacob's appropriate paranoia. His understanding of the security situation is amazing, and his advice is poignant.

From his suggestion I'll be honest his statements has certainly influenced my plans, and make me really consider writing more software in the security space.

</comment><comment><USER9> Does anyone know what the following software is:

 _Just use "triscull/triskill."_ @00:31:49

He mentions it a couple of times, I finally decided to look it up after the reference at 31:49.

<comment><USER10> That would be Trisquel[0], a GNU/Linux distro based on Ubuntu that is completely free (no proprietary software or binary blobs whatsoever).

[0] [https://trisquel.info/](https://trisquel.info/)

<comment><USER9> Wow, I was not close with the spelling. It looks like Debian/main except it comes with a libre-linux kernel?

</comment></comment></comment><comment><USER11> Great talk, thank you for posting!</comment>


Bill and Melinda Gates: Let's Keep Investing in the World's Poor - <AUTHOR> https://www.wsj.com/articles/bill-and-melinda-gates-lets-keep-investing-in-the-worlds-poor-1505300401?mg=prod/accounts-wsj <comment><AUTHOR> Bypass paywall link: [http://facebook.com/l.php?u=https://www.wsj.com/articles/bil...](http://facebook.com/l.php?u=https://www.wsj.com/articles/bill- and-melinda-gates-lets-keep-investing-in-the-worlds-poor-1505300401)</comment>


Sniffing off the air NRF24L01+ and Bluetooth LE packets for under $30 - <AUTHOR> http://blog.cyberexplorer.me/2014/01/sniffing-and-decoding-nrf24l01-and.html

<comment><USER2> This is a nice hack.

BUT: This has been done years ago for under $1 (the price of a nRF24L01 board) by using a nRF24L01 itself.

[http://travisgoodspeed.blogspot.de/2011/02/promiscuity-is- nr...](http://travisgoodspeed.blogspot.de/2011/02/promiscuity-is- nrf24l01s-duty.html)

<comment><USER3> But not for Bluetooth LE, I think?

<comment><USER2> I am not sure, that is a good question. People have shown that it is possible to hack a nRF24L01 into sending BLE transmissions. But there are limits. It could be possible to sniff parts of BLE traffic.

</comment></comment></comment><comment><USER4> That's pretty cool. I always looked at the rtl-sdr stuff but lost interest when I looked at the max frequency being less then my signals of interest. The MMDS apparently changes that though, didn't know about those before.</comment>


Show HN: Advanced Mathematics Library for Node.js and JavaScript - <AUTHOR> https://github.com/sjkaliski/numbers.js <comment><USER2> First of all, good work!

A couple of observations:

1\. You should probably go ahead and implement at least LU decomposition, QR factorization, and maybe some eigenvalue/eigenvector stuff if you want to claim "advanced".

2\. You should use the recursive definition of the determinant in the >3x3 matrix case.

3\. You should consider adding some vector methods of the form: ax+by (for scalar a & b, and vector x & y). This can be useful for doing linear interpolation and whatnot.

4\. You should add cross products/outer products for vectors.

5\. You should have a mechanism for generating a Gaussian or normal distribution, or at least supply some standard mappings from your (presumably uniform) random function to something more useful (Gaussian, Possoin, Weibull, whatever).

6\. An FFT would be nice. :)

7\. Quaternions would also be handy for graphics folks, or motion folks.

8\. Complex number support would be cool.

9\. Support for optimization, like integer programming, linear programming, or even least-squares or whatever would be nice.

~

Again, great work--I look forward to seeing how this project evolves!

<comment><AUTHOR> This is a fantastic list. There are a few people who've expressed interest in working on eigenvalue work. I'll definitely be adding a couple of these in, in the next few days. I'll keep you posted.

<comment><USER3> Sparse and dense matrix math and eigensolvers would be really nice. Especially solvers that let you efficiently get the eigenvectors associated with the smallest eigenvalues as this comes up in graph and image partitioning.

</comment></comment></comment><comment><USER4> This is pretty cool. I've been using CoffeeScript to post-process MD simulation results because it's such an easy language to get things done in. Tools like this will make it even easier.

Although, could someone clarify for me the floating point issues mentioned by Steve? I wasn't aware there were issues...

<comment><USER5> [https://en.wikipedia.org/wiki/Floating_point#Accuracy_proble...](https://en.wikipedia.org/wiki/Floating_point#Accuracy_problems)

It is the same as trying to store 1/3 = 0.333... as a finite decimal. Basically, a floating point number only has a finite space to put the component after the decimal point, so it gets truncated and made inaccurate, just like truncating 1/3 to 0.3333 will mean that calculations become wrong: 3*0.3333 = 0.9999 ≠ 1.

<comment><USER4> Ah, ok. Thank you. This isn't a problem for me then. It appears to be just typical floating-point math. I was thinking perhaps JavaScript did something else weird that I didn't know about.

</comment></comment></comment><comment><USER6> Any interest in adding various statistical regression functions? I had to write some for JavaScript recently, one of which can be found at [http://stackoverflow.com/questions/13590922/how-can-i- use-d3...](http://stackoverflow.com/questions/13590922/how-can-i-use-d3-js-to- create-a-trend-exponential-regression-line)

Seems to work for me, but I haven't had it reviewed by a real mathematician yet.

<comment><AUTHOR> Most certainly. Would love to push the statistics further. Working on integrating some econometrics tools in the next version.

</comment></comment><comment><USER7> What audience do you have in mind calling this advanced? (Not criticising your library, it looks useful).

<comment><USER8> Just out of curiosity, what features would you want to add to make it more advanced? I'll make tickets for them.

<comment><USER6> For statistics I'd be interested in seeing quantiles, regressions, and coefficient of determination.

I intend to contribute what I can in those areas.

<comment><AUTHOR> That'd be great

</comment></comment></comment></comment><comment><USER9> I've used <http://www.numericjs.com/> to handle basic vector/matrix arithmetic and for numerically solving minimization problems to create constraint-based UIs.

Can you give an overview of how your library is different? Is it just a different set of math tools or is the architecture somehow different? Thanks!

<comment><USER10> Constraint-based UIs are not something I'm familiar with, but sound interesting. Can you expand on that for me please?

<comment><USER9> <http://recursivedrawing.com/>

When you drag and drop the shapes, the drawing changes in non-trivial ways. For example, try dragging a shape deep down in the recursion hierarchy.

In a normal drag-and-drop application, it's fairly easy to compute how to, say, adjust the left/top of a div in response to the mouse movement events. However, with Recursive Drawing, I knew that there were certain properties I'd have to adjust during a drag operation, but because of all the nested transformations, it was tricky to figure out the math of how exactly to adjust them.

So instead, I set up a constraint problem. I know that the exact spot I've mousedown'ed on needs to stay under my mouse no matter what. That's the fundamental constraint of the drag-and-drop gesture. Then I set the properties that I knew I could change (e.g. positions or scaling/rotation of a specific shape) and set them as free variables in an energy minimization function. I solved the problem numerically using numeric.js's uncmin (unconstrained minimization, an algorithm originally written in FORTRAN, I believe).

I probably could have figured out how to do this without numerical methods, but this approach was a god-send when rapid prototyping the interactions.

Another good use of constraint systems for UIs is Ivan Sutherland's Sketchpad. His paper on it is long but really worth at least skimming through if you're interested in developing next-generation UIs! <http://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-574.pdf>

I also really like Rebecca Fiebrink's Wekinator, which is a framework for making musical instruments from arbitrary inputs. The approach is similar in that she uses numerical methods to solve for the constraints (the training data). <http://wekinator.cs.princeton.edu/>

I think there's a lot of potential in constraint-based UIs and for me it's the most compelling reason to have good numerical libraries in javascript.

</comment></comment></comment><comment><USER11> This is _awesome_! I started thinking about doing something similar a few months ago, but the project I needed it for kind of fell through and I moved on. Anyway, a few thoughts I had at the time:

      -should support FFT/convolution
      -could tie into http://sylvester.jcoglan.com/ for
       vector/matrix stuff (excellent library!)
        -I emailed jcoglan about the possibility of adding
         complex number support to Sylvester, he encouraged me
         to try but thought it might introduce too much function
         call overhead (caching function results might help a
         bit?)
      -I didn't get to look at it too closely, but
       https://github.com/jtobey/javascript-bignum looks
       interesting, as does https://github.com/pr1001/MathPlus
      -polynomial fit (least squares regression) and
       interpolation stuff is in high demand
      -it should be super easy to integrate output with d3.js
       (like the equivalent of MATLAB plot function)

Honestly, I doubt I would have been able to pull it off, but I intend to contribute to this project as much as I can.

EDIT: Formatting

<comment><AUTHOR> Great, it'd be sweet to have you involved! FFT, polynomial fit, and d3.js would be huge steps. For me, the most important thing is ensuring that all changes are application driven. Building a library that's designed to be used is top priority.

</comment></comment><comment><USER12> Great. I'm studying for my operations research exam, and I've wanted to "study" by implementing some of the algorithms we did by hand through code.

Is there interest in some more advanced matrix algebra functions - specifically Gaussian reduction, simplex, sensitivity analysis, and maybe some transport/network problems and integer programming?

<comment><AUTHOR> My primary focus from here on out is statistics and matrix algebra focused on powering analytics. So yes, some of those functions would be of interest to me.

<comment><USER12> Ok. I'll start on some of it tonight.

<comment><AUTHOR> great! ping me at email@example.com if need be

<comment><USER12> Will do. I forked on Github from philipithomas. I'm email@example.com.

</comment></comment></comment></comment></comment><comment><USER13> Along the same line, (heh line) my friend made a linear algebra library last year.

I present to you "Clique: A Javascript Linear Algebra Library with Applications to Spectral Analysis"

<https://github.com/Forns/clique>

</comment><comment><USER14> What's the use-case-scenario for this? Seems like if you had complex calculations you needed to perform, you would do it on a server side language like Python.

<comment><USER15> 1\. JavaScript is a server side language too.

2\. Canvas and WebGL pave the way for lots of cool graphical JS applications. Linear algebra and calculus are particularly useful for graphics.

<comment><AUTHOR> Yeah, I really tried to keep elements of the browser in mind. Games and graphics definitely can benefit from algebra and calculus.

</comment></comment></comment><comment><USER16> Wow - looks awesome! Congrats Steve et all.

<comment><USER17> w00t! Go Steve

</comment></comment><comment><USER18> Nice!</comment>


Google's One-Time 'Chief Technology Advocate' on Making Facebook Likable - <AUTHOR> https://www.theatlantic.com/notes/2018/04/googles-one-time-chief-technology-advocate-on-making-facebook-likable/557378/?single_page=true <comment><AUTHOR> AKA the difference between Google and Facebook disclosure of private information (none vs a lot).</comment>


Ask HN: Best Website for Solution Architects - <AUTHOR> Any suggestions for website where you can learn or follow the latest trend in term of software, system and solution architecture?<p>Or also any certification worth to have in this space. <comment><USER2> Infoq is pretty good</comment>


Ask HN: How can I add a query string to a URL for a Google Sheet? - <AUTHOR> I'm implementing an inventory system using Sheets and QR codes.
THE GOAL: The QR code needs to direct to the Sheet cell of the item SKU.
THE PROBLEM: Since the spreadsheet is constantly being updated, any given cell is dynamic.
TL;DR: I need the QR code to essentially  be a QR of the sheet's url AND a control-F the SKU (let's say 'Dumbell-1'). I know this has to be possible. Any ideas on how to do it? <comment><USER2> You could have all your skus on one sheet (sheet1) of the Google sheet and have a second sheet (sheet2) where cell A1 is the URL of the qr code, and cell B1 is the query string which searches through sheet1 and returns the sku details for whatever is referenced in cell A1.</comment>


Lava Lamp Centrifuge - <AUTHOR> http://neil.fraser.name/hardware/centrifuge/

<comment><USER2> _Extremely_ cool:

" _The centrifuge is a genuinely terrifying device. The lights dim when it is switched on. A strong wind is produced as the centrifuge induces a cyclone in the room. The smell of boiling insulation emanates from the overloaded 25 amp cables. If not perfectly adjusted and lubricated, it will shred the teeth off solid brass gears in under a second. Runs were conducted from the relative safety of the next room while peeking through a crack in the door._ "

Read the rest to learn if a lava lamp will work on Jupiter or during a space shuttle launch (2.3 or 3 Gs).

<comment><USER3> My team's washing machine prototype achieves 200+ Gs in the spin cycle.

There are some problems in this video that have since been corrected, but check it out: <http://www.youtube.com/watch?v=mK2vpqXk8Jc>

<comment><USER4> haha, that's awesome. Is there a goal to this project aside from epic-spin- dry? I'd love to see where it's headed.

<comment><USER3> It loads through the side of the drum, rather than the end—this addresses two major mechanical sore-spots in traditional front-load washers (which are otherwise vastly superior to top loaders).

It's not an entirely new concept (cf. <http://www.staber.com/>), but our approach to the door and very ingenious and novel.

</comment></comment></comment></comment><comment><USER5> If you plan to make one, make the radius smaller, but the velocity higher.

The energy stored in this goes by the radius squared. But the centripetal force on the object at the end goes by the radius.

So a smaller faster one is less dangerous, and also requires a less powerful motor (or the motor you have can give you a higher force).

Although the bearings are probably a bit harder to handle when it's faster, the whole thing will weigh less.

On the con side, a smaller one will have a larger difference in force between the top and bottom of the lava lamp, making your experiment less accurate.

<comment><USER4> Energy may go by radius squared, but the rpms change to match.

For visualization: the ice-skater who spins slowly & pulls arms in. By spinning faster, no energy is _lost_ , as can be seen by extending the arms. However, a slower-rotating device can more easily be predicted and avoided / hand-stopped if needed.

<comment><USER6> The energy is the same. A slower moving larger centrifuge can tear your arm off with the same ease a smaller, faster one.

<comment><USER4> Totally agree. But a smaller, faster one is less predictable, so you can't bleed of small amounts of energy as easily / safely.

Which would you rather try to stop, with your bare hands, assuming identical energy? A 1-inch pipe spinning at 10,000 RPM, or a large tire spinning at 10?

<comment><USER5> If the energy is identical, why would there be any difference?

Remember that with the larger slower RPM one, the radius is higher so the linear velocity is high too, even if the RPMs are slow.

<comment><USER4> One is more predictable than the other. In that video, I can point out when the arm will come around again with relative ease, and can very easily be accurate to below a tenth of a second.

Now picture it going several times faster in terms of RPM, and tell me when it'd be safe to stick your arm in its path.

Lets scale it up. Picture the earth. Near the equator, the linear velocity is almost 1000mph. Scale it down to the size of the centrifuge in the video, while keeping linear velocity the same. I can easily point out when half of the earth is facing the sun. Could you point out when the centrifuge is pointing north?

<comment><USER5> If you are planning to play chicken with a centrifuge, sure.

But I am more concerned with what happens if you do actually get hit. Or if it comes apart, or falls down.

And if you do get hit, or it breaks, a smaller faster one is MUCH (exponentially much) safer.

The force goes up by the RPM squared, but it goes down only linearly by radius. You don't need to speed it up very much to counteract the smaller size.

On the other hand the energy goes up by radius squared. Meaning the smaller size helps a LOT in terms of destructive power.

<comment><USER4> I've been too long out of physics, so I'll take your word on it. I wasn't sure how quickly size effected energy. Though I'll still take my chances with something I can predict if I have to interact with it.

One question though: is energy->radius^2 based on angular or linear velocity?

<comment><USER5> Angular.

So yes, when you increase the radius the linear velocity goes up even though the angular one doesn't change.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> No wonder landlords ask for a security deposit.

</comment><comment><USER4> I _love_ that the "data recorders" are a cell phone and a camera.

This is awesome. _Everybody_ should do something this awesome in their lifetime.

edit: Yikes, anyone got a torrent / mirror for those videos? They're crawling at sub-30kbps for me.

<comment><USER4> Well, if anyone's interested, these links should work in a bit over an hour (or two... fluctuating speed), provided it all downloaded correctly (I'm headed to sleep). Don't try before then, they won't be complete, I'm just downloading to my Dropbox.

<http://dl.dropbox.com/u/363028/temporary/3g-side.3gp> (16mb)

<http://dl.dropbox.com/u/363028/temporary/3g-floor.avi> (159mb)

<http://dl.dropbox.com/u/363028/temporary/3g-payload.avi> (43mb)

Please mirror / set up a torrent if you can, I'd prefer to not nail my Dropbox too hard. (payload is interesting, you can see the twisting caused by the spinning)

<comment><USER8> Dropbox will shut you off without warning. I had a 25mb training video up there for a 15-person startup and my public folder was turned off astonishingly quickly.

<comment><USER4> Good to know. And makes sense, as they truly aren't providing a CDN.

</comment></comment></comment></comment><comment><USER8> Upon clicking the AVI video links in Safari I discovered that the QuickTime logo is strangely reminiscent of a centrifuge. [http://skitch.com/dasil003/n292m/http-neil.fraser.name- hardw...](http://skitch.com/dasil003/n292m/http-neil.fraser.name-hardware- centrifuge-3g-payload.avi)

</comment><comment><USER9> I wouldn't be concerned so much with glass shrapnel, as with almost molten wax spraying out.

Have you ever opened up a lava lamp? The bottle is capped with an old- fashioned pull-off bottle cap. I guarantee that if anything goes pearshaped, it'll be the integrity of that cap.

</comment><comment><USER10> I want to see the videos of the failure mode testing :-)

</comment><comment><USER11> could an engineer/physicist be kind enough to calculate how hard that lamp would have hit the nice wall, door or window had things gone a little awry?

<comment><USER5> He says it has a diameter of 3 meters, and spins at 42 RPM. (And I hope he didn't confuse diameter and radius.)

So the circumference is 9.5 meters, times 42 per minute = 395.6 meters per minute = 14.76 mph or 23.75 km/h [http://www.wolframalpha.com/input/?i=3+meters+*+Pi+*+42%2Fmi...](http://www.wolframalpha.com/input/?i=3+meters+*+Pi+*+42%2Fminute)

</comment></comment><comment><USER12> The music is cool and the "study" room setup is endearing. But, in plain English, what's the result of the experiment ?!

<comment><USER13> "As one can see in the video above, the lava lamp continues to operate well at three times the force of gravity."

<comment><USER4> As well as "IT LIIIIIIIVES!!!!" when you get it spinning for the first time, and scaring / awesome-ing the neighbor kids.

What the heck is that thing made of, anyway? An erector set? Juice bottles? Over-powered wires and motors? That beast is _worthy_ of a Frankenstein moment.

<comment><USER5> It's made of <http://en.wikipedia.org/wiki/Meccano>

<comment><USER4> So, pretty much yeah, an erector set, though possibly a bit stronger. It's not old-school erector, though. Looks like Meccano has been making Erector sets since about 1990.

</comment></comment></comment></comment></comment><comment><USER14> Well, that's one less thing to worry about.</comment>