Hail VS webviz

I don't have any funding to hire right now, but I'm always happy to chat about the industry and my experience building Hail (https://hail.is, https://github.com/hail-is/hail), a tool widely used by folks with large collections of human sequences.

The other posters are not wrong about compensation. Total compensation is off by a factor of two to three.

However, it is absolutely possible to work with a group of top-notch engineers on serious distributed systems & compilers in service of an excellent scientific-user experience. I know because I do. We are lucky to have a PI who respects and hires and diversity of expertise within his lab.

I enjoy being deeply embedded with our users. I do not have to guess what they need or want because I help them do it every day.

I also enjoy enmeshing engineering with statistics, mathematics, and biology. Work is more interesting when so many disciplines conspire towards the end of improved human health.

I think this post is identifying scientific computing with simulation studies and legacy workflows, to a fault. Scientific computing includes those things, but it also includes interactive analysis of very large datasets as well as workflows designed around cloud computing.

Interactive analysis of large datasets (e.g. genome & exome sequencing studies with 100s of 1000s of samples) is well suited to low-latency, server-less, & horizontally scalable systems (like Dremel/BigQuery, or Hail [1], which we build and is inspired by Dremel, among other systems). The load profile is unpredictable because after a scientist runs an analysis they need an unpredictable amount of time to think about their next step.

As for productionized workflows, if we redesign the tools used within these workflows to directly read and write data to cloud storage as well as to tolerate VM-preemption, then we can exploit the ~1/5 cost of preemptible/spot instances.

One last point: for the subset of scientific computing I highlighted above, speed is key. I want the scientist to stay in a flow state, receiving feedback from their experiments as fast as possible, ideally within 300 ms. The only way to achieve that on huge datasets is through rapid and substantial scale-out followed by equally rapid and substantial scale-in (to control cost).

[1] https://hail.is

Broad Institute of MIT and Harvard | Cambridge, MA | Associate Software Engineer | Onsite

We are seeking an associate software engineer interested in contributing to an open-source data visualization library for analyzing the biological impact human genetic variation. You will contribute to projects like gnomAD (https://gnomad.broadinstitute.org), the world's largest catalogue of human genetic variation used by hundreds of thousands of researchers and help us scale towards millions of genomes in the coming years. We are also developing next-generation tools for enabling genetic analyses of large biobanks across richly phenotyped individuals (https://genebass.org). In this role you will gain experience developing data-intensive web applications with Typescript, React, Python, Terraform, Google Cloud Platform, and will make use of the scalable data analysis library Hail (https://hail.is). Key to our success is growing a strong team with a diverse membership who foster a culture of continual learning, and who support the growth and success of one another. Towards this end, we are committed to seeking applications from women and from underrepresented groups. We know that many excellent candidates choose not to apply despite their capabilities; please allow us to enthusiastically counter this tendency.

Please provide a CV and links previous work or projects, ideally with contributions visible on Github.

email: [email protected]

For the web based part, in terms of integration with ROS RobotWebTools (especially with RoslibJS) and rosbridge cover already a lot, so maybe you may want to first check what's available there. Webviz is also a great web based tools with many components for visualisation.

Hey HN, one of the creators here! I made it at Cruise because it was super painful to develop https://webviz.io with manual memory management (lots of ArrayBuffers), WebWorkers, etc. I thought that there must be a better way.

Very curious to hear stories from other folks building intensive stuff in the browser. How are you dealing with performance issues in Javascript? Have you tried using Rust or C++ with WebAssembly for parts of your apps? How did you make 2d/3d rendering faster? Would you want to use something like Zaplib?

Webviz is a great tool. Just drag the .bag file onto the browser window and you can start viewing the data.

Webviz is actually open source for the most part. https://webviz.io

U can try https://webviz.io/ or https://foxglove.dev/

Cruise | Software Engineer | San Francisco, Seattle, or REMOTE | VISA acceptable | https://www.getcruise.com

Cruise is building the world’s most advanced, self-driving vehicles to safely connect people to the places, things, and experiences they care about. We believe self-driving vehicles will help save lives, reshape cities, give back time in transit, and restore freedom of movement for many.

I'm an engineering manager hiring specifically for the Webviz (http://webviz.io/) team. I'm looking for frontend engineers who want to make fast, beautiful browser-based visualizations of the car using WebGL, WASM and Javascript.

Much of the work that we do on this team is open-sourced (check out the code at https://github.com/cruise-automation/webviz). Cruise vehicles produce mountains of data; we have to visualize it in dozens of different ways at a high frame rate. We recently built a Javascript object proxy that wraps all of our input binary data in an object-like interface that only parses data on access, so that we can limit garbage collection pressure and improve our frame rate. If this kind of project sounds interesting, you might enjoy working on Webviz!

Reach out directly to me if you're interested in the above (open to associate/senior/staff levels), or if you have any questions about Cruise.

PS - for those of you who have seen or used Webviz, Foxglove may look familiar. Some of our team previously worked on Webviz at Cruise, and we reused much of their code, although it has been heavily refactored, several new features added, and we have more coming soon.