maxbrunsfeld

Yes it does. Currently, syntax-highlighting and soft-wrap are disabled for these files. We're continuing to work on optimizations and structural improvements to the editor that will allow it to support arbitrarily large files with the full feature set.

There's still some major algorithmic optimization to be done regarding the time it takes to run the find-and-replace search. The optimizations discussed in this blog post were more focused on the performance of editing the buffer in the presence of large numbers of search results.

> The difference seems to be that Go has a preferred way to do it: explicit case analysis and early returns.

In other words, there is no way to abstract over the case analysis in Go. It sounds like you're saying this is a good thing. I think it's bad.

> ... apparently the Rust folks can't make up their minds

Wow, I'd say the opposite. In Go, the only thing all `error` objects have in common is the `Error()` method, which returns a description. If you want to investigate the causal chain of an error (to achieve what stack-traces give you in languages with exceptions), there is no standard way, even for errors in the standard library. Some errors are basically just strings, others are structs with other fields that you can access by using runtime type assertions.

Rust, on the other hand, has the `Error` trait, which includes a `cause` method, returning the underlying error if one exists. This alone seems to me like an improvement in consistency over Go.

From the left-hand side of the `=>` arrows in the `match` expression.

> I really want Rust to succeed, but I think they took a wrong turn with error handling.

Wow, I have exactly the opposite impression. I am so excited by how elegantly error handling is done in Rust.

> Having to write all that error handling code up front is going to be a big problem for the Agile crowd.

I really disagree. At my last job (Pivotal Labs, definitely part of the 'Agile crowd'), large internal projects have been ported from Ruby to Go. There are a lot of things I don't like about Go, but one thing that everyone I worked with really enjoyed about it was the clarity and explicitness of the error handling. Exceptions are hard to reason about and hard to remember to handle; errors returned from functions are so simple. It seems like Rust's error handling has the good properties of Go's, but it allows for more abstraction because of Rust's more powerful type system. I think the Agile crowd that I've hung out with is going to love it.

Yes.

Would you mind opening an issue for this on atom/atom? There are a couple of open issues related to full-screen on OSX, but this sounds more serious than any of the existing issues.

That screenshot uses the new default UI and syntax themes. Both are called `One Dark`. I think the UI theme is quite amazing; it adapts to complement whatever syntax theme you're using. See simurai's blog post: http://blog.atom.io/2015/02/18/one-themes.html.

CTRL-h doesn't behave the same as backspace on OS-X. This makes it hard to use for me. Cool idea though.

I've been editing typescript using JetBrains webstorm. It works pretty well.

Another very cool take on this idea: https://github.com/nathansobo/space-pen

I didn't know what to make of that comment. Dynamic this-binding is used heavily in any OO javascript code; it's not a feature that should be ignored when designing the new syntax.

To me, writing 'this' as part of the parameter list for methods is more confusing than having a second arrow operator.

As another former physics student, I'm excited about this too. I think my understanding of physics would benefit greatly if the various mathematical formalisms used to describe its different aspects were unified systematically.

I'm starting to read this article carefully right now.