grayrest

> It took lots of mistakes, a lot of reading and shooting my own foot to finally start writing worthy code after like 2-3 years.

This is completely normal and I expect this out of any junior developer hire. My brother-in-law went through a boot camp and picked up a job writing unit/integration tests and he makes the same errors. Having to maintain your own code and seeing the consequences of your decisions gets you over this hurdle. I've seen the same for junior web devs coming out of agency work.

All languages add a bit of code to a binary to make the code you write runnable. Rust [1] and C add almost none, language like Swift and Go have to add their GC support code even if it's in the same binary, and jit+scripting languages generally come with an external runtime.

[1] https://www.rust-lang.org/faq.html#does-rust-have-a-runtime (also mentions what's in the C runtime)

I've been putting time into Rust. There will always be a need for a C-level language and I think Rust has a strong long-term future. The language as it exists today isn't going to be my all-purpose default but it might be. There are a couple major ergonomic wins coming (trait-based exception handling, impl trait) and a set of first-party language services for IDE support. I think IDE-supported Rust has the potential to be a very productive language, particularly since it's okay without IDE support.

Since this is a Swift thread, I will say that I like Swift except for the parts that are clearly there to interact with Objective C. I have no interest in doing apple os interface development but I'll be seeing how it goes as a server development language when the 3.0 preview happens in June. If Rust for all things doesn't work, core Rust + Swift scripting is the planned fallback.

> I see Rust as the big next step for the web—a language that is still a pleasure to develop in, but with excellent static typing and tight, targeted builds without the bloat and buildup I'm accustomed to seeing with current transpile-to-JS strategies.

I think this will depend on the output size of the compiled file. I've always gotten very large js files out of emscripten, which are fine for games or media decoders, but would be undesirable for (e.g.) a vdom implementation that's part of a larger framework.

Enforcement of this particular policy is one of the things I dislike most about HN. The current title is awful. It gives no information that the URL itself does not and doesn't explain why I'd care about the contents now given I've visited the repo in the past. I'm not opposed to the removal of editorializing but it should get replaced with something neutral that still captures why the URL was submitted, e.g. "Swift 3 Roadmap Update".

So in looking at the Kangax tables when the next Safari comes out, it looks like all major desktop browsers will have support of the big ticket ES6 features (arrow functions, destructuring, default params, Map/Set/WeakMap, Proxies). Unless you're doing JSX, type annotations, or upcoming stuff (async/await, decorators, object spread, class properties) you can drop transpiling from your dev workflow and only do it for prod.

Can't wait on that Exponentiation Operator and A.p.includes!

The standard response from the Rust team is that Rust should match or beat non-SIMD C++ performance and if it doesn't, you should file a bug.

Note: The first thing anybody will ask when you complain about Rust being slow is whether you compiled with optimizations turned on (`cargo build --release`) since it tends to make a 10-15x difference.

> Maybe we don't want to show the new task because it would confuse the user and it would be better instead to show a "Show new changes" button.

For the past year at work I've been working with re-frame (clojurescript) which has roughly the same model. The main difference is on the reducer side: components dispatch an event vector directly with the event keyword (action) as first element, then instead of a reducer that switches on action strings, we register a set of event handlers that take a map that looks like the app state and event vector and return an updated version with the reduce happening in the framework. It's really close. The main advantage is that the event handlers are functionally pure and we can apply middleware functions to the handlers on a per-event basis, which we use for analytics, state coordination, input validation, chained event triggering, etc.

In the same controller namespace where we're registering event handlers, we also register topics. A topic is a registered reactive computation like a spreadsheet cell. I'm sure people have built the abstraction for Redux. We'd have `tasks` and `last-displayed-task` in the app state and register `displayed-tasks` (drop-while #(not= @last-displayed-task %) @tasks) and `new-tasks?` (not= @tasks @displayed-tasks) then have the task-list component pull out of `displayed-tasks` and the button show/hide with `new-tasks?`.

The issue with Vim is that the editor has several hundred/thousand idioms and everybody uses a different subset. As an example, most people delete words with `dw` while I usually use `dt<space>` because the t/f motions generalize to subwords. Until you have the majority of your personal subset implemented, vim support in a given editor is "bad".

