100 days with Rust: a series of brick walls - <AUTHOR> https://brandur.org/fragments/rust-brick-walls <comment><USER2> As someone who has been programming in Rust for nearly a year, even for commercial purposes, this article is baffling to me. I've found the compiler messages to be succinct and helpful. The package system is wonderful. It's dead easy to get something off the ground quickly. All it took was learning how and when to borrow.

<comment><USER3> I can see where the author comes from. I've been working with ^W^W fighting against Tokio this week, and the error messages are horrible. Representative example:

      error[E0271]: type mismatch resolving `<futures::AndThen<futures::Select<futures::stream::ForEach<futures::stream::MapErr<std::boxed::Box<futures::Stream<Error=std::io::Error, Item=(tokio_uds::UnixStream, std::os::ext::net::SocketAddr)> + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result<(), ()>>, futures::MapErr<futures::Receiver<()>, [closure@src/server/mod.rs:74:18: 74:74]>>, std::result::Result<(), ((), futures::SelectNext<futures::stream::ForEach<futures::stream::MapErr<std::boxed::Box<futures::Stream<Error=std::io::Error, Item=(tokio_uds::UnixStream, std::os::ext::net::SocketAddr)> + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result<(), ()>>, futures::MapErr<futures::Receiver<()>, [closure@src/server/mod.rs:74:18: 74:74]>>)>, [closure@src/server/mod.rs:78:34: 83:6 cfg:_]> as futures::Future>::Error == ()`
        --> src/server/mod.rs:85:15
         |
      85 |     return Ok(Box::new(server));
         |               ^^^^^^^^^^^^^^^^ expected tuple, found ()
         |
         = note: expected type `((), futures::SelectNext<futures::stream::ForEach<futures::stream::MapErr<std::boxed::Box<futures::Stream<Error=std::io::Error, Item=(tokio_uds::UnixStream, std::os::ext::net::SocketAddr)> + std::marker::Send>, [closure@src/server/mod.rs:59:18: 59:74]>, [closure@src/server/mod.rs:60:19: 69:10 next_connection_id:_], std::result::Result<(), ()>>, futures::MapErr<futures::Receiver<()>, [closure@src/server/mod.rs:74:18: 74:74]>>)`
                    found type `()`
         = note: required for the cast to the object type `futures::Future<Item=(), Error=()>`

I have hope that things will improve on this front when `impl Trait` lands.

EDIT: After re-reading this, I want to add that I don't mean to hate on Tokio. I like the basic design very much, and hope that they can work out the ergonomics issues and stabilize the API soon.

<comment><USER4> The grievances you and the article's author mention seem less to do with Rust itself, and more to do with this seemingly horrible futures library. As far as I can tell, it's still in the rust-lang-nursery, which is an indication it's not ready for prime time yet.

<comment><USER5> I hope async programming doesn't become the standard in Rust. So much work has gone into allowing clean and safe threading, but people seem to be led towards the async libraries, which IMO solves a scaling problem only 1% of users will have. It's great that they exist, but if you're not expecting to have a c10k class problem, you can use threads and you'll probably have a better time.

<comment><USER6> If you're a library, creating threads causes side effects for the host program, and doing async when called doesn't. For instance, in a single- threaded program, it's always safe to call malloc() after fork(). In a multi- threaded program, another thread might have called malloc() and picked up a global lock; since only the thread that called fork gets copied (since you don't want to do the other threads' work twice!), there's now a copy of that global lock being held by a thread that doesn't exist, so calling malloc() will deadlock.

My personal interest in Rust is as a C replacement, including as a replacement for existing libraries that are written in C. While I agree threads can be very efficient (after all, the kernel implements threading by being async itself, more or less), they're annoying for this use case.

</comment></comment></comment></comment></comment><comment><USER7> > universally terrible documentation

Wait, what? Rust has what I consider the best documentation I've seen of any language. The docs explain things at a high-level, but concisely, and have numerous examples. The formatting is good, the keyboard navigation support is good, it's well-linked, and it has convenient features like links to the source and the ability to collapse everything but method headers for easier browsing. And it's extremely easy to add docs to your own project.

Maybe there are some dark corners filled with poorly documented unstable APIs that I haven't seen?

<comment><USER8> (Author here.)

I wrote this piece hastily, and it really wasn't intended for this broad of an audience — I won't redact the existing wording I still think it's roughly right, but I do regret a lot of it.

Rust's docs are _amazing_ in certain contexts — the book is great, the built- in support for documentation on types/functions/etc. is amazing, and compiling code examples are a very laudable idea.

What I'm speaking to here is more once you get into the broader ecosystem and start using a lot of non-core libraries. Oftentimes I found that the front page docs explaining the basic premise were concise and well-written, but that things got quite a bit harder when you started diving into individual classes and functions (put another way, as you started deviating from the happy path). This doesn't apply everywhere, but often the comments are very minimal and the documentation relies heavily on "types as documentation" in that there's a big list of all the traits and the functions on those traits that are implemented. In many, many cases there's little in the way of detail or examples.

I've written quite a bit of Rust now and have used many of the headliner projects. So far there have been very few crates where I didn't have to resort to eventually checking out the source tree and figuring out how to do some particular thing by examining its source code and test suite. I won't call out any single project in particular, but I found this to be the case in every one of `actix`, `clap`, `diesel`, `error-chain`, `horrorshow`, `hyper` and `juniper`, just to pick a few from the top of my `Cargo.toml` (it also happened with many other libraries). It's great that you can do this and open source is awesome, but ideally I could get by on just documentation, which is what you can do in many other languages.

