Artsy.net has had quite a bit of success with a brown field RN app. We adopted RN in our iOS app in 2016 and gradually used it to render more and more screens in the app. In 2020 we decided it would be nice to have an android app, and we spent the last year incrementally refactoring the app infrastructure from Objective-C to TypeScript to support that. Crucially we did the entire thing with a tiny team of 1-3 people and without blocking any product engineers from shipping new features.
We had occasional tooling issues like you describe but all fixable. I'd be happy to go through the same process again.
Willing to relocate: Probably not, but perhaps if the right opportunity comes along.
Technologies: Currently focused on TypeScript, GraphQL, React Native and Node. Previously Java, Clojure, Web.
I'm a darn good full stack product engineer with a lot of experience building and refactoring web/mobile client infrastructure. I've got solid UI design skills and a keen sense for UX. I'm good at planning and executing long-term refactors, building core app infrastructure, optimising CI workflows, automating processes. I put business value and happy users above software craftsmanship, but I've spent a lot of time maintaining old codebases and I have a good understanding of how architectural decisions, and even idiomatic patterns, can impact developers' productivity years down the line.
If you're building modern developer tooling that touches the JS ecosystem, we should talk. Bonus points if you get to work with Rust or C++.
> Glitches as demonstrated via the diamond pattern can be avoided by traversing the graph in topological order.
This is correct for DAGs which only propagate value (as in Javelin[1] and my own library DerivableJS[2]), but for graphs which propagate events (as in Rx), topological sorting would only work for those parts of the graph which are effectively propagating value. Events don't have an inherent dedupe operation, so it is very difficult to even imagine ways in which glitch avoidance could be automatically enforced. It would certainly require semantic program analysis.
Personally I think we should be avoiding the proliferation of events (as encouraged by Rx enthusiasts) for exactly this reason. Their imperative nature makes them very difficult to reason about.
PhD dropout, 2 years full stack web dev. Good with data + functions, uses objects + methods very sparingly indeed. Designs high quality abstractions. Cares deeply about making and using good tooling. Knows how to make stuff run fast when the need arises. Wants to learn how to do event sourcing in the large. If money was no concern would be writing virtual machines (think JVM not VMWare).
> (reduce (map inc) [1 2]) ;; same as (map inc [1 2])
This is wrong. You've missed the point.
(map inc [1 2])
is actually roughly equivalent to
(reduce ((map inc) conj) [] [1 2])
which, due to the use of `reduce`, is eager. To get laziness back:
(sequence (map inc) [1 2])
Transducers are not reducing functions, they return reducing functions when applied to reducing functions. `((map inc) conj)` is a version of `conj` that calls `inc` on all the rhs args before `conj`ing them into the lhs arg.
I suspected I had to be not quite understanding something, because why would we want, say, a map based on reduce that chokes on lazy lists, in a language where laziness is important.
Who got rid of the JVM? Pixie is not Clojure 2. Clojure still exists and you can use it, but now Pixie also exists and you can also use it. There is no downside unless you think developing languages which don't run on the JVM is a waste of time.
> With goroutines the cooperation is handled by the implementation/compiler -- i.e. Yield() calls are automatically inserted by the compiler -- rather than by the programmer manually by hand.
The compiler only inserts yeilds at some call sites. It's not a total solution like real preemptive scheduling, so you still need to be careful.
trust me this was never a serious proposal