My Struggles with Rust - <AUTHOR> https://compileandrun.com/stuggles-with-rust.html <comment><USER3> One thing I've found with rust is that you struggle struggle struggle trying to do a simple task, and then finally someone says "Oh, all you need to do is this".

Rust has already reached the point where it leaves the world behind. Only the people who have been there since the early days really understand it, and getting into rust gets harder and harder as time goes on.

Yes, there's some awesome documentation, and the error messaging has gotten a lot better. But the power and flexibility of Rust comes at the cost of it becoming harder and harder to figure out how all the thousands of little pieces are supposed to fit together. What's really needed is a kind of "cookbook" documentation that has things like "How to read a text file with proper error handling" and "what is the proper way to pass certain kinds of data around and why".

Right now there's a lot of "what" documentation going around, but little that discusses the "how to and why".

<comment><USER4> How is this problem solved for C++?

<comment><USER5> The nice thing about C++ is that it is so widely used that for just about any task you can find examples of how to do it (usually many different ways to do something), especially for tasks like this article. You will also find plenty of C example, which you could also use in C++.

<comment><USER6> Unfortunately 90% of them will be outdated/wrong/unsafe. Being backward compatible with 30 years of code means you're unlikely to find the right answer for the present. And worse, you won't know it.

<comment><USER7> You base your 90% claim based on what? I have entirely different experience and I am using C++14 and C. K&R "C programming language" is from 1978 and it's still one of the best books about C still used in 2017. I see many stackoverflow answers updated from C++98 to C++11/14 and some even to C++17.

<comment><USER8> As someone whose first introduction to C was through K&R, and still has that torn and tattered copy on his bookshelf, the idea that we're still recommending K&R as "one of the best books about C" only validates arcticbull's (sadly-downvoted) point.

