Redwood: An integrated, full-stack, JavaScript web framework for the JAMstack - <AUTHOR> https://redwoodjs.com/ <comment><USER2> Congrats on the release. This feels like Rails for the javascript age. Moving from: REST => GraphQL, Sprockets => Babel/webpack, VM => Lambda, Caching => Static site, ERb => React, Active Record => Prisma, Rspec => Jest, routes.rb => Routes.js

Edit: The twitter thread from the author is a great summary of Redwood and its benefits [https://twitter.com/mojombo/status/1237441122097487873](https://twitter.com/mojombo/status/1237441122097487873)

<comment><USER3> I agree this is super exciting but those things come with a significant operational overhead that your traditional full stacks don't have.

one vm => many lambdas/microservices

react => server side rendering and state hydration, throw redux in there too

prisma => you can't beat the DB with code. Learn SQL and remove the middleman.

Jest => fair enough I guess, but I wouldn't use rspec when Ruby had minitest out of the box

Caching/Static site => wut? ... wut? there's much more to caching than HTML.

routes.js => probably great on the server, not so much on the browser.

And the best for last...

graphql => not a replacement for REST. You can do more with less by just making your client do the work or going with backend-for-frontends. If you don't understand your network then graphql is an easy vector for DOS (speaking from experience).

Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem.

I sound bitter but I'm more incredulous. I don't actually enjoy writing for the browser any more, there are too many divergent trends.

<comment><USER4> _Meanwhile I can spin up Laravel, Rails, Spring or Django up and get a solid application running in a fraction of the time while in JS land, client server arch is a seemingly unsolved problem._

This might be a slightly controversial opinion, but I don't think the time it takes to get an application running with a framework is a relevant metric. Being able to get an application up and running fast is only a useful benefit when you're first starting out and trying things. If you're choosing a tech stack and you're going to be working on something for months or years, the fact that you can see something on a screen after an hour or after 3 days is _completely insignificant_ compared to how good it is to work with in the long term.

Choosing a technology because you can start working on a new application quickly is the wrong way of thinking about your tech stack.

<comment><USER5> I think your post summarizes a major reason why so many people ended up using small frameworks and appreciating glue code after using Rails/Django.

My noob a-ha example is `rails generate devise:install` where I first thought, wow, what a time saver. Eventually I learned lessons like, perhaps authentication is too important to be hiding from your source code. In fact, maybe almost everything is.

<comment><USER6> I think it's important to learn and understand, absolutely. But a default installation/configuration which both works _correctly_ and is easy to set up is pretty damn valuable.

<comment><USER4> _But a default installation /configuration which both works correctly and is easy to set up is pretty damn valuable._

It can be, especially when you're learning or putting together lots of small projects, but my point is that people over-emphasis the benefit of that feature on a long term project. It might be fine that a framework takes a lot of time and effort to set up before you see any results, and it could actually be a good thing if that initial time means other things about the framework are better.

All other things being equal it'd great to be able to spin up quickly, but things are never really equal between frameworks. So, to me, choosing a tech stack because it's quick to initialise a new project feels like you're optimizing for the wrong thing, and potentially you're making a less optimal choice because of that.

<comment><USER7> There are a couple of reasons you want a "quickly spun up" framework. First it shows the API is thought through / not complicated. If it takes hours for you to add a basic route the framework was overengineered. The second is hiring. Rarely will you find devs with all the experience you require, so you'll have to train. Making things overly complicated increases the cost of your devs, increases training time, and generally just slows you down.

So I completely and wholeheartedly disagree. Frameworks should be as simple as they can be.

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> I'm still not sure that those entry-level frameworks using GraphQL aren't repeating Rails' ActiveRecord issues when it comes to more complex data relationships. Both work alright for "blog post" and "user" entities, but become a bit awkward when it comes to even basic CRM-type examples (contact/company/address/junctions). I know that Facebook is using this at scale, but that's a whole different issue, with lots of custom optimizations and special backends.

I've heard GraphQL proponents call joins "premature optimization", and I don't even know how to respond to that…

<comment><USER9> Prisma is definitely limited when it comes to advanced use cases. I have been using it for two years and we are now moving to postgraphile because of this. And Prisma 2 doesn't help, it makes it worse.

<comment><USER10> TBF, Prisma2 also includes a sql breakout that allows you to run whatever Postgres-flavor sql you want in your code.

<comment><USER9> Yes, Prisma allows you to run hand crafted SQL queries. That's is the bare minimum I would expect from it. Graphile on the other hand allows you to do this AND to systematically generate whole classes of such requests, through plugins.

</comment></comment></comment></comment><comment><AUTHOR> Hi! One of the Redwood authors here. I'm really excited to launch Redwood today and happy to answer any questions you have about the framework and what makes it special!

<comment><USER11> This is awesome, congrats! I love Rails but it does seem like nextjs has left it in the dust in terms of making it easy to build simple, performant front- ends in react and there's no official Rails graphql solution yet either. What next is missing is a blessed omakase way to deploy it with a DB.

Can you talk about or point me to docs on the different philosophies between this and nextjs? In particular next already makes bundle optimization, splitting, lazy-fetching and serverless deploys pretty automatic. Why not start with next and work on incorporating the DB/business logic functionality? Related: why Prisma?

<comment><AUTHOR> Next.js is really great, and has definitely helped push the industry forward. I'm not a fan of the way they handle routing, though, and we need to be able to evolve Redwood without fighting against our dependencies. If I had to guess, we may end up writing our own versions of other things as time goes on. We're all about integration, and sometimes you have to own things yourself to make it all work as seamlessly as possible.

<comment><USER12> FWIW we use Next.js without the pages folder convention, we use a routes.js and just have the pages folder as a build artefact, then we have relatively seamless integration with Relay to make data management super straightforward.

</comment></comment></comment></comment><comment><USER13> Congrats on the launch, Tom & the team!

I'm working on something similar. I hope to pick up some ideas ;)

My project is about helping create more traditional JavaScript applications, not necessarily JAMstack. It is inspired by the Self programming environment created at Sun Microsystems in '95, so it's not a framework per-se, but a combination of a framework, an editor (VS Code plugin) and (in the future) infrastructure.

The project is called Huncwot: [https://github.com/huncwotjs/huncwot](https://github.com/huncwotjs/huncwot)

* it supports TypeScript out of the box * it provides background processing (via Postgraphile Worker) * it aims to support _only_ PostgreSQL, so that we could conveniently use all those beautiful PostgreSQL features that are usually «hidden» by ORMs * I'd also like to make SQL more popular ;) * there is a bit of inspiration from Clojure * it favors the function composition, e.g. for handlers * it comes with a built-in authentication/authorization, which you shouldn't probably use in production just yet * it is still very alpha * for the front-end you can use React, but also Vue.js and possibly Angular or Svelte * and many other things which I haven't yet described in the README as I work on this on the side, mostly alone

There is also fantastic Dark Lang ([https://darklang.com/](https://darklang.com/)) in the same, quite similar yet different.

<comment><AUTHOR> Cool! I'll take a look and see if there are any ideas we can pick up from YOU! I love that so much area is being explored in the JS world right now.

</comment></comment><comment><USER14> The latest update from Next.js [1] seems to cover all that redwoodjs does. In particular, the Static Site Generation portion. Next.js already supports API's in the same monorepo.

[1] [https://nextjs.org/blog/next-9-3](https://nextjs.org/blog/next-9-3)

<comment><USER15> Next is limited to browsers and doesn't prescribe how you access data. I would compare redwood to meteor.js but not next.js.

<comment><USER16> Is Redwood _not_ limited to browsers?

<comment><USER17> Correct. One API. But chose the client (or as many) that you want.

<comment><AUTHOR> Like David said, we currently only help you build a web frontend, but we intend to eventually make it super nice to build a mobile app, desktop client, CLI, etc. All under the redwood umbrella (canopy?).

<comment><USER7> KISS / Single responsibility

</comment></comment></comment></comment></comment></comment><comment><USER15> Congratulation on launching!

I like rails, but in js world may be not so good idea to reimplement or integrate everything related to ui, routing etc. Meteor.js was not very successful with this model. I think routing or UI on react- native/web/blessed/VR is too different to be part of one framework.

But I see the usefulness of framework with functionality related to data fetching and business logic.

I consider perfect stack for this things is Postgress->Hasura (or also Prisma)->mst-gql->mobx-state-tree. You create database schema and everything up to models on client is autogenerated and each part of this stack could be updated, customized or completely rewritten. This stack could be used on react-native or web or any other js platform.

<comment><USER18> Because react killed it and by the time meteor switched to react from blaze lot of people had moved on.

<comment><USER19> If I remember correctly, React was only part of it. Lack of support for relational databases was a big issue as well. On top of that, people realized that they didn't need real time functionality and the overhead (and scaling) of mini-mongo et al was a difficult venture. Take with a grain of salt. This was all very long ago so my memory may not be accurate.

</comment></comment></comment><comment><USER20> At first I thought "oh great, this looks very nice but why does it exist when Next.js, Gatsby, etc. are already a thing?"

Then I saw Tom Preston-Werner's involvement and my interest level raised considerably. I'm still not sure if there's a market for this per se, but the bone-fides of the dev team is certainly a good sign.

<comment><AUTHOR> Thanks for the kind words!

Redwood started as an experiment, and we'll see where it goes, but my intuition is that it will fill a need that many React developers currently have (namely: the lack of integrated solutions to all the technologies available in the ecosystem). It's certainly something that _I_ want!

<comment><USER21> How tightly is it tied to React? Would it make sense to try to use with another client side layer?

<comment><AUTHOR> Quite tightly at this point, as really nice integration is a primary goal. That said, it's not impossible that another rendering layer could be used, but it's not our focus right now.

<comment><USER22> I appreciate the focus. React might not be everyone's choice but what the JS world is missing is super tight integration between multiple tools. We forgot everything Rails taught us. People who want to pick their own technologies already have the ability to do so today, what's missing is one off-the-shelf convention-over-configuration solution to be the Rails of JavaScript.

Good luck to you guys.

</comment></comment></comment></comment></comment><comment><USER23> Just want to chime in that I think this looks very promising but I would really want to see full TypeScript support before I picked it up. In particular what would be a killer feature for me would be sharing model types between api and web sides. This is something currently possible (using e.g. lerna) but not trivial to setup for my smaller projects, and if it was a feature of Redwood I'd seriously considering switching my tech stack for future and possibly current projects.

Will be watching it with great interest. Good luck!

<comment><USER24> Thanks!

We'll definitely support Typescript, we're almost there and will make the experience feel amazing.

The boundary between the API and WEB sides is GraphQL and we're looking at making the schema typing available on the WEB side.

We're using yarn workspaces!

</comment></comment><comment><USER25> While prisma2 is probably the best node ORM, it still has a lot of issues. It seems to take a lot of inspiration from the mongo api, which is a good idea, as that is the one thing mongo got right. There are a bunch of issues with it though:

It should be closer to the mongo api.

      await prisma.users.findOne({ where: { id: 1 } })

should just be

      await prisma.users.findOne({ id: 1 })

for example.

It is trying to do too much. There is a hard limit of where ORMs try to take over too many of the things you do in SQL and become slow and complex and a big black hole. prisma tries to do migrations, table creation, etc, etc. These things rarely work properly.

Lazy loading never works. Somewhere litered in your code you access a field that is outside the scope of the pulled in data and it is in a loop and suddenly you have 100 requests. You have to look through your entire function to understand which fields are inside and outside of the scope of the query, and add more includes or whatever.

There are security issues with ORMs that traverse and save relationships, as github itself found out. You add user__roles form field maliciously on the client side to a form that was just supposed to update the user and not the roles, then suddenly you find your user.save() method on the server-side has traversed and added new roles to a user.

I am writing a kind of orm today based on the mongo api without all the $ signs, much like prisma, but closer and without all the additional things. github username is thebinarysearchtree.

ORMS should just be for fairly simple, single table tasks. That way they get out of the road and don't become some big complex thing that ruins performance and adds its own complexity.

<comment><USER26> You should check out the .NET platform with ASP.NET framework and Entity Framework ORM. It's the gold standard when it comes to these tools and has none of the issues you mentioned. There's even Blazor now to for frontend UI powered by WebAssembly or server-side websocket connection.

</comment></comment><comment><USER27> Please excuse my ignorance, what is JAMstack? I couldn't find an explanation on the landing page or the README.md.

<comment> undefined-1 JavaScript, APIs, and Markup.

[https://jamstack.org/](https://jamstack.org/)

<comment><USER28> What does the markup stand for ? I get JavaScript and Apis.

<comment><USER29> Markup refers to html, or the fully rendered result.

</comment></comment></comment></comment><comment><USER30> congrats on the launch! I've been hoping for someone to make a "Rails for JS" for a long time, with the performance capabilities of JAMstack apps (prebuilt, served from CDN). This is a peek into the future!

as a React dev as well, I particularly like the integration of GraphQL into the Cell format. This will work especially well with render-as-you-fetch React Suspense. I think if you throw in scoped css you'll have the ultimate vision of the React Single File Component format.[1]

1: [https://www.swyx.io/writing/react-distros/#what-other- react-...](https://www.swyx.io/writing/react-distros/#what-other-react- distros-should-exist)

<comment><USER24> Thanks! I was very nervous about how people would receive the concept of Cells, but people seem to like it, and we'll improve the implementation!

I personally love styled-components and I had tighter integration with it in the start, but we decided to not be opinionated about CSS frameworks... That may change ;)

</comment></comment><comment><USER31> Is there a plan for how backend jobs would work in this "Rails for the Javascript age"?

I find that JAMstack is great until the need for recurring or out-of-band processes comes up. In Rails of course there are jobs that can be backed by Sidekiq or what have you, and additionally on a VM one can always set up a cron job to invoke some Rails tasks.

For JAMstack there is no clear alternative, as far as I can see. Manually setting up a recurring lambda function (granted, I have not yet done it) seems to be annoying enough that I would rather just deal with a VM instead.

<comment><USER32> My understanding is JAM stack refers to mostly the frontend, being a statically generated site, and talks to server via API, but doesn't dictate anything about your API server or server side jobs, etc. You can still run serverless/lambdas, or actual backend API servers, or whatever else you want to do.

I guess Redwood's model is a little more than JAM stack, since "Rails" for JS would imply it does a lot more than the JAM part, and that's what it looks like on the site.

<comment><USER17> We are stretching the definition of "JAMstack" here. But the primarily intended emphasis is not just React+API -- it's making structure+design choices that target serverless infrastructure out of the box. It's not perfect and we have a ways to go, but being able to deploy fully serverless is what RedwoodJS is all about.

</comment></comment></comment><comment><USER33> Great presentation.

I took a look at the example:

[https://github.com/redwoodjs/example- blog](https://github.com/redwoodjs/example-blog)

As I understand "JAM Stack" the point of the M is to have large chunks of your application pre-rendered.

However in this example; the blog pages are client-side rendered based on a graphql query that goes into postgres database.

Am I missing the point of this? It looks like a standard rich-client with API backend architecture.

<comment><AUTHOR> Your understanding is accurate. We do plan to support pre-rendering on a route-by-route basis, which will perhaps be more inline with what JAMstack tends to mean today. But Redwood is still all about JavaScript (client) and APIs (backend), with markup to follow, as I just mentioned. But more than that, it's about the development and deployment philosophy of JAMstack that we fully embrace.

</comment></comment><comment><USER34> Surprised to see it not written in TypeScript since TS helps immensely with large projects

[https://github.com/redwoodjs/redwood](https://github.com/redwoodjs/redwood)

<comment><USER35> > "We are working on full end-to-end TypeScript support for Redwood, all they > way from the DB schema definition to the frontend and back via GraphQL. It's > in the works!" \- Tom Preston-Werner > ([https://twitter.com/mojombo/status/1237474978825564162](https://twitter.com/mojombo/status/1237474978825564162))

</comment></comment><comment><USER36> Typescript support? Javascript is just too hard for larger projects.

<comment><AUTHOR> Yes! Our intention is to support TypeScript as a first-class citizen in Redwood apps (while still supporting JavaScript as well). We're currently working to make sure all of the framework code is written in TypeScript.

<comment><USER37> Cool. Are named routes typesafe? In other words, if I change the name of a route, does it cause some sort compile time error?

<comment><USER24> I've created this issue to keep track of this: [https://github.com/redwoodjs/redwood/issues/206](https://github.com/redwoodjs/redwood/issues/206)

</comment></comment></comment></comment><comment><USER38> this is very interesting. nextjs gives a lot of this : for example

\- frontend and backend in the same code [https://nextjs.org/docs/api- routes/introduction](https://nextjs.org/docs/api-routes/introduction)

\- graphql based - [https://github.com/zeit/next.js/tree/canary/examples/api- rou...](https://github.com/zeit/next.js/tree/canary/examples/api-routes- apollo-server-and-client-auth)

\- hybrid static page support - [https://nextjs.org/blog/next-9-3#next-gen- static-site-genera...](https://nextjs.org/blog/next-9-3#next-gen-static-site- generation-ssg-support)

\- jest - [https://github.com/zeit/next.js/tree/canary/examples/with- je...](https://github.com/zeit/next.js/tree/canary/examples/with-jest)

\- CMS providers - [https://nextjs.org/blog/next-9-3#collaboration-with-cms- prov...](https://nextjs.org/blog/next-9-3#collaboration-with-cms-providers)

\- pretty url routing - [https://github.com/zeit/next.js/tree/canary/examples/with- pr...](https://github.com/zeit/next.js/tree/canary/examples/with-pretty-url- routing)

</comment><comment><USER39> I think this looks interesting, and I applaud the team.

That said... am I the only one that thinks that anything that is JS based seems ridiculously complicated to use? I don't do much UI work, but any time I look at using react or similar it feels like there are a lot of moving parts and a lot of steps to perform before you can even get started on something useful.

<comment><USER40> Eh, I feel like that's any web framework in any language. Take Django for instance. If you're doing a very boilerplate project, then it's pretty slick. But as soon as you start trying to do any customization you go down a rabbithole of subclasses and mixins, where looking at the source is usually more helpful than the documentation.

I think the reality is web applications stand on the shoulders of lots of giants. We're only able to get anything done thanks to abstraction that someone else did for us. We still have a need to see below the surface occasionally, though, and finding the balance between readability and customizability is an eternal struggle. Plus, everyone has their preferences: I hated Angular at first because of its steep learning curve, and now love it for its strictness.

<comment><USER39> I guess my feeling comes from spending time with opinionated frameworks like Rails. There are sane defaults and you're up and running quickly. Any time I look at something like React or similar, the instructions for getting started are written like "If you're using yarn, do this. If you're using grunt, do this other thing". I don't have either, so now I have to choose one before I can proceed. Instead, I just close the browser tab and go on to something else.

</comment></comment></comment><comment><USER41> Nice!

Building any "Rails for JS" idea is a huge undertaking, purely from the sheer scope of the Javascript (inc. NodeJS) ecosystem.

</comment><comment><USER42> Congrats on the launch. Looks interesting coming from rails stack. I hope you guys can develop a good community around this.

</comment><comment><USER43> hi, just reading through the tutorial and want to say, it's quite enjoyable and beautiful to read. Personally I feel and many would agree that docs and tutorials deserve equal if not more effort for tools that are aimed at making our lives easier. Please keep making the docs stronger.

<comment><AUTHOR> Thanks for noticing our hard work! We spent a LOT of time making sure the tutorial was rock solid and very clear. We will continue investing time into making the tutorial and our docs even better!

</comment></comment><comment><USER44> > For now, you need to set up your own database, but we are working with > various infrastructure providers to make this process simpler and more > JAMstacky.

I recently stepped through this tutorial, which does somthing similar, and uses FaunaDB - turned out pretty nicely.

[https://egghead.io/playlists/building-a-serverless- jamstack-...](https://egghead.io/playlists/building-a-serverless-jamstack- todo-app-with-netlify-gatsby-graphql-and-faunadb-53bb)

Code for the DB part is here - I know it doesn't use Prisma, would be great to see Redwood support this: [https://pastebin.com/aJvFSjsa](https://pastebin.com/aJvFSjsa)

</comment><comment><USER45> Glad to see more batteries-included solutions to frontend development. In particular, I'm glad to see you've addressed a lot of the pain points with building a fullstack application with React: Forms, lack of "laravel artisan- like" CLI generators, integrating GraphQL (and picking between one of the many server and client-side libraries/frameworks).

I only had time for a brief look through it but searching for "redux" and "state" didn't bring up anything; do you have an opinionated approach to global state management?

Keen to check this out when I have more time this week!

</comment><comment><USER46> Nice work! And a good project page. One thing: there's a concept used but not introduced, which, at least to me, does not ring a bell... What's "SDL" in the context of Redwood?

<comment><AUTHOR> That's the Schema Definition Language native to GraphQL.

<comment><USER46> Ah. Thanks for clarifying, maybe im not the only one a little confused. I'd call 'm "GraphQL schemas (SDL)" on the landing page to avoid confusion for some visitors.

</comment></comment></comment><comment><USER47> Congrats on the release, you've certainly done a great job documenting it and creating a great webpage. Hope I will put my hands on it soon.

One question, is the React app being pre-rendered at all before being stored on the CDN? If not, how does it qualifies as a JAMstack project? If the React app is being completely rendered on client side, then I don't see any difference with a regular Next.js (without generating a static site) project but I certainly see lots of differences with Gatsby for example.

<comment><AUTHOR> We are currently not doing any pre-rendering, but it's on the roadmap to enable pre-rendering on a route-by-route basis. Even so, Redwood is still JAMstack because it's JavaScript, APIs, and Markup; it's just that we're delivering the entire client via JavaScript, and the API is our entire backend. Our goal is to let you build a full-stack web app but still deploy in the JAMstack style. We're pushing the boundaries of JAMstack intentionally!

</comment></comment><comment><USER48> This is incredibly ambitious: every subheading on the landing page, such as form validation & handling, routing, service logic, is enough to have many big libraries already working on the problem. Yet here's this thing that says here it's all wrapped up in one solution. Historically, Vue has more than demonstrated that well opinionated whole solutions can be very popular on the frontend too so it's interesting to follow where Redwood will end up.

<comment><USER24> Thanks, sometimes I need to take a step back and realize the scale of what we're building!

Thankfully, we're building on the backs of giants here.

We're glueing a bunch of the technology together in a way that makes it feel idiomatic, documenting it and asserting our opinions on how to use it.

</comment></comment><comment><USER49> Kind of unrelated but love how we moved on from Docker in development. Most of these new frameworks are not suggesting you run the app in Docker.

I hate docker in development!

<comment><USER50> I'm on the opposite side - maybe thanks to Docker I got lazy or something but when I don't see docker (or even better - ready to use docker-compose file with whole required stack prepared) then I think I'm like 10 times less eager to give it try.

</comment></comment><comment><USER51> While this looks great I'm having trouble fitting it to any of the projects I'm already working on.

We already have all those pieces in place, along with the ability of swapping any one piece with a different one; say, if we wanted to go RESTful we only need to swap one block.

It does look gorgeous tho; how would one go about gradually adopting it?

<comment><AUTHOR> As a fully integrated framework solution, it may be hard to gradually adopt Redwood, and that's ok. If you already have a setup you like, and it gives you the flexibility that you need, then that's awesome! I want Redwood to be around for the majority of devs that don't already have a sweet setup going, and are lamenting the endless hours of choosing, setup, and integration ahead of them just to get something started.

<comment><USER51> First things first, thank you very much for the fast response!

It's very true that all the prepwork is pretty costly, hence my eagerness to try and adopt random bits and pieces even at this stage; it might end up saving us time down the line haha

While I have you around... what would be a good toy to build with this? Our megalithic, business rules heavy app sounds like a potential good fit for the Redwood, but it's entirely too large a bite to tease our engineering leads with.

</comment></comment></comment><comment><USER52> The further from the metal you are the harder it will become to do even the most simple of things. In this case, the code will be "compiled" up to ten times before it hits the metal. And every time some information will be lost, and unnecessary extra instructions will be added. / Debbie Downer

<comment><USER53> >The further from the metal you are the harder it will become to do even the most simple of things

>And every time some information will be lost

Maybe from an embedded systems/OS point-of-view, but these statements are just not true on the web.

</comment></comment><comment><USER54> This look great. How does this compare to other JS fullstack frameworks like Vulcan.js, Meteor or Keystone?

</comment><comment><USER55> Nice to see the JS ecosystem taking this route: fullstack frameworks.

Just like Next.js was built for zeit/now, redwood was built for Netlify.

Since Top Prester-Werner (Author) is in the board of Netlify this makes sense. But is it a good idea for frameworks to be tied to specific deployment platforms? Unsure, we'll see!

<comment><AUTHOR> While Redwood is currently optimized for deployment on Netlify, it is by no means restricted to that environment. Our intention is for Redwood apps to be deployable to a variety of JAMstack providers in addition to traditional serverful setups. My main interest is in providing an integrated, joy-inducing experience for app developers that want to leverage the full awesomeness of modern JavaScript and friends. It's true that if Netlify wins, I win too, but I'd rather DEVELOPERS win, and that's what keeps me motivated.

<comment><USER55> Thanks for the honest answer here!

</comment></comment></comment><comment><USER56> Congratulations, but I don't think I'll use it, I don't like being forced to use GraphQL

</comment><comment><USER57> Congrats on launching! I'm super jealous of that quality landing page. Is it built from scratch?

<comment><USER17> That's all @cannikin doing!! Here's his framework, opinions included :) [https://github.com/cannikin/cameronjs](https://github.com/cannikin/cameronjs)

</comment></comment><comment><USER58> Really big fan of everything in this stack; I've been building my product on React/Apollo/Prisma/Postgres and it's been a pleasure. It's nice to see a well-thought-out architecture added to the process. Great work.

</comment><comment><USER59> Damn this looks pretty promising.

<comment><USER24> Thank you!

</comment></comment><comment><USER60> Interesting the documentation uses the term "generators" to refer to scaffolding tools. I read that word and got excited that they had python-esque generators.

</comment><comment><USER61> This is really great. Node.js really needs more of these type of frameworks. I for one would love a non-Graphql version.

<comment><AUTHOR> Thanks! What would you use instead of GraphQL? Curious what your specific needs are.

<comment><USER62> I'm personally in the same boat (and use a philosophically similar JS-based framework called SailsJS instead, right now)

For me: I need services that support the UI, as well as a public-facing API with basically the same data. I don't have the time/resources to build/maintain them separately, and my perception is that GraphQL and the wider ecosystem around it haven't yet reached the same level of ubiquity/maturity as plain-old REST.

A single, well-designed REST API that can be consumed by my own UI as well as public clients is how I'd prefer to handle it right now.

<comment><USER63> Would have to agree. GraphQL is kind of a non-starter for every project I've worked on in the past few years, and a GraphQL ONLY framework is right out.

</comment></comment></comment></comment><comment><USER64> Will this work with Cloudflare Workers?

<comment><AUTHOR> Unfortunately, no. Cloudflare workers are heavily restricted in what they can do, both from an outbound request and compute time perspective. If those restrictions are reduced, it's possible we could make it work someday. It sure would be awesome!

</comment></comment><comment><USER65> This does look great compared to previos efforts like Sails. Is there support SSR out of the box?

<comment><AUTHOR> Not currently, and we will prefer pre-rendering to SSR if we can make it work well enough. But we are planning to address SEO concerns.

<comment><USER65> Great stuff - looking forward to exploring this properly.

</comment></comment></comment><comment><USER66> Could someone explain how this compares to Next.js?

<comment><USER30> next is primarily focused on the rendering layer, capable over static, server, and serverless rendering. it makes it easy to set up api routes but doesnt have any opinions whatsoever on data layer.

redwood is full-stack, has an opinion on graphql/prisma as part of your data layer, integrated into Cells for declarative loading states. its still super early days but you can feasibly view it as doing the same thing Rails does in terms of organizing and picking techs for you for all parts of a stack, including setting up scaffolding for you.

</comment></comment><comment><USER67> hey guys, ever heard of meteor.js? It's pretty cool too! [https://github.com/meteor/meteor](https://github.com/meteor/meteor) [https://www.meteor.com/](https://www.meteor.com/)

</comment><comment><USER68> > JavaScript

No thanks, we have Blazor now.</comment>


Water Out of the Tailpipe: A New Class of Electric Car Gains Traction - <AUTHOR> http://www.nytimes.com/2016/07/22/automobiles/water-out-the-tailpipe-a-new-class-of-electric-car-gains-traction.html?hpw&rref=automobiles&action=click&pgtype=Homepage&module=well-region&region=bottom-well&WT.nav=bottom-well <comment><USER2> The big piece left out of the discussion about hydrogen often is the energy costs for producing hydrogen. It is either produced by extracting hydrogen from natural gas which produces CO2, or by electrolysis from water. In both cases, the hydrogen has to be compressed up to 700 bars for transportation. In the hydrogen car, the fuel cell produces electricity to drive the car. The net result is, that the hydrogen car has perhaps a 30% efficiency of the electricity reaching the motor. A battery powered electrical car has about 90%.

The bottom line is, for the same amount of primary energy, a pure electrical car gets 2-3x the range of a hydrogen car. And of course, that directly translates into the costs of driving.

The article also gives some off number about electrical cars: they are not limited to 200 miles of driving - a Tesla does up to 300, and recharging at a supercharger station takes about 30-45 minutes. And, of course, in contrast to a hydrogen car, an electrical car can be recharged over night at home, so most trips do not require any recharging at all.

<comment><USER3> Recharging your car at home at night only works for suburban US (and some parts of Europe), there are also lots of people like me who live on apartment flats 8 or 10 storeys high who cannot use that. There's also the issue with what happens to the battery, long-term, when you're driving your car at -15 Celsius in the winter and at +38 in the summer. I agree, though, for most of the HN demographic (own their own suburban homes, live in CA) owning a Tesla is feasible.

<comment><AUTHOR> > there are also lots of people like me who live on apartment flats 8 or 10 > storeys high who cannot use that

Why is installing a few NEMA outlets in the parking garage not an option? My HOA did just that, and while we still need to figure out the etiquette of taking turns (there are more vehicles than available outlets), it's not an architectural issue for most buildings.

End of the day, though, this is less about charging availability and more about range after a single full charge - you don't expect your apartment complex to host a gas station, for example, but you go out of your way to fill up at one and then drive on a full tank. Gasoline vehicle's top-of-the-line range looks to be 600 miles (Toyota Prius has a 12-gallon tank, so multiplying that by 50 MPG), top-of-the-line Tesla Model S is 90D with rated 292 miles of range, so I'd say things are getting pretty close to where one could drive to a Tesla SuperCharger, spend exciting 20-25 minutes there, and then drive charge-free for the next 4-5 days, with perhaps occasionally charge-up at the office, train station, or the mall.

<comment><USER4> A huge number of European apartment buildings have NO on site parking spaces whatsoever. Look at most of the apartments in Berlin for example. It's all street parking, or you have to rent a space in a parking garage somewhere.

</comment></comment></comment></comment><comment><USER5> Have they solved the problem of where hydrogen comes from? Last time I looked this up, the main process for making hydrogen is the shift reaction, which is hardly carbon neutral.

<comment><USER6> Just as electricity for EVs produced by coal or natural gas power plants is not carbon neutral.

<comment><USER7> But with both cases, something clean is at least possible. Solar/wind/stuff not invented yet, could be the source. Phase out the coal and you're done. When petroleum-based combustion happens in the car, you probably wont ever get carbon neutrality.

<comment><USER8> Well, if we are talking about not-yet-invented stuff, we might also someday have feasible artificial hydrocarbons or corn-fuel farms run with electric combines. Nether one of those would require a fundamental change in car design.

<comment><USER7> All I meant there was that it can be changed and blended instantly, electricity is electricity. Look how long it's taken to change sulphur, lead, ethanol, etc in the us gas supply. And this still requires work for the existing fleet of cars.

</comment></comment></comment></comment></comment><comment><USER9> I thought hydrogen had been debunked by now.

Tesla had a great 'well to wheel' efficiency analysis post on their blog a few years back that killed any notion of a hydrogen economy.

<comment><USER10> They quote Mr. Musk in the article, but it seems Toyota and Honda feel differently.

<comment><USER11> Here in Michigan the Big 3 have promoted hydrogen for a long time. But other than small level fleet tests its never been a real option.

The stories cycle back every couple of years. In fact it reminds me of PG's old submarine essay:

[http://www.paulgraham.com/submarine.html](http://www.paulgraham.com/submarine.html)

</comment></comment></comment><comment><USER12> Once you start filling your electric car every night from a plug in your garage, the idea of (weekly?) driving to one of a handful of special hydrogen fueling stations is seriously unattractive. In fact, filling up the old gasoline car becomes annoying.

This article definitely reads like a PR piece from an oil company (which is, after all, where the hydrogen comes from). The New York Times has a history of biased journalism against electric cars...

<comment> semi-extrinsic As I've said before, going all-in on EVs are a non-starter in some areas (esp. Japan) because they can't produce enough electricity locally, and they can't import it from a trusted ally. Hydrogen, OTOH, can be shipped over long distances.

<comment><USER12> I've never seen a hydrogen tanker. Have you? At that point, you might as well ship LNG or refined gasoline.

</comment></comment></comment><comment><USER13> > _Battery electric vehicles are still limited to a maximum of about 200 miles > of driving before a recharge is required, and charging up can take time — > four hours or more in some cases. Batteries are also heavy, which presents > challenges for powering larger vehicles like trucks or SUVs._

I had not considered the weight disadvantage of Li-on. Perhaps we'll have two technologies side by side: batteries for smaller, more centrally-located vehicles and hydrogen for larger and more remote ones.

The energy-intensity of enriching, packaging and distributing hydrogen looks less daunting in a duck-curve [1] characterised solar future. One could simply generate hydrogen when rates drop below a threshold.

[1] [https://www.caiso.com/Documents/FlexibleResourcesHelpRenewab...](https://www.caiso.com/Documents/FlexibleResourcesHelpRenewables_FastFacts.pdf)

<comment><USER14> Weight is practically immaterial, the majority of energy required to drive is in pushing air out of the way, drag.

<comment><USER15> F =ma. The force you need depends on your acceleration requirements. Going uphill, taking turns, slowing down etc all make mass/weight very material.

Edit: I know weight and mass aren't the same but we are all considering the same gravitational pull so we can disregard the pedantic argument...

</comment></comment></comment><comment><USER16> The two Achilles heels of fuel-cell automobiles have been the cost of the fuel cell itself, and sourcing the hydrogen needed to fuel it.

Fuel cells typically use a lot of highly-expensive catalyst, with full costs on the order of a million dollars each. Odds are good the sales price of these vehicles (just under $60k) represents a small fraction of the manufactuer's actual costs. This is a test pilot for real-world experience.

Hydrogen is the other problem, both in sourcing it and in distributing and dispensing it. Hydrogen is an _energy carrier_ , not an _energy source_ [1], but an _energy carrier_. You need some other source of energy to _provide_ hydrogen, usually via hydrolysis, or from some hydrogen feedstock, usually natural gas.

In the case of hydrolysis, your problem is the energy cost of electrolysis, which costs you about 40% of the input energy. The bad news is you get much less hydrogen energy out than electrical energy in, the good news is that you can store the hydrogen, while electricity doesn't bank well.

In the case of natural gas, you've got the sitation that your vehicle is still ultimately consuming fossil fuels, though methane (CH4) emits far less CO2 than petrol (about a C8H18) -- roughly half as much. Since you're pre- processing the methane into hydrogen, there's the option of sequestering the carbon for other uses.

Hydrogen also has extensive problems with storage and handling -- it doesn't like to be contained, will literally leak out between the atoms of containers, embrittles metals, etc., etc.

Another alternative, one I'm interested in, though 50 years of serious research[2] has yet to result in a working large-scale prototype, is Fischer- Tropsch fuel synthesis. Effectively it creates hydrocarbon fuels using electricity. The most promising model I'm aware of sources both hydrogen and carbon from seawater, hence seawater-based Fischer-Tropsch fuel synthesis. Penciling out the studies I'm aware of, it actually _could_ scale up to current US and forseable global levels of production, without literally paving the world with solar panels and/or synthesis plants[3]. E.g., not patentently impossible. The fact that the research _hasn 't_ proceeded further makes me question its ultimate practicality.

If, however, it is possible, then we end up with a fuel that is an exact chemical analog of existing hydrocarbon fuels, is infinitely miscable with them in the fuel processing, dispensing, and utilisation chain, and is carbon neutral.

And if you're generating hydrogen, you're already about 90% of the way to creating synthetic hydrocarbon fuels which avoid most or all of hydrogen's storage, transport, dispensing, handling, embrittlement, and energy conversion issues.

As I mentioned, I've looked into this in several posts, you might want to start with the historical overview here:

[https://www.reddit.com/r/dredmorbius/comments/28nqoz/electri...](https://www.reddit.com/r/dredmorbius/comments/28nqoz/electrical_fuel_synthesis_from_seawater_older/)

________________________________

Notes:

1\. Technically, so are petroleum, coal, and natural gas. Though the source energy was supplied hundreds of millions of years ago, on average, in the form of sunlight converted to plant matter. Given this, at the rate of roughly 5 million years of ancient primary production per year of current consumption, you could make a reasonable argument that the fully realised solar energy cost (what's called "emergy") of petroleum is about 5 million per single unit of energy delivered. At the very least, we're spending 5 million years of accumulation per year. Something you might want to reflect on.

2\. Brookhaven National Lab, M.I.T., and the US Naval Research Lab. Generally serious outfits.

3\. For a counterexample, see schemes for biofuels. At _best_ , present US fuel consumption would require plausibility-stretching levels of development, if not quite literally multiples of total US landmass. E.g., quite patently and evidently batshit impossible.

</comment><comment><USER17> I have always hated parking meters and felt in most cases it was just another way for cities to milk the tax payers for more money. But parking meters start to make real sense in an EV world. Instead of just buying time, the meters could have a plug so you can buy electricity and recharge the car too.

</comment><comment><USER18> One of the issues with hydrogen power that you can't use regenerative braking as easily. Of course you could run a hydrogen/battery hybrid system, but its not obvious that hydrogen would really be that beneficial in that configuration.

<comment><USER19> Aren't most of the planned hydrogen vehicles hybrids? Combusting hydrogen won't be a lot of fun...

</comment></comment><comment><USER20> Hydrogen and hydrocarbon fuels are just sources of electrons. The beauty of a real electric car is the efficiency of going directly from stored electrons to power.

<comment><USER21> Refueling time and storage equipment seems like major differences between hydrogen and battery. They both have slightly different use-cases that make different bets on future technology. Maybe one will win out or maybe both will play a role. I'm personally waiting for the Nucleon to come back.

<comment><USER20> and transportation. Hydrogen is a very inefficient way to transport electrons compared to wires.

<comment><USER21> I'm not an expert at any of this stuff and this math could very easily be wrong, but I just spent some time with Wolfram Alpha validating that claim. a 40,000 liter hydrogen truck can carry 425 gigajoules of liquid hydrogen; if it drives 500 miles, a diesel tractor trailer getting 5mpg would burn 100 gallons of diesel, that's 14 gigajoules of energy (now keep in mind that much hydrogen only weighs 3000kg - a typical load for a tractor trailer is 10000-20000kg) - if it was a fuel cell truck, it could be twice as efficient as an ICE so would only need 7 gigajoules. 7 gigajoules is 1.6% of the transported 425 gigajoules of energy. A state of the art HVDC transmission line loses 3.5% per 1000 km, so it seems like a hydrogen truck might actually be more efficient than wires.

<comment><USER20> what about locally-produced electricity ? If an electric car recharges on locally-produced electricity along its journey then we can eliminate transmission losses

<comment><USER21> There are hundreds of what-ifs that influence which will be a better choice, IMO it's not clear cut that one technology is better enough for all situations that it'll crowd the other one out of the marketplace entirely.

</comment></comment></comment></comment></comment></comment><comment><USER22> _Mr. Manning now has enough fueling options in Southern California to cover his 45-mile commute to Playa Vista with little anxiety._

Wow!</comment>


Yalo – Lisp OS running on bare metal x86-64 hardware - <AUTHOR> https://github.com/whily/yalo <comment><USER2> This seems like a cool start for a project but it may be a bit premature to share it and call it a "Lisp OS running on x86_64", because at this point it doesn't run any lisp code or run on x86_64.

Basically all it is at this point is a stage 1 bootloader in 16 bit real mode that prints out "REPL>". It does detect the CPU type and verify that it can enter long mode (64 bit mode) but never actually enters long mode.

I find it awkward that there's so much hype on HN and twitter and tons of people starring and forking it but it is rather evident that not many people actually read the code and see what it does. It seems like this project has got a few recent commits, though (after a hiatus of a few years) so there might be some progress happening.

However, what _is_ very cool about this project is the way that it is written, basically Lisp macros that implement a single pass x86_64 assembler.

Let's hope that this project gets the love and the attention it needs to actually grow into a proper Lisp OS.

<comment><USER3> D-wav quantum prototype is running a full Lisp OS. I want to work there just to actually witness a working lisp machine

</comment></comment><comment><USER4> I'm the original author (not OP), and I'm quite surprised that the project was starred by so many people in github and discussed in HN. The project was originally hosted in Google Code, and I decided to migrate to github last night.

As many of your have already commented: the project is only at very very initial stage, with an assembler written in Common Lisp, and a 16 bit bootloader. Currently I can only describe it as a toy.

<comment><USER2> Thanks for an interesting project! I have also written some bare metal OS projects before and I have a few suggestions for you.

First of all, I recommend using a multiboot capable bootloader (GRUB is one, QEMU and Bochs have built in multiboot bootloaders). This will allow you to skip some of the arcade initialization code required. In particular, loading the code from a floppy is painful because most PCs these days don't have a floppy drive. So while you'll be able to test the code on emulators, running on real hardware require getting a floppy drive. With GRUB, all you need to do is put the binary image in your /boot and you can boot on it with real hardware.

When using multiboot, the bootloader will set up 32 bit identity mapped protected for you.

Many bootloaders also support setting up a graphics mode, which will save a lot of trouble, because you'll have to drop back to 16 bit real mode to access the BIOS interrupts to change the graphics mode.

I do understand the appeal of not using a bootloader and doing things from scratch but when it comes to getting things done, that's just not a good way to go.

I also recommend staying in 32 bit mode, it's just a lot easier. In 64 bit mode you'll need to deal with paging (no identity mapping is available) and this becomes a burden very early in the project when you will need to access memory-mapped i/o devices (in particular the APIC interrupt controller) and Intel Multiprocessor configuration, which are scattered around the physical memory address space.

When you have something that actually works, it is easier to go to 64 bit mode than it is to start from scratch with 64 bit long mode. I found this out the hard way and my hobby OS project[1] stalled because it was just too much work to get anything done in long mode.

In addition, I would recommend emitting debuggable elf files instead of flat binary files. Using the QEMU/Bochs monitor will take care of your most basic debugging needs but to go further, remote debugging with GDB is going to be very helpful.

Best of luck for your project!

[1] [https://github.com/rikusalminen/danjeros](https://github.com/rikusalminen/danjeros)

<comment><USER4> Thanks a lot for your advice and sharing your experience!

</comment></comment></comment><comment><USER5> That's the kind of projects I think about in the shower or when I'm procrastinating.

I need to hack on X. \- Current editors suck, I should create an editor. \- Current languages suck, I should create a language, and I'll build my editor in it. \- Current OS suck, I'll write the OS in my editor using my language.

Meh, maybe another day, 2 hours later X is hacked in python using vim.

<comment><USER6> I did this.

I built the hardware (Z80 SBC), wrote the OS (tiny single tasking Unix like UZI180), started to write an editor (like ed). Then I got distracted with something shiny and abandoned it.

Think I blew 200 hours on that and don't even have the source now.

<comment><USER7> next time build first a source control system (and/or a snapshotting filesystem)

<comment><USER6> My host machine was MSDOS and this was before I was aware of things like VCS'. I still have the ROM and board so I could possibly disassemble it.

The actual loss was caused by a disk failure and an untested backup system (my bad)

</comment></comment></comment></comment><comment><USER8> This is incredibly similar to an assembler I wrote in Scheme, almost a decade ago. I was using Bochs and even unit testing with NASM.

I think people are going to be disappointed, if they can even get this to run in Bochs. About the only "Lisp OS" thing here is the REPL, which looks like it's incomplete anyway. Movitz is ahead of it by a bit, since it at least has, IIRC, a working compiler and possibly a driver or two.

But nothing we have today is anywhere close to what people think of, when they think "Lisp OS". However, I've used Genera, and I'd really caution people about getting this romanticized view of it. There are still many good ideas there, but Linux and OS X today are not the Unix of 1980. We've come a long way.

<comment><USER9> We've come a long way, but it's a bit tragic so many of our eggs are in what amounts to two baskets. One is the "Unix-ish" basket, where we have Linux, *BSDs, OSX, Haiku, and even Hurd. The other is the heirs to VMS, where we have Windows, which is completely opaque to research, and ReactOS.

It's nice to have people exploring OS ideas in other spaces as well.

<comment><USER8> That's true. It would be nice for a true alternative. I still think about it from time-to-time. My Scheme project was to be a SchemeOS. It wasn't even the sheer amount of work that got to me, and ultimately did it in. It was the realization that I'd have to go it _completely alone_.

I was a lurker for years when the TUNES project was going on. I won't say a new "from scratch" OS is impossible, but I will say that TUNES ended up with a death by a thousand bike sheds. Linux worked thanks to POSIX and other *ix systems in existence. The groundwork was there. There was a model. Anyone that wanted to contribute knew what a Unix looked like and how a Unix functioned.

Not so with any LispOS. Or TUNES. It's a new thing, wholly different from anything that existed before. The few people that had access to Genera weren't going to want to replicate that for reasons that become apparent when using it (it's quite outmoded in many ways). And since there was no Genera community and nothing to really salvage there, it made more sense to start over anyway.

With all that said, I believe the true appeal of a LispOS is that it's homogeneous. It's Lisp from top-to-bottom. Which means it's great for programming at any level, great for productivity. But not so great for people that love variety in languages.

</comment></comment></comment><comment><USER10> See also Movitz: [http://www.common- lisp.net/project/movitz/](http://www.common-lisp.net/project/movitz/) and Lithium: [http://github.com/nathell/lithium/](http://github.com/nathell/lithium/)

<comment><AUTHOR> I saw this from xach's tweet [https://twitter.com/xach/status/427490779326451712](https://twitter.com/xach/status/427490779326451712)

suggesting movitz isn't moving anymore, but maybe I'm reading it wrong.

</comment></comment><comment><USER11> Excitedly tried it out, but I get this error on both 32-bit and 64-bit ubuntu:

      $ git clone https://github.com/whily/yalo
      $ cd yalo/cc
      $ ./lnasdf
      $ sbcl --version
      SBCL 1.0.58
      $ sbcl
      * (require 'asdf)
      * (asdf:oos 'asdf:load-op 'cc)
      * (cc:write-kernel "floppy.img")
      #<THREAD "main thread" RUNNING {AB4FD11}>:
        match-instruction: unsupported instruction (JC NO-BGA-ERROR)

Also, I'd love to hear more about Ink. I'm not sure where it is in such a tiny codebase.

<comment><USER12> From Github: "The system programming language is Ink, a new Lisp dialect which combines the elegance of Scheme and powerfulness of Common Lisp."

And no link! It's like eating chocolate in front of a child and not giving him any. Me want.

<comment><USER13> This is description of every Lisp dialect I've ever heard of.

</comment></comment></comment><comment><USER14> Somewhat related, the vpri work on a os (for among other things the oltp) -- written in a cascade of DSLs:

[http://vpri.org/fonc_wiki/index.php/XO_Hacking](http://vpri.org/fonc_wiki/index.php/XO_Hacking)

<comment><USER15> Yes, an Allan Kay "child". :)

</comment></comment><comment><USER16> It looks like it's just written in assembly, but with a Lisp syntax.

<comment> vezzy-fnord Not entirely, although a Common Lisp function wrapper to NASM syntax does seem to play a big role.

<comment><USER16> Does any Lisp code actually run in the OS itself, or is it just involved in building the OS image?

<comment><USER17> I don't understand, everything is assembly/machine code when it executes.

<comment><USER16> To be more clear: is there any compiled Lisp code, or is it just manually written assembly?

</comment></comment></comment></comment></comment><comment><USER18> I wouldn't raise my hopes too much.

Of course he's creating his own LISP dialect, no doubt with the purpose of "fixing" few of the myriad of artificial percieved non-problems of Common Lisp and its ancestry. ( * )

I'll be one happy nerd if this turns out to be anything but yet another crock of ---- layered on top of an idiotic architecture, but given the vanishing fraction of sane people amongst todays "hackers" (I can't make those quotes big enough), I'm very much in doubt. Show of hands, everyone: who actually believes that this thing is being designed from the beginning with the purpose of total inspectability and modifiability?

( * ) I'm not saying that Common Lisp doesn't have problems; for instance, the interactivity and debugging support of todays Common Lisp implementations is pathetic compared to the Genera and friends. I'm saying that the actual problems are so far beyond the casual idiot's horizon that he tends to make up problems he can actually understand (parentheses! archaic naming! standard too big! blah blah blah blah blah!).

</comment><comment><USER19> I have been looking for something like this. Original author: do you have any screen shots to share of Yalo running in VirtualBox?

</comment><comment><USER20> I am sure I am missing something, but I really want to know how to run it on a VM.

<comment><USER21> Look here: [https://github.com/whily/yalo/blob/master/doc/GettingStarted...](https://github.com/whily/yalo/blob/master/doc/GettingStarted.md)

</comment></comment><comment><USER22> Finally, we can have the technology they had in the 70s. I hope we reach 80s tech by 2024.

<comment><USER23> See, in 1970s this was the stuff of top-notch research labs and expensive computing centers. Same applies to multi-core multi-megaflops CPUs, advanced multi-user OSes that run multiple VMs while networking with computers on the other side of the globe. It was there in 1970s, too. Only today it's something that can run on your laptop, or a smaller device like the Intel Edison, for a few hundred dollars.

Can you notice the difference?

Another area where a massive copy-catting of 1960s and 1970s is happening today is space launch tech. And again, where 1960s had to spend a significant portion of national budgets, today's private firms do pretty well with a fraction of a valuation of a picture-sharing service, and turning a profit in the process.

The goals did not change all that much, but the means are now much more accessible.

<comment><USER24> But by the mid 1980's lots of stuff most people don't have today _could_ run on home computers in the few-hundred-dollars range. I'm still missing stuff I had on my Amiga 500.

Sure, there's lots and lots of stuff I can do on my current computers I wouldn't have a chance in hell of doing on my A500.

Yet I'm finding myself seriously considering running UAE (Amiga emulator) or AROS (Amiga OS "reimplementation") in a VM to run Amiga mail apps (why could I handle thousands of messages from BBS's on my A500 with 1MB RAM, while Thunderbird chokes on my (smaller) inbox?) and my favourite editor (FrexxEd).

I keep cringing when I see hacky re-implementations of stuff that was done so nicely on the Amiga. E.g. want transparent compression in your applications? Implement support for XPK and your users can just drop in libraries implementing whatever formats they want. Rather than the Linux way of everyone implementing a varying, small, incomplete subset of the available formats, making you resort to a set of binaries all with inconsistent command line options.

Similarly, how every app that needs image loading support ends up with a small subset of common formats, rather than the AmigaOS approach of supporting datatypes, allowing users to drop in a library for whatever format they want, and instantly having support for loading the new format in every application.

As a result, apps that haven't seen updates in a couple of decades, still supports the latest formats.</comment></comment></comment>


High Performance Php My Sql Scaling Techniques - <AUTHOR> http://www.slideshare.net/ZendCon/high-performance-php-my-sql-scaling-techniques-presentation

<comment><USER2> Good to see my friend (and former co-worker, twice) Eli White, make HN.

Though I think (without looking at the slides in five or six months) I can summarize. Cache with APC and Memcached. Use versioning and aggressive caching for static resources. Be careful about fields and field sizes in mysql, and use Innodb.

</comment><comment><USER3> Nothing new here.

</comment><comment><USER4> Thanks for sharing. This info is very helpful.

</comment><comment><USER5> Look guys, I know slides are cool for some (I hate them), but watching a hundred slides is a PITA instead of one single web page (or two) with the same information which makes it more digestable and easier to get the important tidbits.

In short, slides suffer from the same shortcomings of video.

Long and boring.</comment>


Ultimate Guide to Switch Debounce - <AUTHOR> https://www.eejournal.com/article/ultimate-guide-to-switch-debounce-part-1/ <comment><USER2> Debouncing is a useful concept in software design too.

Many UI elements are all too eager to emit hundreds of state update events (like a slider) as the user is finalizing the input they want - but you wouldn't want to send 100 AJAX requests to the webserver while the user's fiddling around. So resetting a 200ms timer before sending the web request is a great analog to the process of physical debouncing.

<comment><USER3> That's useful as an implementation detail, but even more important is the _user experience_ of failing to debounce correctly. If I press a button (etc) twice within 100ms, that generally does _not_ mean I want this to be seen as two presses. Rather, my finger slipped, maybe I have minor neurological problems, I'm drinking, the software itself glitched, whatever. For the user's sake, user interfaces should debounce themselves.

It's all rather striking to me, as the concept of debouncing was one of the first things I learned while reading microcontroller code as a child. (No, I'm not kidding--that was the only book on computers I could find growing up in BFE.)

That we _still_ haven't generally solved this in 2020 is appalling.

(There are lots of variations. There was an article in _Software: Practice and Experience_ in the 90s (?) lamenting the UI race in most X interfaces (and probably all other GUIs). Briefly, lots of interfaces can pop up a dialog or whatever while the user is pressing a button underneath. The dialog often gets the press, resulting in the software executing some action the user did not even see, much less intend.)

<comment><USER4> If a computer is going to disobey my instructions it should be extremely sure it's doing the right thing. 100ms is too long a threshold to make that assumption. 100ms repetition interval is only 10Hz, which is easily accomplished in short bursts by anybody with moderate skill in button mashing. I'd set it no higher than 50ms (20Hz), which is very difficult even in short bursts.

<comment><USER3> Yeah, well, wait until you're older. Or sicker.

<comment><USER5> When I'm older or sicker, I'll use a thing that works for me when I'm older or sicker. Otherwise it's like turning on the screen reader for everyone because blind people can't operate computers otherwise.

<comment><USER3> That's great for people that are technically inclined. Spend some time with senior citizens and the disabled and you might develop a bit more compassion.

</comment></comment></comment></comment></comment></comment><comment><USER6> The simplest strategy I have been using successfully since forever is one that I found on some device I have repaired.

For most devices it is enough to just probe the switch periodically.

Nobody is ever going to notice couple of milliseconds of lag. Other debouncing strategies also introduce latency as they need to observe the signal for some time.

It is important to set the check period to be longer than settling time.

Assume the switch is in stable state before the check, then there is check and then it is in another stable state. It does not matter which state the check finds as long as the state changes from one stable to another stable. Even if the switch is bouncing at the moment of the check it will be either interpreted as previous state before the switch or the next state after switch.

If you have delicate switch with good (for example gold plated) contacts, to extend the life of the switch it is then possible to only apply potential for a brief period of the check which means that during actual bounce the contact is very unlikely to see any sparks, extending the life of the switch. This does not work for some switches that rely on spark to remove oxides to get good contact.

<comment><USER7> > For most devices it is enough to just probe the switch periodically.

No, no, no, please don't. Almost all appliances I use ignore an estimated 60% of my usual button presses because they're polling in intervals just long enough to not recognise anything, and I absolutely hate it.

I always have to hold it down for a bit to make sure my input isn't just ignored. My laptop's power switch has this issue just like the washing machine, the dish washer and pretty much everything else that's not a PC keyboard, and it's one of the most infuriating UI issues I encounter every day, beside inactive text input fields with blinking cursors or selected text.

<comment><USER8> Power buttons, like on a PC or washing machine, often require being held as a means of preventing accidental activation.

<comment><USER7> I don't mean just power buttons. When I said almost every button not on a PC keyboard I meant it. On the washing machine every single button has to be held almost half a second or it won't do anything. It's super frustrating. But of course it's possible to mess this up the other way too - one of my devices reacts quick to button presses, but you have to wait about half a second until it will react to the next press.

</comment></comment></comment></comment><comment><USER9> _Well, according to The Art of Electronics by Horowitz & Hill (Page 506 of the Second Edition), "When the switch is closed, the two contacts actually separate and reconnect, typically 10 to 100 times over a period of about 1 msec." This just goes to show you how undefined this field is, because this book is regarded as the "Electronics Bible" by many engineers, but their value of 1 msec (which is the one I was told as a young engineer) is less than Jack's average findings, let alone his maximum findings._

In the Third Edition, on page 802, Horowitz and Hill write "For physically large switches, the bounce can be as long as 50ms." That first quote is from a section on clocked debouncing, which can be made insensitive to contact bounce by digital means.

I like the data sheet for the automotive contact debouncing IC.[1] That's very cute. In dirty environments, you need a minimum current and voltage, maybe 10mA, 12V, to punch through dirt and water on the contacts. That IC does that, but it only turns on the power intermittently, so you don't drain the battery polling the dashboard switches.

I've hit that with the antique Teletype machines. They were intended to run with 120VDC on the keyboard contacts, and you need about 24V or so to get reliable punch-through.

[1] [https://www.ti.com/lit/ds/symlink/tic12400-q1.pdf](https://www.ti.com/lit/ds/symlink/tic12400-q1.pdf)

<comment><USER10> The Maxim's MAX6816/MAX6817/MAX6818[1] are pretty good as well in that you don't need RC filters for each input, so less components needed to debounce inputs.

[1] [https://datasheets.maximintegrated.com/en/ds/MAX6816-MAX6818...](https://datasheets.maximintegrated.com/en/ds/MAX6816-MAX6818.pdf)

</comment></comment><comment><USER11> In my experience with a variety of switches and microcontrollers this actually isn't too big of a deal as it used to be. It is worth testing out, but I think it's worth testing before investing a lot of hardware/software development on it. Adding some resistance or a simple RC low-pass filter can help, and also many microcontrollers come with basic anti-bounce inputs.

As other posters said another easy effective strategy is to just ignore inputs after the initial transition. You can do this and still pick up long presses too if you need to!

</comment><comment><USER12> This is definitely a problem with any circuit that is complex enough. It was nice to see Ben Eater explain it and solve it in multiple ways, once using a 555 timer and a capacitor[1] and the other time using just the SR latch of the 555[2].

[1] [https://www.youtube.com/watch?v=81BgFhm2vz8](https://www.youtube.com/watch?v=81BgFhm2vz8)

[2] [https://www.youtube.com/watch?v=WCwJNnx36Rk](https://www.youtube.com/watch?v=WCwJNnx36Rk)

</comment><comment><USER13> Must admit I've always though this is an oscillation created by the inductivity and capacitance of the circuit, never though of it as an actual mechanical switch bouncing off the other contact. Shouldn't a spark form and short-circuit the mechanical contacts even if they bounce around a little?

<comment><USER14> Arcing is only present if there's a significant amount of current flowing, which there isn't in switches used for user input.

</comment></comment><comment><USER15> When I started dabbling in electronics recently, I ran into switch bouncing apparently as I used a push button to generate the "clock" input of a CD4017 decade counter and it showed rather erratic output behavior.

Adding a capacitor fixed it. Which reminds me that I should really invest in an oscilloscope to validate my (not so) educated guesses.

Great resource to read up on this topic, thanks.

</comment><comment><USER16> He never explains why this actually happens. As a non-engineer, I'm curious why it's not immediate...

<comment><USER17> Nothing is perfectly stiff. Nothing moves perfectly smoothly. Every mechanical part has some amount of "springiness" and will vibrate when struck, pushed, flexed, etc. So a switch contact literally "bounces" like a hammer on a piano string as it is closed. His analogy of a ping-pong ball on a desk isn't great, but it's not exactly wrong, either.

As for "immediate", the switch closure feels immediate to human perception (supposedly limited to about 1/20 second, for touch). But to modern electronics, nanoseconds are easily countable; and switch bounce can be measured in microseconds, or even milliseconds for a big, heavy electromechanical component.

Here are some better articles.

[https://www.allaboutcircuits.com/technical- articles/switch-b...](https://www.allaboutcircuits.com/technical- articles/switch-bounce-how-to-deal-with-it/)

[https://www.maximintegrated.com/en/design/technical- document...](https://www.maximintegrated.com/en/design/technical- documents/app-notes/2/287.html)

</comment></comment><comment><USER18> When I saw the title I thought it would be the old Jack Ganssle article which is also worth a look if you're interested in this topic: [http://www.ganssle.com/debouncing.htm](http://www.ganssle.com/debouncing.htm)

</comment><comment><USER19> Is it really that hard to just add a simple RC circuit?

No polling required.

And here's a component values calculator: [https://protological.com/debounce- calaculator](https://protological.com/debounce-calaculator)

<comment><USER20> Well.

If you see the circuit this calaculator (sic) proposes, you'll see it won't debounce fully the closing the switch (and you'll have to invert the logic, which in principle it's ok).

Plus adding one component to the circuit (you'll most likely have the resistor anyway).

It might work for your case but you'll most likely need a software solution as well, depends on your switch and the logical gate input impedance.

</comment></comment><comment> ur-whale aka : what functional transform can I apply to an unpredictable function Signal(Time) to decide if it models a zero or a one.

<comment><USER21> Isn't the answer some form of hysteresis? Whether you implement it in hardware or software it's up to you.

</comment></comment><comment><USER22> When given the chance, I like using SPDT switches and an SR Latch to deal with bouncing.

<comment><AUTHOR> One problem, finding SPDT momentary switches is haaard, near nothing there that is small, and smt

<comment><USER22> Yeah - that is one problem. I would love to have MX switches in SPDT format. I have find these a while back ago: [https://www.aliexpress.com/item/32430367243.html](https://www.aliexpress.com/item/32430367243.html)

</comment></comment></comment><comment><USER23> I instantly closed this website because it loaded slow and then hit me with 2 pop-ups and a location request.

<comment><USER24> I instantly skipped reading your comment when I saw "I instantly..."</comment></comment>


What's Smaller Than Apple? - <AUTHOR> http://visual.ly/whats-smaller-apple

<comment><USER2> Comparing market cap vs. various revenue numbers is misleading at best.

<comment><USER3> I agree, might as well compare like with like.

===== REVENUE =====

      United States: 2000B
      China:         1150B
      Wal-Mart:       421B
      Exxon Mobil:    370B
      South Korea:    250B
      Greece:         130B
      HP:             126B
      Apple:          108B
      IBM:            100B
      Ireland:         93B
      BHP Billiton:    72B
      Hong Kong:       37B
      Pfizer:          17B

(2010 or thereabouts. very approximate. google finance and wikipedia, entities chosen haphazardly.)</comment></comment>


BayesDB: A probabilistic programming platform - <AUTHOR> http://probcomp.csail.mit.edu/bayesdb/ <comment><USER2> Anyone doing probabilistic programming with big data? I started experimenting with probabilistic programming frameworks several years ago, but couldn't get it to scale to the level of data I'm working with (~6 dimensions ~100 trillion vectors), or even a small fraction of that. But, I'm sure it's being done in scientific circles somewhere.

Are there communities to collaborate on probabilistic programming? It seems like he domain knowledge is obscure enough that all the good information is locked up in the big corporations and academics.

<comment><USER3> Things have gotten much more mature in the past few years.

Check out edwardlib.org which is adapting Tensorflow to support probabilistic modeling (with a heavy focus on variational inference, less so on MCMC methods). If you've got trillions of observations you can use stochastic VI. And tensorflow now can do distributed computation graphs, or you could just go data parallel and then average your parameters at the end.

In general David Blei's group at Columbia does a lot of work in scalable probabilistic inference.

The other big option is of course Stan, which is really well optimized but I don't think is particularly intended for "big data" of this kind. If you have "medium data" that fits on one machine though, it's blazing fast.

<comment><USER4> Funny you mention those.

I've been really excited about Edward but when I tried it for a project last year I could never get it to come together in the right way. I got the sense that it wasn't quite ready for prime time yet, although very promising. My memory of it was that a lot of claimed flexibility in how to specify models wasn't really implemented fully. The experience also turned me off of TensorFlow a bit. But that was a year ago, so maybe it's improved?

I ended up doing it in Stan in part because I was more familiar with that, and it worked out fairly well.

Just a personal anecdote.

</comment></comment></comment><comment><USER5> Welcome to the project I've been waiting for _years_ to get out of alpha. It's frustrating. If I had a hundred million dollars I'd burn a couple million getting this funded. It seems like it will be useful to humanity.

<comment><USER6> ... they are funded. (I know of >=1 of the investors) [https://empirical.com/](https://empirical.com/)

</comment></comment><comment><USER7> previous discussions:

[https://news.ycombinator.com/item?id=6864339](https://news.ycombinator.com/item?id=6864339)

[https://news.ycombinator.com/item?id=10750900](https://news.ycombinator.com/item?id=10750900)

</comment><comment><USER8> I can imagine this could be really great wrapped up as a Postgres extension

</comment><comment><USER9> This sounds kind of similar to the stuff this startup called "Prior Knowledge" was working on prior to being acquired by Salesforce: [https://www.crunchbase.com/organization/prior- knowledge#/ent...](https://www.crunchbase.com/organization/prior- knowledge#/entity)

</comment><comment><USER10> Glad to see this is out as well! Using probabilistic frameworks has the potential to eliminate a lot of the human error which can easily enter a large simulation. It's fair to say in the future probabilistic modules will become part of every standard library in every programming language, and distribution sampling functions will be as common as trig functions in a math library.

I am curious though how I would build up large queries in the BQL (SQL-like query language) or MML (meta-modeling language). For the orbital example, we conceivably only have a relatively low dimensional space. But what about a Bayes net for investigating genetic variants in a large genomic population? Doesn't this quickly become intractable?

<comment><USER11> Some probabilisitic systems can cope with big volumes of data. E.g. [http://i.stanford.edu/hazy/](http://i.stanford.edu/hazy/)

<comment><USER12> Note that Apple recently acquired this technology. Lattice Data is the commercialization of DeepDive.

</comment></comment></comment><comment><USER13> Is there a comparison of its accuracy against traditional methods? Admittedly, this machine assisted modeling sounds really interesting.

</comment><comment><USER14> They really missed out on an opportunity to call it _DataBayes_.</comment>


"The Trolley Problem" (A Jewish Perspective) - <AUTHOR> https://www.chabad.org/library/article_cdo/aid/4372124/jewish/The-Trolley-Problem-in-Judaism.htm# <comment><USER2> "you have to make up your own mind"</comment>


Remy: Computer-Generated TCP Congestion Control - <AUTHOR> http://web.mit.edu/newsoffice/2013/a-faster-internet-designed-by-computers-0719.html

<comment><USER2> I really appreciate they have a "reproduce the results" section. We need a lot more of that kind of thing in CS research.</comment>


Show HN: people post daily food experience here with friends. Beta users needed - <AUTHOR> https://plus.google.com/communities/101937919788197695663

<comment><USER2> I really find problem that its hard to find where my friends eat. Good Job! BTW: what's your username OP? I want to add you.

<comment><AUTHOR> Oh, my username is leo

</comment></comment><comment><USER3> I ma try it out

<comment><AUTHOR> make sure to give some feedbacks, thanks!</comment></comment>


Hygiene Is Overrated – You Can Be Too Clean - <AUTHOR> https://www.theatlantic.com/magazine/archive/2020/07/hygiene-is-overrated/612235/ <comment><USER2> That's well and good until you have eczema on your groin or underarms.

<comment><USER3> Seems to me you can be too dirty as well as too clean. As with so many things in life there's a golden middle to be found.</comment></comment>


World Health Organization (WHO) Covid-19 App - <AUTHOR> https://github.com/WorldHealthOrganization/app <comment><AUTHOR> Still in development - current build 0.5 not intended for public release

Related post announcing the app development in anticipation of its release next month:

[https://news.ycombinator.com/item?id=23119031](https://news.ycombinator.com/item?id=23119031)

Related news:

[https://www.reuters.com/article/us-health-coronavirus-who- ap...](https://www.reuters.com/article/us-health-coronavirus-who-apps/who- readies-coronavirus-app-for-checking-symptoms-possibly-contact-tracing- idUSKBN22K2QV)

<comment><AUTHOR> The app is anticipated to be released _this_ month. Apologies.</comment></comment>


Ask HN: multi-window SSH client alternative to putty? - <AUTHOR>

I've used putty for years for connecting via SSH.  Often I like to have multiple putty windows open, sized, and positioned so that I blanket a third monitor with 5 individual putty windows/sessions.  Is there another client which better manages a setup like this?
Hopefully one that: -opens child windows within the parent -can tile child windows -remembers child window positions -remembers passwords
I've tried 'Poderosa' but it's buggy and seems to have fallen by the wayside in terms of active development.
If there are alternatives that fit the bill, that aren't free or open source, I would be interested in those as well...
thanks! <comment><USER2> Try GNU Screen with the vsplit patch, through putty. It can split any which way and will hold that state across reconnects.

<comment><USER3> I second that. Byte for byte, GNU Screen is probably one of the most useful pieces of software ever developed.

</comment></comment><comment><USER4> I use Poderosa daily. You have to modify your .inputrc to suit it, but asides from that it's stable and has a decent UI, unlike Putty.

It's also significant more stable than Putty Connection Manager.

</comment><comment><USER5> SecureCRT is fantastic if you're stuck in a Windows environment.

<http://www.vandyke.com/products/securecrt/>

</comment><comment><USER6> I also tried Poderosa. I used it for some time, but decided that I didn't need the multi-window feature as badly, so went back to putty.

</comment><comment><USER7> PuTTY Connection Manager - <http://puttycm.free.fr/></comment>


New 82 bedroom compound for AI / ML in central SF - <AUTHOR> I have a new (acquired in April 2019) 30 bedroom, 9,000+ sq ft house in central San Francisco, called 'ML House' (https://ml-house.org/). We also have a 52 bedroom / 12,000 sq ft building on the same block, which we'll later use to expand our ML campus as we grow (probably a few years from now).
I'm working with some close friends in machine learning to assemble the best possible community of AI/ML enthusiasts, with this site serving as the HQ for our global network. We currently have a group of ML engineers in the house, with many similar types moving in next month from Harvard, MIT, Princeton, etc. We believe that advanced AI/ML will have an unprecedented impact on the future, and that forming this community is one of the most impactful things that can be done right now.
Here's what value we offer our members: Quality connections with people in AI/ML, short-term/long-term housing, co-working space, and many ongoing events that are focused on rigorous technical and personal development (expert speaker events, coding competitions, technical lectures/classes, top-notch personal development workshops, structured feedback/accountability sessions for member goals/projects, etc).  To see a quick example of an event that we had this past week, check out our new Medium blog: https://medium.com/@james_30820/test-a4cdf5b4502f.
If you're interested in getting involved with our community in any of the following capacities, we'd love to speak with you: Long-term housing (stays of > 1 month) / Short-term housing (stays of < 1 month) / Co-working / Events mailing list / Giving us feedback on what you want to see happen.
Lastly, we'd love to have you involved in our community in a remote/online capacity even if you don't live in the Bay Area (but work in AI / ML).
Feel free to get in touch via www.ml-house.org/apply. Thanks! <comment><USER2> Maybe this Q deserves its own _Ask HN,_ but what do folks think of the feasibility, limits and/or power of using AI/ML for self-programming/seld- designing systems? How soon would it impact the salaries of programmers?

</comment><comment><USER3> This is super tone def given the housing situation in SF. Of all the people who need to live in a dorm style situation experts in AI/ML are probably pretty low on the list.

Who was displaced to build this tech paradise of dorm style living?

At least address this on your website or something.

TLDR: wtf?

<comment><AUTHOR> People displaced: 0. Both buildings were previously co-living spaces (for the past 4-5 years) before our management of the property. And before that, both buildings had fires and sat vacant for many years prior. So yeah, nobody displaced.

Getting the future of AI/ML right stands to massively benefit/hurt everyone, and there's a strong need for this sort of community to help with that.</comment></comment>


Microsoft Anti-Porn Workers Sue Over PTSD - <AUTHOR> http://www.thedailybeast.com/articles/2017/01/11/microsoft-anti-porn-workers-sue-over-ptsd.html <comment><USER2> Duplicate of what was already posted 10 hours ago:

[https://news.ycombinator.com/item?id=13378346](https://news.ycombinator.com/item?id=13378346)</comment>