Unfortunately, read with little context, it sounds like the tone of my piece was intended to crucify, but it's not. It can be simultaneously true that Rust's docs can still use lots of improvement _and_ that the Rust team is doing an amazing job of improving them (there's just a lot of work and a long way to go). Both these facts are true with Rust.

<comment><USER9> I wonder idly if it would be useful to have 'cargo doc deps' that would generate docs for all your dependencies (or top level dependencies) in a project.

The rust docs are super useful, but not everyone bothers to publish them, and people tend to forget to pit full working examples in them.

<comment><USER10> 'cargo doc' generates documentation for dependencies (along with the main crate) by default.

</comment></comment></comment></comment><comment><USER11> > The wall is impassable until a point that you make a key discovery which > lets you make your through. Often that discovery is a eureka moment – it > felt impossible only hours before.

These moments are my favourite, or at least most memorable, parts of learning. Which is what attracts me to hard, important concepts because they tend to be the most rewarding once you begin to grasp it.

I'll never forget when SICP's connection between programming and abstraction started to really click, after much effort, and the way it blew my mind, despite having programmed for a couple years. Really grasping the fundamental concept took the whole experience of programming to the next level - and made learning other things easier like a rolling snowball.

The fact the author's walls never got "smaller" is a real problem, that can be disheartening.

That said, brick walls aren't always bad things. Although it's often hard to tell whether it's a reflection of a poor design/structure of the thing you're learning, or just the learning material, or the learner themselves. Then there is the question of "necessary evils" of steep learning curves which, who knows, might be required entry-fee for a truly great language or tool (see: Emacs/Vim).

Haskell was much the same way for me. Each cliff I climbed had a new big cliff waiting. It got me into learning not just pure FP but also lambda calculus/set/category theory. It felt never ending. I ultimately never went "all in" with Haskell (maybe because of this) but what I did learn has been very useful in my non-Haskell programming elsewhere, so it's not all for naught. But it was admittedly a hard and significant time investment which isn't for everyone... nor necessary for being a productive programmer. But I don't regret it.

</comment><comment><USER12> I am currently learning Rust and I feel this intensely[1].

I really want to like Rust, but I feel like the way they cope with no GC (lifetimes, borrowing) fights me at every turn, and really simple situations in other languages[2] become these intensely painful situations. Every time you think you've worked out how to fix a problem you find while you've fixed that one you've actually created 2 more.

Want to have a data structure of variable size (eg a struct with an Vector in it)? You can't do that, structs have to be fixed size. OK so I'll make it a reference to a Vector. That's great, but now you can't have a factory function because the lifetime goes out of scope. OK so I'll wrap my reference in a Box. OK that's great but now your OTHER reference: a trait (because traits are also of unknown size) is complaining. OK I'll wrap that in a Box as well. Sorry, you can't wrap this trait in a box because before your trait requires implementors to implement copy because at one point you have to use the trait in more than one place and references break the lifetimes and--- __THROWS LAPTOP OUT WINDOW __

I 'm going to keep chipping away at it for a bit longer, but I can feel my interest waning.

[1] Except for the bad docs bit, I really like the docs, and the error messages are definitely earnest in their attempts to help you.

[2] that I'm familiar with, which are no languages that don't auto-GC

\-- EDIT --

To everyone taking the first line of my intentional rant paragraph and pointing out it works fine… you're correct, I am mistaken! Let me paste the reply I made to the first person:

\---

You're absolutely right. What I really meant was that you can't have Vec<T> where T is a trait without also wrapping that in a box, which for me in turn doesn't work for a bunch of other reasons.

In any case, my point remains the same: it is very challenging-- at least for someone used to just creating data structures and letting GC handle it-- to build code that does what you want, and you spend large amounts of time "fighting" the compiler. I am OK if people wish to peg that on me being stupid or whatever, it doesn't change the core point: it's hard for new people to get into, and if you're wanting there to be less Electron apps and more native apps things like Rust being easy to use seems important for that.

<comment><USER13> It's important to note that in C++ you can easily run into problems with what you're describing: structs (objects) with different sizes being put into a vector. You may very well get the program to compile, but then run into odd bugs which come about because your objects get clipped to the size of the smallest possible (the base class). So any overridden methods which expect extra data in a subclass will not behave as expected.

So what you usually do here is have a pointer and a VTable and all that jazz. But there's been a resurgence in interest in putting data into contiguous blocks of memory. Check up on data driven design.

I don't think it's fair to compare GC'd languages to Rust's complexity. At least, compare C to Rust. But still, to be truly fair, weigh the usability differences against the safety differences. There are a lot of trade-offs here and perhaps this isn't the right way for you to go forward, but keep a broad view of the other aspects at play.

<comment><USER14> > It's important to note that in C++ you can easily run into problems with > what you're describing: structs (objects) with different sizes being put > into a vector.

This is simply wrong.

> You may very well get the program to compile, but then run into odd bugs > which come about because your objects get clipped to the size of the > smallest possible (the base class).

That has nothing to do with object sizes. You're describing the object slicing problem

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

The cause of this problem is ignorance and incompetence regarding fundamental aspects of the language.

<comment><USER15> > The cause of this problem is ignorance and incompetence regarding > fundamental aspects of the language.

No! You can rationalize _any_ language problem away with this argument. That's why it's a fallacy with a name: "no true Scotsman" (as in: "no true C++ programmer would let object slicing introduce a bug").

Object slicing is a problem with C++, period.

<comment><USER14> > No! You can rationalize any language problem away with this argument.

Sorry, the sole problem is incompetence. Coupling incompetencr with the inability to learn is a problem that no programming language solves. If you insist in shooting yourself in the foot, it makes absolutely no sense to complain that the gun is broken because it doesn't guide bullets away from your foot when you intentionally aim at it.

The object slicing problem is C++ 101. It isn't the language's fault that people who don't know the very basics end up doing mistakes.

<comment><USER15> "Don't use heap memory after it's been freed" is C++ (and C) 101 as well. Yet if the bar for C++ competence is "never wrote a use-after-free", then your bar for "competence" excludes essentially everyone in the industry.

Whether a theoretically "competent" C++ developer makes mistakes related to object slicing is a completely uninteresting debate. Whether experienced C++ programmers make that mistake _in practice_ is the interesting question. And they do.

<comment><USER14> > Yet if the bar for C++ competence is "never wrote a use-after-free"

The bar for C++ competence in that regard is RAII.

Furthermore, your strawman doesn't hold up. The object slicing problem is actually like someone being foolish enough to cast a 64-bit int to a 32-bit int and then complaining that the programming language is broken because the 32-bit variable doesn't hold 64 bits. Of course it doesn't. Why should it? And why make excuses an play the pin-the-blame game when the problem is caused by ignorance? Heck, you're assigning heterogenous objects of variable-length to a data structure that by definition was designed to hold homogeneous sequences of fixed-size objects, and even still you want to pin the blame on the language? How, if you clearly don't know what you're doing?

<comment><USER16> > The bar for C++ competence in that regard is RAII.

If it was that simple we'd never need kungFuDeathGrip in Gecko. Yet, we need it a lot: [https://searchfox.org/mozilla- central/search?q=kungfu&path=](https://searchfox.org/mozilla- central/search?q=kungfu&path=)

(KungFuDeathGrip is the pattern of introducing an extra RAII refcount incrementer/decrementer on the stack to avoid subsequent method calls doing something that would free an object from underneath the current stack frame.)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> >Even something as simple as abstracting a new helper function often turns into a veritable odyssey because getting type annotations right can be so difficult (especially where a third party library is involved).

This is a sentiment I can't say that I share or even understand. You have a compiler doing inference, it will _tell you_ what the types are if you ask?

A lot of times when I find myself writing something where I'm unsure of the concrete type -- I'll just stick a bogus type ascription in the expression somewhere. Then I run `rustc` knowing full well that it will fail. Somewhere in the error will be a message of the form "found <x> expected <y>" and now I know what the inferred type is.

>The horribly anti-user futures system, compiler messages generated by a misused macros that are second only to C++ template errors in how egregiously difficult they are to parse, universally terrible documentation and lacking examples, unstable APIs, type annotation hell, and so much more.

Given the author's dig at the `futures` crate though, I have a feeling a lot of the verbosity in errors they are seeing is due to the extremely long chains of combinators that the futures crate encourages. I haven't run into these errors myself since I'm avoiding async IO in rust until an `await` style abstraction becomes available. In my opinion: jumping into using an async library/runtime that is undergoing heavy development is probably not the best place to start when it comes to learning Rust.

I think this is one thing that Go definitely got right: having concurrency baked into the language that encourages a "syncrhonous-style" of programming is absolutely the way to go for approachability. I'm not sure that I'd go so far as to call `futures` user-hostile, as the tokio devs are doing great work, but it certainly isn't user-friendly yet.

<comment><USER3> > A lot of times when I find myself writing something where I'm unsure of the > concrete type -- I'll just stick a bogus type ascription in the expression > somewhere. Then I run `rustc` knowing full well that it will fail. Somewhere > in the error will be a message of the form "found <x> expected <y>" and now > I know what the inferred type is.

I've found myself doing this a lot in order to find the type of an expression. I stick it in a variable, add an `variable.asdf();` somewhere and look for the error message "no method asdf() on type <x>".

</comment></comment><comment><USER18> I was following along until this:

> universally terrible documentation and lacking examples, unstable APIs, type > annotation hell, and so much more.

The docs in Rust are by far some of the best I've seen, without specifics it's really hard to understand what issues he hit.

<comment><USER19> They're completely different kind of docs that Python's. Python's are written by hand, with many examples and tips how to use the various tools. Rust's documentation very much feels generated, and the last time I checked methods were not grouped. So vast portions of a page are consumed by variants of methods (overloaded methods?) which work exactly the same except they take different argument type. Python documentation is text with methods and code samples inbetween. Rust's documentation is like someone iterated over functions and types and printed a message for each. There's A LOT of redundancy.

<comment><USER18> You mean like how Vec has a ton of examples?

[https://doc.rust-lang.org/std/vec/struct.Vec.html](https://doc.rust- lang.org/std/vec/struct.Vec.html)

FWIW I'm not a huge fan of Python's docs because I can't quickly scan them to track down that one detail about a function I was using.

Rust's docs also let you collapse everything which makes browsing them much faster.

<comment><USER20> The traits implementation section is god awful and in an utterly unusable order because the ordering makes no sense.

I find myself always just looking at the source to make sense of things rather than the docs which kind of defeats the point.

<comment><USER18> That's because the trait section only shows what traits a type implements. If you want to see how to use a trait just click that trait's name for the trait specific documentation.

<comment> Paul-ish Sometime I don't know what trait I need, but I do know what kind of operation I want. In documentation such as Python's, I can "ctrl + F" for word similar to what I want to do and I usually find what I need. In rust, that textual description is usually hidden on the trait's page. This is probably more frustrating to beginners who don't know what most of the basic traits are. In general though, the standard library is better about this than other libraries.

<comment><USER21> The built-in Rustdoc search isn't perfect, but it _should_ search the textual description for you. It might only search the first line? I should dig into that code again...

</comment></comment></comment></comment></comment></comment></comment><comment><USER22> I have been working with Rust, full time, for a little less than 100 days. Like the author, I also came from Python (I authored Yosai).

Unlike the author, I haven't been hitting brick walls. I also have observed all of the warning signs that the futures bridge on the tokio highway is unfinished so I didn't cross the barrier and still try to use it anyway.

Instead, I have been working on myriad other synchronous parts with great success. I've made substantial progress in this time largely due to the Rust community and --- the Eco system! Sure, I've had to build custom parts but there haven't been showstoppers.

<comment><USER23> I'm from the Ruby community, did a year of Scala after leaving Ruby. I'm now with rust and after the first struggle, I don't really have trouble with Rust anymore. I know the design I need to do to get certain things done, I know what is allowed now easily with purely concurrent Rust, and when do you need to split things up into threads. Right now I can refactor a project from threads to reactor in a couple of days and deploy to production with Rust. And I know everything just works.

<comment><USER22> What type of projects?

<comment><USER23> Async consumers that deal with events and trigger stuff on internal and outside services. RabbitMQ in, http out, response back to RabbitMQ kind of things.

</comment></comment></comment></comment><comment><USER15> I'm obviously about as far from the modal Rust user as one can get, but at this point the language has completely melted away into the background. I'm often tempted to write smallish scripts in dynamic languages, but even for those I frequently choose Rust just for the Cargo ecosystem. In particular I never see a reason to use C++ unless I'm contributing to a codebase that's written in it.

It takes different programmers different amounts of time to get to this point, and I certainly believe we can do better to make it easy to get up to speed, especially when async I/O is involved. But it does come eventually.

<comment><USER24> Same here. I used to use Python for small one-off scripts, but I now primarily use Rust. I can write Rust nearly as fast as Python and Go now, plus there are a lot of useful crates for the type of command-line utilities that I write.

For me the benefit is that a Rust utility usually works when it compiles, plus I can easily deploy the binaries on other machines (without going through another pyenv/pip dance).

To give an example: I work a lot with dependency treebanks on CoNLL-X format. Over my past to years with Rust, I have accumulated a bunch of utilities for doing things like paritioning data, merging treebanks, shuffling treebanks, extracting forms/lemmas, checking for cycling graphs, etc. I use them nearly daily:

[https://github.com/danieldk/conllx- utils/tree/master/src/bin](https://github.com/danieldk/conllx- utils/tree/master/src/bin)

</comment></comment><comment><USER21> We've been putting a lot of work into making Rust easier to learn. A lot of that stuff is just starting to land now. Some of it is inherent, but some of it is also just rough edges. Including things that the author talks about here.

So, my message is, we hear you! We're working on it. Might want to check back in in a few months.

</comment><comment><USER25> Disclaimer: Am a C++ programmer

Watching from a distance I have to concede that from a safety, dynamism of the community and package management using cargo Rust has improved upon C++ in meaningful and measurable way.

However on the complexity of the language front, I wonder if Rust will also join C++ in the realms of "too complex" 10 years from now. Would love to get some Rust experts to weigh in here on their thoughts about managing complexity of the language long term and whether being a simple systems programming language is an end goal.

<comment><USER21> Rust is certainly not the "end of history" for programming languages. But, taking on that task is for future generations of language devs; it's an open research question today. I can only hope so!

I wrote some thoughts about "complexity" and language design here: [http://words.steveklabnik.com/the-language-strangeness- budge...](http://words.steveklabnik.com/the-language-strangeness-budget)

I also think the difference between incidental and inherent complexity is important...

<comment><USER25> One question I had after reading your post is - We currently build languages with purely additive models, ie features can be added to a language over time. Overtime the interaction between features creates "incidental complexity". Was wondering if you know of any languages that have been able to drop old features / ideas in a controlled manner.

<comment><USER26> Lua has been known to remove things. The language still remains small and clean after over 20 years. The creator has given some talks about how breaking compatibility (e.g removing features) requires its own thought process. There are different types of changes. The easiest to change are the ones that can be detected immediately in existing real world programs whereas the hard changes are the kinds that could go silently undetected by users until it is too late.

</comment></comment></comment></comment><comment><USER27> I'm looking forward to the full article, because it's nice to know that I'm not alone here. I too started learning Rust with great optimism, and had the same experience: I expected that things would be difficult starting out, but assumed it would get easier as I acquired more knowledge, and then it didn't. Mostly this was for the same reasons as the author cites: Rust futures are incomprehensible, and there is rarely documentation to answer simple questions (one that I ran into the other day was "How do I parse a string into a datetime in a particular timezone?", which took about an hour to answer, compared to the 60 seconds it would take in something like C#)

I'm saying this as a lover, not a hater. I really believe in the mission of Rust, and I really _want_ to like it, but I realized that even after a few months of learning, it was still taking me orders of magnitude longer to accomplish things in Rust than in C# (or even C++), and I wasn't finding the tradeoff worth it.

<comment><USER28> I'm observing some similar muttering in the JavaScript community with Promises. Chain them incorrectly and you get an error with no actionable context.

The most popular 3rd party promise framework in JavaScript collects extra cause and effect data when you run the code in development mode. It helps but it still isn't always enough.

I fundamentally don't understand how people still think writing tools and libraries is the same process as writing production code. Which is to say: I wrote it, I understand it, ship it!

It's a profoundly different process. I don't think we give enough kudos to the people who can do it well.

I keep telling my ambitious jr devs the same two pieces of advice. The one relevant here is: nobody is going to look at your code until something is broken. Which means they are already having a bad day. Don't make it worse.

<comment><USER29> Don't leave us hanging. What's the other piece of advice?

<comment><USER28> Oh. For a similar reason (nobody reads your code unless they're looking at a problem): describe your piece of code in plain english. If you can make the code work the way you just described it, the code will age better.

(It might not be the fastest, but everyone will know if it's correct. When you're hunting for a bug it's important how quickly you can eliminate false positives to get to the real culprit. And you can make good code fast but you can't make fast code good.)

</comment></comment></comment></comment><comment><USER30> I've been learning Rust for a little while, and while I agree that it can be frustrating, it's nowhere near as bad as trying to learn Haskell. I regularly get a friend of mine to explain things to me, because the documentation and community for Haskell are 90% incomprehensible to anyone who doesn't have a comp-sci degree or a higher education in mathematics. Example: [https://wiki.haskell.org/Lifting](https://wiki.haskell.org/Lifting). It's not that I don't get the concept (after being given a much better explanation), it's just that the Haskell community in particular really seems to struggle with communication. And I think that's where Rust is actually in a good place for learning.

Rust has some confusing concepts, and it does feel like you're fighting the compiler sometimes, but I can see what it's trying to achieve and it's improving very rapidly. I find that I can more-or-less stumble my way through it until I get where I want, as the documentation that is about is generally well-written, even if it doesn't cover everything yet :)

And it's kinda fun!

<comment><USER31> > Lifting is a concept which allows you to transform a function into a > corresponding function within another (usually more general) setting.

What's there not to understand? :)

<comment><USER30> Yeah that bit was alright, it was everything after that I struggled with ;) As an example; I don't know what a functor is. I've not come across that term in anything I've done before, so I click on it to read up and get the definition: "The Functor typeclass represents the mathematical functor: a mapping between categories in the context of category theory. In practice a functor represents a type that can be mapped over.", which uh, doesn't really help. I only did mathematics to GCSE level here in the UK, during which I never came across most of the terms used frequently in Haskell's documentation :D

There's a lack of examples of "real-world" usage in Haskell. e.g. here's how you'd use lifting, in a practical example. e.g. why is lifting a thing and what possible uses does it have when writing an application? Because to my knowledge I've never done it before, so why is it good?

Thankfully my friend sent me this: [http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...](http://adit.io/posts/2013-04-17-functors,_applicatives,_and_monads_in_pictures.html), which is a much better explanation. It's probably due to a difference in my background (predominantly web, applications, self-taught etc) and the more academic history of Haskell, but I find the vast majority of examples irrelevant. Luckily there are a -few- books/tutorials around that explain the language more clearly and why I might want to write software with it.

It's a shame because it looks like a really cool language, but it is seriously hard to get into. Whereas with Rust, it just kinda makes sense to me.

<comment><USER31> I did mathematics to first year university level and didn't come across any of the terms used in Haskells.

Our programmers group is currently working through category theory with - [https://bartoszmilewski.com/2014/10/28/category-theory- for-p...](https://bartoszmilewski.com/2014/10/28/category-theory-for- programmers-the-preface/) \- and a lot of it is utterly bewildering, but at least I am starting to understand some of what Haskell is going on about. As for real world usage, however, I still have a long way to go...

</comment></comment></comment></comment><comment><USER32> I think what happened here, is the author wanted to do something with futures and the whole frustration is comming from not understanding that Rust Futures are just not ready yet. The whole language and ecosystem has plenty of stuff in the pipeline to make them better.

</comment><comment><USER33> This is a 100 sentences rant with 0 substances. Literally, there are no examples at all of any "brick wall".

Why was this even posted here?

<comment><USER34> ? Plenty of examples.

 _The horribly anti-user futures system, compiler messages generated by a misused macros that are second only to C++ template errors in how egregiously difficult they are to parse, universally terrible documentation and lacking examples, unstable APIs, type annotation hell, and so much more._

<comment><USER35> These are all very subjective. I personally love the error reporting; The examples and docs are excellent; Many times I've needed unstable nightly api features and have appreciated how easy it is to enable.

</comment></comment></comment><comment><USER4> I feel like a lot of difficulties people run into with Rust are because they're trying to do things the "right" way. You can often make your life easier with liberal use of reference counted objects, instead of solving difficult lifetime constraints, but it doesn't feel like the perfect way to do it. Often people are pursuing zero-cost abstractions to their detriment. They then compare the language unfavourably against languages where those zero-cost abstractions weren't even an option.

<comment><USER36> I think this is an important point. When prototyping or developing one-off utilities, I'm not looking to shave off CPU cycles or run everything under 6 MB. I wish someone would write a "Rust for <insert-gc-lang> Programmers". :)

</comment></comment><comment><USER37> _" getting type annotations right can be so difficult"_

I had the same experience. After getting lifetimes (more or less) this became my largest headache... I wish for stronger type inference and features like this: [https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_gu...](https://downloads.haskell.org/~ghc/7.10.1/docs/html/users_guide/partial- type-signatures.html)

I feel my productivity (and code quality) would increase a lot. For example right now I have to struggle so hard if I would like to write generic code, while in haskell that's more or less the default thing (the compiler infers it) if I just omit type annotations...

</comment><comment><USER38> > I don't like how little time I spend solving the problems that are > interesting to me.

Welcome to systems programming.

</comment><comment><USER39> PG had this comment about programming languages: The correct solution of a problem is the most simple solution. Just like in math, you can solve one problem in multiple ways, but the correct one is the shortest, beautiful looking one.

When I look at Rust, it gives the feeling "could be simplified". Obviously it's a new language and it comes with lots of cool stuff, but it looks ugly, doesn't excite those who seek simplicity.

If I had the time to invest in learning Rust, I'd use that time for building something new with any language that makes me productive.

<comment><USER21> There are some ways in which Rust can be simpler; see my above comments about learn ability. But a lot of the complexity is inherent in the choices we've made for the constraints of the language. For example, including a GC would make things much simpler in some ways! But it would also make it not appropriate for many of the use cases that are crucial to Rust's existence.

<comment><USER40> The way I see it, Rust exposes more of the underlying complexity of things which makes Rust itself appear more complex than its peers.

<comment><USER21> Yes. The String stuff is the epotiome of this, IMO.

</comment></comment></comment></comment><comment><USER41> Exactly my feelings. Interesting how some people claim a rather different experience. Rust was voted the most loved technology on StackOverflow, which is unbelievable to me.

<comment><USER42> It was probably done by the Rust Evangelism Strike Force.

<comment><USER43> I don't think so. Rust is a brilliant language in theory, and for many high- performance applications. There's a lot to love from afar. But it still hasn't made good on its promises to be a great language for everyday application development. That said, the goal is lofty and laudable and the community's positive attitude and ability to take constructive criticism are world class.

</comment></comment></comment><comment><USER44> As a long-time C guy, it's nice to see Rust as a modern replacement. But most of the time, such low level programming is not needed.

The popularity of Rust and its friendly hand-holdy docs almost don't even make sense for what it is, to me anyway. I suspect it will end up frustrating many high-level developers.

</comment><comment><USER45> The problem with Rust is that it is very hard to program interconnected graphs.

Basic Rust does not allow cyclic references, which means that almost every graph needs to use special tricks to make it work. These tricks are variants of reference counting. A trick that was copied directly from C++.

It feels like having to build a car with only a screwdriver and hammer. Each section of your graph needs to be managed separately. With non-safe rust or C++ you can put whole panels or sections on your car. And a garbage collector works like a robot: usually effortless.

<comment><USER46> The easiest way to build graphs in Rust is to store all your graph nodes in a Vec, and use indices instead of references to refer to other nodes. Also a cache locality win.

<comment><USER47> This is really the only practical way to do it, yes. But it's gross and means that you have to write custom code to print the data structures. That might sound trivial, but the ability to autoderive pretty printers is super useful when debugging.

<comment><USER21> Or just use petgraph, which does this for you.

<comment><USER47> That's fine if you're actually running a bunch of graph algorithms, but it's not a good fit for, e.g., a parse tree where each node has a link to its parent as well as links to its children. At least, I for one don't want to have to pull in a relatively large library just to define such a simple data structure.

</comment></comment></comment></comment></comment><comment><USER48> This sort of feedback would much more helpful and credible if you added what sort of project you're using Rust on, your technical background, and concrete facts (not just metaphorical opinions / complaints) about what goes wrong. As it is, this article helps no one make informed technology decisions. See [https://vimeo.com/9270320](https://vimeo.com/9270320).

</comment><comment><USER49> I have a similar story: [http://genesisdaw.org/post/progress-so- far.html](http://genesisdaw.org/post/progress-so-far.html)

This is why one of the main features of zig listed on the home page is:

"Small, simple language. Focus on debugging your application rather than debugging your knowledge of your programming language."

<comment><USER50> Looks like your complaints were

> I fixed a lot of code after updating to the latest Rust compiler each day.

When referencing your experience, it might be good to point out that this is before Rust hit 1.0 (commits mention Jan 2015 and 1.0 was released May 2015). This problem goes away and a lot has improved about the language and ecosystem since then.

> But nothing in life is free. GTK is sufficiently complicated that a Rust > "safety wrapper" is in order. The one available was not complete.

I think GUIs might still be a weak point for Rust but it sounds like this has gotten better. I hear a lot of positive reactions around relm

[http://relm.ml/relm-intro](http://relm.ml/relm-intro)

> And then I tried to abstract the font rendering code into a widget concept, > and everything broke down. The Rust compiler has many false negatives - > situations where it is a compile error due to safety, but actually it's > pretty obvious that there are no safety problems.

Any examples of false negatives?

The main source of them is borrows that don't need to live to the end of the scope ("non-lexical (borrow) lifetimes"). While in most cases this is easy to work around (add a scope), things are progressing for the Rust compiler to understand these.

</comment></comment><comment><USER51> I consider myself a good enough engineer, and I've picked up a lot of languages. Recently I built and launched a server agent for Cronitor. Going in I knew it needed to be portable and compile to an executable. I considered Go, Rust and C.

I decided to spend a day and build 3 versions of a basic Usage block to get a feel for each. I'd never written Go or Rust, and only passable C.

I did C first and then tried Rust. I gave up. It was too much of a learning curve for a ~3 mos project. I ended up using Go. I'll write up a blog post soon, Go is not without challenges, but I'm comforted by blog posts like this to see that I'm not the only mortal here still challenged by Rust.

<comment><USER52> While people can learn Go in a day, it is basically impossible to learn Rust in a day.

The only reason people can learn Go in a day is that Go is similar enough to a language the person already knows. Rust is different enough to every other language in existence (including C and C++) to make learning in a day impossible.

I don't think "deciding to spend a day" is the right way to evaluate programming languages. Unfortunately, it is the common way to evaluate programming languages and Rust fares very badly in such evaluation, in my opinion, much worse than its fair score.

</comment></comment><comment><USER8> Author here. I want to apologize a bit for the tone of this article — it was written from a place of frustration, and this part of the site is very much akin to a development journal — these are short articles without a lot of concrete facts that are not really intended for broad or comprehensive consumption. In no way is this meant to be an anywhere-near comprehensive critique on Rust.

I'll quickly point out that Rust is my favorite programming language, even if reading this piece in isolation would give you the opposite impression. There are about a million things to like about it: The syntax, type safety, sober choices around language design, built-in documentation facilities, conventions, `rustfmt`, linting with `clippy`, toolchain management with `rustup`, community (in the sense of project management and organization), development momentum, ecosystem, and a whole host of other things are all downright _incredible_. Some of the people working around the core are undoubtedly some of the smartest throughout the entirety of professional software.

That said, I wouldn't take back anything I wrote here because even when I read it back today with a much more optimistic place (I bypassed many "brick walls" that I alluded to since I wrote it), I still think it's true. Months later, even after writing a lot of Rust, I often still don't feel productive.

No language is perfect, and it's probably healthy to have the occasional counterpoint to its fairly consistent positive press. I've spoken to people who don't know much about the language and refer despairingly to the "Rust Evangelism Strikeforce", which I think is largely internalized rationalization that what they've read is too good to be true, so there must some nefarious element at work. Rust really _does_ deserve its good press, and hopefully the occasional dissenting opinion and subsequent discussion will help convince them of such.

IMO, Rust has a few existential threats — the one that I think most about is that despite being well passed 1.0 at this point, there's a distinct lack of pragmatism around getting core features like concurrency nailed down and shipped. Futures and Tokio are widespread at this point, but the APIs are still changing, and the error messages that they produce are still quite awful. Even once they're fully feature-complete and stable, they're still not going to be very pleasant to use — you have to think really hard about how you're doing future composition. Contrast this to a concurrency system like Go's, where you can more or less pretend that you're writing synchronous code, and let the runtime take care of the heavy lifting. I love how much careful thought and consideration is being put into the development of a cohesive concurrency model, but unless it can get to the point where it's stable and far more user-friendly, people (like me) who are trying to use the language to build things are going to continue having a hard time.

In summary, Rust is awesome, the core team is awesome, and the development community is awesome. I'm confident that the usability problems it has today will be worked out.

<comment><USER21> No worries <3

There's a lot of stuff coming down the pipeline that I think would help you a lot.

> there's a distinct lack of pragmatism around getting core features like > concurrency nailed down and shipped.

For one example; we're working _really hard_ right now on getting async/await shipped, and dealing with ergonomics problems around it. The recent changes are to make it simpler, not make it harder. For example, you should need to think a lot less about future composition, since you'll be able to borrow across futures, as just one example.

There might be a disconnect between what we're working on and what we're perceived to be working on. Messaging is hard!

You're 100% right that criticism is the only way to evolve, and so I appreciate calling out things that aren't great. Details help, but as you said, this blog post wasn't intended for this audience, which is a problem I feel quite deeply, personally. So I get it :)

<comment><USER8> Thanks for not taking it personally :) that's not always easy!

> _For one example; we 're working really hard right now on getting > async/await shipped, and dealing with ergonomics problems around it. The > recent changes are to make it simpler, not make it harder. For example, you > should need to think a lot less about future composition, since you'll be > able to borrow across futures, as just one example._ > > _There might be a > disconnect between what we 're working on and what we're perceived to be > working on. Messaging is hard!_

Sufficed to say that I can't wait to see these improvements come out. It may end up being the case that I simply got started on this project a little too early — six months from now many of my problems may have evaporated already.

</comment></comment></comment><comment><USER53> I'm not sure how easy Rust claims to be... The main idea here is " I love that Haskell-esque feeling where a compiling program is usually a working program." Rust will probably get easier, but it's main goal is safety.

The main problem I have with a pure safety focus is that the warnings often feel like overkill for 99% of programs. For example, when gcc yells about comparing signed and unsigned ints, I find that there rarely is a true safety concern involved. I hope Rust is better than that.

<comment><USER54> > For example, when gcc yells about comparing signed and unsigned ints, I find > that there rarely is a true safety concern involved. I hope Rust is better > than that.

In Rust these are treated as two completely different types so this is a compiler error and not a warning. You need to explicitly cast one of them to make the comparison and integer types are not automatically converted in any way. You have to do the same for any other operation involving the two types (e.g. addition).

You could certainly define the `ParitalOrd` trait for the two types to make the comparison possible (I don't know the implications off the top of my head). The language defaults to safe and explicit.

<comment><USER55> > You could certainly define the `ParitalOrd` trait for the two types to make > the comparison possible

I don't believe that's possible. Unless something changed relatively recently, the trait implementation has to be either a) in the module where the trait itself is defined (so the standard library in this case), or b) in the module where the type you're implementing the trait for is defined (again, the standard library). Since you can just modify the standard library, implementing PartialOrd would not be possible for e.g. comparing u16/s16 (or whatever).

</comment></comment></comment><comment><USER43> I've been dabbling in Rust on and off since 2014, and this has always been my feeling. I thought my background in C++ would make things reasonably easy, and while I have little fondness for C++, it's still easier to get things done than with Rust, which is not at all what I expected given my 4 years with the language.

There's a lot to like about Rust, but it falls far short of the "easy-as-Go" promises made by many of its proponents.

<comment><USER56> I've literally never heard anyone say Rust was as easy as Go.

<comment><USER43> Really? I was hearing that 2 or 3 times a week before Tokio was popularized. "Rust is as easy as Go for writing server apps!" "You don't need goroutines or async for high performance servers; Linux threads work fine!". When people started hearing about Tokio, many people seemed _sure_ it would be easier. None of this is meant to bash these people; I think their goals and vision is laudable and I hope they get there; I just think their optimism blinded them a bit.

</comment></comment></comment><comment><USER57> The more I read about those new-wave languages, the more I end up thinking that the simple languages like python and C are the clear winners.

I started to learn about rust, but honestly it feels like it has the same design and features of ADA, in term of code correctness. It's a great thing, but I still wonder if it's really useful for everyone. Usually ADA was used in aerospace.

And I still believe C++ has a good future, of course as long as you keep using the good parts.

<comment><USER58> If software companies got recalls and were sued for lack of quality like in other industries, by now everyone would care about how their code gets written.

<comment><USER57> Sure, but that's a different debate.

If that would be the case, you would have much less competent programmers who would be able to do their job properly.

I believe the software industry is still too young and immature.

<comment><USER58> On the contrary, only those able to meet the bar would be on the field, and we wouldn't have self taughs calling themselves engineers.

<comment><USER57> There is a big demand for programmers, so raising the bar doesn't make sense.

<comment><USER58> If companies payed programmers properly, gave training and benefits, there wouldn't be lack of programmers.

Raising the bar makes sense in any engineering.

<comment><USER57> It doesn't make sense if the country cannot afford to properly educate all those programmers.

Don't shift the argumentation towards inequality.

</comment></comment></comment></comment></comment></comment></comment><comment><USER59> There are a few things in life you just should not do. One of them is jump from your only language experience being Python into an advanced language like Rust when you're struggling to grok SQL.

<comment><USER60> I don't care for this assumption that people who struggle with a programming language are so inexperienced anything they struggle with is their fault. It might be the case that Rust will always be an advanced language that beginners should avoid until they've mastered something else, but feedback from beginners could still make the experience easier for programmers who take the ideal path and learn it as their second or later programming language.

The other reason I dislike this assumption is that it's frequently wrong. Judging by the rest of his blog, the author _does_ grok SQL. I'm pretty sure the Python to SQL example is either hypothetical or describes the author when he first learned SQL well in the past.

I don't mean to pick on you. I just see this attitude repeatedly in software development, and it leads to unnecessarily difficult software.

<comment><USER59> "anything they struggle with is their fault."? When did I say or even imply that? I didn't. Like the author, don't make stuff up.

<comment><USER60> Your comment stated that going from Python to Rust while struggling with SQL is something "you just should not do". That implies that the struggles they describe are the result of trying to learn Rust before they're ready—an attitude I disagree with, even if it were true that the author was struggling with SQL.

<comment><USER59> Read what you wrote. You said that I implied that "ANYTHING they struggle with is their fault."

<comment><USER60> I stand by "anything"—your post didn't make any exceptions. I should have been clearer that I was referring to an attitude your comment implied rather than an attitude you have, though, and for that I apologize.

</comment></comment></comment></comment></comment></comment><comment><USER61> I knew people are different. But if somebody can say that Rust compiler generates complicated error messages, then I just can't imagine how different people can be.

</comment><comment><USER62> Rust is not for you, and better stick to something which you are good at it. Friendly advice :)

</comment><comment><USER63> You can spend a month or two and get used to the bulk of Rust out of raw exposure. After seeing the same compiler errors over and over, you start to pattern match and learn how to jiggle the handle to get what you want.

For example, have you ever accidentally passed &Request across a thread boundary? The compiler explodes with UnsafeCell errors deep within the inner sanctums. It feels impenetrable for a while. You throw some clone() at it and whatever your go-to guesswork is. Then 30 minutes pass and you realize you just needed to pass Request instead of &Request. And at the end of i you really haven't learned much beyond "I'll try that sooner next time."

I think that's the hardest part about Rust. It takes quite a bit of mastery to actually understand and work around the more difficult compiler errors, like one that seems to threaten the whole abstraction you were going for. But adding a `+ Send + Sync` somewhere suddenly fixes it and it's not obvious why. It can feel very precarious.

Anyways, I think most of Rust's issues are just tooling issues. For example, imagine being able to hover identifiers to see their scope shaded in and where they'll get dropped -- instead of just error-message ASCII art. Or being able to hover something to see that it can do something because it implements this certain trait.</comment>


Web Developer Needed - Technical Cofounder Opportunity.  - <AUTHOR>

We are looking for a web developer to potentially join our venture. Learn more about us here: http://stickyframes.posterous.com/pages/about-us Sticky Frames are magnetically attached frames that contain messages that users create and print themselves. At this stage we are going forward with production of prototypes/low volume test series but we need a functioning web platform to maximize the potential of the product. The web service should help our users to create and manage content of their StickyFrames. We can offer up to 14% of stake in SF project - but we are also ready to discuss other forms of compensation. Essentially we are looking for a website similar in functionality to something like this: http://www.signazon.com/car-magnets/
If interested please contact me via HN or email at computerfix at gmail dot com We are very easy going. We are also YCombinator rejects. Join Us.
P.S. We thought that we have a match, but it did not work out due to schedule constrains. <comment><USER2> Dustin & Adam, I wish you guys the best of luck. This sounds like a really interesting project!</comment>


Swarm-dpl: A transparently scalable distributed programming language  - <AUTHOR> http://code.google.com/p/swarm-dpl/ <comment><USER2> Very interesting talk, but man vimeo sucks. The audio interrupts every 3 seconds.

Thanks anyway!

It should probably be pointed out though that swarm isn't so much a programming language as it is a modification of a large subset of scala to allow live thread migration to different machines at will.</comment>


Backlift now supports handlebars, less and coffeescript - <AUTHOR> https://blog.backlift.com/entry/coffeescript-and-more

<comment><USER2> This sentiment gets echoed all the time here, and I hate to clutter up these comments with a gripe that's relatively unrelated to the actual post, but _please_ make the Backlift logo in the top-left corner link to www.backlift.com instead of blog.backlift.com.

I'd never heard of you guys before, and now that I've checked out what Backlift is I'm super-interested in learning more, but I shouldn't need to manually edit my browser's URL bar just to get to your homepage from your blog so I can find out what your product actually does!

<comment><USER3> Random idea given that the header is "Backlift Blog." Why not make those two separate links that change color/opacity/something on hover where "Backlift" links to the home page and "Blog" links to the blog.

I don't think it'd be confusing and from a usability standpoint it's nice because you know people click the header to get to one of those two places. Since you can't anticipate which their going for, put them side by side and they're very likely to find the answer their looking for. Just a thought.

</comment></comment><comment><USER4> Ha, totally forgot about backlift. Did you guys send out an email when the open beta was launched?

I'm looking forward to trying this out as I'm front-end developer turned product manager that can't seem to build any of that 'backend stuff'.

Have you seen any good prototypes built using backlift yet? I'd be curious to check them out.

</comment><comment><USER5> is there any kind of "about" page that explains whether this is free or not? it seems to include hosting, but i can't find any prices (i'm talking about <http://www.backlift.com>).

<comment><AUTHOR> OP and backlift founder here. Backlift is free while it's in beta.

<comment><USER6> Hey Cole, Backlift looks really cool. Any chance we could chat over email about something? I can't find any contact info for you.

<comment><AUTHOR> shoot me a note at support (at) backlift.com

</comment></comment></comment></comment><comment><USER7> This is awesome. Cannot wait to start using it.

</comment><comment><USER8> I would love to see he reaction of someone who is not in tech try to parse that sentence. It would appear to be gibberish to them.</comment>


Microsoft to acquire Skype - <AUTHOR> http://www.microsoft.com/Presspass/press/2011/may11/05-10CorpNewsPR.mspx

<comment><USER2> Can anyone shed light on this statistic from the press release:

 _"With 170 million connected users..."_

Every article on Skype for the last 3 months has mentioned "600 million accounts". (<http://www.google.com/search?q=skype+600+million+accounts>) But I can't find an original source for that number; it seems everyone is quoting "industry estimates".

Were the estimates on Skype's userbase wildly wrong, or is a "connected account" somehow different?

<comment><USER3> If you look at the SEC IPO filing[1], the most recent numbers (Dec 2010) are as follows:

* 663M registered accounts

* 145M connected users

* 8M paying users

The 170M number is the most recent update of the 145M connected users number. They define 'connected users' as active within a financial quarter

I have spent the past few hours reading through the SEC filing. Skype is still growing very strongly[3], especially in the key metrics of active (connected) users and paying users (both up 30%)

I think this is a great deal and will work out as well for Microsoft as PayPal did for eBay. See my comment in the other thread about that[2]

As I mentioned in that thread, Skype is not profitable only because they wrote down assets and acquisition costs to the tune of over $350M. Within Microsoft it will profit near $500M this year (my back-of-the-napkin sums by projecting out the old revenue figures with the new growth figures). A PE of 17-19 is not a bad buy, considering the strength of the brand and the large user base.

Skype is probably the largest non-browser web/net application, and likely the second largest social graph after Facebook.

What will be interesting now is the question of if Microsoft will work with Facebook on Skype, or use it as a platform to compete with Facebook.

[1] [http://www.sec.gov/Archives/edgar/data/1498209/0001193125110...](http://www.sec.gov/Archives/edgar/data/1498209/000119312511056174/ds1a.htm)

[2] <http://news.ycombinator.com/item?id=2531885>

[3] From their filing: _"We have significantly increased both our free and paying users, growing our average monthly connected users by 38% and average monthly paying users by 19%, from the three months ended December 31, 2009 to the three months ended December 31, 2010."_

<comment><USER4> Really only 8 million paying users? That sounds very low... given it is the only online company other than adwords with my credit card details.

<comment><USER3> 8.8M that made a transaction in that quarter, which if you project forward with the current numbers would equate to 5.8% of active users making a payment

not bad in terms of a freemium conversion rate and I think some of it can be explained with:

* credits now have a longer expiry date, so you can bulk purchase and hoard credit

* US and Canada calling became free

* negative network effect of more people using skype = less people that you require the dialout feature to reach

<comment><USER5> US and Canada calling became free? As far as I know that only happened for part of 2006. In addition to calling 1-800 numbers being free.

</comment></comment></comment></comment></comment><comment><USER6> Am I the only one finding this simply amazing how Niklas and Janus managed to sell same technology/business twice?

Granted, there was an incredible mistake on eBay part not doing proper due- diligence, but pulling off what they did takes a lot of chutzpah for sure.

This most probably going as a case-study into modern economy text-books.

</comment><comment><USER7> Why is it that I like Skype less on the other side of this announcement? It's not that I'm anti-MSFT; I just like communications software like Skype to be vendor neutral, competing on innovation and working to keep as many platforms + devices as possible at parity. I don't want someone to use Skype as leverage to try to get me to switch platforms. I'm more likely to drop Skype and be left looking for an alternative.

<comment><USER8> There may be alternatives that cover Skype functionality at least partly if you have the skills and nerves to use them (based on SIP or jingle). But for most of the 170 million connected users, including those who use Linux, there is no alternative to Skype if they want the same featureset (im, voip, video, encryption, conference calls,...). Sad but true.

<comment><USER9> GChat is pretty idiot-proof, and platform-independent.

<comment><USER10> Does it still not have cross platform video support?

<comment><USER11> How many people REALLY use video chat though? I mean more than once a year. Even among techies and businesspeople, video chat rarely seems to have an advantage over regular voice chat.

<comment><USER12> Ever been in a long distance relationship, missing your kids when you're away from home, or just want to see someone's face? Video chat isn't as convenient as voice chat, but when you want to take some time out to really talk to someone, it's the closest thing to face to face.

Also, I think video chat works better and will pretty much always work better on computer than on smartphones. There's a much better screen, you don't have to hold it just right, and it's easier to sit down and make time for a video chat on a computer. If you're looking at the numerous failed attempts at video chat on phones, I can see how you'd see it as useless, but Skype is different.

<comment><USER9> FWIW, FaceTime on an iPad is very, very good.

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> My girlfriend has been traveling abroad and we haven't used Skype once. We just used the built in capabilities of Google Talk. Its a simple plugin for the browser, doesn't sit on my machine bugging for updates and slowing down my startup time.

No dropped calls, good video quality, and simple integration.

<comment><USER14> I have been using google talk but recently switched to skype because my wife got an iphone and google talk does not work on it. Skype on iphone is really painless to use and call quality is also very good.

<comment><USER13> Thats one of my biggest gripes, there is not Google Talk voice on the phone. I don't think Carriers would like it very much if Google had a free voice platform.

</comment></comment></comment><comment><USER15> I see this as a good thing. Currently Skype is used in my workplace, and poorly at that. Mostly because the contact information isn't in sync with Outlook accounts. This could probably be alleviated with some sort of process, but no one has taken the reigns on that. So if this syncs up nicely with the Microsoft programs I'm forced to use everyday, it'll just make things that much easier.

</comment><comment><USER16> The official announcement. I wonder how interoperability between various VOIP solutions will turn out with MS on board.

I am one of these dreamer of a multiprotocol VOIP solution. Like emails actually.

<comment><USER17> Or telephones.

<comment><USER18> In my eyes this is Facebook's missed opportunity. Facebook is a sufficiently powerful brand to be able to negotiate exclusive deals with operators around the world to launch a VOIP phone relying on flat rate data only, replacing the address book with a subset of your social graph and SMS with Facebook Messaging. Such a move could have been very disruptive towards voice phone operators if paired with 170M desktop clients and the Skype protocol.

It's a strategy Facebook could adopt without Skype, but with the two brands in unison they could rule the market. I don't see Microsoft being able to do the same.

<comment><USER19> I completely agree with you. Facebook could of became one of the largest telecommunication companies in the world overnight. Maybe they will get the chance to buy it off of MSFT much like how eBay sold it off. Probably not.

</comment></comment></comment></comment><comment><USER20> > Microsoft will continue to invest in and support Skype clients on non- > Microsoft platforms.

I don't personnaly use Skype for various reasons, but for the people who do, let's hope that's true.

<comment><USER21> That's certainly my concern. I have somewhere approximating zero faith that they will continue the Linux client, considering Skype themselves have essentially abandoned it, and the prospects for the other two I use, Android and Mac, seem rather dim. We do have 30 years of MS history to go by here, after all.

</comment></comment><comment><USER9> Hopefully Microsoft is swooping in to save Skype from the death-spiral it's been heading towards for the last few years. There really is a lot of room for improvement (software-wise) and I'm going to give MSFT the benefit of the doubt for the moment.

<comment><USER22> I don't see a new Linux version coming...

<comment><USER23> I was thinking the exact same thing when i read the headlines. But not that the linux client is (was) as good as the mac or windows versions...

</comment></comment></comment><comment><USER24> I'm curious to see what Microsoft will do with the more or less unmaintained Linux version of Skype.

<comment><USER25> Probably nothing. It will continue to be more or less unmaintained.

</comment></comment><comment><USER26> I just don't think Skype is a 8.5 billion dollar feature, especially any MS implementation. It's not like Skype was a closed platform- they have an API and their policy is to let the market decide which UX will win. I'm sure MS could have built all the features they want without buying the company. Apple already used the video conference marketing gimmick anyway and it's not exciting anymore. Who uses Facetime? Video conferencing solutions are good enough.

</comment><comment><USER27> Windows version written in delphi.

</comment><comment><USER28> This should put some pressure on Google to allow international customers into Google Voice. They have an opportunity now to take on all customers this deal might alienate, but since I don't live in the US I can't use Google Voice.

</comment><comment><USER29> Perhaps this will be a good opportunity for open-source alternatives to finally take off if Microsoft kills off the Linux/OS X/iOS/Android versions...

<comment><USER30> Can't happen, at least in the US, for patent reasons.

</comment></comment><comment><USER31> I predict that in two years they will have successfully marginalized their investment into 'Microsoft Skype' - part of the OS/Office/Outlook suite.

</comment><comment><USER32> My hope for this deal is that Microsoft partners with CLEAR (or any nationwide data provider) to create a VOIP Windows Phone.

</comment><comment><USER33> I was really hoping Sony would be smart enough to adopt Skype one day as their game chat system but oh well.

</comment><comment><USER34> So do the co founders list themselves as 2X entrepreneurs? lol "Oversaw the successful acquisition of Skype to eBay and Micorsoft." Talk about double dipping.

</comment><comment><USER35> Skype+Kinect+XBox actually sounds pretty cool, even WP7 _seems_ to have some potential. I actually think MSFT made a good move and it was worth it to keep Skype out of the hands of Google/Facebook.

If I were Microsoft I would even look at buying out Pandora/Spotify/Slacker/Last.fm, Netflix, and remove the file limit on their Windows Live online storage to compete more directly with Dropbox and others-- then there'd actually be incentive to use a Hotmail/Live account again and with a plethora of subscription services they could set up their own app store that would compete a bit better with iTunes and sync with Xbox Live. Something else powerful is it would be one bill for your Xbox live, online storage, email, movie rentals, games rentals (potentially), apps, music subscription, and VoIP calls.

<comment><USER36> I've been thinking the same thing.

Look at the modern smartphones. The lesson I take from iPhone and Android is that if you build a device that has a fair amount of memory, a modern processor, and an array of interesting sensors and input devices, developers will build for you amazing applications, killer apps even, in ways you're not able to imagine.

I imagine a next-gen xbox. It has kinect built in. Great APIs for that. It has Skype and Xbox Live and the various Windows Live services all built-in, with great API's for those, treating them as services.

You push the appstore model via xbox live on that device and I bet $10 that developers produce some amazing things for that platform. Perhaps even game changers. It revolutionizes computing in your living room the way that the iPhone revolutionzed computing in your pocket.

I also think... you'd have a very powerful remote control and connection ability to that device using every new Nokia phone (and any new phone on WP7).

Final thought along those lines is that WP7 is really a great mobile OS. I bought a new phone just last week. I'm on Sprint, so the HTC Arrive was available to me which is a new WP7 phone. I had to decide against it and went for an Android device but that was begrudgingly because there's no 4G WP7 phones in Sprint's line-up. (Ended up going Evo).

Here's the thing... WP7 just FEELS good to use. Way moreso than Android and also moreso than iOS. It's very snappy. It uses screen space well. And the Arrive has a GREAT physical keyboard, the best I've ever used on a phone.

No 4G killed it. Also, no removable SD card. And finally there was the Apps issue but they've put out some great dev tools for WP7. I think it's only a matter of time before they catch up.

Also I'm skeptical that the voice UI works as good as it does on Android.

Sorry for taking this slightly off topic but to bring it back around it's this: Microsoft could really do some great value-adds with Skype on a number of their platforms.

<comment><USER33> I'm loving my WP7. Oh well maybe next time :)

</comment></comment></comment><comment><USER37> On a side note, why has no serious competitor to Skype appeared? Given the maturity of the tech involved (its just VOIP) and the size of the pie, i'd have thought there would be more competition for a slice.

<comment><USER38> I believe the underlying tech, Global Index, is patented and valuable. Global Index is the p2p matchmaking software that runs under Skype (and Kazaa back in the day), which means Skype doesn't have to run centralized servers to route call data. Its also what lets them punch holes in firewalls.

My understanding is that their competitors don't (can't?) do this. For example, SIP runs through a central server (e.g., Google's). This allows Skype to run their service more cheaply, and its cheaper to provide service for each marginal user. Its a pretty strong network effect.

So, in addition to their brand and userbase, they do have some tech MS might want and can't get elsewhere.

<comment><USER39> You seem to be confused about SIP. SIP is the "Session Initiation Protocol", and its entire point is to coordinate initiation of a direct session between endpoints, the so-called "SIP Trapezoid".

SIP is a lot like SMTP. When you make a SIP call, you talk to your local SIP server, which talks to N intermediaries (usually 0) before going out to the public internet. After passing off to the destination server, the connection can go through N intermediaries on the remote side before being delivered to a final user agent. This connection isn't for delivering audio and video, though, it's for _coordinating_ a direct RTP connection to use for audio and video. Once the two endpoints are communicating, they send information about their real network location, work out details about NAT, and set up a direct RTP connection, possibly using STUN to deal with NAT issues. In a normal SIP environment, neither party's SIP server ever sees any of the actual media.

This is all fairly similar to what skype does, except skype has additional infrastructure for routing media through other clients, in cases where two endpoints can't find a way to communicate directly, as I understand it. I'm not actually authoritatively-informed about skype, though, so don't rely on this last bit.

<comment><USER38> Thanks tene, that's really good info. I was 100% turned around on that - definitely thought SIP had to route the call data through a central server.

</comment></comment></comment></comment><comment><USER40> What's next, MS? LinkedIn?

</comment><comment><USER41> Oh lord, does this mean fb is going to own skype data? Just no escaping the claws of Zuckerberg.

<comment><USER42> What does Facebook have to do with Microsoft?

<comment><USER43> I'm not sure if he meant this but Microsoft is investor in Facebook so apparently Facebook getting access to the Skype technology.

</comment></comment></comment><comment><USER44> apt-get remove skype

</comment><comment><USER45> Maybe MS can clean up Skypes habit of puching big holes in your network security - it's one reason why it's banned here..

<comment><USER46> It's one of the reasons why it is popular: because it just works for ordinary users, without the need to do something about network configuration.

</comment></comment><comment><USER47> Can anyone shed light on this: "share the vision of bringing software innovation and products to our customers"

Are they the only one sharing that vision? Are they software companies with a vision of dumping obsolete software and products to their customers ?

Big fan of stuffing fluffy meaningless statements into each PR. This one is a keeper.

<comment><USER31> "read share the vision of bringing software innovation and products to our customers" as

Grab a piece of (someone else's) software innovation and products and sell those to our customers.</comment></comment>


Tufts asks prospective students to explain "YOLO" - <AUTHOR> http://www.businessinsider.com/tufts-applicants-yolo-2013-7 <comment><USER2> I googled it too, and after learning that it is You Only Live Once, remembered citation from How the Steel Was Tempered:

Man's dearest possession is life, and it is given to him to live but once. He must live so as to feel no torturing regrets for years without purpose, never know the burning shame of a mean and petty past; so live that, dying, he can say: all my life, all my strength were given to the finest cause in all the world – the fight for the Liberation of Mankind. And one must make use of every moment of life, lest some sudden illness or tragic accident cut it short.

</comment><comment><USER3> _Tufts admissions officers may have included the question because they 're genuinely curious as to the meaning of the popular phrase._

This is clearly not true, since the first part of the question shows they understand the meaning pretty well.

</comment><comment><USER4> [http://xkcd.com/1234/](http://xkcd.com/1234/)

</comment><comment><USER5> This certainly shows my age. I had to google YOLO.

<comment><USER3> The question says right in the middle: _You Only Live Once (YOLO)_</comment></comment>


What If 'Capitalism' Isn't the Problem? [audio] - <AUTHOR> https://musingmind.org/podcasts/julie-nelson <comment><USER2> It's not a productive word really because it almost poisons every discussion based on whether someone's broadly sympathetic to 'capitalism' or not. Even when people actually agree this can cause meaningless confusion.

What I think is very valuable within our system is markets _as a tool_. There's no functioning replacement yet for allocating resources through something like a market at large scale. Even socialism sympathetic economists like Oscar Lange recognised this a long time ago.

What's wrong with the status quo I think is markets as an ideology, confusing social ends or larger objectives with the outcomes markets or capital produce. There is too little coordination in society, too little forward thinking and planning at a high level. It shows in the covid pandemic into which we stumbled like fools despite knowing it would happen at some point, the way we're screwed every time a wildfire breaks out despite we know it'll happen. I think it's glorifying capitalism as a way of life rather than a tool that produces these failures.

<comment><USER3> I don't think anyone denies that omniscient, well intentioned planners would be very efficient, but subjectivism and the calculation problem mean that you will never have the former, and political economy explains why you will not acheve the latter.

Spontaneously ordered systems are also better at dynamic adaptation to exogenous changes (such as technological ones).

<comment><USER2> How can political economy explain away something that's already succeeded? It's how Singapore moved from the third world to first, in the words of LKY, how Taiwan and South Korea got rich, how China has dragged people out of poverty, arguably also how the US navigated a huge portion of the cold war, by strategic thinking and determining clear goals, and then leaving the _how_ to less centralised systems to figure out.

The 40s to 70s broadly were an era in which there appeared to be a pragmatic balance between strategic planning and decentralized execution, in which markets where tools, serving national interest. It's also probably the era in which we saw more technological progress than at any other point.

Bringing up 'political economy' in this context is what produced the old saying 'Economists are the sort of people that see something work in practise and ask if it works in theory', it's exactly a symptom of the dogmatism that I think is plaguing us.

</comment></comment></comment><comment><USER4> I can't listen to the podcast at the moment. But, along a similar theme Doughnut Economics tries to imagine adjustments that are required to traditional economic models from the 19th and 20th century that are required to keep the biosphere productive for humans.

[https://www.kateraworth.com/doughnut/](https://www.kateraworth.com/doughnut/)

An idea that stuck with me is that markets are powerful tools that need to be embedded into other systems but arent self regulating systems all by themselves. It seems too often in debates on big problems the argument is simply we need a market solution not how is the system designed to best utilize a market.

<comment><USER5> > It seems too often in debates on big problems the argument is simply we need > a market solution not how is the system designed to best utilize a market.

"We need a market solution" is politician for private interests want to change laws so that they can expand their businesses.

<comment><USER6> While I agree, it's kind of throwing the baby out with the bath water. Carbon taxes are also a market-based solution which aligns well with public interests, for example.

</comment></comment></comment><comment><USER7> Capitalism's basic meaning is that the means of production are owned by private parties.

Putting them under government ownership instead doesn't seem like the solution to anything, unless you are very sure that the government will follow your ideological beliefs, not be corrupted by its newfound direct power over peoples lives, and not get taken over by populists.

<comment><USER8> One problem with the term "capitalism" is that it means such different things to different people. For example, feudalism is not generally considered capitalism by those that are anti-capitalist, but feudalism was still private ownership of the means of production.

Or, in the Democratic primaries, Bernie Sanders railed against capitalism, whereas Elizabeth Warren embraces the term, and they both had very similar policies. They were talking in different ways to appeal to different crowds that have different definitions of capitalism. And it creates tribal responses for some supporters.

<comment><USER9> Feudalism was not private ownership of the means of production.

Indeed, uner feudalism, the means of production were not commodified, and de facto the lord did not have the right of ownership to the land, because he was only allowed to use it in one very specific way. Therefore, lacking the right of exclusive control, feudal property does not fulfill the definiton of private property.

This is why feudalism is universally understood not to a form of capitalism.

<comment><USER8> Well that's a very different definition than "private control of the means of production," however. People focus on different aspects of the myriad definitions of capitalism, and the term becomes meaningless unless some part of the conversation first defines what sort of definition or aspect of "capitalism" one is talking about. However, people often experience a tribally-motivated response to the word before the meanings can be focused on. I'd doesn't make the word "capitalism" useless but it does make it difficult to start a discussion with a general group of people when leading with the word rather than the specifics that one would like to address.

<comment><USER9> I agree, we do need a very specific and structured definition of capitalism which analyzes it as a social and political system. Which has been done and achieved consensus almost two hundred years ago, but now it's become almost taboo to mention :)

But yes, confusion about these definitions is due to the fact that we haven't had a serious _remise en question_ of the social order in the anglophone world since the end of WW2.

As for my definition of private control of the means of production, I think it's fairly uncontroversial to say that if someone may not decide how to use something then they are not owners of such a thing, but merely hold a license to it. It's the same argument for why you can never own a copy of proprietary software, only own a license to it :)

</comment></comment></comment></comment></comment><comment><USER10> Two alternative viewpoints I have that are radically opposed:

What if government regulations warp capitalism and give protectionism and favoritism to certain companies while excluding the rest and not allowing for the free market to work?

What if unregulated capitalism has cannibalized itself and destroyed the free market by way of big fish eating up all of the small ones and now we're left with a bunch of huge corporations with outsized power and no threat from competition?

<comment><USER11> The first usually happens as a direct consequence of the second.

<comment><USER12> This is the correct answer. Look at what happened at the end of the Wilson administration when Andrew Mellon took over as Treasury Secretary as a prime example.

</comment></comment></comment><comment><USER13> > Rather, she targets 'economism' - a particular set of economic theories and > assumptions, plus a layer of incentives we've built atop them. Neither > updating our theories to better match reality, nor redesigning the incentive > structures that underlie economic outcomes require an exit from capitalism.

While that may be true, I think the reason we got here is because Capitalism inherently incentivizes those types of theories, assumptions, and incentives. You can argue that an ethical Capitalism is possible sure, but that would require labor power and a strong state to prevent the erosion that we have seen in the last half decade.

</comment><comment><USER14> Capitalism is not the problem, the problem is that people continue to do business with companies that operate with disregard for the long term consequences of their business practices.

<comment><USER15> If humans are innately short-sighted and tribal/selfish creatures, any system of organization that assumes otherwise is problematic. That seems to be the case with capitalism.

A society with a strong education system that perpetuates cultural values of long-term sustainability could get by with less explicit regulations, but I don't see us getting from here to there.

And even if we got there, such a utopian capitalist society would be fragile and prone to corruption towards over-exploitation. Other systems are needed to maintain balance -taxes, political advertising regulations, labor laws, etc

</comment></comment><comment><USER16> For Capitalism to work properly the government needs to be be empowered, and properly able, to enforce rules that prevent any one organisation from becoming so powerful that it corrupts and undermines the whole system. We don't have that today.

<comment><USER17> Its important to prevent individual companies from doing it but its also important to prevent groups of companies and even entire industries from doing it.

<comment><USER18> It really is this simple. Unfortunately simple isn't the same thing as easy.

</comment></comment></comment><comment><USER19> I'm not far into it yet, but this isn't the first time that I've heard this thought from Zen practitioners - that the practitioner should not blame capitalism for their problems. It makes me want to look further into Zen to see what leads people to this line of thinking.

<comment><USER20> It's the same reason why libertarianism is so popular in Silicon Valley. Billionaires want and can afford complete freedom from the government. Including taxes, including regulations, including responsibility for the consequences of their actions. So they will seek out any teaching that (if corrupted far enough) will justify those desires and actions. But they're just as happy to enforce all the things they hate on you, because their belief is a corruption of libertarianism. They don't actually believe it, it's just an excuse to not pay taxes.

Like libertarianism, SV has a way of taking exactly what they want from Zen and leaving the rest of the beliefs lying in a pile behind them. The Zen teacher Les Kaye famously said about Steve Jobs that he understood "the art, not the heart" of Zen.

If SV really cared about Zen, would we have unskippable ads? Would we have "like" buttons? Would we have auto-playing Netflix movies while you're merely sitting still in a menu?

They don't care about Zen. They never have. What they care about is making themselves feel better about the horribly un-Zen-like things they inflict on their audiences. Zen is just a coping mechanism to stroke their ego a little more.

</comment></comment><comment><USER21> Big government is the problem.

With a growing size of government, every conversation becomes a conversation about your life.

</comment><comment><USER22> Capitalism when balanced is near perfect.

Capitalism taken to its fullest extreme is greed out-of-control. This is where the US is right now.

<comment><USER11> What we are experiencing now is reversion to the norm. The post-ww2 period was a special moment when a lot of things lined up to produce a capitalism that was relatively egalitarian, but that was the result of the USA being the only intact industrial economy left, and owning the world reserve currency, and so on. It was never going to last, and it will never happen again. We're already bringing back sweatshops and extreme inequality.

<comment><USER23> In 1949 (just after WW2), Einstein wrote: "The economic anarchy of capitalist society as it exists today is, in my opinion, the real source of the evil."

Einstein was not a sociologist, but it's an indication that about "egalitarian capitalism" is not exactly true.

<comment><USER24> Judging that just several years ago Soviets managed to starve another million of their citizens, I'd say Einstein was utterly naive.

</comment></comment></comment></comment><comment><USER25> The problem isn't capitalism as such but the mindless worship of capitalism. The belief that more capitalism is always better than less.

In particular in America capitalism has become a holy cow. If you suggest ideas from socialism you are labeled a dangerous radical and taken off the air.

The so called "liberal media" are bastions of capitalism. One can only look at the scathing criticism and scare mongering about Bernie Sanders.

When it comes to capitalism there is unfortunately a lot of pearl clutching. You are not say something negative about capitalism and positive about socialism in polite company.</comment>