A half-hour to learn Rust - <AUTHOR> https://fasterthanli.me/blog/2020/a-half-hour-to-learn-rust/ <comment><USER2> This is the most useful introduction to a language I have ever read. Often language introductions produce a "Wall of Complexity" and I failed in my last two attempts learning Rust failed because of that. This is just great.

Be warned, the "half hour" part is probably a bit like "99 cents" as a price tag. I've already spent more than that, but it is time well spent.

Thanks for writing this!

<comment><USER3> You might like this: [https://learnxinyminutes.com](https://learnxinyminutes.com)

<comment><USER4> I also like Derek Banas videos ([https://www.youtube.com/channel/UCwRXb5dUK4cvsHbx- rGzSgw](https://www.youtube.com/channel/UCwRXb5dUK4cvsHbx-rGzSgw)) for this same quality. He doesn't do many "deep dives" into the languages, but he does a fantastic job getting your feet wet with very common tasks... much like these learnxinyminutes pages do.

</comment></comment></comment><comment><USER5> Underscore is not exactly "throw away" but rather it is exactly "don't bind to variable". The difference becomes evident with the statement:

        let _ = x;

This is a no-op and the value remains owned by the variable x, and is not thrown away.

<comment><USER6> I debated which terminology to use and thought "throwing away" was more intuitive, especially if you've never heard of "binding" before.

It has its limits though - in your example I'd say you're throwing away the result of evaluating "x", just as if you did:

        x;

<comment><USER5> I don't agree, because we can try the two following programs, and one of them does not compile. It compiles with underscore.

1:

        let x = String::new();
        let _ = x;
        println!("{}", x);

2:

        let x = String::new();
        x;
        println!("{}", x);   // ERROR: Use of moved value x.

And this is why I said that let _ = x; is a no-op. :)

<comment><USER6> Huh, TIL! Had no idea `x;` actually moved `x`.

<comment><USER7> But where is it moved _to_? Who owns it now? Or is it just lost?

<comment><USER5> yes, it is dropped

<comment><USER8> Ahh, I remember a while back reading a blog where the author talked about `std::mem::drop` being their favorite standard library function because they used this effect. It is literately defined as:

        pub fn drop<T>(_x: T) { }

[https://doc.rust-lang.org/std/mem/fn.drop.html](https://doc.rust- lang.org/std/mem/fn.drop.html)

<comment><USER9> So is drop like free, or is it something else?

<comment><USER10> Yes, it's effectively like free -- though C++'s "auto" is probably a closer idea.

The main difference to C's free is that you simply cannot double-free a value (without using unsafe). That's because a value is only dropped when it falls out of scope -- and since it values only have one owner (and references must not outlive values) there cannot be any dangling references after it's dropped.

The documentation for std::mem::drop is explaining that dropping a value is a property of the language and scoping rules -- thus there is nothing for the function to do other than take a value and let it go out of scope.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> Nothing related to the tutorial itself, but I've seen many Rust basic tutorials recently, and this sorta remind me of Haskell - especially its Monad.

The Haskell community once was flooded with Monad tutorials[1]. People kept trying to put meanings on this mathematical construct, and had come up with tons of different ways to describe it. The problem is, this simple thing can fit into so many different places, so people couldn't possibly run out of new ideas. This oversaturation only confused newcomers even more, so the community concluded not to write any more Monad tutorials.

While individual tutorials enrich the community in general, it's more crucial to have a few good documentation that kill the need for more tutorials (e.g. MDN + W3School), so that efforts can be redirected into more productive things. Rustonomicon is one good documentation, but it always falls few steps short in practice. That's probably why more tutorials are being written, and why they get upvoted well in both HN and Reddit.

[1]: [https://wiki.haskell.org/Monad_tutorials_timeline](https://wiki.haskell.org/Monad_tutorials_timeline)

<comment><USER12> The dust is settled and the fight is over. Which monad tutorial won "best monad tutorial?"

<comment><USER13> None of them. The concept is fundamentally flawed. It's as if everything you ever read about C was all about bitwise manipulation operations, on and on and on about bitwise manipulation, to the point not-C programmers think the language is primarily about bitwise manipulation and people start porting bizarre misunderstandings of bitwise manipulation into other languages and claiming they're just like C now, when it's just a part of the language that you'll pick up over time. Not a perfect metaphor but close enough.

<comment><USER14> However, the c community never felt like going on and on and on about bitwise manipulation... Anyone have any idea why people get so hung up about explaining monads?

<comment><USER15> I've seen that some programming communities focus on writing software, while others focus on talking about software.

C and Haskell are two good examples of this dynamic, although C is used in so many different projects that "community" only loosely applies.

<comment><USER14> Interesting, maybe the Sapir Whorf hypothesis is much more relevant for programming languages than for natural languages; maybe the language shapes the things a human can comfortably express, and this shapes the communities

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

</comment></comment></comment></comment></comment></comment><comment><USER16> The way I like to think about the expression / statement divide in Rust is that _everything_ is an expression, and the semicolon is an operator akin to `ignore` in F#; it takes any operands, disposes of them, and returns the unit type `()`.

Rust in general is just such a pleasant language. It can be a bit tedious to work with sometimes, but that's usually because the problem in question is tedious in and of itself, and you didn't even notice all of the little screw- ups that could occur until you saw how Rust dealt with it.

</comment><comment><USER17> Reminds me of Learn X in Y Minutes: [https://learnxinyminutes.com/docs/rust/](https://learnxinyminutes.com/docs/rust/)

</comment><comment><USER18> Has anyone struggled with the lack of HashMap literal?

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

I just cant bring myself to doing something like this:

        let m1: HashMap<&str, i32> = [("Sun", 10), ("Mon", 11)].
        iter().
        cloned().
        collect();

[https://doc.rust- lang.org/std/collections/struct.HashMap.htm...](https://doc.rust- lang.org/std/collections/struct.HashMap.html)

<comment><USER19> Would a macro work ok for you, like the inbuilt vec! one? There's a crate for that named maplit: [https://docs.rs/maplit](https://docs.rs/maplit)

        let map = hashmap!{
            "a" => 1,
            "b" => 2,
        };

<comment><USER20> one of the fun things about Rust, is any time you think "man I wish there was some syntax to do this thing in Rust" you can make a macro to make it reality, usually one already exists.

</comment></comment></comment><comment><USER21> Only, it's more one hour and a half rather than half an hour. Excellent quality stuff nonetheless

<comment><USER22> It's only an half an hour if you are familiar with these concepts (generics, traits, pattern matching, error propagation, etc...). Some concepts are exclusive to Rust (lifetimes/ownership), so I doubt you can get it in 30 minutes if you have never written code in Rust before.

<comment><USER23> I've seen this guy's posts a few times lately, he needs to learn to edit things down. What he's saying is good, but it is extremely digressive, and the digressions never seem to return to the original point. I'm not the audience for this so I don't have that much time to spare reading it, but I can't imagine that style working well for an introduction to a language.

<comment><USER6> I respectfully disagree but - can't make everybody happy.

There's plenty of introductory articles to Rust in the style you desire :)

edit:

To expand a little bit, the digressions aren't just about me "getting distracted" while writing - they're very much on purpose. I always try and write pieces that expand in many different directions, because there's so much to discover, always.

Some folks come to an article wondering why Rust has two string types and end up spending an hour on Wikipedia reading about legacy code pages - and I think that's great.

My way of getting people interested in something is never a top-down, present- the-bare-minimum way, it's always about showing how what we're discussing is connected to a lot of other things, which are also fascinating and that you should check out if you want!

<comment><USER23> I think I'm talking more about your Mr Golang piece, but now that I have your ear, I guess may as well. I am less concerned with the existence of digressions than the way they're introduced. When I say needs editing, I mean that because I cannot navigate the piece properly, it takes longer to understand what you're getting at if I want to, so it seems like it's too long. Editing down is only one solution to that.

An example of this is when I was really confused reading about path extensions and non-UTF8 paths. I was promised by Cool Bear that you had a point to make using an example about a stat call, but you were no longer talking about stat, and yet you were still writing as if it was central to your stat discussion. So instead of expanding, I thought you just couldn't express what was wrong with the stat call. I nearly gave up waiting! And I was surprised that, in the end, you could (and put it quite well). Unfortunately, there are thousands of thinkpieces out there that never make the point they promise to, instead just dumping information at you and hoping it hits you like it hit them. So I am trained to close the tab when that is happening.

It might help to state why you're going to digress before you do, with a promise to return, so that people who are hooked can be confident you'll eventually make your point (and may skip back and forth to digest your argument again without interruption). If nothing else, you are making a promise to yourself to structure things in a way that is friendly to the reader.

Rather than making the piece less exploratory, adding signposting helps get the reader into the mindset you describe in the last sentence there. Otherwise, they are not sure whether to be interpreting what you're saying as a core argument or some side discussion. It hurts both the exploratory and the argumentative qualities of the writing if one is confused for the other. Without making it clear, the argument runs like my first para above: unnecessarily long-winded and questionably relevant, with no exploratory levity. With good signposting, you get to nail both. It's about two sentences' and two headings' difference, maybe a little shuffling around.

Hope that helps, looking forward to your next one.

<comment><USER6> The Golang piece is definitely subpar, it was quickly thrown together in half a day, didn't expect it to be spread so widely haha.

For other articles there's usually a few days of research, and 1.5 days of writing and editing, then a lot of touch-ups in the following weeks/months responding to feedback.

Thanks for the more detailed criticism though - I agree with the general sentiment, and haven't solved the navigation problem yet!

</comment></comment></comment></comment></comment></comment><comment><USER24> This is very good but... Description of traits suddenly dumps references, mutable references, reference bindings, dereferencing with zero explanation:

\--- start quote ---

Trait methods can also take self by reference or mutable reference:

      impl std::clone::Clone for Number {
        fn clone(&self) -> Self {
            Self { ..*self }
        }
      }

\--- end quote ---

What? What does this even mean? What is <asterisk>self, and _why_?

Too many questions, not nearly enough answers.

<comment><USER25> If you have a struct of type T and an instance of that struct t, you can create a new instance using the syntax

      T { ..t }

which means "a new T with all the fields set to their values in t".

Inside the trait "Self" is an alias for "Number".

"&self" is shorthand for "self: &Number", i.e., a reference to Number.

To dereference a reference, prefix with

      *

So:

      self

has type "&Number"

and

      *self

has type "Number".

Thus,

      Self { ..*self }

is creating a new instance of Number with its each set to the same value as self.

 _Disclaimer!_ everything I know about rust I learned 2 days ago from this blog post, so I might be wrong :-)

</comment></comment><comment><USER26> What a nice approach to presenting the language in a clear cut way. We should have this for every language out there.

<comment><USER27> ive been perusing a bit of rust code for the past 2 years, reading an article here and there....always heard it was a complex and low level , next generation C language. comparing it to go etc... but never wanted to learn it... This article is _so_ simple in its delivery. It really got excited in the 'beauty' presented by each simple chunk.

</comment></comment><comment><USER28> This is great write up. I wish every language had this on their official page. I'd personally love one for C++.

</comment><comment><USER29> This is so good. I would love this kind of "learning" for every language. It's definitely not beginner friendly but for anyone that already knows a language this is a super introduction and quick start, maybe even tipping point to start using the language.

Only remark: If I had anchor tags at specific points creating a reference would be easy, this is referenceable material.

Great job though, I am amazed at the quality of this. Hell yeah!

</comment><comment><USER30> I am really happy I found this blog post. If you like this one you should check out some of his other posts. He has some amazingly insightful other posts on Rust including some very in depth topics. Also, a great comparison of Rust and Go. This is also why I love Hacker News. I would have never found these posts if this one had not made it to page one.

<comment><USER31> I want off Mr. Golang's Wild Ride [1] is a great read. The part about how different OS file permissions are handled in Go vs Rust is great. Even though I don't know Rust, I thought the Rust approach looked easiest since it's accurately represents the underlying systems. It was really surprising to see that Go's motivation in glossing over the complexity is to keep things simple. Is a half working implementation really simpler?

1\. [https://fasterthanli.me/blog/2020/i-want-off-mr-golangs- wild...](https://fasterthanli.me/blog/2020/i-want-off-mr-golangs-wild-ride/)

</comment></comment><comment><USER32> Every young language must have tutorials like this.

Start with the utter basics but move quickly through the common issues.

More than anything, these kinds of tutorials make it possible to at least start grasping the rest of the documentation.

I find with so many funky languages, the little examples aren't so hard, but there's too much 'unknown' syntax in the way to make sense of it.

These are essential.

</comment><comment><USER33> I want books written like this. I've had too many books where I die of boredom over and over again in the first 150 pages and then I never read them again. It's like there's some rule saying books must be super wordy.

<comment><USER34> That rule is usually called the publication contract, and it usually literally says how big the work needs to be, even if you can say it better in fewer words/pages/chapters/etc.

<comment><USER35> TIL. This seems to be waste of paper/time for consumers. What is the incentive for publishers by preferring wordy version than terse one? Is it because they afraid of being perceived as not worthy enough to be a book?

<comment><USER25> Holdover from another era. Pre-internet, we had more time to spend w/ books, and it was harder to gain context to make things make sense -- a little hand- holding and digression was more appropriate then.

</comment></comment></comment></comment><comment><USER36> I really enjoyed this, and it also inspired me to try a quick experiment: what would the same blog post look like for Go?

I tried it and wrote [https://dmitri.shuralyov.com/blog/27](https://dmitri.shuralyov.com/blog/27). It was a fun exercise to go through.

<comment><USER37> Thanks for sharing. I enjoyed this. Could you elaborate on your closure example though? This was the only one I didn't understand. The explanation is a bit terse = "Closures are just variables with a function type with some captured context." Are these anonymous functions? What is calling the anonymous function if so in main? Cheers.

<comment><USER36> Thanks for feedback. I'll try to clarify that section.

</comment></comment></comment><comment><USER22> Numbers could also be differentiated in Rust. For example, to make sure your "16" is an _i32_ you could write

> let x: i32 = 16i32;

Otherwise, it's a very comprehensive article. The only missing parts are the _async /await_ keywords and the sync primitives (like Mutexes/RwLocks).

<comment><USER38> C# has a similar feature, but it's less verbose, e.g. "16l"/"16L" is a long (64-bit integer), "16u" is an unsigned, 32-bit integer etc.

I find the rust syntax a little difficult to read. Take "16i32" for example - it's not immediately clear which part is the actual value.

<comment><USER6> One neat thing Rust let you do is put underscores in number literals. It's great for readibility:

        0xFFFF_FFFF // easier to count than 8 Fs

And you can use that with type suffixes:

        let a = 255_u8;

Although in that case, you'd probably either omit u8 entirely, letting the compiler infer the type of 'a' from usage, or use a colon to give it ane explicit type.

Type suffixes are especially useful for arguments to generic functions:

        write_le(12_u32);
        write_le(255_u8);

<comment><USER38> You can do the same thing with C#, which is great for groupings, e.g. "2000000" becomes "2_000_000".

As a rust noob, I didn't realise rust supported the same syntax, or that you could use it to separate the type from the value (which in rust's case, I find really helps readability).

</comment></comment></comment></comment><comment><USER39> Nice. What is dont understand is why is the second Vec2 used in this example? It introduces x and y, which are of type float right, not Vec2?

let v = Vec2 { x: 3.0, y: 6.0 }; let Vec2 { x, y } = v; // `x` is now 3.0, `y` is now `6.0`

<comment><USER40> Because you're ---unpacking--- destructuring a Vec2.

The most common form of this idiom I've seen is:

        if let Some(x) = foo() {
            println!("{:?}", x);
        }

where fn foo() -> Option<_>, i.e. foo returns either Some(_) or None. (if let is used to account for the possibility of None; it's technically different syntax to let, but very similar.)

Here, x isn't a Some (a variant of Option). It is, however, representing a value inside a Some, which we want to get out. Likewise with your example; we want to destructure from a Vec2, so we specify a Vec2 (with identifiers instead of data) on the left hand side and the data on the right hand side, and it takes the data out and binds it to the identifiers.

</comment></comment><comment><USER25> This is fantastic! Using it, I was finally able to write my favorite toy- problem in Rust (scoring a boggle board). Rust solution came out 25% faster than my (I thought) highly-optimized C++ solution, wow...

</comment><comment><USER41> I've been writing Rust for about 2 years, I read this and learned all kinds of stuff I still did not know. Fantastic job on this! I am now a bit upset that everything isn't taught this well :o

</comment><comment><USER42> I wish all languages had this kind of page as a requirement of the language manual. Author, I will hold your beer...

</comment><comment><USER43> What does `type Output = Self;` for the `std::ops::Neg` trait mean? It wasn't explained on the page.

<comment><USER44> IIRC that's called "associated type" and is mostly used for shortening the function declaration inside the trait through using e.g. "Self::Output".

E.g. the definition of the real std::ops::Neg trait: [https://doc.rust- lang.org/std/ops/trait.Neg.html](https://doc.rust- lang.org/std/ops/trait.Neg.html)

<comment><USER45> It's not about shortening things, it's actually about semantics! Choosing to make something have a type parameter vs an associated type depends on what you're trying to accomplish.

</comment></comment></comment><comment><USER46> I found this extremely helpful. I've always been interested in Rust but never got around to it cause most of the source code I've read on GitHub was overwhelming. This is a nice walkthrough to get someone like me interested. Great work!

</comment><comment><USER47> Loved the approach, no time wasting and you can dig on things are not clear for you.

</comment><comment><USER48> Close to the beginning there is a phrase you'll want to review:

> _If we we really we wanted to annotate the type of pair, we would write_

Ok understood, we're us and we're all together in reading this! :-)

</comment><comment><USER49> For a clickbaity title, it's surprisingly useful. Of course, the time to read it might take half an hour, but the time to really absorb it might take two weeks.

</comment><comment><USER50> this is the style that let me get into python reading a python book by new riders within 3 days. i replace perl based module within a week of reading.

this: teaching material should give immediate confidence to apply learned material and - refine it later.

excellent write up

</comment><comment><USER51> Does anyone know of a similar tutorial for C, C++, Python, et al?

</comment><comment><USER52> is there a poignant guide to rust ? something similar to 'learn you some erlang for great good' ?

</comment><comment><USER53> Typo: "If we we really we wanted"

</comment><comment><USER54> Next up: Learn mandarin in 0.1^99999999999999999999 seconds.

</comment><comment><USER55> Very nice! first impressions is that it is very similar to Kotlin which i love working in, seems modern languages are converging on common set of niceties

</comment><comment><USER56> Serious question; why aren't we all using Rust?

<comment><USER57> I think for a lot of use cases, the safety and security and whatnots you get from Rust just aren't required and people already have a large time investment in Python/Go/Java/etc.

Certainly I can do pretty much everything I need to with C/Python/Go because I accept the tradeoffs and know enough to work around the safety/security issues.

(But Rust is on my list of things to get around to in 2020.)

</comment></comment><comment><USER58> > let x: i32 = 42;

I'm sorry but this notation will always make me scream. C is so much simple:

int x = 42;

not "let", no colon, and no ambiguous "i32 = 42"

<comment><USER59> You mean, like when declaring an array:

        int[4] arr; // oops, doesn't compile

Or a function pointer:

        int (*)(int) fptr; // oops, doesn't compile

So much for the simplicity of C declaration syntax.

<comment><USER60> One can make the argument that the C declaration syntax _is_ simple, because the rule to make a declaration is to simply follow a type name by an expression where the declared variable is used. The fact that you write "int[4] arr" shows that you don't know how it works (which is not a criticism; it's just not well known how it works).

The correct way is to write

        int arr[4];

and to interpret it as "arr[4] is an int" (which is only a slight lie because arr[4] is undefined if arr is a 4-element array).

How do you declare an array of pointers? Again, you write

        int *arr[4];  // array of 4 pointers to ints

because in C expression syntax, "* arr[4]" means to index into the array first and then to dereference. If that is an int, it means that arr[4] is a pointer to an int, and consequently arr is an array of pointers to ints.

If you want a pointer to an array of ints instead, do this

        int (*arr)[4];  // pointer to an array of 4 ints

again, because that's how regular C expressions work. Functions are (mostly) not an exception:

        int myfunc(int x);
        int (*myptr)(int x);

which is to say that "myfunc(x) is an int" and "(* myptr)(x) is an int", i.e. myptr is a pointer to a function that takes an int and returns an int.

Note that in the beginning (i.e. K&R C, pre-1989) the way to declare functions was consistent: Declarations had to be

        int myfunc(x);

i.e. there was no types in the argument lists. The types in the argument list appeared, I believe, after Stroustroup added them to C++ in order to improve type-safety.

<comment><USER61> > the rule to make a declaration is to simply follow a type name by an > expression where the declared variable is used.

Not really. You can't just use _an_ expression, you have to use a specific expression. For example, * ppX is a perfect valid expression for a pointer to a pointer named ppX, as in:

        int **ppX;
        if (*ppX == NULL)

So you need to use an expression where the declared variable is used _that results in a non-pointer type_. And then, there's actually more to it... only certain types of expressions are valid. E.g. this isn't a valid declaration for a pointer, even though it's valid as an expression:

        int pX->;

I find that basically anytime somebody tells me that C rules are to "simply [...]", they've inevitably ignored a whole bunch of cases. Your post is no exception.

<comment><USER60> > So you need to use an expression where the declared variable is used that > results in a non-pointer type.

I think you are wrong here, you can't even make something other than what "results in a non-pointer type". Because by definition, you're making the type to the left with the expression. (That could still be a pointer type if it is a typedef'ed type; such as "typedef int * intptr; intptr x;" but I don't think you meant that by "pointer type" [0]).

And your first example is perfectly syntactically valid (other than missing the conditional statement that must follow the if-condition).

And no, "pX->" is not a valid expression. Was that a typo?

And yes, only a subset of expressions are valid. Basically, the expressions that you can form by applying subscripts, (x[3]), dereferences (* x), and function calls. Because, a declaration like "int x + 3;" or even "int x + y;" just doesn't make sense. I don't see a problem there.

Btw. I'm not saying that C as by the current standards is super straightforward and pure. It's definitely not, and C does actually have a lot of historical baggage that makes our lives a little harder. I'm just explaining the underlying unifying principle, which IMHO is actually nice. And honestly it seems you, too, are still confused because there is just a lack of clear explanations about C declarations. That principle should be much more well-known, and almost all problems that novices have with declarations are unnecessary frustration that they wouldn't have if someone would have told them the trick.

[0] By the way, typedef is another thing that seems to be super obscure, while it is extremely simple: It's just a keyword that modifies declarations to declare an alias for that type, instead of a (named) variable of that type.</comment></comment></comment></comment></comment>


Rails, still? - <AUTHOR> https://blog.phusion.nl/2018/08/30/rails-still/ <comment><USER2> "Sinatra is Ruby with Rails in mind. You will find yourself using more of Rails in your Sinatra application over time and ask yourself why you're not just using Rails."

This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly.

To riff on Greenspun's Tenth Rule, "Any sufficiently complicated $MICRO- FRAMEWORK application contains an ad hoc informally-specified bug-ridden slow implementation of half of Ruby on Rails."

<comment><USER3> > This is an important point. If you've ever developed a non-trivial > application using Sinatra, Express or any other "micro" or "non-opinionated" > framework, you'll have hit this wall quickly.

Not really. You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library. I don't see how big frameworks like Rails make all these things better, especially when they don't give you the choice as to what tool to use. If you ever developed a non trivial application, you also know that your first concern will be to avoid unnecessary bloat and complexity and only bring in libraries that are strictly required. And as we are moving from traditional html rendered server apps, big frameworks lost even more value since there is no need for a templating libraries, html form libraries,...

<comment><USER4> I actually consider Rails in its 3.x+ versions to be a pre-selected combination of smaller libraries - because it really is. Don't need mail? Remove actionmailer. Don't need a database? Remove ActiveRecord. The benefit is that when you _do_ need those tools, they are there, they work together, and you don't have to choose.

That's not always perfect or suitable for every use case, but it's not a bad thing.

<comment><USER5> Agreed; those days are when I worked on Rails, and that was a lot of the things that made 3.x different from 2.x. I wrote a blog post about it that's one of my most popular ever: [https://words.steveklabnik.com/rails-has-two- default-stacks](https://words.steveklabnik.com/rails-has-two-default-stacks)

This sentiment also was a major theme of my forward to The Rails Way.

I've been thinking about this stuff a lot in the context of Rust...

<comment><USER6> > I've been thinking about this stuff a lot in the context of Rust...

Do you mind extrapolating further, or will that be the topic of a future blog post?

<comment><USER5> For now, what I'll say is that I've seen how Node never really got a rails, and how Rust has a zillion microframeworks but no Rails either, yet. Do we need one? What would it look like? That kind of thing.

<comment><USER2> > Node never really got a rails

I'm, admittedly, out of the loop when it comes to Node, but I do remember Sails looking promising when it was first announced. I recently suggested it to someone (who uses Node regularly) as a possible solution for a project we're working on and they'd never heard of it. So, between that reaction and the fact that I haven't heard of anyone else using it (or anything similar), I think you're right that a Railsy solution never took off.

Elixir is an interesting counterpoint, though. It seems like Phoenix was released and saw broad adoption very early on.

I'm wondering if this dichotomy is a result of where people are coming to these newer languages from: people writing Elixir probably aren't coming from the FE/JS world, but there's a very good chance people writing Node are. Prior to the somewhat recent proliferation of JS client app frameworks, using a smattering of libraries was a very common approach to solving problems. (It arguably still is, albeit at a different level of abstraction in React/Babel/Webpack land.)

Anyways, I'll be looking forward to reading the post you alluded to above, should it ever come together.

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Copy from my previous reply

 _This is pretty amazing. Both GitHub and Shopify are huge, billion dollar companies running on the original apps made over a decade ago. And they now both on the latest Rails, helping to push the framework forward [1]_

 _I can 't wait for y'all to see what we upstream now that we're in a position to give back and improve Rails. My keynote; Rails 6.0: Scalable by Default [2] at RailsConf was just a small portion of our plans for Rails. [3]_

There are also work from Discourse on Rails performance, Ruby is getting a Method JIT. [4] and working on more pref work. TruffleRuby is close to 1.0 and it is available on all ruby manager [5]. The Open Source build is now also available on macOS as well.

There are lots more, and all of them were years in making, It took a year for Github to get to latest Rails release. For the past few years, many have been writing off Ruby Rails, Ruby is comparatively expensive to scale ( and it still is ) , we expect other frameworks to catch up in terms of productivity, and will spell doom to Ruby Rails. Not only has such framework yet to appear, Ruby Rails continues to improve on all front.

I say the best days of Ruby Rails has yet to come.

[1] [https://twitter.com/dhh/status/1030528476250562569](https://twitter.com/dhh/status/1030528476250562569)

[2] [https://speakerdeck.com/eileencodes/railsconf-2018-the- futur...](https://speakerdeck.com/eileencodes/railsconf-2018-the-futur..).

[3] [https://twitter.com/eileencodes/status/1030461847256875008](https://twitter.com/eileencodes/status/1030461847256875008)

[4] [https://twitter.com/k0kubun/status/960112559343878144](https://twitter.com/k0kubun/status/960112559343878144)

[5] [https://github.com/oracle/truffleruby/blob/master/doc/user/r...](https://github.com/oracle/truffleruby/blob/master/doc/user/r..).

<comment><USER8> Would you consider laravel to be that framework that allows rapid development increased speed and provides an easier way to scale.

<comment><USER9> Based on the following benchmarks, Laravel is slower than Rails. But still, both frameworks are much slower than .net/java/erlang based frameworks.

[https://www.techempower.com/benchmarks/#section=data-r16&hw=...](https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune)

<comment><USER10> FWIW those benchmarks are inconsistent. Usually it's a matter of optimizing for direct calls to C libraries.

</comment></comment></comment></comment><comment><USER11> Disclaimer: I've worked with but dislike ruby and rails in comparison to other choices (whether language or ruby framework).

IMO people are still using rails because a bunch of orgs moved to it from Java years ago, or started with it after some successful hackathon. It's in wide demand because a large number of orgs mindlessly (or mindfully) chose it long ago. Basically all enterprise/large company apps I've seen have been in either Java or Rails. Some places are still using COBOL. Some places are still maintaining/starting codebases in COBOL. I assume that people will be able to make this same argument about NodeJS in ~2-5 years.

Also, the the point about micro-frameworks being bad being made in the comments because you eventually re-implement rails seems to be wrong or badly articulated -- that's exactly the point of using a smaller-yet-composable tool, you don't use any parts until you need them. Sinatra has also leaned into this by allowing pieces of rails to be loaded, and providing a path to transitioning to Rails proper.

I dislike rails because there's too much magic, and too many ways to do things -- it's precisely why I like micro frameworks. Also, the (request, response, next) middleware/handler paradigm is the most composable way to write server software I've ever seen.

<comment><USER12> There's a little big detail w/r/t java comparison: every company I've personally worked with who uses rails for their backend vs java moves WAY WAY WAY faster. So in terms of the "enterprise stack" dichotomy, there is a difference in kind between rails/java.

I get things done faster and more maintainably (for future me and other devs) when I do it in rails. Hopping into apps that rely on (request, response, next) always hits me with a learning curve every single time I come back to em, which gets worse as complexity rises. It could also be that I'm very bad at thinking in terms of pipes and need to practice that more.

I also find that in rails, there really aren't _that_ many ways to do things. And, in general, apps that age gracefully always figure out how to phrase their domain concepts through the smallest restful url's/resource mappings they need. There's a lot to be learned from the approach the smaller micro frameworks take, and you can get the best of both worlds in a lot of ways.

<comment><USER13> And there are some companies where you need to move fast while at the same time need to have high performance (100.000 req/s with 30-50 ms mean latency). In that case Java is the only option between Rails amd Java.

<comment><USER14> The gap between Scala + Play and Ruby + Sinatra (or cut down Rails) is not like it was in 2008. Ruby 2.5 is ~13x faster than Ruby 1.8. Now you're lucky to squeeze 3x the web throughput out of a Java/Scala service as opposed to CRuby and JRuby closes that gap further.

<comment><USER13> Can you point to me any performance site where Ruby 2.5 + Rails that backs your point? If you use JRuby than you are on the JVM already. In that case why Rails at all?

<comment><USER14> In terms of pure Ruby performance, there's a semi-official non-trivial benchmark called optcarrot. Ruby 2.4 is 14.3x faster than Ruby 1.8.7 here: [https://github.com/mame/optcarrot/blob/master/doc/benchmark....](https://github.com/mame/optcarrot/blob/master/doc/benchmark.md)

Rails performance relative to JVM+Scala+Play is tricky to measure but the closest thing to a decent benchmark I know of is this: [https://www.techempower.com/benchmarks/#section=data-r16&hw=...](https://www.techempower.com/benchmarks/#section=data-r16&hw=ph&test=fortune&l=hr9r0f&f=zg21hb- zik0zj-zik0zj-zik0zj-zik0zj-zijunz-zik0zj-4zsov)

My own experience at ChartMogul with building production services in Ruby, Go and Rust is that the overall throughput of REST API type services increases a disappointing amount.

With JRuby you get to retain all the benefits of the Rails ecosystem. Most of the Go and Scala community is driven by much larger companies who do open source libraries but they don't really build frameworks to help developers build software quickly.

</comment></comment></comment></comment></comment></comment><comment><USER15> "And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags."

The author has no idea what they are talking when it comes to the alternatives.

I was making simple CRUD apps in Phoenix (the types of apps I would normally use rails for) for a year before I even looked at OTP. You can become productive in elixir and Phoenix very quickly especially if you come from a ruby/rails background.

I recall a blog post by dockyard where they said they had new hires making commits within the first week.

<comment><USER16> The author isn't wrong. You need to learn OTP to know that you don't need it (at least in the very beginning).

When I was learning Phoenix, I spent a substantial amount of time learning Elixir as well and OTP is one of the first few things they put in front of you. Don't get me wrong, I loved learning about it personally, but I am not surprised that a lot of people would consider it too much effort.

</comment></comment><comment><USER17> > In summary, we 'still' use Rails as it works just fine.

PHP works fine. COBOL works fine.

Nobody ever said Rails doesn't work. Or doesn't work fine. That's a straw man.

It's just that Rails, and Ruby in general, is in clear decline. Not just because some new flavor of the month frameworks are coming out, but because a lot of the concepts Rails supports are antiquated, and Rails hasn't shown to be that adaptable to more modern front end trends after years of efforts from DHH.

Hell, I'm sure that even DHH himself would be very upset if people settled for something that "works just fine". He's just not happy that this time around, that characterization is being used to describe his creation.

<comment><USER18> 1) "a lot of the concepts Rails supports are antiquated" ...

2) "Rails hasn't shown to be that adaptable to more modern front end trends"

Would you mind elaborating? What Rails concepts are "antiquated", and what "modern front end trends" does Rails not adapt to?

I've never done any Rails development, but understand the general idea of how it works, so I don't have any skin in the game. I'm just honestly curious about what you were referring to.

<comment><USER19> I imagine SPA trends with frameworks such as Angular are leading to the parent's conclusion. However, you can still use SPA frameworks and just use Rails as an API, or you can take a step back and realize a large percentage of web apps still don't need a complex SPA framework and might get enough front- end functionality out of something like Vue. In other words, many developers fall into the trap of choosing tools they prefer even when they may take more time to use and not provide enough business value. Plenty of web apps would ship faster if built with Rails and be just fine.

</comment></comment></comment><comment><USER20> I'm waiting for a framework that covers the whole stack and also makes it easy to make SPAs, if you wish. When that arrives I think it'll really take off.

For a while Meteor seemed to be that framework, but for a number of reasons — performance issues, lack of support for SSR - it hasn't taken off. While it's often good practice to separate the API and the frontend, for solo developers or small startups that's often overkill and adds complexity.

<comment><USER21> Or - get 90% of the benefit of SPAs but leave your business logic where it belongs (on the server). PJAX/Turbolinks/Intercooler or something similarly lightweight is probably all most people need when they reach for full-fat front-end framework.

<comment><USER20> Yes, for personal projects I've moved away from SPAs to backend frameworks and as little JS as I can get away with. I admit I don't know how easy Turbolinks or PJAX are. A while back when i played around with Intercooler in Django it wasn't seamless.

<comment><USER22> Turbolinks and PJAX are really what a lot of folks wanted before the web development community at large was introduced to client-side routing through SPAs post-Knockout.js days.

</comment></comment></comment></comment><comment><USER23> We still use Rails and it's a good fit for getting projects off the ground quickly and validating ideas. It's a niche but it's an important niche.

Once Rails projects get beyond a certain size though they start getting exponentially more difficult to maintain. My sense is that Node is going to surpass Rails by sheer brute force eventually. When I work in JS now I'm just amazed at how much better the tooling and performance is than Ruby and ES6/7 is overall a pretty nice language to work with. And having something like Typescript is essential once a codebase gets big enough.

<comment><USER24> JS tooling better than Ruby's? Care to elaborate? Which Node.js framework comes anywhere near the productivity of Rails?

<comment><USER23> By tooling I mean things like code editing, linting, type checking, debuggers and runtime quality and performance. As far as I can tell Rails is still a lot more polished than any JS web frameworks.

</comment></comment></comment><comment><USER25> The flowchart usually goes like this:

\- Oh wow this framework looks great I wish rails had that. I am gonna try and use this when the opportunity arises

\- Aha this is the perfect project for that framework I saw

\- hmm how do I do... Oh. Well I guess I'll just build it myself.

\- This plugin is the equivalent of paperclip, perfect! Great DSL, great documentation. Hmm what is this error. _3 hours later_ github issue time.

\- Turns out this wasn't the right project for me to try out this framework, maybe the next one.

\- Oh rails n+1 is out can't wait to try it

</comment><comment><USER26> >>And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags.

You don't need to learn OTP to become productive in Elixir/Phoenix. It's abstracted away from you, but also gives you the ability to dive in if you want/need.

<comment><USER10> Agree. You don't need to learn OTP to use Phoenix anymore than you need to learn the entire Java ecosystem to use Kotlin.

Erlang has been around for 30+ years...there's a lot. Doesn't mean you need to use it all.

<comment><USER27> I think it's disingenuous to say you don't need to learn OTP. You need to learn the basics of it, or you will struggle, because you will be trying to solve problems in a way that doesn't fit with the underlying language and runtime. That said, learning the basics of OTP is super easy, and can be done in an afternoon (spawning processes, sending messages, supervision, understanding what applications are in Erlang/Elixir parlance).

It's like saying you can build a Rails app without understanding classes/objects - sure maybe you could throw something together because the tools are so friendly, but you would get lost pretty quick when trying to do something on your own. Learn those basics up front, and you can get a long way without having to delve into more advanced topics.

<comment><USER10> Basics, sure. I think you learn the basics just to learn Phoenix though.

</comment></comment></comment></comment><comment><USER28> One of the biggest and often overlooked features of Rails is rspec and db:migrate. For whatever reason, I have yet to find alternatives in other frameworks that have matched the elegance of these 2 indispensable tools.

Similarly, while I'm not a huge fan of ORMs im general, ActiveRecord is pretty hard to beat pound for pound.

</comment><comment><USER10> People take for granted that Rails provides the closest thing to Aspect Oriented Programming that exists today (that I know of).

I don't use rails regularly anymore, but I used it long enough to appreciate what it gives you. As long as developer efficiency and time to market is more important than than micro performance optimizations, Rails and other options that emphasize developer efficiency will continue to succeed.

Unless you're in an established enterprise environment, that is generally going to be the story.

</comment><comment><USER29> >And then there's the Phoenix framework. Chris McCord wanted this MVC framework for Erlang, where Elixir is based on Erlang, used mostly for large scale backend systems. And Phoenix would be the Rails to Erlang's Ruby (Elixir). The learning curve is steep, you will need to learn OTP. Which is probably why adoption lags."

This is false, you do not need to know OTP to be productive.

These days if I'm forced to work with Rails, I almost always write functionaly-kinda-ish Ruby code. Elixir sold me heavily on the idea of one input in, one input out and all the other good that comes from functional programming.

I probably no longer write idiomatic Rails code (40 methods in a ruby model).

<comment><USER27> I commented elsewhere already, but you do need to know _some_ OTP to be productive. But those basics (processes, messaging, supervision) can be learned easily in an afternoon.

In my opinion, OTP is not the reason why the learning curve is steep. If anything, the learning curve is steep for those trying to switch from something like Ruby to a functional programming language for the first time. A language with immutability as the default, no concept of classes or objects (though viewed through the Alan Kay lens, processes could be seen as "true" objects). If it is your first FP language, most of one's object-oriented experience is not going to help, so there is a lot to absorb before you even get to Phoenix or OTP.

<comment><USER29> You don't need to know _any_ of these to build a fast, working, business- helping CRUD app.

processes, messaging, supervision

</comment></comment></comment><comment><USER30> In 2007, Rails was the hot new fad like Node.js became a decade later. Now it's the boring legacy app, like Java was in 2007 and Node.js will be around 2020. Looking back, all this effort now seems like mostly-pointless reinvention.

<comment><USER31> You have to remember how people were writing web apps in 2007 in order for this to be contextually correct.

<comment><USER30> Yeah, I guess I should have written about Perl or PHP rather than Java.

Spaghetti code is no fun, but you can still write that same style today in .erb files.

</comment></comment></comment><comment><USER32> No one avoids Ruby/Rails because it's old, we avoid it because it locks you in to conventions that most other modern languages / frameworks considered bad practice, like magic, metaprogramming, one process per request, locked in to OO, the concept of "controllers," separating templates from view logic, and doing everything at runtime.

<comment><USER33> That, and generally ORMs are out of practice as well. Using rails without ActiveRecord is almost pointless to me.

Even when I was programming primarily in rails in it's hay-day (2010 - 2013), I was always swapping out my inefficient AR queries with just custom SQL. I am generally a "performance doesn't matter that much" kind of guy, especially when people try to micro-optimize, but one place it matters a lot is with your data. These days I just go straight for SQL and save myself a lot of trouble. There will always be impedance mismatch between your data store and models, and ORMs in their ambitious attempt to serve every use case, at times, generate some _really_ inefficient queries. ORMs really like to stay within relational SQL databases as well, with half-baked support for a couple NoSQL stores like Mongo, but then get into Cassandra or Dynamo territory and they are useless.

</comment></comment><comment><USER34> The usual amount of snarkiness I've come to expect from the Ruby community. What a smarmy tweet: "Lol 20 something developers using new tools when they could just use this ancient slow dynamically typed OO language I allied myself with doing the exact same thing 10 years ago"

Ok I'll bite:

\- Because it had it's milkshake drunk by nodejs which has better support for modern front end workflows and great languages like typescript built in top of it. And is faster and better supported.

\- because it's slow and difficult to scale

\- because it has years and years of baggage

\- because I prefer elixir it golang or rust or Scala

\- because it's not a perfect fit for every project

\- because I do not like stateful object oriented languages with magic so I can trust my intern and Jr devs to write something decently maintainable

<comment><USER32>
        extend ActiveSupport::Concern

        attr_accessor :foo

        class << self
            included do
                def method_missing(name) do
                    define_method(:after_save) do |bar|
                        ...
                    end
                end
            end
        end

What do you mean? This stateful, first class mixin OO metaprogrammed magic, implicitly globally mixed in to your application, makes it super easy to understand the flow of your application and the capabilities of your system. It's also super easy to see where things are defined, and the structure of methods/classes/object doesn't depend on luck / the order your program _executes_ in! Fat models are the way to go, there's obviously no problem with stateful mixins to "separate" model logic and make sure your model can do absolutely everything, because what is data, really?

Perfect for junior and senior devs alike.

edit: I forgot to include `method_missing`, which definitely isn't a design flaw, and there's absolutely no fundamental community problem that Ruby developers don't see any problem with using it.

<comment><USER35> This is sarcastic right? I really can't tell. And you either deserve and upvote or a downvote and I can't tell which because of it.

</comment></comment></comment><comment><USER36> Essentially, this article gets written every year.

<comment><USER37> That should tell you something, no?

<comment><USER38> It tells me that some people _want_ Rails to die way more than it actually _is_ dying.

</comment></comment></comment><comment><USER24> Since discovering Clojure in 2013 my biggest regret is that the Clojure community is not interested in building a Rails equivalent. I don't mean an MVC clone but a full-featured web framework supported by the wider community rather than someone's personal curated list of libraries like Luminus. I think Rails set the bar for whether a new language can transition to mainstream adoption.

</comment><comment><USER39> I only did a short stint in web dev between undergrad and grad school for about a year. We used Rails. This was about 7 years ago. Are the reasons Rails has fallen out of favor technical or faddish? Or a little of both? I'm not intending to start a flame war of any sort. I'm just curious, having been out of the field for a while.

<comment><USER40> I'm not sure it has fallen out of favour but there is more competition now especially from javascript stuff.

</comment></comment><comment><USER41> The annual "is rails still relevant" post :D

</comment><comment><USER42> I have a few Rails apps. Team now wants to move to nodejs. I made a few apps in nodejs. It's such a mess, yarn vs. npm, webpack setup. I guess nodejs community is still searching for their holy grail (Rails.)

<comment><USER43> The node community is that xkcd comic about standards in human form. Nothing is ever settled, always a new way to do something.

</comment></comment><comment><USER44> I want to build an ecommerce website, are there alternative JavaScript that can replace RoR and the Gems ecosystem?

</comment><comment><USER45> Wait, when did Rails become old or uncool?

<comment><USER46> >Wait, when did Rails become old

It was released in 2004. Youtube and twitter didn't even exist then. The iPhone and Android were still 3+ years away, which means mobile internet as we know it today wasn't around then either. ROR has been around the block.

</comment></comment><comment><USER47> seems like very strong confirmation bias

</comment><comment><USER48> After all this time?.... Always

</comment><comment><USER49> Sinatra is frustratingly limited in some ways. I would describe it as easy, but not simple. It's easy to use it to bang out any use case the authors foresaw. But now I'm going back and reading the code all the time to figure out how to accomplish certain things. And that reading is difficult, because like some other Ruby things it's more focused on providing a pretty DSL for the user. How-to docs for basic things are easy to find, but reference docs aren't, and often just list methods without any description of what they do.

</comment><comment><USER50> If Rails is in decline it's because almost all languages now have some sort of MVC framework on par with Rails now. Since C# is used in the enterprise it's just natural to go with ASP.NET MVC Core instead of trying to get Rails to run on Windows. In my opinion, I feel one of the big mistakes that Rails made was not focusing on getting it to work officially on Windows.

<comment><USER51> Why rails should bother? There are plenty of other ruby gems and their developers who don't care about Windows. Even if Rails works, you can't convince community to make every single gem compatible with Windows. So it makes no sense.

</comment></comment><comment><USER52> As we transition to a more multicore, multi threaded environment Ruby cannot perform well. And thus by induction Rails. An interesting way forward is functional programming, because of its composable nature can perform really well in such environments. I dont see where Rails ideal niche exists going forward, is it in Large Apps that need really scalable apps that exist on multicore environments? Does it lie in small SPA like apps for which it has virtually no support? or Does it lie in the middle where you just throw more hardware at the problem before rewriting the whole app? In the last one yr i have seen more enterprise apps being activated in Nodejs than in Rails. Why does the enterprise Like Nodejs while Rails is on its downward spiral? i suspect it has to do with Nodejs being Beginner friendly. I left the Rails ecosystem 3 yrs back never looked back, and i dont see why i would ever go back.

<comment><USER53> I'm not sure I agree with this, you can always achieve parallelism with multiple processes and IPC, and can do so fairly efficiently if communication is light.

Rails' biggest problem is that it isn't JavaScript, and thus code is not portable between client and server.

<comment><USER54> Out of curiousity, where have you found it useful for code to be portable between client and server?

I've been using Node.js/React together for a while, and I haven't found code reuse across client and server to be as important as I initially thought. The only code that I've tended to share is validation and a handful of utilities, which are a tiny proportion of the total, and even for those the business rules aren't always the same.

<comment><USER55> I've made a few multiplayer games where players need to keep a game state synchronized with the server. I used redux for state and game logic, and it's been really nice to be able to share the reducers between server and client. This made it so all I had to do to keep all clients in sync was share actions across clients as they happened.

I've also found it useful to have TypeScript on client and server to be able to share types between them.

Also, when using React, Node on your server makes server-side rendering a lot easier.

</comment></comment></comment></comment><comment><USER52> Rails has a problem most are aware of, When i started rails few yrs back, they said skinny controllers fat models, but in a few months our Models became 3000 lines, so they said external loading libraries, then came concerns, then they took concern back because it doesnt work. Then another solution came in the form of gems, people thought lets make more gems we have tried so many different ways to do this. If that is not all there is a problem in rails that exist purely because of the way the framework works. The mass assignment problem, this problem literally doesnt exist in any other framework. What we do with this is a patch to restrict an action, but it really exist because of the nature of the framework. This is a code smell if your program due to its very nature creates problems that needs patching is probably not doing something right. In my opinion best is to go back to simpler ways of organising code. Rails is too much an abstraction that creates its own unique problems.

<comment><USER56> Seriously though, the only problem firebase solves is the question "what infrastructure decision can I make right now that I will regret as soon as possible?"

I'm being facetious but then I feel like this whole thing is a joke, so it's kind of fitting.

<comment><USER57> I've known a lot of people get started quickly with firebase and then proceed to have to yank it out for the nonsense they run into. I also question the real value/merit of firebase.

<comment><USER58> Heroku did this properly imho. They are a perfect example of how one can provide hosting that actually is helpful and sophisticated where it needs to be but gets out of your way when you don't need to care (for 99% of applications that don't need to scale beyond a certain point).

The people want postgres, give them Postgres.</comment></comment></comment></comment>


Am I Stupid Again? - <AUTHOR>

A couple of years ago, say around 3 years ago, I could not watch movies anymore. Every single movie was quite predictable IMO which completely ruined the experience.
This let me to believe that that phase of my life were I could just vegetate all day in front of a TV watching films was over.
I decided that it was either two things, I'm smarter now, more experience, or the population is simply stupider. I did not think that the films were worse then before, is just that I'd seen so many films that no new films felt original. For somebody just getting introduced to films, say a child, they were great films.
Lately though I've started to see a lot of really good films. At least films that have kept me entertained. And although sometimes you can still predict that the hero will win and how he will win I still find the films interesting.
This has let me two believe one of two things, I've become stupider or I was simply going through a depression phase of which I'm just becoming aware of.
By the way, two examples of really good films that I've seen are "The Last Stand" and "Jack Reacher".
Just saw a trailer of "The Internship" and though it was hilarious.
So what does everybody else think? Has anybody gone through something similar? <comment><USER2> Liking or disliking films is, more often than not, independent of intelligence.

Just because you now enjoy films doesn't necessarily mean your intelligence has changed. It's more likely to mean that your personality has changed. Remember that there are almost certainly many people that are smarter than you whom absolutely love films.

Please don't be the guy in the room who thinks that they're really smart because they have different/non-existent consumption habits than other people. This is dumb social signalling because others will think you are being pretentious.

You seem to have some kind of hang-up about being seen as being smart by other people...

</comment><comment><USER3> >I did not think that the films were worse then before, is just that I'd seen so many films that no new films felt original.

I think it's both. One wearies of a film's efforts to tell a story (compared to a book and an active imagination), given certain limitations in the medium, but the filmmaking process is getting much worse as time passes -- there's the temptation to blow stuff up for two hours (the Michael Bay approach) instead of tell a story. Also flimmakers know high-quality films can't find an audience -- old-style films that respect the intelligence of the viewers end up in art houses and late-night TV.

To a first approximation, modern filmmaking is a bunch of business-school graduates getting together and trying to create a "new" film that's as much as possible like the last film that attracted a large audience. They do all they can to include elements that worked before, they're extremely risk-averse, and their cynicism about their audience is boundless (and largely justified).

Meanwhile, films like "Juno" and other first-rate films get a modest audience, but at high risk -- most courageous films like "Juno" fail, so the risks are high in producing a remarkable film that people also watch.

People need to realize that filmmaking is primarily a business, not an art form. When a modern film is justly described as art, that's an accident, not part of the original plan.

</comment><comment><USER4> I don't think predicting that the hero will win is necessarily indicative of intelligence.

<comment><AUTHOR> Right, it sounds quite stupid in retrospect.

</comment></comment><comment><USER5> I don't think you have become stupider. Maybe more in need of the mindless relaxation that a predictable yet entertaining film can provide. I'd think if it had been depression, but there would certainly be other signs then film watching habits, right?

I don't even bother watching about 95% percent of the films available, just because they are so predictable, but predictability isn't everything. If you've watched a Lord of the Rings or Star Wars film more than once, it wasn't because you were wondering how it would end. I think unexpected plot twists are a relatively minor tool in the filmmaker's bag, compared with great acting, great storytelling, wonderful cinematography, etc.

Could it be that when you were vegetating in front of the TV, you were slightly depressed or indulging in some kind of escapism? Then you latched on to something exciting to spend your time on that erased your need for dodging reality? And now the raw peak of that excitement has faded a bit, leaving you some time and mental energy to enjoy the subset of films that are good, even when predictable. Could that be it?

</comment><comment><USER6> Yep, with novels.

I've read many SF/F novels and got to the point where they were pretty predictable and only bought one or two a year for a while.

After a break of a few years, I've been enjoying a higher fraction again.

For me, I think, it's an ability to enjoy the suspension of disbelief. If I've been reading a lot, it's harder to do so.

</comment><comment><USER7> Knowing the hero will win does not make you smart. Most people go into films knowing the outcome (even when the hero doesn't win). That's not why people like seeing films. It's for fun and it is an escape. When you're watching a movie you don't have to think about work, family, that doctor/dentist appointment you have been putting off..

I don't think you are "stupid again", I think you have matured more. Your previous opinion is similar to what a lot of teenagers go through when they think they know everything.

</comment><comment><USER8> You're not becoming more stupid - Hollywood IS. In their quest for more return at the box office they make dumber movies that appeal to a large share of their target market (which is anyone with eyeballs - *thanks to Argo for that great line). Audiences, in turn, think that they are seeing really great films as the bar becomes lower with each passing year. In the end it is a complete circle and audiences end up getting the quality of films that they deserve because Hollywood told them so.

</comment><comment><USER9> I'll play devil's advocate. I don't think you are now stupid as in your cognitive ability is lessened, but you are settling for a lower standard of thinking (assuming how you used to spend that time was more mentally taxing.)

I think that you are unwinding after more strenuous living, which is great, but I encourage you to find more beneficial ways to recreate that are also a lot of fun.

</comment><comment><USER10> I would say irrelevant. If watching moves and being smart/stupid were correlated, I wonder where I will end up :). I personally enjoy all kinds of movies. Serious types, movies with a mesage or just cheesy/silly ones.

You probably watched too many movies back then and lost interest. You are back now.

<comment><AUTHOR> This could be it. I pretty much stopped watching films for a long time. I know find them enjoyable again.

</comment></comment><comment><USER11> I believe that likely your hypothesis that you were smarter then or the movies were dumber is flawed.

Perhaps the movies are just more entertaining to your tastes.

</comment><comment><USER12> You probably overdid it on watching movies and TV before, and just got sick of it. Then after you took a break, you were able to enjoy them more.

</comment><comment><USER13> Could you give more examples of films in the past you've seen that you considered "stupid"?

I haven't seen "Jack Reacher" or "The Last Stand", but both garnered pretty lukewarm reviews, and at first glance, seem like the typical uncreative blockbuster fare.

How many independent studio films have you seen? How about foreign films? I've always been a fan of Kurosawa flicks, but a lot of Western movies follow in his thematic footsteps. After watching Park Chan-wook's films ("Oldboy" being the most internationally famous), I started to realize how formulaic Western blockbuster films were and have generally stayed away from them.

That said, blockbuster films can still have a predictable end but still be very entertaining. The first three Indiana Jones movies are the best examples of that -- i.e. you know Indiana Jones is not going to die at the end, and yet each (literal) cliffhanger is shot and structured so well that you suspend disbelief.

<comment><AUTHOR> The last Batman films and the last transformer films. I wouldn't say they were stupid, just so predictable that there was almost no point in watching.

I know that Jack Reacher and the Last Stand were not critical successes and yet I enjoyed them immensely. Which is what makes me think that I was probably suffering some form of depression.

</comment></comment><comment><USER14> i always upvote satire</comment>


Ivan Kaspersky kidnapped - <AUTHOR> http://www.heraldsun.com.au/news/world/it-tycoon-eugene-kasperskys-son-ivan-kidnapped-in-moscow/story-e6frf7lf-1226043194874

<comment><USER2> I feel bad reading these, having spent the first 10 years of my life in Russia before it all went from shit in disguise to outright, oh-the-audacity type of shit (~1990)

But this is the rule, not the exception, and it saddens me to say that Russia's the last place I'd want to start a company.

</comment><comment><USER3> This happens every day in mexico. Paying the ransom will unfortunately only validate the kidnapping "business model". There's no easy solution.</comment>


How to master Google Photos (2017) - <AUTHOR> https://www.theverge.com/2017/6/9/15762170/google-photos-how-to-master <comment><USER2> This is all nice and well, but sharing albums on Google is naive. You get a "hidden link" to an album that you can then share with people.

Back in 2005, I set up Famipix (www.famipix.com) to share my own private family photos. And keep them private. No public albums.

The site currently has users in more than 100 countries, and I've made a special version for schools that is free to use. We have good traction in the Netherlands (where I'm from).

Dutch legislation will require _all_ schools who post photos online to use a similar system, where only authenticated users (i.e. parents) can login to view the photos. Explanation here: [https://support.famipix.com/category/47-famipix-for- schools](https://support.famipix.com/category/47-famipix-for-schools)

If you're interested in a free account for your (kid's) school, just send me a message.</comment>


Web Scraping Finds Price Fluctuation - <AUTHOR> https://blog.scrapinghub.com/2016/02/10/which-stores-are-guilty-of-price-inflation/ <comment><USER2> I dislike the "guilty of inflating prices" theme here. These stores are guilty of no crime. Prices fluctuate all the time, sometimes daily, sometimes hourly.

Bottom line, none of these products are essentials to life. The price is either worth it to you as a buyer, or not. Thinking you lost money because it's later available for less is the same sort of faulty logic used by people who think they are "saving" money by buying something on sale (when it's an item they wouldn't ordinarily buy). I had a friend who used to do that all the time. We'd be at a store, and he'd see something on sale that he had no intention of buying before he walked in. He'd buy it, and congratulate himself on "saving" money. I'd point out "no, you just spent $50 that you hadn't planned to spend." He just didn't see it that way.

<comment><USER3> In Quebec, the CONSUMER PROTECTION ACT adequately protects consumers from such unfair practices :

225\. No merchant, manufacturer or advertiser may, falsely, by any means whatever,

(a) invoke a price reduction;

(b) indicate a regular price or another reference price for goods or services;

(c) let it be believed that the price of certain goods or services is advantageous.

[...]

231\. No merchant, manufacturer or advertiser may, by any means whatever, advertise goods or services of which he has an insufficient quantity to meet public demand unless mention is made in his advertisement that only a limited quantity of the goods or services is available and such quantity is indicated.

The merchant, manufacturer or advertiser who establishes to the satisfaction of the court that he had reasonable cause to believe that he could meet public demand or who offered the consumer, for the same price, other goods of the same nature and of an equal or greater cost price is not guilty of any infraction of this section.

I feel that the United States are a bit reluctant to protect their citizens.

<comment><USER4> I believe the US has protections against deceptive pricing like that too, but i don't think any of these companies or practices described in the article would be in violation of it.

The law you're referencing is a protection against raising the price before a sale so you can advertise the sale price as x% off the inflated price instead of the store's regular price. Most e-shopping sites advertise a discount relative to MSRP, not relative to any price they've previously charged, which leaves them free to raise or lower the prices as they want.

<comment><USER3> I'm fairly certain that established case law requires the retailer to have actually offered the item at the listed reference price for a reasonable amount of time before the sale. Using the (usually inflated) MSRP as reference is in contravention of art. 225.

</comment></comment></comment></comment><comment><USER5> Alternative title: "Some stores offer more consistent prices than others. Some stores have lower average prices than others."

We're not entitled to low nor consistent prices. We should expect pricing to fluctuate.

Buy at a price where an item is worth as much (or more) to you than the price you pay, and you'll always get your money's worth. Sometimes this means not buying the item.

If you want to know which stores practice consistent pricing, or want to know which stores fluctuated low in last year's known-big sale days, this article is useful.

<comment><AUTHOR> I like your extremely accurate title pitch. And no, we're not entitled to low or consistent prices, but the fact that there is inflation on "sale" days is noteworthy because of the air of false advertising. You're absolutely correct though, shoppers should buy when they feel comfortable because buyer's remorse is meaningless when you're happy with the purchase.

</comment></comment><comment><USER6> JC Penney just went through a complete meltdown because the CEO forced out honest pricing instead of the inflate-prices-and-have-sales that was their SOP for more than a generation.

Turns out their customer base really liked the sense of saving money, even though the straight forward pricing was actually saving them more money.

This kind of a thing feels unethical - especially to those with an analytical mindset like a lot of programmers. But the proof is in the pudding. People (at least older people in the U.S.) prefer bargain shopping to straightforward pricing.

Culturally, there are differences like this around the world. In Japan, they cannot grasp subscription models very well. In many places in the middle east, negotiation is just a part of shopping. In the U.S. we really like sales. In Russia, you get in line and then ask the people around you what it is that you are buying (granted, haven't been there since the 80s).

<comment><AUTHOR> I think the unethical aspect of arbitrary pricing that goes beyond daily fluctuations really came out in this project. I actually was not aware of the situation with JC Penny, but really fascinating glimpse into their consumer mindset. Probably comparable to Sam's Club, since even I expected a ton of lower prices from them based on membership. I like your cultural analysis!

</comment></comment><comment><USER7> Such price inflation would be illegal in the European Union, as what can be advertised as a "sale" is regulated by consumer law, and raising prices in the previous weeks is forbidden.

Nevertheless, that doesn't mean that it won't be done; the appeal of marketing tricks is too strong for many businesses, because psychology trumps buyer's rational consideration in the aggregate and thus these practices pay for themselves against any possible sanction.

(If it didn't work, the art of advertising would look completely different).

<comment><AUTHOR> If I'm not mistaken (which I might be), there are only specific and regulated periods of the year where sales are actually approved. So it might be an interesting follow up project to track EU retailers. My qualm with the practices of certain US retailers that we tracked was that they offered the inflated prices on the same days as the sales, so that it wasn't even a matter of raising prices in the weeks leading up.

</comment></comment><comment><USER8> This would be far more interesting if it had items that weren't electronics. So many products are sold with what is called a "Minimum Advertised Pricing Policy" that it makes it risky to sell less than the competition (which is probably selling at the absolute lowest price the market will allow).

Apple for one has one of the most aggressive policies. I'm sure Target is counting on their size, and the fact that its a one day thing when they offered their discounts.

<comment><AUTHOR> Well, the Toys category had non-electronic items and it was the category that was the most examples of inflated pricing (not such a shocker). However, all of the stores offered discounts on electronics at one point. You just had to be lucky in going to the right store on the right day.

</comment></comment><comment><USER9> Scrapinghub changed not only their pricing, but their pricing model! Guilty! :)

[http://scrapinghub.com/pricing](http://scrapinghub.com/pricing)

[https://web.archive.org/web/20150302014145/http://scrapinghu...](https://web.archive.org/web/20150302014145/http://scrapinghub.com/pricing)

Edit: Joke was easier to get before they changed the HN title for this submission.

<comment><AUTHOR> haha, I would say touche except for the fact that we never advertised a sale and then elevated our prices.

<comment><USER9> If you say so. Consider the following, less nefarious theory.

\- Company puts an item on sale,

\- After the sale, they follow of pattern of starting cautiously, but increasing the price on a regular basis until they see either a drop off in sales, or competitive pressure

\- The next sale happens whenever it's scheduled to, based on calendar events, excess inventory, etc.

</comment></comment></comment><comment><USER10> I have the camelcamelcamel chrome extension which shows me a price graph over time for any item on Amazon, and you can set alerts for when prices drop to a certain level. It's very useful, and because of it I already knew that the vast majority of amazon deals are not discounted at all.

Amazon items fluctuate a lot, maybe especially for baby items. But I got 30%+ discounts on car seats and strollers by setting a price alert and waiting a few months.

</comment><comment><USER11> For me, the convenience of Amazon outweighs any "deals". I don't consider $10 off of a $50 item a deal. It needs to be 40%+ for the price reduction to really make a difference in my calculus.

Amazon has my sister's address information already saved, I can just click it from the list when I'm buying presents for my nephews.

Brands still have value when properly managed, don't let anyone tell you they don't.

<comment><USER12> There's a positive externality that arises from price-sensitive shopping. It promotes competition, which leads to lower prices for everyone.

If everyone behaved like you, requiring a 40% discount before moving away from Amazon, then Amazon would just set its prices 1/.6 = 66% higher than the other stores. Fortunately, not everyone is like you, so Amazon's prices are often competitive.

To some degree, I suppose this is like buying index funds versus buying individual stocks. I only buy index funds. But the reason I can get away with it is that there are at least a few people out there searching for value. I can't compete with them. But I can price-compare online, or at gas stations, etc. I see shopping for low prices as part of my duty as a capitalist. :)

<comment><USER13> _> There's a positive externality that arises from price-sensitive shopping._

The term "price sensitive" is a bit misleading. A better term would be "value sensitive". Your duty as a free market participant (I prefer that term because "free market" is not necessarily the same as "capitalism") is to get the best value you can for your money. But that is value _to you_ , and will be different for different people. Also, that value has to include the cost of the time and effort you spend searching for value, which is also different for different people.

</comment></comment></comment><comment><USER14> I found it extremely misleading to call out Amazon.com when, in fact, most of the Amazon products listed are specified as being sold by "an Amazon seller", not by Amazon.com.

This needs to be made MUCH clearer on the site. I'd be curious about the changes for those products _sold and fulfilled by Amazon.com_ versus _sold by a third party (on the web site|and fulfilled by) Amazon.com_.

<comment><AUTHOR> There is a distinction made by those sold and fulfilled by Amazon.com vs sellers on Amazon. Both have inflated prices.

</comment></comment><comment><USER15> Stores aren't "guilty" of anything. Prices fluctuate based on demand. That's normal. If you don't think that's normal, break out a basic economics textbook and do a bit of reading.

<comment><AUTHOR> Fair enough and consumers are rewarded for carefully researched shopping. However, many of the days we compared were specifically billed as major "sale" days and so I, at least, found the price inflation disconcerting.

<comment><USER16> It's only a reward if you consider your time spent researching worth less than the discount you actually receive.

<comment><USER17> That's one of the reasons stores offer sales, coupons, and similar: they allow stores to effectively offer different prices to different people, extracting more total revenue than if they had to charge everyone the same price. A store could never get away with directly saying "we charge more if you have more money". But they _can_ offer coupons and sales, which have the same effect: those who take the time to clip coupons and watch for sales pay a lower price (and thus buy anyway), while those who don't pay a higher price.

</comment></comment></comment></comment><comment><USER18> I find it odd that the baseline used is after the holiday sales period, in the doldrums of retail.Couldn't the lower price after the holiday season be explained by excess stocks due to insufficient demand relative to forecasts during the holiday season?

I think the fact that toys, a product highly prone to fads and trends, are the main culprit would reinforce such an explanation. It would be nice if they had a baseline both before and after or an even average of multiple non-shopping holiday points, rather than one day.

</comment><comment><USER19> I'm assuming that scrapinghub.com is invested in web scraping, so it'd be wise not to flaunt the actually illegal act going on here, which is the violation of the CFAA and various intellectual property laws that scraping almost always constitutes under conventional interpretation.

</comment><comment><USER20> Guilty? Price inflation? Since when is it a crime to charge more than everyone else for something?

This just in, major exchanges are guilty of stock inflation!

<comment><AUTHOR> I stick by the title. No, it's not a crime, but there's definitely a disingenuous aspect to overcharging for a product.

<comment><USER13> "Overcharging" compared to what? If you mean, compared to other stores selling the same product at the same time, consumers have access to the same information that this study did. If it's worth it to them to seek out a better deal, they have the information to do so. If they decide it's not worth it to them, how is that the store's fault?

What you are calling "overcharging" is actually just the free market at work. Stores vary prices in order to find out what the best price for them to charge is--"best" meaning the price that maximizes their profit. Customers evaluate prices in order to find out what the best price for them to pay is--"best" meaning the price that maximizes their benefit from the purchase--the value of the item to them minus the cost. But "cost" includeds the time and effort spent price searching, and different people place different values on their time and effort relative to other things.

So in a free market, you should _expect_ to see different prices for the same product at the same time at different stores, because they are selling to different customers with different relative priorities. It would be a lot _more_ suspicious to see the same item sold for exactly the same price at every store--that would mean the market is not a free market any more.

<comment><AUTHOR> By overcharging, I mean that we compared prices to a baseline day in January (the 13th, to be exact) and then showed those prices against what was on offer from other retailers. Consumers do have access to this information and their buying decisions are their own. And that's true, this study reinforces the free market system we have. There is something to be said for the shadiness of certain retailers elevating their prices on days that are being touted as "sale" days.

<comment><USER13> In other words, you're using "overcharging" to mean "the price went up". That doesn't seem like a very good use of language; there are lots of valid reasons why the price might have gone up.

As for retailers using the word "sale" to mean "we raised the price a week ago and now we're dropping it back to where it was before, in the hope that you'll think it's a great deal", that could certainly be described as "shadiness", yes, but since you appear to agree with the market being free, the free market should sort that out just fine. If such practices hurt consumers, on net, then consumers can respond by not buying from such retailers.

</comment></comment></comment></comment></comment><comment><USER21> [https://en.wikipedia.org/wiki/Caveat_emptor](https://en.wikipedia.org/wiki/Caveat_emptor)</comment>


GitHub vs. GitLab - <AUTHOR> http://usersnap.com/blog/gitlab-github/ <comment><USER2> I use gitlab for the free private repos, the only bad part is that most third party services target github first</comment>


Theory Disproven: Money as Motivation - <AUTHOR> http://jtame05.wordpress.com/2008/12/28/theory-disproven-money-as-motivation/

<comment><USER2> Some people want to start businesses because they are poor right now, and don't want to be poor. Such people will make money but they will never become rich, because all they really want is to have some toys. Once they have maybe $20.000 a month, they can get all the toys they want, all the girls they want, and their journey is done. These are people who want to "make it" and retire to an island they bought. Unfortunately, they will never be able to buy the island, but they will be able to rent a cottage there for a few weeks each year, and that will be enough for them.

Some other people just want to win. Money is the path they have chosen, and they will continue to try to win, time after time. They are playing a game, and they want to be first. These are the people that look for new opportunities, keep trying them, expanding and so on. They will be able to afford the island at some point, but they will never want to go retire there, because the game by which they define themselves does not exist there.

Another group of people care about their ideas. They have an idea, they nurture it and build it out and they want people to use it and admire it. When people buy it or use it, or ooh and ahh at some way he expanded it, that is when they feel the sense of accomplishment. The money is not that important, but if the idea is a good one that people want, it will make money. When his idea gets bought out, he will find a new idea and work again to make it appreciated.

In the end, all groups just want to get some positive feedback for something they did. They want to push a button and get a dopamine rush to the head. They just choose different ways to do it.

</comment><comment><USER3> money motivates people in two very distinct ways.

1\. as a means of material comfort. (the most common assumption)

2\. as a measure of success against others. This comes into play once you have enough money to satisfy any reasonable material desire. At this point money ceases to be about absolute buying power and becomes a comparative measure.

some people are all about 2 even before they have any wealth. Cuban is one of them.

</comment><comment><USER4> "Business is a sport. Except there's no seasons, it's 24×7x365, and there's always someone out there trying to kick your ass." - Mark Cuban

I like this.

<comment><USER5> _"Business is a sport. Except there's no seasons, it's 24x7x365, and there's always someone out there trying to kick your ass. - Mark Cuban_

I'm trying to work out the math here. 24x7 is 168, and is presumably the number of hours per week. Why is that multiplied by 365?

Maybe he means 24x365 (and gets a day off every 4 years), maybe he means 24x7x52 (which gives one day off a year, 2 in leap years).

Who knows. Perhaps he gives 700%. Maybe being really, really rich means you don't need to make sense. As Pedro Guerrero said about sportswriters

"Sometimes they write what I say and not what I mean."

<comment><USER5> In response to being down-modded ...

Clearly someone thinks that my comment was a waste of time and space, and is non-constructive, but I offer you this observation: One of my customers is my customer because one of my competitors said they would give 120%. My customers expect accuracy, not exaggeration. They appreciate clear communication.

OK, it's one of my personal hobby-horses, but I invite you to consider how your customers, or clients, or colleagues, perceive you through the language you use and choose.

</comment></comment></comment><comment><USER6> Some people like winning. For some pursuits, money is an indicator of points.

</comment><comment><USER7> There are two aspects to money. Money as a goal and money as a reward.

Rewarding people with money with bonus' just doesn't work. People become dependant on the bonus, growing to expect it for no extra effort. fail.

Using money as a goal works as part of a package of goals (for most people). If you sell it as 'solve this problem, save the world and we'll be rich' it works. The money is a result of their efforts.

There are a few people who are purely motivated by making money for themselves and that's fine. They will either be very rich or very unhappy (that's a logical or so they can be both rich and unhappy).</comment>


A Cloud Computing Clash - <AUTHOR> http://www.economist.com/business/displayStory.cfm?story_id=13414155&source=hptextfeature

<comment><USER2> Every cloud computing service let you run your choice of Linux and has an API. It would be trivial to write a library that talks to all APIs. What's the problem?

(I'm not including Google AppEngine, because despite their branding, their current offering is web hosting, not cloud computing.)

<comment><USER3> The problem is latency and the cost of moving data. If I'm sitting on, say, AppEngine it is expensive and impractical to use Amazon SQS with it.

Fast-forward 5 years when you company is large and dataset larger. You'll find yourself dependent on all of the features of your chosen vendor and you never look at or know about other vendors. The cost of moving is simply too high and mix-an-match doesn't work.

If you stay nimble and limit yourself to intersection of the different cloud's features you'll be ok. That's not going to happen for a lot of larger non-tech companies.

</comment></comment><comment><USER4> "You can get locked into a cloud."

That's a funny thing to be concerned about with respect to technology. It's like the old arguments, "Don't buy the computer because it'll be cheaper next year."

</comment><comment><USER5> cmon, let's just call it Web 3.0 ;)</comment>