I've thought about doing a vim implementation for years where motions are expressed as composable functions projecting from text range to text range with commands taking a list of text ranges, mostly because I'd like to whether non-text based motions (e.g. AST based or generalized cursors) would work. I like VSCode and expect to move over to it so I've thought about starting my project but the scope of doing a good implementation is daunting.

Congrats on the 1.0 release, VSCode is a great product.

Code is not based on atom, it's based on Electron, which is the runtime (node+webkit without the UI chrome).

VSCode has lower typing latency and a more considered system for building / debugging / code completion. Atom has a richer plugin api and has been around longer so it has more plugins. I've done basic plugins for both and plan on using/developing for VSCode but I've been too lazy to write Vim bindings and not willing to use the editor without them.

I learned vim 15 years ago because I saw its history and realized that if I learned vim, I'd never need to learn another editor's key commands. If you're not going to be programming, spending 20ish hours learning the intricacies of a text editor probably won't get you a return on your time investment.

> deleting word while curser is in the middle of that word

:help text-objects

Text Objects are really the best thing about vim after the command grammar itself.

> insert parantesis around the word im on

Install surround.vim and add the following to your .vimrc (I think s duplicates c too closely for the prime keyboard position. Therefore, s is for surround):

    nmap s      ysi
    nmap S      ysa
    nmap s$     ys$
    nmap sv     gvs

You can then surround whatever text object you want. Surround the current word with `sw(`, surround the current braces with `s{(`, etc. The `sv` prefix lets you surround the thing you just surrounded: `sw"sv(` turns `wo|rd` -> `("wo|rd")`.

As a heads up, node will pick up destructuring the next time they bump v8. That's the last feature keeping me on Babel so I expect adoption to be fairly quick.

My biggest annoyance with Lambda is that it's stuck on node 0.10.x. How are language versions handled on Azure Functions?

It'd be related to inlining a function since size is a common rule there. Some searching turns up this[1] article on crankshaft from three years ago, which lists the restrictions as ">600 source characters including whitespace or 196 AST nodes".

[1] http://jayconrod.com/posts/54/a-tour-of-v8-crankshaft-the-op...

