pea

This makes a lot of sense. I would rather they either built amazing orthoganal SaaS products and charged me for them, or had some >$100k ACV enterprise plays.

On the former, it's of course a massive shift off of their current focus and they'd get a lot of kickback from the community, but you could imagine a world where they had a model like 37 Signals/Basecamp/Hey etc. On the latter, I don't know anything about the browser market in proper enterprise and if there are many opportunities for products there - you would presume there could be some value capture though.

Not to mention that having 25cl of raki after lunch isn't really a sustainable day-to-day habit unless you are on the beach :)

Altair is SO fantastic. For the Python side, I maintain a gallery of community visualisations built in Altair, Plotly, Bokeh, Folium etc https://datapane.com/gallery/

Yep, there are some websites which _should_ be SPAs because they are actual applications - for instance, I can't imagine Google Docs or Trello as an MPA.

But, many websites are a graph of documents (like Reddit), so trying to model them as an SPA just massively increases complexity and introduces some really tricky problems. We moved from an SPA -> MPA and haven't looked back (with Intercooler/Stimulus/alpine).

One of the main parts is that, because you don't need to manage and reconcile state in two places, you have much less complexity. When we need a single component that needs to be very interactive (for instance, we have an interactive table viewer which allows sorting and searching), we embed a little bit of React or whatever -- but that's kind of a last resort, and it's as stateless as possible.

I think handling state sensibly in a pure SPA architecture is actually much more complex than people give it credit for. A Redux + React + REST architecture can be done properly - but it also introduces a huge number of potential rabbit holes which have a high ongoing maintenance cost, especially if you do not have a team of very experienced FE engineers.

New Reddit is a great testament to just how badly it go can when you fight against "the web as a collection of documents" and what browsers originally did. For instance clicking on the background of a Reddit post to then navigate you "back" in the SPA, instead of using your browser back button - it's actually insane.

None of this is to say that templates can't be a bit painful themselves at times too - not sure what happened to https://inertiajs.com/, but I quite like the idea of that approach too.

So this has gotten to the point for me where it is a big enough burning painpoint where I would pay for a service which provided passably fast versions of the web-based tools which I frequently have to use.

In my day-to-day as a startup founder I use these tools where the latency of every operation makes them considerably less productive for me (this is on a 2016 i5 16GB MBP):

- Hubspot

- Gmail (with Apollo, Boomerang Calendar, and HubSpot extensions)

- Intercom (probably the worst culprit)

- Notion (love the app - but it really seems 10x slower than a desktop text editor should be imo)

- Apollo

- LinkedIn

- GA

- Slack

The following tools I use (or have used) seem fast to me to the point where I'd choose them over others:

- Basecamp

- GitHub (especially vs. BitBucket)

- Amplitude

- my CLI - not being facetious, but using something like https://github.com/go-jira/jira over actual jira makes checking or creating an issue so quick that you don't need to context switch from whatever else you were doing

I know it sounds spoiled, but when you're spending 10+ hours a day in these tools, latency for every action _really_ adds up - and it also wears you down. You dread having to sign in to something you know is sluggish. Realistically I cannot use any of these tools with JS disabled, best option is basically to use a fresh Firefox (which you can't for a lot of Gmail extensions) with uBlock. I tried using Station/Stack but they seemed just as sluggish as using your browser.

It's probably got a bunch of impossible technical hurdles, but I really want someone to build a tool which turns all of these into something like old.reddit.com or hacker news style experience, where things happen under 100ms. Maybe a stepping stone is a way to boot electron in Gecko/Firefox (not sure what happened to positron).

The nice things about tools like Basecamp is that because loading a new page is so fucking fast, you can just move around different pages like you'd move around the different parts of one page on an SPA. Browsing to a new page seems to have this fixed cost in people's minds, but realistically it's often quicker than waiting for a super interactive component to pull in a bunch of data and render it. Their website is super fast, and I think their app is just a wrapper around the website, but is still super snappy. It's exactly the experience I wish every tool I used had.