<comment><USER9> K&R is so clearly written that I was able to understand it as a sixth grader. (At least, I felt like I did; subsequent events later proved that I did not understand pointers, but I don't think it was K&R's fault that a sixth grader didn't understand.) That's why it's still being recommended and the much thicker tomes also purporting to teach the C language have been forgotten. It's probably the same reason that your copy is torn and tattered.

<comment><USER8> _> It's probably the same reason that your copy is torn and tattered._

Er, well I was also using it as a mousepad for about three years...

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> Hello Justin Turpin! Sorry to hear your struggles with rust. It's always going to be a bit more verbose using rust than Python due to type information, but I think there are some things we could do to simplify your code. Would you be comfortable posting the 20 line code for us to review? I didn't see a link in your post.

Anyway, so some things that could make your script easier:

* for simple scripts I tend to use the `.expect` method if I plan on killing the program if there is an error. It's just like unwrap, but it will print out a custom error message. So you could write something like this to get a file:

        let mut file = File::open("conf.json")
            .expect("could not open file");

(Aside: I never liked the method name `expect` for this, but is too late to do anything about that now).

* next, you don't have to create a struct for serde if you don't want to. serde_derive is definitely cool and magical, but it can be too magical for one off scripts. Instead you could use serde_jaon::Value [0], which is roughly equivalent to when python's json parser would produce. * next, serde_json has a function called from from_reader [1], which you can use to parse directly from a `Read` type. So combined with Value you would get:

        let config: Value = serde::from_reader(file)
            .expect("config has invalid json");

* Next you could get the config values out with some methods on Value:

        let jenkins_server = config.get("jenkins_server")
            .expect("jenkins_server key not in config")
            .as_str()
            .expect("jenkins_server key is not a string");

There might be some other things we could simplify. Just let us know how to help.

[0]: [https://docs.serde.rs/serde_json/enum.Value.html](https://docs.serde.rs/serde_json/enum.Value.html)

[1] [https://docs.serde.rs/serde_json/de/fn.from_reader.html](https://docs.serde.rs/serde_json/de/fn.from_reader.html)

<comment><USER11> While it's too late to change the name "expect", could one create an alias for it and call it say, "on_error"?

<comment><USER12> I'd expect 'on_error' to take a function as a callback, not a string. But yes, a better named function could be added

<comment><USER13> Perhaps or_die, similar to Perl?

<comment><USER14> Yep, this is what I always wanted it to be! But maybe or_panic would be better. Naming things is hard.

</comment></comment></comment></comment></comment><comment><USER15> I was under the impression that the (somewhat) verbose syntax for error handling and memory management via the type system was a necessary side effect of Rusts entire point of existence: a compiler-guaranteed safe systems language. Neither Python nor C force you in any way to pay attention to errors, making simple scripts much easier to write.

I guess I'm just surprised people think that Rust should be as simple to use as Python. Maybe I'm wrong.

<comment><USER16> I think the complaint is more that Rust has seemingly tried very _hard_ to make error handling "simple". But in the process it has managed to invent a whole series of new idioms and special syntax that is alien to pretty much everyone. There's a thread in /r/rust about this same article where you can look and see people suggesting all sorts of ways to write this that are split into clear sedimentary layers depending on when the writer learned the language.

At this point the cognitive load required to read and understand Rust implementations of "typical" practical problems is _rather higher_ than it is for C++. And it seems to be getting steadily worse from my perspective on the outside.

<comment><USER17> > There's a thread in /r/rust about this same article where you can look and > see people suggesting all sorts of ways to write this that are split into > clear sedimentary layers depending on when the writer learned the language.

As someone that participated in that conversation, I think that's a pretty inaccurate characterization of it. It's not about _when_ the writer learned the language, but rather, _what problem you 're trying to solve_. If you'll allow me to summarize very briefly (perhaps at the expense of 100% accurary):

        * Use unwrap/expect when you don't care.
        * Use `try!`/`?` with Box<Error> in simple CLI applications.
        * Use `try!`/`?` with a custom error type and From impls in libraries.
        * Use combinators (e.g., map_err) when you need more explicit control.

You might imagine that you could use any number of these strategies depending on what you're trying to do, which might range from "a short script for personal use" to "production grade reliability."

All of this stuff was available at Rust 1.0. (Except for `?`, which is today an alias to `try!`.) It all falls out of the same fundamental building blocks: an `Error` trait with appropriate `From` impls.

The one exception to this is that, recently, there has been a surge in use of crates like error-chain to cut down on the code you need to write for defining custom error types and their corresponding `From` impls. But it's still all built on the same fundamental building blocks.

<comment><USER18> "new idioms and special syntax that is alien to pretty much everyone"

->

"an `Error` trait with appropriate `From` impls."

Note, that it may be entirely necessary for us to invent new idioms to make progress in the art of programming.

<comment><USER19> It might be worth pointing out that this Rust:

        #[derive(Debug)]
        enum ConfigError {
            Io(io::Error),
            Parse(ParseIntError),
        }

        impl From<io::Error> for ConfigError {
            fn from(err: io::Error) -> ConfigError {
                ConfigError::Io(err)
            }
        }

        impl From<ParseIntError> for ConfigError {
            fn from(err: ParseIntError) -> ConfigError {
                ConfigError::Parse(err)
            }
        }

        fn read_config() -> Result<i32, ConfigError> {
            Result::Ok(parse_int(read_config_file()?)?)
        }

        // given the following
        fn parse_int(str: String) -> Result<i32, ParseIntError> { ... }
        fn read_config_file() -> Result<String, io::Error> { ... }

Is, in a sense, the equivalent of this Java:

        int readConfig() throws IOException, ParseException {
          return parseInt(readConfigFile());
        }

        // given the following
        int parseInt(String str) throws ParseException { ... }
        String readConfigFile() throws IOException { ... }

The reason i say that is that this:

        throws IOException, ParseException

Is essentially a sum type. It says that if this method results in a failure value, it can fail with one of two types of failure values. It might not look like a new type, because in Java, types are almost always nominal, and this is structural, but that's what it is. I think that throw and catch clauses are the only place that Java will let you define an ad-hoc sum type. You have to use polymorphism everywhere else you want a variety of types.

Whereas in Rust, there are no structural sum types, and so the only way to make something resembling a sum type is:

        enum ConfigError {
            Io(io::Error),
            Parse(ParseIntError),
        }

Which means you also have to write the machinery to convert between the types.

I wonder if it would help to have a compiler- or library-defined From impl for all newtype enum variants (or all newtype structs more generally), that makes the variant from its argument. Or maybe it could be derived. It would wipe out a lot of this boilerplate.

<comment><USER20> I would love a `#[derive(From)]` for newtype structs and enum variants. Would bring Rust error handling back below Java in boilerplate levels. :)

<comment><USER21> There are some crates that add a derive for errors, but most people tend to use error-chain or quick-error. Both give you the boilerplate pretty much for free, with various other advantages. E.g., using error-chain, you can just write the above code as

        error_chain! {
            foreign_links {
                Io(io::Error);
                Parse(ParseIntError);
            }
        }

and it'll even generate an aliased `Result` type as well as fancy chaining support.

<comment><USER20> Right- error_chain is just a bit too much magic for me compared to what #[derive(From)] would do.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER22> Being able to port a 20 line Python script to a 20 line Rust is the holy grail. Surely Rust has the ambition to one day achieve that, but it is by no means the main priority nor the original design goal of the language.

Justin criticizes the file_double function, it being complex with nested maps and conditionals. All of this complexity is also in the Python code, just hidden away in abstractions, the library and the virtual machine. Rust, right now, is still very explicit and revealing of inherent complexities. This code is exactly why you should use Python and not Rust for this kind of little script. One day the Rust developers hope Rust will be comfortable enough for you to consider using Rust in this situation, but it won't be soon.

The point gets softened a little by the remark that it probably would not be a picnic in C either, but I don't think even that is true. C still allows you to be very expressive, it would not encourage using those maps or even half of those conditionals. Rust is just that more explicit about complexity.

That said I honestly believe Rust is the best thing that has happened to programming languages in general in 20 years. Rust is rocking the socks off all the non-web, non-sysadmin fields, soon its community will make good implementations of almost every hard problem in software and Rust will be absolutely everywhere.

<comment><USER23> Rust hasn't made significant incursions into math modelling or industrial processing. It's advantages are slim there. Embedded will fracture into network interfacing and realtime where user input is less hostile, more predictable and doesn't require extensive constraint.

<comment><USER24> Isn't it this kind of thinking that leads to sql injections in number plate readers?

</comment></comment></comment><comment><USER25>
      > import json
      > with open("config.json") as f:
      >  contents = f.read()
      > config = json.loads(contents)

translates to:

      extern crate serde_json as json;

      fn read_json() -> Result<json::Value, Box<std::error::Error>> {
          let file = std::fs::File::open("config.json")?;
          let config = json::from_reader(&file)?;
          Ok(config)
      }

And

      > import configparser
      > config = ConfigParser()
      > config.read("config.conf")

can be translated to:

      extern crate config;
      use config::{Config, File, FileFormat};

      fn read_config() -> Result<Config, Box<std::error::Error>> {
          let mut c = Config::new();
          c.merge(File::new("config", FileFormat::Json))?;
          Ok(c)
      }

Difficult stuff indeed.

<comment> stable-point I think this highlights that while there are easy solutions to the problem the OP faced, they're difficult for a newcomer to discover. (I have been using Rust for a couple of months and I'd also have reached for serde and maybe serde_derive to solve the problem).

Hopefully this is something the Libz Blitz[0] will solve with their Rust Cookbook[1]. (You could almost but not quite arrive at as simple a solution from chapters 1 and 2).

[0] [https://blog.rust-lang.org/2017/05/05/libz-blitz.html](https://blog.rust- lang.org/2017/05/05/libz-blitz.html)

[1] [https://brson.github.io/rust- cookbook/intro.html](https://brson.github.io/rust-cookbook/intro.html)

<comment><USER26> The curious thing is that OP linked to the error handling docs, and the solution with Box<Error> is right there.

</comment></comment></comment><comment><USER27> These struggles are real. I don't see a way around them other than just learning them (and then they go away, because you know what code won't work, and don't fight it).

It's probably because Rust looks and operates mostly like a high-level language, but still satisfies low-level constraints.

e.g. the confusing difference between `&str` and `String` is equivalent of C's `const char * str = ""` vs `char * String = malloc()`.

In C if you had a code that does:

         char *str = foo();
         free(str);

you'd know that in `foo()` you can't return `"error"`, since an attempt to free it would crash the program. And the other way, if the caller did not free it, you'd know you can't have a dynamic string, because it would be leaked. In Rust you don't see the `free()`, so the distinction between non-freed `&str` and freed `String` may seem arbitrary.

<comment><USER28> These struggles are indeed real, but at least as far as verbose error handling goes, remember that Rust is forcing you to handle a lot of things that are silently ignored in Python. Truly equivalent Python code would include a bunch of exception handling and checks for nil.

<comment><USER29> I haven't done much Rust, but why isn't there a safe way to do some of this implicitly? If you don't want to think about errors and just want to crash, then I feel like there should be a sane way to crash the script with a default error message. Could you write a thin abstraction to achieve this? Maybe there could be a new crate called "rust-script" or something, where the goal is to write code as easily as Python or Ruby.

Again, I'm not a Rust developer, but it's not hard to imagine an abstraction (or even a transpiler) that makes it easy to read a file, parse it as JSON, and do something with the data.

<comment><USER28> As the other comment says, that's exactly what's done with unwrap and try. You do obviously have to write that out, but on the other hand that means you know where to add the error handling when you come back after the fact. It might take a little getting used to, but it's a decent compromise. I'd say it's a matter of taste, but yeah, there are a few more characters there.

<comment><USER30> Couldn't there be an opt-in Deref for Option and Result? Then you could just pretend everything unwrapped fine.

</comment></comment></comment></comment></comment><comment><USER31> My main gripe with Rust so far has been the unnecessary profusion of Result<> types, making it hard to process and forward errors.

Case in point: the example in the article from the rust documentation that converts errors to strings just to forward them: [https://doc.rust- lang.org/book/error-handling.html#the-limit...](https://doc.rust- lang.org/book/error-handling.html#the-limits-of-combinators)

In practice, I find a type like Google's util::StatusOr ([https://github.com/google/lmctfy/blob/master/util/task/statu...](https://github.com/google/lmctfy/blob/master/util/task/statusor.h)) a lot easier to use (I've written >100kloc c++ using it). This uses a standardized set of error codes and a freeform string to indicate errors. I've yet to encounter a case where these ~15 codes were insufficient: [https://github.com/google/lmctfy/blob/master/util/task/codes...](https://github.com/google/lmctfy/blob/master/util/task/codes.proto)

<comment><USER32> I think having Result alone does not make error handling complicated, but having different error types for each operation (and concrete result) instead of using one generic error type for all of them does by pushing the job of unifying erros towards the user.

Go works around the problem by Error being an interface, which means any function can return any kind of error without needing to transform it to another form. However Go benefits from the Garbage Collector here - I totally understand why Rust libraries don't want to return heap allocated errors.

Maybe C++ std::error_code/error_condition provides some kind of middle ground: It should not require a dynamic allocation. And yet the framework can be expanded: Different libraries can create their own error codes (categories), and error_codes from different libraries can all be handled in the same way: No need for a function that handles multiple error sources to convert the error_codes into another type.

The downside is that the size of the error structure is really fixed and there's no space to add custom error fields to it for error conditions that might require it. A custom error type in Result<ResultType,ErrorType> can be as big or small as one needs.

<comment><USER33> > However Go benefits from the Garbage Collector here - I totally understand > why Rust libraries don't want to return heap allocated errors.

This doesn't have to do with the GC or lack thereof. Instead it's part of the philosophy of zero-cost abstractions: idiomatic C libraries don't require heap allocations to return errors, so neither does Rust.

</comment></comment></comment><comment><USER34> A common theme I find in posts criticizing Rust is that their authors take a problem they've already solved in another language, try to blindly convert it in non-idiomatic Rust and then complain because things get awkward.

I think that it's important to pick the right tool for the job and to follow the patterns of the tool you're using.

Is Rust the right tool for the task described in the post? Probably not, but it could still be used albeit it will always require more work than Python.

What's really missing is a resource showing common problems and their idiomatic solutions.

</comment><comment><USER35> The `error-chain` crate [1] exists to get rid of precisely the error handling boilerplate the author has encountered. That's not ideal, though, as I believe that a place for such functionality is in the core language, not a separate library, but it gets the job done. As for the `let mut file` bit, that makes sense to me: a file in the standard library is an abstraction over a file descriptor in the operating system, and the descriptor has a file pointer which must be advanced when you read from it. I don't consider it internal state; the read operation will return new data every time, so it's not a pure function. It follows that in order to behave that way, it has to depend on some pretty explicit state.

As the other comment said, Rust needs to make some trade-offs, because you simply can't have an expressive and easy-to-use language that runs so close to the metal and is aimed at being C++-level fast. As such, Rust will never be as easy to write as Python, and for scripts like the author mentioned, I'd say that Python is a much better choice than Rust.

Rust is, by design, a systems programming language and it does have complexities and gotchas that arise from the need to have a lot of control of what actually happens at the machine code level. If we had a Sufficiently Smart Compiler(tm), of course, you wouldn't have to worry yourself about those low-level details and just write what your program needs to do and nothing more. However, in the absence of such an ideal, we must accept that a high- level abstraction must always leak in _some_ way in order to let us control its operation more closely to get the performance we need. In my opinion, it's much better that necessary abstraction leakage is made a deliberate part of the API/language and carefully designed to minimize programmer error, and Rust, I think, does a good job of doing exactly that.

That's not to say that the language cannot be made more ergonomic. For one, I think that rules for lifetime elision are a bit too conservative and that the compiler can be made smart enough to deduce more than it currently does. I'm also excited about the ergonomics initiative, and I hope that the core team will deliver on their promises. In general, as someone who's written more lines in C/C++ in my life than any other language, I'm very excited about the language as a whole, as I think it provides the missing link between those languages that are expressive, high-level, and reasonably safe but slow, and those that are fast, low-level, a bit terse, and allow one to shoot oneself in the foot easily.

[1]: [https://crates.io/crates/error-chain](https://crates.io/crates/error- chain)

<comment><USER36> I'd like to see error-chain standardized into the standard library as well. It seems by far the most sensible approach to building Error types.

<comment><USER37> Conversely, I __really hope it doesn 't __. error-chain doesn 't implement `PartialEq` which means that I can no longer write tests for my failure types. I'm a big believer in quick-error instead.

<comment><USER36> There are some good `assert_match` macros that allow you to pattern-match error cases instead.

Might also be possible for error-chain to implement PartialEq if you didn't want some of its generalized error-boxing bits. If that's something you need, you might file an issue.

</comment></comment></comment></comment><comment><USER38> [https://nim-lang.org/docs/parsecfg.html](https://nim- lang.org/docs/parsecfg.html)

(Scroll to the examples.)

An exception would be thrown on error. That exception could be trapped in a simple try/catch block.

Nim is very similar to Python -- but statically typed and compiled (quickly) to machine code. There are many situations where Python is a better choice than Nim, but if you're looking to translate Python code for speed and type- safety, Nim is worth considering.

And if you want to translate Python to Nim gradually, look at this magic:

For calling Nim from Python: * [https://github.com/jboy/nim- pymod](https://github.com/jboy/nim-pymod)

For calling Python from Nim: * [https://github.com/nim- lang/python/tree/master/examples](https://github.com/nim- lang/python/tree/master/examples)

</comment><comment><USER39> The big question is would the Python script crash or handle the error when obvious problems like not valid JSON or file not found happen?

My experience with Swift vs Objective-C is that clean Swift is crash free but more verbose when all other things are equal.

If you don't need that level of security because it's just a small script Python was the right choice.

<comment><USER40> Depending on where it crashed, the Python script would raise an exception. It would most likely be an `IoError`, `KeyError`, or `ValueError`. Then it would show an error message with a line number, column number, and traceback. Using a debugger would allow you to step backwards through the traceback to determine if the error was caused by something further up the line or where the exception was raised.

All of Python's exceptions are an instance of `Exception`. In order to catch and handle any exception that can be raised, you can use a `try, except` block with the base `Exception` class. This, however, is bad practice as there may be some exceptions you want to ignore and, generally, you also want to print a different error message depending on which exception was raised.

<comment><USER39> So the Python script proposed in this article really just skips all error checking and will die just the same as the hard unwrapped Rust version with the only benefit it actually produces a more user-friendly error and it doesn't look as ugly.

I can't edit my reply anymore but the question was actually meant to be rhetorical rather than I really wanted an answer.

<comment><USER40> > So the Python script proposed in this article really just skips all error > checking

Only if the programmer chooses to not handle exceptions, which is bad practice.

>and will die just the same as the hard unwrapped Rust version with the only benefit it actually produces a more user-friendly error and it doesn't look as ugly.

No, it won't die unless the programmer wants it to. In Python you can catch an exception and continue the operation in a different manner. In fact, it is common practice in a lot of Python libraries to use exceptions to determine the presence of data and act according to whether or not the exception occurred. If I'm not mistaken, I believe that this is common practice in most languages that utilize the exception pattern.

> I can't edit my reply anymore but the question was actually meant to be > rhetorical rather than I really wanted an answer.

Well, you seem to not know a lot about exception handling in Python, so I hope I was at least a little helpful.

</comment></comment></comment></comment><comment><USER41> Rust's aversion to exceptions is exactly like Go's aversion to generics - <USER2> strongly held position that doesn't actually make anyone's life easier.

<comment><USER42> I find result types to be much easier to understand and work with than exceptions. Result types can be handled by the type system, even when you have checked exceptions in java, there are still exceptions that aren't checked, and the syntax for the checking becomes monstrous.

<comment><USER43> The anti-pattern I've seen in dysfunctional enterprise development shops (i.e. most of them) is that checked exceptions mean exceptions that "we'll never have" get buried lower in the stack; so code can fail silently and continue running just to avoid the monstrous checking code and propagation of exception type declarations up the call stack.

I don't see how the Rust approach would avoid this fate but I doubt it will ever be used in these contexts to begin with.

<comment><USER42> I think that part of it is that the idea of a Result type being normal will help prevent much of the cruft and burying we see with exceptions. I also feel like handling Result types is more natural than exceptions.

First, you _have_ to do it, even if that means a try! and passing the buck. The syntax for this isn't as monstrous as it is for checked exceptions as well.

Second, it feels more like a natural code-flow, not the break that exceptions provide.

Third, it's useful for more than just "Exceptions". Coupled with Optional types, it provides a more expressive way of not-hapy-path-code where exceptions just feel heavy handed. For instance [https://docs.python.org/3/library/stdtypes.html](https://docs.python.org/3/library/stdtypes.html)

         d[key]

            Return the item of d with key key. Raises a KeyError if key is not in the map.

The key not existing isn't really exceptional. A proper optional, union, or result type handles this case much more easily.

In sum, I think the expressibility of Result and Option, along with a more natural flow for handling them will make working around them less tempting/viable/easy to pass over in a code review.

<comment><USER43> You don't have to convince me of the value of Result types, I prefer them too. I've only written a couple thousands of lines of Rust but tens of thousands of Haskell which rely on the same concepts (though its nicer with do notation). I don't have faith in the masses though and right now there is a strong selection bias in Rust that means only people concerned with quality and correctness are using it in the first place.

I think twenty-five years ago there were similar hopes and dreams for Java checked exceptions.

<comment><USER44> The big problem with Java checked exceptions was that the language was simply not flexible enough in other areas to handle higher-order stuff. For example, quite often you want to define something like "this method takes object X, and throws everything that X.foo() can throw, and also E". But there's no way to express it in Java. So the moment you start doing any sort of HOF-like stuff - even as simple as event handlers - you have to struggle with checked exceptions.

This is not a problem in Rust.

</comment></comment></comment></comment></comment></comment><comment><USER45> The author doesn't really justify why he needed to port the python script to rust in the first place.

Pulling down some JSON, doing a bit of transformation and sending alerts seems like a perfect candidate for a high level language, I don't see any reason why you would port it to Rust unless you had significant performance concerns

<comment><USER17> > The author doesn't really justify why he needed to port the python script to > rust in the first place.

And they don't need to. When I first learned Rust, I tried to write a `filter` function. Why would I ever do that? I could write `filter` much easier in Python, or heck, just use the `filter` method on iterators that is already in the standard library. I did it because I saw it as an opportunity to learn. I wanted to connect something I knew (`filter`) with something I didn't know (Rust).

<comment><USER45> I guess I was getting at the fact that porting the python script that does something very simple is the wrong tool for the job.

A good candidate for trying to learn Rust is to find a script or tool that currently has the problems that Rust claims to fix.

<comment><USER17> When someone comes to me and says, "I just spent the weekend porting a simple Python web crawler that was working just fine to Rust, and I came across problems x, y and z." What do you think an appropriate response is? Should we berate them for "choosing the wrong tool for the job"? Or should we ask them what they're problems were and help them fix them?

I'm not saying we shouldn't have a conversation about which-tools-are- appropriate-when, but when someone is obviously trying to learn, let's put that on the back burner.

</comment></comment></comment></comment><comment><USER46> I don't think it should be as easy and concise as python — it's systems programming language without GC. It is not designed to be used in place of all programming languages, just in place of C and C++.

</comment><comment><USER47> Isn't nim built for pythonists to do just this sort of thing?

<comment><USER48> I think Nim may be the most underdocumented project I've ever used. I spent a week or so with it, but quickly grew extremely frustrated as I was constantly scouring old forum posts to learn how to use the basic features of the language. That is not a tolerable situation for me.

<comment><USER49> I think the idea has great potential, but the absence of a strong community is killing it :(

<comment><USER38> Nah, I've always found quick answers to questions in the forum.

Simplicity is under-rated. With Nim, most problems are easy to grasp just by reading source code. And when I don't understand the docs, I look for a simple example at [http://rosettacode.org/](http://rosettacode.org/)

</comment></comment></comment></comment><comment><USER8> See also previous discussion on /r/rust: [https://www.reddit.com/r/rust/comments/69i105/the_grass_is_a...](https://www.reddit.com/r/rust/comments/69i105/the_grass_is_always_greener_my_struggles_with_rust/)

</comment><comment><USER50> Rust has stressed ergonomics of late, yet I sometimes struggle to read Rust code. Obviously, there is value in elegant code, but my question is, would anybody find value in an extremely simple language that could compete with the likes of c/c++? Does something like this exist?

<comment><USER51> Nim. It lets you get stuff done without having to drink the provably correct kool-aid.

<comment><USER52> GC, though, an a much, much smaller community.

<comment><USER50> googling "GC language" predictably comes up with mostly links to garbage collection. Do you have a link to this language?

<comment><USER53> There's the Nim website[0] as well as the document describing the (soft) real- time GC that Nim comes with[1].

[0] [https://nim-lang.org](https://nim-lang.org) [1] [https://nim- lang.org/docs/gc.html](https://nim-lang.org/docs/gc.html)

<comment><USER50> oops, I was confused - thought the comment was talking about a language named GC, rather than the fact that Nim has GC.

</comment></comment></comment></comment></comment></comment><comment><USER54> It makes me sad to see the example. This is why I maintain `.unwrap()` is one of the worst things in rust.

...because people use it; and then say; 'but don't use unwrap...'; and then use it, and your 'safe' language then happily crashes and burns everytime something goes wrong.

Blogs and documentation are particularly prone to it.

Result and option types are good; but if you're gonna have unwrap, you basically have to have exceptions as well (or some kind of panic recovery), because, people prefer to use it than use the verbose match statement. :/

<comment><USER55> > your 'safe' language then happily crashes and burns everytime something goes > wrong

I'm not sure why you put 'safe' in quotes here; nothing about 'unwrap()' (or even 'panic') is unsafe in the context of Rust. In fact, it acts just like Python would in the same circumstances: print a developer-centric message out and exit with a bad return code.

What's unsafe about that?

> if you're gonna have unwrap, you basically have to have exceptions as well

Why do you think that? unwrap() is meant to be the same as throwing an uncatchable exception; if you want to throw an exception that you mean to catch somewhere, you should be using something else.

> people prefer to use [unwrap()] than use the verbose match statement

People may not be aware (which will come with time) but there are more than just those two choices when it comes to error handling in Rust.

<comment><USER54> I didnt say it was unsafe, I said it crashes.

Unwrap is a shortcut to let you be lazy; it exists for no other reason, and it causes application level crashes in way that is very much easier to avoid in other languages.

That 'catch_unwind' exists is evidence that some kind of panic recovery is necessary... and I wonder how often you hit it from a real panic, vs. a stray lazy unwrap?

Whats your justification for unwrap? I've never seen a meaningful justification for it other than not wanting to handle errors properly.

An application error (returned null) shouldn't abort your application with a hard error, no logs. Its just plain poor practice to use unwrap().

<comment><USER56> > I didnt say it was unsafe, I said it crashes.

Your phrasing implied that you said the crash was not safe, as you put "unsafe" in quotes and contrasted it with the crash. At least, that's what I understood you to be saying too.

<comment><USER54> meh.

I feel like any time someone mentions the word 'safe' regardless of context, the rust safety pedants roll out of the woodwork to dispute to dispute any minute detail of what's been said, regardless of if its relevant to the discussion at hand. I shouldn't have put 'safe' in the comment at all, what a waste of a thread.

My point had nothing to do with safety; it was purely that having given advice being to write good code that doesn't panic, and then having code that shamelessly panics in all your examples is hypocritical.

`?` is a better choice in basically every case; I'm glad to see the documentation will be moving eventually towards using that.

<comment><USER55> In the context of this article and discussion, panics via unwrap (or better, expect) is a fine answer, and I'm not sure why you think it is hypocritical to suggest it, especially to Rust newcomers who are looking to write script-like programs.

Panics mostly match the verbosity, ergonomics, and functionality of the analogous python script.

Now I agree that a caveat should follow advice like using unwrap and expect, perhaps a small blurb about how they should eschewed for better error handling when you want to catch the errors and make decisions because of them (especially when writing libraries) but that's quite a bit short of hypocritical to me.

<comment><USER54> > a caveat should follow advice like using unwrap and expect, perhaps a small > blurb about how they should eschewed for better error handling when you want > to catch the errors and make decisions because of them.

That is literally the definition of hypocrisy; the behavior of people who do things that they tell other people not to do.

"When you do this, do it like this, but properly with error handling." :P

Anyhow, as I said its my oppinion that unwrap() is lazy, and `?`, `expect` and `assert!` cover the same functionality in more explicit and meaningful way.

You're welcome to your own opinion.

<comment><USER55> > That is literally the definition of hypocrisy; the behavior of people who do > things that they tell other people not to do

Except I'm not saying that at all.

I said it's fine to use unwrap() or expect() if you want script-like default behavior (a developer-centric error message and a quick exit with a bad return code) and if you want something more than that, then use something better than unwrap() or expect().

There's no hypocrisy here. I think anyone should follow that advice. Me, you, a newb to Rust, a Rust veteran, anyone. Same advice.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER57> If the goal is [fast, compiled, statically typed], a language like Crystal [1] would probably be a better fit for the author:

        require "yaml"
        config = YAML.parse(File.open("test.yaml"))

[1] [http://crystal-lang.org](http://crystal-lang.org)

<comment><USER58> Does Crystal have YAML.load_file like Ruby does? Loading a YAML file only requires one method call in Ruby.

<comment><USER57> Crystal does async IO underneath, so this approach allows the use of a streaming parser (you're just passing it a file handle, not the contents).

<comment><USER58> Cool, thanks!

</comment></comment></comment></comment><comment><USER59> Would it be theoretically possible to get to this?

        fn gimme_config(some_filename: &str) -> MyConfiguration
        {
           toml::from_file(some_filename).unwrap()
        }

</comment><comment><USER60> This is a staggeringly bad comparison, almost like comparing drawing a line in C# (couple lines) to trying the same thing in C++ (possibly 100+ lines).

</comment><comment><USER61> Why was the title of this post changed?

</comment><comment><USER62> Fortunately, Rust gets so much love from so many that it will thrive without winning over Everyone

</comment><comment><USER63> Rust is important, it has a great chance being a first modern native system language (memory safety).

Though, I wish it has less exotic syntax. It's like C++ and Erlang had a baby. Look at modern languages with nice syntax like Go, Julia, Swift and compare it to Rust. Someone coming from C, C++, C#, Java, PHP and JavaScript has to learn a lot of new syntax twists that look uncommon and different for little reason. Sure some overly complex early syntax ideas like different ones for different pointer types vanished in newer Rust releases. Now it's probably too late to improve the syntax.

<comment><USER64> It continues to puzzle me when people think of Rust's syntax as particularly exotic.

It's much closer to C/Java/JavaScript than e.g. Python or Bash are. Rust still has curly braces for blocks, uses ampersand and asterisk in ways that aren't too far from C, uses dot in a way that's not too far from C or Java and uses less-than and greater-than to denote generics like C++ and Java.

Personally, what keeps tripping me up when moving between languages is either forgetting to put parentheses around "if" conditions in non-Rust languages after writing Rust or having the Rust compiler complain to me about unnecessary parentheses after writing non-Rust code.

But if new languages couldn't do things like omit unnecessary parentheses around the "if" condition or improve readability by moving the return type to come after the function name, that would seem like too big of a restriction on trying to make some syntactic progress.

Edit: Plus it makes sense to have types after the variable name when they are optional in most cases (and then to have them in the same order in function signatures for consistency).

<comment><USER19> > Edit: Plus it makes sense to have types after the variable name when they > are optional in most cases (and then to have them in the same order in > function signatures for consistency).

Since you brought this up, the one thing that really (but irrationally!) winds me up about Rust's syntax is that variables are:

      let foo: Bar = ... ;

And functions are:

      fn foo() -> Bar { ... }

Why not use a colon for the return type of a function as well?

<comment><USER65> "returns" and "is of type" are different concepts, so having different syntax for them makes sense.

\- In your first example, foo is of type "Bar"

\- In your second, foo is of type "function that returns Bar".

ie, if you stored your foos in separate variables they would be:

        let my_var: Bar = ...

vs

        let my_function: fn() -> Bar = ...

If they were to change it to your suggestion the latter would be either awkward (multiple colons?) or inconsistent (different syntax for types and declarations).

</comment></comment></comment></comment><comment><USER66> Hopefully some mechanism to handle exceptional cases at the language level will be invented soon.

</comment><comment><USER67> Use Nim

<comment><USER68> The author was using this as an opportunity to learn Rust so while it might look sort of crazy to use a systems programming language for build failure notification there was a reason behind their decision. Nim is a lovely language but in the author's case he doesn't really care about speed for the use case so if they were being strictly pragmatic they could have just stuck with Python.

<comment><USER67> What!! Just as I was responding another of my hard earned points got deducted

Who are these mean Rustaceans?

Is Nim considered such a threat to Rust?

<comment><USER69> I guess people consider your comment not really helpful. Everyone could come into this thread and write "Use <favorite language here>".

If you'd have provided some good advantages of Nim in this case, or in general added to the discussion at hand, you might have gotten less downvotes.

Maybe you want to stop attacking a community directly, aswell... last time I checked this site wasn't Rustacean only.

</comment></comment></comment></comment><comment><USER67> The author might consider Nim - [https://nim-lang.org/](https://nim- lang.org/). It is a statically-typed compiled language that about equals Rust in performance, but has a much cleaner higher-level Python-flavored syntax, and a very Pythonic parsecfg module in stdlib.

PS. To my earlier downvoters can I have my hard won karma back, please??? This is the response I have been advised to proffer after consulting on the Nim forum, after my earlier terse comment.

<comment><USER70> If you're so concerned of imaginary internet points (a.k.a. hard won karma), I'd advise you to stop talking about that. Complaining about downvotes is one of the few reliable ways in HN to get further downvotes. (I mean, you could say "What? That's bollocks!" and stop caring about votes given by these mindless hordes. Or you could follow the social norm and happily gather sweet internet karma. It's up to you.)</comment></comment>


Show HN: I'm building a IMDB for tech events and tech speakers - <AUTHOR> Eventil [1] is a (yet another) website that lists tech events [2] and their participants: attendees, speakers & organizers [3]. You can filter events by topic [4] & location [5]. You can find events where Call for Papers (CFP) is open [6]. Speakers can list their talks [7] along with slides & video [8]. Users can access this data via a RESTful API [9] as JSON (I'm working on GraphQL implementation). If you're an event organizer, you can create an event page and enable CFP form. You can follow people to see their event activity (as attendee, speaker or organizer) as weekly email.
It's a side-project. I've been working on it almost 2 years. In my spare time I organize various tech events myself. I'm most proud of PolyConf [10]. I've created Eventil to solve my own problems with tech event organization. There are many organizer features that help me be more efficient. My focus is on speaker profiles. I'd like to help fellow organizers out to find interesting speakers. I'd like to also help tech speakers easily find related events.
A business model is being built around my insider knowledge. It could result in consulting projects through the platform. This is already the case to some extend. Eventually it could be automated.
The project is in alpha stage. There are bugs, but there's also a consistent cycle of weekly iterations. Please bear with me. I usually fix everything quickly. I'd be happy to have your feedback. You can also submit issues via GitHub [11]
[1]: https://eventil.com/ [2]: https://eventil.com/events [3]: https://eventil.com/users [4]: https://eventil.com/events?q%5Bwith_topics%5D%5B%5D=JavaScri... [5]: https://eventil.com/events?q%5Bwhere_scope%5D=London [6]: https://eventil.com/events?q%5Bcfp_open%5D=cfp_is_open [7]: https://eventil.com/users/eryno [8]: https://eventil.com/presentations/bL1sJe [9]: https://eventil.com/docs/api [10]: https://www.youtube.com/watch?v=8aYSKeAvvu8 [11]: https://github.com/eventil/eventil.com/issues <comment><USER2> I don't see enough signaling that I'll get anything of value for clicking on your "pill button" and giving my contact info. I more than half-expect to get spammed frequently about talks in places where I don't live (London) or about topics I don't care about (JavaScript).

<comment><AUTHOR> Thanks for your feedback! The phrasing is not yet perfect, indeed. I'll work on it. Regarding spam, you must explicitly opt-in (in Settings) to have those emails being sent to you. ;)

</comment></comment><comment><USER3> So, looking at the list of cities, it's hard to find anything since they are not sorted.

Also, they don't seem to recognize that Montreal is the same as Montrèal. Or Brussels is the same as Brussel, and also the same as Bruxelles.

I haven't looked any further.

</comment><comment><USER4> Could be a great alternative to Lanyrd. I feel like Lanyrd abandoned and there are a lot of spammy content now.

@zaiste I created [https://techevents.co/](https://techevents.co/) \- an aggregator for tech events and will be launching it next week. I would like to integrate it with eventil.com once it finished. Are you planning to have some basic public API?

<comment><AUTHOR> Yes, I totally agree. TechEvents looks great. An API for reading the data from Eventil you mean?

<comment><USER4> Yes, basic API to get events list(name, description, start_date, url, etc..).

Now I aggregate tech events from Meetup, Eventbrite, Lanyrd, Facebook. This helps people to look events in one place instead of browsing all websites separately. And once the user clicked on the event I am forwarding him directly to original website/content. I would like to integrate to Eventil too once it will have more content. Of course, if you would like that?

</comment></comment></comment><comment><USER5> That's great. Looks like a good alternative to [http://lanyrd.com/](http://lanyrd.com/) Lanyrd got acquired by eventbrite and is stagnating. Last week the site was down for a half a day.

</comment><comment><USER6> I can verify that finding good tech talks amongst all the noise is a pain point!

Question is, if you can actually solve it :)</comment>


Show HN: vim-easyclip - <AUTHOR> https://github.com/svermeulen/vim-easyclip

<comment><USER2> Seriously? Mark's not important?

... aside from that, interesting!

<comment><AUTHOR> Yes, that might have been a poor choice of words. Marks obviously have their place. In my case though I tend to use it much less than the other keys so was an obvious choice for remapping. YMMV however, and the plugin is written in a way that allows you to easily use whatever keys you want instead.</comment></comment>


How I killed app sales by going freemium - <AUTHOR> https://medium.com/@shuveb/how-i-killed-app-sales-by-going-freemium-31c04c60d2f2 <comment><USER2> I think part of the problem with freemium is that it changes your perception of where the value lies. The user discounts the value of the free component to nothing and only measures the value of the additional functionality that is unlocked with buying the premium portion. A lot of the time, this looks like a ripoff.

The developer on the other hand tends to look at the value of the whole application and prices the premium portion in consideration of this.

I'm not sure that I have a solution, except to say that the developer might be more succesful to discount the value of the free portion to nothing as well and only price the premium portion at a rate that considers the actual value that it adds to the user experience. I think you have to consider the free portion as a marketing expense.

<comment><USER3> Yup. And the problem now is if its not free, your product is not going to get ANY users. I really hope, everyone starts rolling back on freemium, because its hurting everyone (except customers).

<comment><USER4> I would argue that it hurts customers too, at least for some apps. If a developer doesn't get constant revenue there'd be little incentive or resources to update and maintain the app.

The customers are then stuck with an app that might have been good but decays over time.

<comment><USER5> Until the next cool freemium app in that space comes out, then the customer just switches to that one.

The real problem is that we just don't need 80 gazillion apps. The "app" market is extremely competitive, that's really what people are complaining about, profits have been driven down to basically nothing. Normally you would expect some developers to drop out of the market, which would help the situation, but two things are stopping that from happening, in my opinion.

First, the platform companies (Apple and Google) have been incredibly successful at promoting app development as a gold mine. For every developer who gets sick of it and moves on to something else, two people become "app developers".

Second, there's a startup bubble and the wisdom out there says you need an app or your startup is nothing. This partly relates to the first point, the hype around "apps", even years after Apple launched the app store, is deafening.

<comment><USER6> App stores should try charging people $100/year after the first year an app is in the store.

Or the reverse, pay $100 to pull your app from the store after its first year.

<comment><USER7> I believe Apple does do this - it's $99/year to become an Apple Developer, and I think you need to be an Apple Developer to have an app in the app store.

<comment><USER8> It is $99/year to have apps in the App Store, but it is per developer account and not per app.

I almost think devs would be better off if it was per app. At least any devs planning to make a living off the store. It would cut down on a lot of the crappy spammy apps out there.

<comment><USER9> It would also kill the one-off hobby stuff with which many, especially teens, get their taste for (app) development, which would be a high price to pay. Without a secondary path to distribute apps I think it would be a bad idea.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> I don't think this is a fair comparison. You changed the business model from v1 to v2, by moving from a one time payment for unlimited articles to a pay- per-article approach.

A more suitable change would be to offer the app for free, with 10 free articles and 1 per day, and offer a one time purchase of 1.99 to lift the limits entirely, turning it into the equivalent of v1.

The way you did it is you changed it so that the act of sending an article cost money, instead of paying a small one time fee and sending as many articles as you wanted.

<comment><USER11> As a user I wouldn't understand why each article costs money, therefore I would feel ripped off.

<comment><USER12> Based on the article, I understand exactly why it costs money - he has to pay for the server that does the hard work.

That said, as a developer I don't understand why the server is involved at all. Here's the relevant part of the article:

> The server would then fetch the article, format it, package it into a .mobi > file the Kindle can deal with and send it to Amazon for delivery to the > device.

I understand all this, I really do. What I don't understand is why the computer that I'm holding in my hand when I ask for the article to be converted, which is probably as powerful as the $20/mo Linode instance, can't do this conversion itself.

Surely it can fetch the article, convert it, and pop up an Email sheet with the attachment ready to go and the "to" address filled in. All it would require is for me to tap the Send button and it would get emailed to my Kindle without having the developer's server involved. This way if the developer decides to discontinue the app and take down the server everyone who purchased it isn't left out in the cold.

<comment><USER11> A server easily handling hundreds of thousands of requests per day would cost only $10 per month. And if you want to link the app price to server costs, a monthly subscription would make more sense.

<comment><USER12> True, though having the conversion logic built into the app would require no server (costing $0 per month) and scale up to billions of installs without any effort on the developer's part.

</comment></comment></comment></comment></comment><comment><USER13> Your app is too niche for a freemium model. You Said yourself that the app solves a very specific problem and it's the only app in the store that solves that problem. I would suggest you switch back to up front payment but jack up the price to the 5-10 dollar range.

I've seen my revenue triple when switching from 3.99 to 9.99 for a very niche app that was almost without competition. And that was on Android where people are even less likely to pay.

<comment><USER14> This was my analysis as well, although we both have the benefit of hindsight, and everything is obvious once you know the answer. But it looks to me like the following models are likely optimal:

1) App that solves a trivial problem, no viral potential, lots of competition: free (or don't do it at all). Apps that fall into this category are things like distance measurement, to-do lists, etc.

2) App that has viral potential but lots of competition: freemium (games fall into this category)

3) Niche app that solves a hard problem for a small number of users: paid, with the price as high as possible.

There is a fourth category, but it's illusory: app that solves a hard prolbem for many users and has viral potential. If you're an individual dev, the odds are in those areas you'll be facing competition from players with much deeper pockets who are often giving apps away free to drive their core business.

This person's experience tends to validate this general analysis.

</comment></comment><comment><USER15> If you want to experiment with letting people try the app for free, you might want to consider just using a single permanent IAP purchase of some higher- than-$1.99 value (say, $4.99 or $9.99) that unlocks unlimited articles. Without this purchase, you could limit them to something like 20 or 50 articles. Enough for them to get a feel for what the app is doing and decide that it's worthwhile. The idea being that anyone that does send enough articles to hit the limit would likely have decided it's useful enough to be willing to pay the higher cost (which they may not have been willing to pay upfront if you simply charged that much).

Or you could just go back to your original price, since that was working out. It's hard to say which would do better.

<comment><USER16> Exactly what I was thinking. "Credits" feel like a huge ripoff.

<comment><USER17> The credits makes people think 'Is this article worth sending to my kindle? It costs money to do so. Maybe I should just read it?', that adds loads of friction and poor UX.

But the OP was experimenting, so I guess that's all good :)

</comment></comment></comment><comment><USER18> Previously the user paid 1.99$ for unlimited use, forever. Now you nickle and dime users, forcing them to think about credits, what the value of the service really is, etc.

<comment><USER19> This got me thinking about something.

What's to stop an unscrupulous developer selling an app for, say, $1.99 with the (implied) promise that the app will work forever and then, once people have bought it, turning off the backend so it no longer works?

Is this illegal? Would Apple shut down the developer's account?

<comment><USER20> I think it would depend on the jurisdiction, and the "degree" of "implied promise". Eg. in Norway there's pretty strong protection for (private) buyers. On the other hand, proving fraud in the case of the company behind the app simply declaring bankruptcy/shutting down would probably be pretty difficult.

I suppose a relevant study would be Microsoft Zune/music store, and/or Yahoo(?) Music that shut down and killed the DRM servers, effectively removing music people had "bought"?

<comment><USER21> I'm not sure why Zune keeps coming up as an example in these threads. It got rebranded to Xbox Music, but all the servers are still up and anyone who subscribed still has all their music.

An earlier Microsoft DRM that was used by a bunch of services (PlaysForSure) was indeed shut down, but it's not the same thing as Zune.

<comment><USER20> Oh, I was thinking of the earlier one. I suppose it's often conflated with Zune, because of the spectacular flop of the Zune devices/rebranding thing.

</comment></comment></comment></comment></comment><comment><USER22> I don't view freemium as a business model, I view it as a distribution model. The distribution model changed from paid to free. This usually results in a user base that grows faster but pays less. By making the app free you've set an expectation of not having to pay. This attracts a certain type of customer, which are usually much harder to convert. If you're trying to build traction for investors this might not matter. If you are trying to monetize then this does matter.

The business model changed from a one time purchase model to a micro payment model. My recommendation would be to try a monthly payment model for v3. Let the users pay to access the service (setting an expectation to pay for value) but allow them to pay less than what you perceive to be the cost barrier (the amount you believe is the maximum amount they would pay to give it a try). I'm going to agree with others that you are priced too low. One of the best lessons I've learned is that it's not what you think it's worth, it's what your customer thinks it's worth.

</comment><comment><USER23> I noticed a key metric was missing from your article. What was the average number of transfers per day per user with the original version? The explanation for the drop in sales could be as simple as most of the existing users were doing 1-2 per day...

</comment><comment><USER24> After averaging $5.00/day for a year with my iOS app using a freemium model ($1.99 in-app purchase), I decided to switch to a paid upfront model just to test. It resulted in a sustained average of $25/day. That's a big deal to me and so counter to everything I read about freemium being the only way to go in today's mobile market.

<comment> tuna-piano Out of curiosity, what is your app? I'm interested in seeing what kind of app that would happen to.

</comment></comment><comment><USER25> How I killed app sales by switching to metered pricing

<comment><USER26> Which is more-or-less exactly the same as saying "freemium", 99% of the time.

<comment><USER27> Not really. Many apps have a one-off "premium features" IAP. Certainly more than 1%.

</comment></comment></comment><comment><USER28> FWIW a while ago I decided to publish a free + IAP version of my iOS photo/video effects app, which was previously a paid-only app. At first the results were a bit disappointing but over time it's grown to generate about three times the revenue of the paid app, and about 20 times the overall user base. I'm sure it's true that freemium is not a panacea but it's worked for me.

[http://plastaq.com/liquidlens/](http://plastaq.com/liquidlens/)

<comment><USER29> Hey, this is off-topic, but I'm working on an app that's in the same market as yours. (MIDI-based DAW-ish thing with an emphasis on ease-of-use. I don't think my app would be competing with any of yours.) If you're willing to share your thoughts, how easy was it get the number of users for, say, Sythe as it has now? Did you do any marketing? Was the relatively high price point ever a problem? Are you considering freemium for that one, too?

I was hoping that I could mostly wing it and just make a nice video and send out some review copies to people who might be interested. The music app market seems small enough where this might be possible. But this is just me guessing, and it would be great to hear from someone who's actually had some success in the space.

Anyway, loving your design aesthetic! Will give Sythe a download as soon as I charge up my phone.

(And, obviously, if this is information you're not willing to share, then no hard feelings! Just thought I'd ask.)

<comment><USER28> To be honest, Scythe was a huge amount of work and brings in about half of the revenue of my photo effects app, which took about 1/10th of the time to write. Knowing what I know now I would never write another iPad app again, and I'm not sure I'd write another serious music app. If I do decide to write any more music software I'll target the VST plugin market, where people are still willing to pay $99+ for a good instrument. It's a shame because I think the iPad has tremendous potential as a platform for music making but it seems like the volume just isn't there to make up for the low price points users expect for iOS apps.

One thing I would do differently if I started from scratch on Scythe today though is make the base app free and make up the difference with IAP preset packs and additional features.

<comment><USER29> Thank you for your insight! It's too bad Scythe isn't as lucrative as you hoped... seems like it's hard to get serious software noticed in the App Store over free, bite-sized entertainment apps. Incidentally, my app is targeting the iPad as well, but I don't really mind the business reprecussions: I'm writing it for my own personal use above all else, and I wanted to give my trusty old iPad 3 something useful to do instead of just serving as a very expensive web browser. I was thinking of going Lite/Pro, but perhaps freemium might be better after all; I just really don't philosophically like the idea of charging for individual features, especailly when they're part of the MIDI standard already. (But that's just business, I guess.)

There's been a lot of talk recently about the iPad languishing, and it seems that Apple is taking notice. Would not surprise me if they made more of a marketing push towards promoting iPad apps in the coming years, especially with the possible arrival of the iPad Pro.[1][2]

Crazy that the VST market can be so lucrative! It makes me happy that some people are still willing to pay a fair price for their "workhorse" software.

[1]: [http://www.macrumors.com/2015/02/08/apple-ipad- grammys/](http://www.macrumors.com/2015/02/08/apple-ipad-grammys/)

[2]: [http://www.macrumors.com/2014/12/31/apple-expands-start- some...](http://www.macrumors.com/2014/12/31/apple-expands-start-something- new-campaign/)

<comment><USER28> The VST market isn't really lucrative. I have it on good authority that most plugins sell at most 200 copies. Music software is also very challenging to write because it combines multi-threading with soft-realtime requirements. So any programmer good enough to write non-trivial music software can easily make more money with fewer headaches writing almost any other kind of app. So I'd say the only good reason to write music software really is just for the enjoyment of doing it.

As for myself, as much as I enjoy writing music software I enjoy making music more and it seems like I only really have the mental energy for one or the other.

</comment></comment></comment></comment></comment><comment><USER30> As someone who would like this sort of app there's no way in a month of Sundays I'd be willing to pay for each article after the first

This sort of thing is a one off purchase (if my device does the work) or fixed monthly fee (if your servers do the work)

<comment><USER31> This seems more fair. But it is weird, because thinking about it, isn't buying N units of work the most fair pricing scheme? I didn't have the same gut reaction to Amazon's Lambda service.

Perhaps it is that we know the article limit isn't related to any real-world costs that make the difference.

<comment><USER30> It's fair but the worry comes in with what happens if I run out of units of work and send a new article. Does it reject the article and I miss out? Does it charge as and when I send an article[1]? Do I get charged extra for unexpected usage?

If I have to ponder any one of these questions I'd just switch to a different app, there's a fair few that provide this functionality

[1] In this case the main worry is what if I accidentally somehow send every tab I have open to this service through a bug or something? Do I pay or does the app maker take one for the team?

</comment></comment></comment><comment><USER32> Great article and I love the experiment, but as the author himself points out this isn't apples to apples.

What you really want to see is a freemium version where you get:

1\. 3 _total_ articles for free 2\. A 1.99 in-app purchase that gives you infinitely more articles.

The current free limits are high enough to support the majority of casual readers.

</comment><comment><USER33> I have never read up on app business models but intuitively I'd say in app purchases create unneeded extra friction. Additionally if you pay up front you have a sense of ownership.

My guess is that I'd only use freemium when network effects matter. The app described in the article doesn't rely on network effects at all but it's nice to see my gut instinct corroborated experimentally.

I'd be interested in seeing this repeated for Android because I'd suspect iOS users are generally more likely to buy stuff.

</comment><comment><USER34> This comes up in advertising all the time - you can increase how many impressions an ad gets easily by just showing it more but the conversion rate depends entirely on the kind of user, match between user & ad than anything else.

In this case, the people who paid for the app self-selected themselves by the act of paying, but the barrier to install the free version is much lower than that.

<comment><USER2> I agree, it's a really complex interaction.

You have to consider: 1\. The number of users that would never pay for your app, but are happy to download it for free. 2\. The number of users that would never pay for your app without trying the free part first. 3\. The number of users that would pay for your app without trying it for free.

You then have to consider the amount of revenue you lose from Type 3 to support Types 1 and 2. Hopefully you come out ahead, but you may not.

</comment></comment><comment><USER35> Are there any good examples of successful Freemium apps that sell additional functionality (rather than games or consumables like the article)? The only major examples that come to mind to me are photo apps that sell filter packs. Are there any apps that lock down their major functionality as demoware or upgrades? (like say, "add iCloud support for $2")

<comment><USER36> Maybe an abberration but Cyanogenmod's ClockworkMod comes to mind. They provide it for free but the auto updates are paywalled.

</comment></comment><comment><USER37> I can only guess it's because he was faaar too generous with the credits. One article per day? I send maybe one-two per week. Maybe a better solution would be to give each user 5 credits total, and then they would have to pay to keep sending articles(I would do it as an unlock thing, rather than selling them more credits though).

<comment><USER38> yeah... definitely. Cut back on the free offering, and make it "pay to use" for anyone who ends up using it anything resembling daily.

Also probably worth making it a subscription ($1/month?) instead of credit- based - subscriptions can give dependable revenue, and users wouldn't feel nickle'd and dime'd.

Anyhow, the simple lesson here is that freemium isn't a magic bullet - probably takes some time to figure out the right place to put the paywall to get growth / usage via free users, and revenue from not giving everything away for free.

</comment></comment><comment><USER4> I'm launching an app in a couple of weeks and I'm really worried about the revenue model. It's an app that acts to an client to an other service and they'll probably start charging for the API in the near future.

I felt like I had a few choices seeing as I'm foolishly doing this full time and need some kind of revenue:

1) Free + Ads

2) Free + Freemium for "pro-features"

3) One-time fee

4) Subscription fee

I have a distaste for ads so I really didn't want to go down that road.

I don't like freemium because looking at "pro features" and valuing them based on them alone it seldom seems worth it. Also keeping useful features away from non-paying customers seems lose-lose.

I could go with a one time fee but then I won't be able to support it over time and the API fee's will eat away any revenue, no matter how small, over time.

So I've decided to launch with a subscription yearly fee (through a in-app purchase). From all examples I've seen of changing revenue model to subscription model _after_ you've launched it seems almost impossible without the mob getting out their pitchforks. It also seems more honest to have the subscription carry over than launching a separate new app that you have to buy for future OS versions.

Still, mentally users aren't really used to paying subscriptions for an app so it remains to be seen if its successful. Also since most people don't pay for this service itself already there's another mental barrier.

Actually if the app wasn't dependent on a service I'd rather see you'd own the app and subscribe to updates, it seems like a much better model since you never lose "ownership" even if you don't pay, but unfortunately app stores don't support that model.

I think my app is better than the competitors but will people choose a competitor because of the subscription model? It will be interesting to see.

<comment><USER39> Funnily enough, I am just on the opposite side.

I've a free API that allows people to build clients for mobile apps (some are free, some are one time fee, etc) and the costs of running this free API are starting to worry me.

<comment><USER40> I ran a free system and while it is small it easy but as soon as you get tens of thousands of users you are on the hook for all of the background costs while your userbase grows exponentially because they are so happy. Better to have 10 customers then 10,000 free users. I was never able to get free people to pay anything. I bragged about my free users and I felt self-important while taking away my ability to use my time more wisely.

<comment><USER41> I've noticed online services which probably cost a few cents per user to run seem to either charge $0 or something like $10/month which works out quite a lot. I wonder if there is a gap for charging say 3x actual costs which might be say $5/year or $10 for 5 years or some such?

</comment></comment></comment></comment><comment><USER42> 1.0 is rewarding use and 2.0 is addig friction to use. For this app to demonstrate value you should be able to freely use. The "buy credits" to do this niche action feels like is not worth.

I will risk to say that there is a Cognitive Load inbalance. Fremium induces people to track the economics behind the usage of the freemium app. If the problem it solves is less painful than the Cognitive Load of tracking its fremiumnality, then why bother?

It would be interesting to do tests about models without "risking the 1.0s"

</comment><comment><USER43> Would love some insight and helpful advice on sales.

We have a product that is ready for paying customers and we have a landing page (only) that is to collect sign ups. We get 100 sign ups a week & up to 15% of those express interest in being customers, but once we get to talking ... after a few emails these talks taper off and even a follow up email leads nowhere.

We have had talks with small parties no one has heard to huge Fortune 50 to 500 companies (this week a VP from Lowes started talks, previous Black & Decker, Motorola, Samsung, Beats, etc).

It seems most people want to use our unique WEB technology for free, though once we put it on the web these potential customers may just show their true motives of wanting to know how we accomplished X and copy it.

Thus, I've been thinking of doing a freemium model myself where users can use part of the product that is not our secret sauce yet have to pay X amount of money to add our secret sauce into the product for their specified use.

What do you think is a better sales channel then we have it now and or does my next sales channel idea sound solid?

</comment><comment><USER44> Freemium is almost always a scam, remarkably for games where it degenerates into "pay-to-win". As a parent of two young tablet users, I'll happily pay a decent price for any game they want, but I won't allow them to spend even a single cent in in-game crap.

<comment><USER45> It's kind of scary the number of games aimed at children that have IAPs of £69, and parents sometimes don't know enough to prevent their children spending hundreds of pounds on IAPs.

[http://www.theguardian.com/technology/appsblog/2013/mar/13/s...](http://www.theguardian.com/technology/appsblog/2013/mar/13/stop- children-spending-money-in-ipad-games)

<comment><USER44> I wish we'd crack down on this kind of abuse, but it's an arms race, and at some point hard to distinguish objectively. There's no solution without some parental responsibility... many parents are just too lazy, the hand a device to their kids and hope for the best. Parenting takes some effort; my children's devices have parental control apps (I use and recommend ScreenTime), as for purchases of any kind they have to ask me to put my password every single time because I don't check the "remember" checkbox, it's not terribly hard.

</comment></comment></comment><comment><USER46> Freemium allows you to have more users and more chances to sell.

With a paid app, the same users would have to make a decision to buy based on just a picture, description and reviews.

Many freemium apps work really well by selling in-app currency. The most effective ones, sadly, were games that made it increasingly difficult to progress without spending said currency, making people addicted and choosing to spend money instead of time, which they valued more after a certain point.

Angry Birds found out two years ago just how much freemium beats the pants off them.

Look up pricing tricks online. One is when people see a too-low price that looks out of place next to the others. They think they caught a good opportunity.

</comment><comment><USER47> Freemium could potentially work here with better calibration. I suspect some of the things that might be important for you users:

1) Unlimited usage or unlimited usage per month -> Managing credits is an annoying experience for when I just want to share an article: I'll have faster ways if the actual transaction is a hassle. Paying once and forgetting about it adds a lot of value. This could work with your original paid model or with a freemium model that includes an unlimited tier.

2) Better analytics to calibrate the use cases: How many articles were people using. Did you have a way to detect how many of the articles were actually being read? I suspect that 1/day might be a very high free tier if people are switching to a mindset of: is this worth being my 1 article a day? Or converting the cost of a paid article and asking "do I want to pay X for sharing this to my kindle?"

Other have made the point that a key aspect of freemium is viral growth. Do you have any social sharing features that people would want to use -> Could you share an article to Kindle and/or Facebook + Twitter? Could you get shares of your app in exchange for additional article shares to kindle?

If freemium was the right model it might end up at something like:

10 Initial Free shares 1 share/week free 3 shares/week free to device if also shared to a social network A Paid credits/usage tier A Paid Unlimited/time tier (monthly or weekly unlimited use pricing?) And Possibly a paid outright unlimited tier.

You'd want to measure and track analytics on how you get users. Something like web bounce links through your own analytics package on the way to the app store.

Here you actually have an interesting tradeoff: You get less money per user which you hope to balance out by driving down CAC through large amounts of organic growth.

The purpose of freemium is seldom a try before you buy value proposition that makes sense for the company, it's the ability to generate viral growth even out of users who never spend money. If the app won't get substantial viral growth then freemium is almost always wrong.

</comment><comment><USER48> I think the biggest issue is you switched to using credits. That and you've only let this play out for 20 days. People can take quite a while to evaluate an app and decide to purchase. You have more experimenting to do. A one-time upgrade fee for unlimited or a yearly subscription seem like a better fit for how a user would expect to pay for this type of app than credits. At the very least perhaps add an "expensive" unlimited use option and I bet you get some purchases of that.

</comment><comment><USER49> Products with ongoing pricing turn out very expensive in the end. A product that is $10/month will often workout more than one that it is $100 upfront. I prefer iOS apps that you either pay or upfront or, even better, a one-time fee to upgrade. I don't have to worry about ongoing costs then. I'm reminded of ongoing costs everytime I get a statement or receipt, and then I look for alternatives or look to cancel.

</comment><comment><USER50> Fremium only works with high retention apps. The goal with a high retention app is growth, not revenue. You want people to use it a lot, tell their friends and they use it a lot. If you can hit 4%+ week-over-week growth then this is a good candidate for fermium.

Anything that has low retention should be charging up front.

</comment><comment><USER51> This bit really hits the nail on the head, "One thing freemium compensates for is the lack of a free trial system in the App Store."

There is no reason the app store should not allow developers to offer free trials. This is the one thing that Microsoft got right with the failed Windows phone.

<comment><USER8> IAP does pretty much the same thing. I understand we wanted trials 6 years ago, but I personally feel like this is a solved problem.

</comment></comment><comment><USER52> If people have a specific problem, and your app solves that problem, you don't need a trial. Just tell people in the description that you solve their problem, and they will buy it.

Free trials are only necessary when you want to sell solutions to problems that people don't know they have.

</comment><comment><USER53> It'd be interesting to see what the retention numbers were like for those initial v1 users, and how many people use the free version on an ongoing basis. It could be that people stop usin the app after the first week or so anyways.

</comment><comment><USER54> Freemium isn't the only option to allow people try the app before buying it. There are free trials that allows to use the app for several days and then asking to pay the full price to continue using it.

<comment><USER55> I think Apple would likely reject such a design as being a "demo" version, which is explicitly forbidden--unfortunately.

<comment><USER56> Has apple ever given a reason why they dont allow demo/trial apps?

A time limited trial seems like the perfect fit for productivity apps, not sure entertainment based apps would want this model. You have a day/week/month to use the app in its entirety, if after the trial you value the product you purchase it, otherwise it no longer works.

<comment><USER27> I don't think they ever gave a reason. Personally I like how it has forced developers to come up with more creative product offerings than time limited demos. While convenient for developers, time limited demos suck as a user experience IMO. The whole "trial expired! buy now!" experience is very grating.

<comment><USER31> I am fairly certain the "trial expired" experience is exactly the reason. They're also trying to make a commodity out of software and having an app store half full of trial versions doesn't help them with that goal.

</comment></comment></comment></comment></comment><comment><USER57> Penis

</comment><comment><USER57> Penis.

</comment><comment><USER58> The startup world has pretty much destroyed future chances of making a living from an application. Sure, the top 10 apps in the apple store might be making good money, but most apps that charge $1.99 will most likely not pay a living wage to the people that created it.

The same thing happened to the music industry. The total amount of revenue has dropped 10 fold since 1999. I know a few independent artists and they can't really make a living on just music anymore. They need to sell t-shirts or have a day job. So in the end, free music and file sharing has decreased the overall cost of music, but it really only hurt the small and independent artists.

Even look at things like Spotify. 1,000,000 plays nets an artists something like $100.

It has forced many artists to go with large labels because the large labels will take all of the risk and actually pay them some sort of a living while they are touring.

Software is going the same way. With all of the open source out there (and more coming out every day), it has allowed companies to hire software mechanics for pennies instead of software engineers for a living wage. Why? Because all of the parts that need to be engineered are given out for free. Development now in most businesses is mashing frameworks and libraries together. It really doesn't take a computer science education to get the job done.

Business owners are also becoming more tech savvy as the older generation retires.

I've never seen so many smart communities of people put themselves out of a job so quickly.

To me, apps are just an interfaces to a paid service, not the actual service itself. So, I might have a service that you pay X amount of money to use and the app is something free that is thrown in as a benefit.

<comment><USER59> Totally agree with your comments about the music industry, however I don't think the same applies to software development.

If many businesses can now get by with "mashing frameworks and libraries together" then that is a good thing - it means problems have been solved in a repeatable way that many people can benefit from, and the real software engineers, rather than doing the same old work over again can refocus on new challenges and create the frameworks and libraries of tomorrow.

Is that really a bad thing? The only people putting themselves out of a job are people trying to earn a living working on problems that were solved a long time ago.

Suggesting there are fewer jobs now for software engineers than any time in the past is a bit of a stretch!</comment></comment>


Facebook TOS Change: All Your Stuff is Ours, Even if You Quit - <AUTHOR> http://mashable.com/2009/02/16/facebook-tos-privacy/

<comment><USER2> Are people really worried about this? The only reason this is in the TOS is so they have the right to keep running their data mining algorithms even after you delete your account, in case they find a new way to leverage your data. It's not like they're going to start selling a poetry anthology of your stuff or something.

<comment> Tuna-Fish The problem isn't that facebook is gonna use your stuff - it would be too much of a pr shitstorm for them.

The problem is that facebook is still bleeding money. Once they go belly-up, all their assets will be sold to the highest bidder, and the world largest collection of stock photos will likely be among the most valuable of them.

I have serious problems with "irrevocable, perpetual, non-exclusive, transferable, fully paid, worldwide license (with the right to sublicense)".

<comment><USER3> Uhh, dude, have a browse around the Corbis website. Then have a look around Facebook. The idea that Facebook has any value as a library of stock photos is frankly _laughable_.

<comment><USER4> The danger in using Facebook for stock photo's is an uploadeder who did not own copyright on the photo.

Facebook can't really sell the content unless they can prove the person who uploaded it had the writes to distribute it. Which you can't do in an automated fashion.

</comment></comment></comment></comment><comment><USER5> Mark Zuckerberg's blog post on the TOS change: <http://blog.facebook.com/blog.php?post=54434097130>

</comment><comment><USER6> Yuck. I had heard previously about how difficult it is to _completely_ remove yourself from FB, but this getting unreasonable.

Also I have an issue with the article:

> Someone can still take your photo, slap it on Facebook, and now neither you > nor the author of the photo can stop Facebook from using the photo in > whichever way they please.

I doubt that that's the case. If someone takes something to which I have a copyright and then places it on Facebook without my approval, I would think I have legal recourse. Isn't this what a DMCA takedown notice is for? Unless I'm misreading that quote.

<comment><USER7> No you're absolutely correct. If someone takes your photo (I read about this for a childrens entertainer and someone duped her account) facebook will disable the persons account and likely depending on the situation may take extra steps (I believe in the case I'm thinking of, Facebook gave a list of the IP's and times the user had accessed the duplicate account from to the police in case they believed it was potentially criminal due to the nature of the womans job and the likely hood of the dupe being made by a pedophile).

Facebooks ToS explicitly state that they respect the IP rights of others and that they will remove any infringing content, or for repeat offenders their account will permanently be suspended (presumably their email will be banned too). It also says they do everything in accordance with the DMCA. The one thing people don't understand about the DMCA is that whilst it might be evil, it also protects individuals as much as companies because every single photo, sentence or anything you or I make or write are immediately copy protected in all western countries.

<comment><USER8> >> It also says they do everything in accordance with the DMCA. The one thing people don't understand about the DMCA is that whilst it might be evil, it also protects individuals as much as companies because every single photo, sentence or anything you or I make or write are immediately copy protected in all western countries.

1\. Warning: Wrong conflation detected. DMCA != copyright

2\. Warning: Wrong conflation detected. copyright != "copy protected" (copyleft = copyright, copyleft = "copy invited")

3\. DMCA is neither universal nor universal to western countries. It's actually no universal to anything. Just an internal USA law.

</comment></comment></comment><comment><USER9> Upon reviewing the Facebook ToS as posted today,

<http://www.facebook.com/home.php#/terms.php>

I see it continues to include the phrase "subject only to your privacy settings" as Facebook asserts what it can do with your content. Now I wonder if that is as much of a problem as Facebook asserting it will not respect your privacy settings at all (which would be very worrisome indeed).

I see my reply below asking about this was read for the literal meaning of the too-brief words, rather than for my intended implication. My bad, for not being more clear. What I was trying to introduce to the learned discussion here is the idea that Facebook says, even after its revision to its ToS, that it will respect your privacy settings. So, if you have used the Facebook features to set your privacy setting so that only friends, or only a subset of friends, see most of your submitted content (as I did immediately upon signing up for Facebook), is this ToS change really that much of a worry? If you know how to set your Facebook privacy settings, and like the effect of those settings, the only people who have access to your submitted content are the same people to whom you have already shown it, right?

</comment><comment><USER10> Is this what happens when you have no business model?

<comment><USER11> They certainly have a business model. Advertising. Problem is, they haven't accepted who their paying customers really are: Advertisers.

<comment><USER12> Monetizing Facebook's Feed is tricky business.

"Your best friend just got dumped by his cheating finance...brought to you by Carl's Jr." will not go over as well as Carl's Jr. intended.

But it is pretty interesting how they microtarget ads. I've seen my staunch republican friend login to facebook. She gets ads like "Do you feel the election was stolen? Voice your thoughts here."

Where as I get ads indie rock music sites and student loan "bail outs".

</comment></comment></comment><comment><USER13> The timing of this article is ironic for me, since I just had a big argument with a friend about why I like Facebook less and less...

There's one thing about this that confuses me: with a change like this to the ToS, why didn't they alert me and make me confirm that I agree with the new terms?

<comment><USER14> Simple, because the old TOS said they didn't have to. And why would they? "Hey we just changed our TOS to take even more control over your stuff, are you still okay with that? Yes/No"

And if you're using Facebook now, you should be okay with the change because it's not like much has actually changed with regard to how FB is going to use/sell your data.

<comment><USER15> One TOS to rule them all : "We can change this TOS anytime and your agreement to this TOS implies agreement to _any_ changes made to it"

No need to have anything more in it.

<comment> Tuna-Fish Not legal in Europe.

<comment><USER8> Care to cite some european law about that? If true, I thing the GPL would also be illegal. I don't think that's the case.

</comment></comment></comment></comment></comment><comment><USER16> I recently set up Facebook Connect on my poetry editor web app. When a user writes or updates a poem, they can have a link published in their news feed. Being very far from a lawyer, can anyone tell me whether the fact that the link is published to the feed now means that Facebook owns that the content on the other end under these same terms?

I noticed something about using the "Share" link, but I don't know if that's considered the same thing.

Appreciate the insight!

</comment><comment><USER17> I see no reason to worry more than before.

Has anyone read MS Windows EULA?

EDIT:

* Facebook has millions of users, its TOS allows it to do anything with your data. If you don't accept the TOS you can't use the service.

* MS Windows has millions of users, its EULA allows it to do anything with your data. If you don't accept the EULA you can't use the OS.

<comment><USER18> I am fairly sure that you are just mistaken. For example, Microsoft Windows's EULA does not, as far as I know, grant Microsoft any copyright license in your data. Maybe you can show me where I'm wrong?

<comment><USER17> For example, Windows can just one day destroy all your data without any consequences. Is it enough?

<comment><USER19> What would you consider a fair action on MS's part? In this scenario I'll consider it a given that you have traced the loss of all of your data to a bug that Microsoft agrees exists and did in fact destroy all of your data.

<comment><USER17> I don't expect anything (and should not actually). If I lose my data due to a bad backup/updates policy it is my fault.

The question is not about MS. I've picked Windows because it has a huge user base.

My initial statement is equivalent to: if you take any software product that has many users then its legal docs effectively leave no rights to the end users. So it is not a big deal when Facebook changes its docs accordingly.

I understand that software companies are forced to adopt such policies to survive.

Therefore I rely on MS' good will that it tests updates before it releases them to the general public (even if it breaks all Windows boxes one day, people will be using it anyway).

<comment><USER19> kragen's comment below sums up my thoughts.

</comment></comment></comment></comment></comment></comment><comment><USER9> What does the "subject only to your privacy settings" phrase in the new ToS

<http://www.facebook.com/home.php#/terms.php>

do for users? How do you set your privacy settings on Facebook?

<comment><USER3> You click on the word "settings" on your homepage.

</comment></comment><comment><USER20> Dupe of another frontpage story.

<comment><USER9> The other HN submission

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

links to a different Web source, so not exactly a duplicate. Just a hot new story.

<comment><USER21> Except that the other HN story linked to the source on Consumerist, while this one links to "Mashable" which is an article regurgitating the Consumerist story.

</comment></comment></comment><comment><USER22> FB is waste of time.</comment>


Show HN: Fist – An in Memory Full-Text Search and Indexing Server Written in C - <AUTHOR> https://github.com/f-prime/Fist <comment><USER2> Is it relying on TF-IDF or BM25?</comment>


SpaceX Lead Software Engineer Perspective on Parallel Computing - <AUTHOR> http://blog.rescale.com/industry-perspective-with-spacex-lead-software-engineer-stephen-jones/

<comment><USER2> One nitpick: the excessive and pointless use of _sic_ seriously detracted from the readability of the article. Whoever put them in should learn to save that for scholarly articles, or when the significance of the mistake is relevant to the meaning of a quotation.

</comment><comment><USER2> The problem of helping non-software engineers who code to properly understand computers and modelling problems in software is huge, it would be good to see more articles about it.</comment>


Festive spices and their intoxicating history - <AUTHOR> http://theconversation.com/out-of-your-noggin-festive-spices-and-their-intoxicating-history-35425

<comment><USER2> Potentially interesting, but largely anecdotes, hypotheticals, and historical trends, with little to no science.</comment>


Discord Increases Max Go Live Viewers to 50 - brian-armstrong https://blog.discordapp.com/helping-out-where-we-can-3a5fb7bac77a <comment><AUTHOR> Just in time and demand for remote meetings and remote schooling. If it's a PR move, it's a damn good one.</comment>


Cassette Tape Format Is 50 Years Old - <AUTHOR> http://www.synthtopia.com/content/2013/09/14/cassette-tape-format-is-50-years-old/ <comment><USER2> From the article> Although there were other magnetic tape cartridge systems, Philips' Compact Cassette became dominant as a result of Philips' decision in the face of pressure from Sony to license the format free of charge.

It is interesting that _Sony_ pressured Philips to license the compact cassette "free of charge". One of the often quoted reasons for Sony's later loss of the Beta vs. VHS videocassette war was Sony's refusal to license their Beta format free of charge. They did not listen to their own advice that time around.</comment>


Did Pentagon lose billions, pennies at a time? - <AUTHOR> http://www.msnbc.msn.com/id/30456930/

<comment><USER2> A long, poorly written article that says a lot of contractors use a 2080 hour year as the basis for rates, instead of a 2087 hour year, which would account for leap years. It's just not a realistic statement anymore, given that most people I work with aren't paid on an hourly basis. Not to mention that the cost of the changes to the accounting systems would likely be greater than the cost reduction, which would then be put back into the rates as overhead.</comment>