More or less. There was a minor parser combinator arms race in the Rust community a few months ago using http parsing as the benchmark and my takeaway (only half paid attention, I haven't needed to write a parser) was that they got to roughly as fast as handwritten C parsers. Example:

https://github.com/Geal/nom_benchmarks/tree/master/http

This hasn't translated into actual use in the Rust HTTP libs with hyper and rotor-http using their own handwritten parsers but I still think it might.

The simplest library for this kind of data parallelism is Rayon[1]. The README provides a nice overview and links to a series of blog posts about the details.

[1] https://github.com/nikomatsakis/rayon/

> But aren't those the goals of every browser?

They are but they're Servo's goals "for reals".

Parallelism: All current browsers are written to do layout in a single thread and the specs were written assuming this. When Servo started, whether you could write a parallel layout algorithm for the web was an open question. Servo has a multithreaded layout system that's faster than Firefox per-thread.

Security: The Rust programming language is memory safe. This prevents a large class of security vulnerabilities from happening. The number I saw was ~50% of the critical security vulnerabilities reported in Firefox in 2014 wouldn't be possible in Rust. It's also architected from the ground up to be multi-process sandboxed. I think there are other layers of defense but those are the two I know about.

Modularity: The pieces of Servo are in seperate repositories and the repos (crates) are actually used by the Rust community. Similarly, Servo pulls in crates from the broader community. This combined with the desire to port bits and pieces to Gecko makes the browser a lot more modular than you might expect. It's also designed for embedding and (I think) matches the CEF api so it should be usable wherever webkit/blink are but I haven't been keeping up with things there.

Performance: Parallel layout with a GPU-based scene graph [1] should result in a browser that's several times faster than anything currently available. The Servo team has been hesitant to really push benchmarks given the incomplete support but everything published is really promising.

[1] https://news.ycombinator.com/item?id=11175258

Should just be replacing Emscripten in the toolchain with Binaryen [1].

[1] https://github.com/WebAssembly/binaryen

> Doesn't some state belong in the component itself? Certainly there are cases where this makes sense, right?

It depends how pure you want to be. The app I'm paid to write is in clojurescript and follows the convention of keeping almost everything in the global state. The main things I'm missing is focus and cursor state in text fields. The main benefit to doing this session recording and playback. I capture every point of non-determinism in the app as an event so I get full fidelity playback from recorded event streams.

It's more work than just keeping things locally or using two-way bindings but the code to handle the sort of things you'd keep in internal state is simple so handling the events is just registering the cross-app generic handler for the event. I designed the system for capture and replay but the main benefit turned out to be that when something goes wrong I generally know the source of the problem immediately even if I didn't write the code.

To use your menu open/closed as an example, I click on the preferences menu and it doesn't open. I look at the log and don't see `[:preferences/toggle-dropdown-menu :open]`, the problem is that something's eating the mouse event and I have to walk the component hierarchy. If I do see the event, I dump the app state and look in `:preferences :dropdown-menu` and see that the value is `true` instead of `:open` so my handler is broken. If the value is correct, the problem is either in the component itself (click another dropdown and see if it works) or in the computed value chain I'm using to feed the data into the component. For everything but the mouse event, I know by convention which file and function contains the relevant code and they're almost all 5-10 lines of code. Here's what the handler would look like:

    (rf/handler :preferences/toggle-dropdown-menu
      (mw/path preferences-path)
      (mw/set-value :dropdown-menu #{:open :closed})

> Could you expand on "form input fields are rudimentary"?

All of the above except the lack of HTML5 fields. :) I don't mean to be negative, just to give reasons it's not as simple as "just slap chrome on it". I really should start contributing.

I compile Servo twice per week or so to check out the progress. It's really not ready to go as a daily browser. You can load pages, they're recognizable but generally not fully correct, the form input fields are rudimentary, and it crashes every time I go back to the previous page.

There's been one proof of concept basic chrome [1] and it wouldn't be THAT difficult to build a more robust one but I'd be much more interested in seeing it running in Electron so you could run Atom or VS Code since the domains are much more limited and rendering perf is a fairly significant limiting factor in those apps.

[1] https://github.com/glennw/servo-shell

P.S. I've never had perf issues with Firefox like you're talking about. You might want to try cleaning out your profile and if it's not that, you might have addons doing something screwy.

Do you want contributions? I've done a cursory check of the repo a couple times but my use thus far has been fairly low key and I haven't run into errors for bug reports and most of the stuff on your roadmap from last fall the sort of conceptual / organization work where outside contribution isn't particularly helpful.

This is true unless you're using cljs-datetime. The library's use of goog.date objects under the hood means that storing one in your state tree invalidates the fast equality checks that everything in the clojurescript space is assuming.

Elm is a language for writing web applications. There are a lot of good ideas in the framework and it's a fairly big influence on up-and-coming UI frameworks/approaches but it won't help you write Swift/Cocoa apps directly.

[1] http://elm-lang.org/

No more odd than using Java. There's the huge difference in libraries and tooling but I don't think any inherent feature of Rust makes it less suitable for web backends than Java. I wouldn't pitch this project at work today but somebody has to go first.

Rust makes the most sense to me in a GraphQL/Falcor type backend. The lower number of endpoints combined with Rust's perf and focus on correctness seem like a better fit than templating out web pages.

> It looks like there is some stuff on the road map to do just this, based on a merge I saw recently.

The "Trait Based Exception Handling" RFC is in final comments:

https://github.com/rust-lang/rfcs/pull/243

shouldComponentUpdate only prunes the size of the vdom tree, updates are still O(n_virtual_dom). I've always thought this was an advantage compared to alternative approaches I know about since pruning the size of the vdom tends to be fairly easy compared to, say, optimizing a KVO chain.

I ran across [1] last week. I saw another (not ractive) a month ago but I've forgotten the name.

[1] https://github.com/Lucifier129/react-lite