IMO there are different types of latency - I use some tools which aren't "fast" for everything, but seem extremely quick and productive to use for some reason. For instance, IntelliJ/PyCharm/WebStorm is slow to boot - fine. But once you're in it, it's pretty quick to move around.

Can somebody please build something to solve this problem!

In haskell, a lot of the uptake in financial services is because they are writing internal DSLs to do things like modelling exotic options.

There is a good book on this called "Uncivil Agreement" which I enjoyed. It covers how, on both sides of the US political spectrum, identity trumps political issues in what people care about.

I think identity has been more of a focus of right-wing movements right throughout history, although people frequently refer to it in the context of the current US progressive zeitgeist; identity and nationalism are very intertwined. Identity and what it means to be an American plays a large role in Trump's support, for instance.

BTW, the 5000 restriction is more a "guide" for structuring your data - you can turn it off.

Also, Altair plots can certainly be used outside of notebooks! Happy to share some examples..

Hey, that's what we do at Datapane! https://docs.datapane.com/tutorials/tut-creating-a-report - you can create a standalone HTML report which contains interactive tables and plots.

You can also publish this to the web (https://datapane.com/leo/reports/stock_report_5d2925b9/), embed it into social media (https://medium.com/@leo_26134/embedding-with-datapane-366e60...), or deploy your Jupyter Notebook or Python script so that other people can run them with parameters to generate reports dynamically.

It's still pretty new, so if there's anything you'd like to see, give me a shout at leo [at] datapane.com.

I find the big benefit of Altair is that the API is so nice and composable, and because vega provides a ton out of the box to build really high quality visualisations.

For instance, if you take this (sample) report using Altair to plot Default Alive / Default Dead: https://datapane.com/leo/reports/startup_finance_report/ - the interactive code is actually relatively small: https://gist.github.com/lanthias/5a41c1e4b21ae274ddb95cf5ad1...

It's also great being able to add Altair shapes to Folium for geoplotting (as the vega geoplotting is a bit more low-level).

What I really think is missing in the ecosystem is a "vega for tables", so you could be rich, interactive tables with a similar grammar. That would rock.

Cool! Have you checked out https://github.com/bvaughn/react-virtualized too? Might be totally useless to you, but I think they've done a lot under the hood to optimise table loading.

Congrats again on a beautiful product.

Great work - really clean documentation, and it looks beautiful!

We currently use `react-table`, which is good in that it can support some reasonably large datasets (for instance, here's 2 million rows on the client-side - https://datapane.com/leo/reports/table-test/ - a bit laggy with sorting, but passable). This may not be the use-case you're going after at all, but have you run any benchmarks for how big a dataset you can support?

Do you guys think k8s is doing a job which previously the jvm did in enterprise? i.e. if everything is on the jvm, building distributed systems doesn't require a network of containers.

Can k8s success be explained partly due to the need for a more polyglot stack?

Awesome - kind of reminds me of the Renoise interface!

I had this the other day when I was reading about the origin of the word 'bear'. I found this page: https://charlierussellbears.com/LinguisticArchaeology.html

This is anecdotal, and I'm not making a "then vs. now" argument - but there was something about the exchange that I found reminicent of this 'old web', and totally devoid from the way people communicate nowadays. I can't put my finger on it - but on what social platform where would this exchange live now?

I've also seen small teams of smart engineers using decidedly "boring" stack like Django/Rails + MPA on EBS do as much as much work as a larger teams going hard on more cutting edge stuff (React + Redux + Scala on k8s).

I wonder what the deciding factor is. I used to be part of a Haskell team and it was actually net negative vs. just using something really batteries included.

The unintended benefit of this is that the battery is soldered to the keyboard. So, when your battery is failing, you can take your keyboard in to get fixed under the service programme and get a new battery for free.

Hey - I'm hacking on a product which allows you to build interactive browser-based apps/dashboards from Python and dataset blocks. You can return altair (vega) plots from your Python and they'll get rendered in the app, and we're just adding the ability to import existing Jupyter notebooks this week.

It's still really early, but feel free to have a play and create an app. Here is an example app examining using the Prophet forecasting library: https://nstack.com/apps/rdA647Q/

I'd love any feedback, and if you'd like to chat to learn more, reach out to me on leo@nstack.com.

I agree. Anecdotally, I've seen a few of companies hire large data science teams and operate them outside the context of any product management; i.e. as basically R&D arms. The problem is that most companies do not have R&D-level problems, and they do not have a good way to surface priorities to the data science team, manage delivery, etc., and the data science team ends up building a lot of stuff from scratch, or working on priorities that don't add a lot of value, or not having stakeholders really understand what they do. This isn't good for the data science team either, as it's hard for them to communicate value.

I think the pin analogy in the article is a slight straw-man and a strange choice of comparison: sure, running a data science isn't like running a factory production line. It requires experimentation and isn't deterministic. But IMO that doesn't mean it should sit outside of product management, or is completely different from building or managing a regular software engineering team: in some instances, hiring full-stack developers absolutely makes sense. In some, you will need folks who are specialised to certain problem spaces; isn't it the same in data science?

I also think that, if data science code is going from R&D into actual prod, it is helpful if it is reviewed and tested from a more software eng POV, and may end up in parts being rewritten by teams with more specialised skill sets around e.g. performance. It would put a huge onus to put on every data scientist if they had to learn this stuff (and I'm not talking like petabyte data engineering)

I've been working on a way[1] to help data scientists more easily share and run their models/code without having to spend a lot of time on the engineering side, but a big group of our users are also folks in data teams who are not experts in lots of ML or engineering (are not "full stack" in this sense), but they work with data every day and need a way to use parts of the data science ecosystem more easily. IMO upskilling these folks may be more then norm going forward than being able to hire data scientists who are also experts on the entire stack.

[1] https://nstack.com

I grew up and went to school in Silicon Valley ('02 - '08), and remember one of the most stark contrasts was the difference in sociodemographics when you crossed from Palo Alto to EPA. Crazy difference in school quality, poverty, etc; it was unimaginable that people could live so close to one another and have such a different experience. I don't remember the really extreme academic pressures in high school that OP mentioned in Mountain View/Los Altos area, though.

After recently being back, one of the things that really hit me was what a monoculture it seemed. Of course in the 2000s a lot of people worked in tech, but it had a really different vibe to it now; it was never that obvious before when you spoke to them, and peoples' parents had a wide variety of jobs. SF seemed more like a normal city. When I spend time there now, after living in London, it does seem really, really homogenous. This is quite possibly a huge bias on my part as I was a teenager.

What really flummoxes me is how my Yamaha SY99, which is a digital FM synth from 1991 with 512kb of memory and, by modern standards, a tiny, tiny CPU, manages to do things that are really CPU intensive on a normal OS (like large plate reverb, tons of polyphony, on 12 tracks at a time) without ever lagging. The only real limit I've hit on it is loading in proper samples, versus waveforms, though this[1] insane project seems to have hacked memory expansion boards for the old SY/TG random. This is a piece of purely digital equipment that is now 27 years old, and yet my phone doesn't last for more than 2 years without feeling obsolete.

Why is this? I've always wondered if these golden-age hardware FM synths provide any benefits over software (people talk about the super HQ DACs, etc., but I'm not sure if I buy that these components are better than modern commodity equipment?). The thing is, to my ear, the SY99/SY77 etc. do sound a lot better than e.g. Dexed or FM8, but is that just because Yamaha patented a bunch of the FM algos and architectures, and, with a retail price of £3,000 in 1991, they put more care into a complete end product than a VST FM developer realistically would? Or, can really low memory, low CPU, super purpose-built hardware somehow win against a modern OS?

[1] https://www.sector101.co.uk/waveblade.html

We're actually building something really similar at https://nstack.com. You can deploy your Python model into an API in one command, and then turn it into an HTTP endpoint, or build plug-and-play workflows with your data warehouse, 3rd-party APIs, etc.

I'll reach out on email!

This is really interesting. Firstly, I wonder how fundamental notebooks have becoming to the preparation phase in the last couple of years (to avoid https://cacm.acm.org/system/assets/0001/3683/long-filenames....).

It also strikes me that a lot of these problems in dissemination have been solved to a large degree in software development. I guess 'writing code everyday' and 'knowing how to architect systems and use software development principles' are getting increasingly less mutually exclusive, which lends itself well to further abstractions.

Distribution is one of the things we deal with most frequently at https://nstack.com. We let data scientists deploy their models into bit-for-bit reproducible modules which run in the cloud and can be composed with various data sources. Because these are semantically versioned and packaged on the server as bit-for-bit reproducible builds, this solves the fact that "one's own operating system and software inevitably get upgraded in some incompatible manner such that the original code no longer runs". Our background was in writing programming languages, so we took a lot of the ideas of type-safety and composition and applied them to this problem.

Actually the most common way we see dissemination solved in enterprises is folks writing back to the warehouse and using Looker / Tableau to visualise, with a workflow like:

    import Redshift:0.1.0 as Redshift
    import CustomerModel:0.0.2 as Classifier

    def workflow = Schedule { interval = "Daily"} | Redshift.query("cookies.sql") | Classifier.predict | Redshift

Looking forward to jumping into his http://pgbovine.net/cde.html project. We explored a ton of solutions here (including Nix), but ended up settling on btrfs.

Hey guys, I'm Leo - one of the founders of NStack.

We started work on NStack around a year ago, to help data-scientists productionise their models and compose them together with various data sources.

We built NStack using a mixture of low-level Linux technology, including systemd-containers, btrfs, dbus IPC, along with high-level concepts such as building a DSL, type-checker, and runtime. As a functional programming company, NStack is built using Haskell and are really excited to launch our CLI and server -- along with a sandboxed demo PaaS which you can try out now.

We'd love to hear any feedback.

BTW this is what we're hacking on at NStack.. we're building an analytics platform which gives you a high-level language which provides an abstraction over infrastructure. The aim is that data teams can productionize code without thinking about anything but business-logic and without requiring an engineering team. So you can write things like..

  nstack start "Schedule { interval : 'Daily' } | DataWarehouse { sql : "./request.sql" } | YourPythonClassifier | Postgres { insert_table : "Results"}"

..which then gets distributed on your cloud-provider. You can kind of think about it like a type-safe, distributed cloud bash!

I'm clocking off for bed, but would love to give you a demo if you're interested: leo@nstack.com.

NStack | London, UK | Full time | Onsite | Functional Developers / Data Scientists | http://nstack.com

NStack lets data analysts to do sophisticated data work in the cloud without a team of engineers. To accomplish this, we’re a building a platform for composable, data-driven microservices, using a mixture of Haskell and Linux systems (including containers, systemd, dbus, with some typed DSLs, systems code, and distributed systems thrown in.) Our aim is to use the fundamental lessons of programming languages and operating systems to provide an abstraction over infrastructure.

We’re looking for both talented programmers -- preferably with some knowledge of typed functional languages and *NIX systems programming -- and data scientists to join our team to make this a reality. It’s a challenging role, working on hard problems, and offers the chance to work with a top technical team and shape a company and product from an early stage.

NStack is funded by top-tier investors from the West Coast, the founders are both technical and ex-YC / academia, and our team is lucky enough to include world-class talent for the problem we're solving. Salaries are competitive and include generous stock options. EU applicants welcome (other visas possible). We’re looking at a range of positions and experience levels - whether you’ve just left uni or been hacking for 20 years, if you’re interested please get in touch.

Any questions please comment, reach out via leo@nstack.com, or https://angellist.com/nstack/jobs

Cheers!

NStack | London, UK | Full time | Onsite | Functional Developers | http://nstack.com

We’re a building a platform for composable, data-driven microservices using a mixture of Haskell and Linux systems technology (including containers, systemd, dbus), with some typed DSLs, systems code, and distributed systems thrown in.

Our goal is to make it as easy as possible for the next generation of developers to build the next generation of cloud services, and we're doing this by applying the fundamental lessons of programming languages and operating systems to provide an abstraction over infrastructure.

We’re looking for talented programmers -- preferably with some knowledge of typed functional languages and *NIX systems programming -- to join our small tech team to make this a reality. It’s a challenging role, working on hard problems, but the chance to work with a top technical team and shape a company and product from an early stage.

NStack is funded by top-tier infrastructure investors from the West Coast, and the founders are both technical and ex-YC / academia. Salaries are competitive and include generous stock options. EU applicants welcome (other visas potentially possible), although roles are onsite only. We’re looking at a range of positions and experience levels - whether you’ve just left uni or been hacking for 20 years, if you’re interested please get in touch. Any questions please comment, reach out via jobs@nstack.com, or http://nstack.com/careers.

Cheers!

NStack | London, UK | Full time | Onsite | Functional Developers | http://nstack.com

We’re a building a platform for composable, data-driven microservices using a mixture of Haskell and Linux systems technology (including containers, systemd, dbus), with some typed DSLs, systems code, and distributed systems thrown in. Our goal is to make it as easy as possible for the next generation of developers to build the next generation of cloud services, and we're doing this by applying the fundamental lessons of programming languages and operating systems to provide an abstraction over infrastructure.

We’re looking for talented programmers -- preferably with some knowledge of typed functional languages and *NIX systems programming -- to join our small tech team to make this a reality. It’s a challenging role, working on hard problems, but the chance to work with a top technical team and shape a company and product from an early stage.

NStack is funded by top-tier infrastructure investors from the West Coast, and the founders are both technical and ex-YC / academia. Salaries are competitive and include generous stock options. EU applicants welcome (other visas potentially possible), although roles are onsite only. We’re looking at a range of positions and experience levels - whether you’ve just left uni or been hacking for 20 years, if you’re interested please get in touch. Any questions please comment, reach out via jobs@nstack.com, or http://nstack.com/careers.

Cheers!

NStack | London, UK | Full time | Onsite | Functional Developers

We’re a building a platform for composable microservices using a mixture of Haskell and Linux systems technology (including containers, systemd, dbus), with some typed DSLs, systems code, and distributed systems thrown in.

We want developers to spend more time writing core business-logic vs. writing infrastructure, and are using lessons from building programming languages and operating systems to accomplish this. We’re looking for talented programmers -- preferably with some knowledge of typed functional languages and *NIX systems programming -- to join our small tech team to make this a reality. It’s a challenging role, working on hard problems, but the chance to work with a top technical team and shape a company and product from an early stage.

We’re funded by top-tier infrastructure investors from the West Coast, and the founders are both technical and ex-YC / academia. Salaries are competitive and include generous stock options. EU applicants welcome (other visas potentially possible), although roles are onsite only.

We’re looking at a range of positions and experience levels - whether you’ve just left uni or been hacking for 20 years, if you’re interested please get in touch. Any questions please comment, reach out via jobs@nstack.com, or http://nstack.com/careers. Cheers!

We're a startup in London (shameless plug: www.nstack.com) using Haskell to develop a containerised microservices platform, bringing in lots of low-level Linux coding along with high-level concepts such as typed DSLs.

So far it's working extremely well for us and has been a great decision - letting us build complex/reliable systems really quickly and effectively. It is also very good for attracting amazing people, and we have found a small Haskell team can deliver truly spectacular product. This does on how you architect a Haskell codebase: e.g. you could spend a ton of time focusing on the most pure approach vs. pragmatism, so it's a balancing act.