matijash

That's a good point, I'm not so much in mobile these days so weren't aware of push notifications issue. Also great to hear PWA can cover a lot of cases, that would definitely be a natural first step towards mobile.

For now it's pretty flexible, we only enforce top-level dirs - client/, server/ and shared/ and then everything else is referenced through imports in .wasp file.

But I agree providing some best practices on the structure would be helpful - I personally prefer top-level grouping-by-feature (e.g. "billing/" and "reports/") over grouping-by-type (e.g. "controllers/", "components/"), but I know some folks prefer by-type, especially in the smaller projects.

We plan to add more starter projects and templates so that might be a good start. Is there anything specific you'd like to se enforced/suggested, based on how you like to structure your projects?

We haven't yet thoroughly looked into it, but it could be possible. Especially for Supabase since they support integrating with Prisma (https://supabase.com/docs/guides/integrations/prisma) which Wasp uses as a db layer.

I think the main question here is what experience we want to offer and which level of integration (e.g. with Wasp's entity models) we can achieve. Do you have any particular features of Supabase/Hasura that you'd like to use?

We were in W21 batch, so Jan 21. It was just after we released the first version of Wasp somebody could actually download and try out (before that it was just the landing page with the vision statement + gh repo with Haskell source). We got some good feedback on Product Hunt and Reddit and I believe that also helped.

We documented our adoption journey (through gh stars) here (https://wasp-lang.dev/blog/2022/09/29/journey-to-1000-gh-sta...), and we also marked the moment when we were accepted in YC (we actually applied 3 times in a row!).

You mean native mobile and desktop apps? That's definitely a much longer-term goal (and even more unclear :) but theoretically, given that Wasp is being designed as stack-agnostic framework, it's possible which makes it really exciting.

We thought about it a bit already and definitely not 100% of concepts from the domain of web apps would apply (e.g. routes maybe don't make sense in mobile apps), but there is still a lot that could be share. Maybe Wasp could also generate some SDK you could use from your native mobile code.

That's all long-term stuff so really hard to know, but we imagined we'd first focus on getting to 1.0 with React & Node, then add support for more client/server stacks (e.g. Vue and Python), and then go towards mobile and desktop.

I think the main reason for that is that Wasp is a domain specific language, catering to the domain of web apps, so it was easier to demonstrate/present use cases and what kind of additional services it could offer in the future.

At the beginning of our fundraising VCs were often skeptical towards Wasp being a "new programming language", because who ever monetized (directly) Python or C++? Once we changed the narrative a bit and started referring to Terraform (DSL and a successful VC case) and emphasized that Wasp is a config language that interacts with the existing stack (so no big learning curve), we started having much better conversations.

Fundraising wasn't an easy journey for us (it took over 250 meetings) and we learned a lot about how to present and also think about Wasp. For more details, we documented our fundraise in details here: https://wasp-lang.dev/blog/2021/11/22/fundraising-learnings

Also just realized we don't mention it explicitly anywhere, but Wasp is completely open source!

still very much open to feedback, especially when it comes to dev experience! We still expect the language to evolve both in features and the syntax. We were initially inspired by JSON and HCL (lang behind terraform) so I think that's what influenced us in the start.

ooh this is nice! What did you implement it with? I think this might fit really nicely with https://wasp-lang.dev/ at some point

Might be! Although a still bit hard to imagine someone "accidentally" buying this exact domain and then deploying the content.

we also thought that at first but we checked (there's only 5 of us) and it wasn't!

Wasp-lang (https://wasp-lang.dev/) | Founding Engineer | Full-Time | Remote [GMT - 5, GMT + 3]

At Wasp, we are building a compiled, stack-agnostic DSL for implementing full stack web-apps, that interops with the existing stack (React & Node.js currently). Imagine Ruby on Rails as a language and not bound to the specific stack or architecture. The compiler is implemented in Haskell.

Our team is remote, with engineers currently both in US and Croatia.

Job link with more details: https://wasp-lang.notion.site/Founding-Engineer-at-Wasp-88a7...

awesome insights, thank you!

Thank you for sharing this, I love it. I love how you are having fun and don't care about what will come out of it. Better than playing any game IMO :).

I'm working on a platformer game for fun (will present it at my wedding actually and make a little competition) and in the process, I came across this article - really amazed to see how much there is to it, and what makes our favorite childhood games feel the way they do :).

Our compiler stack is in Haskell so we initially started with Parsec (parser combinator library) and then eventually switched to Happy (parser generator that Haskell uses itself) since at first we didn't have a formal grammar defined so that made us write a lot of code for every little addition to the language (it's a simple declarative DSL, https://github.com/wasp-lang/wasp).

The problem we're now facing with Happy is that it doesn't really have support for error recovery. We're trying to implement LSP so recovery is important in order to have proper syntax highlighting and error reporting in an IDE.

Wondering how well ANTLR covers this, I was quite surprised to find out that Happy has so little support for it.

yep that would be really interesting! If e.g. the target generated code was some language with high type safety or a DSL whose compilation already guarantees certain properties.

Haha you should have seen the first draft! Still appreciate the feedback

This is an interesting thought. Kinda analogous to when you e.g. change your C++ code and the new assembly code is generated.

If there was high-level intent (e.g. something like spec language) that was preserved and versioned, that might be possible I guess.

I agree, this is becoming really confusing! And then also "center-stack" which I heard somewhere recently re one of the frontend frameworks.

When I hear of a full-stack framework (in a modern setting), I think of stuff like Meteor, Redwood, and Wasp-lang (disclaimer: I am one of the authors of that one). RoR also always comes to mind, although it's more commonly used as an API server nowadays.

This is really cool! I've been looking for something like for a while - my learning path was through LYAH and Real-World Haskell (also tried Haskell from the first principles but a bit too extensive IMO). I think this would fit in perfectly between LYAH and RWH.

I am using Haskell mostly for writing compilers (https://github.com/wasp-lang/wasp currently), but I believe if the tutorial isn't using a lot of specialized libraries/frameworks (which seems to be the case from the first glance), a majority of the material taught should be transferable to any domain.

Wow, this thread really exploded! My 2 cents on Haskell, since we're building https://wasp-lang.dev/ in it and also just hired several founding engineers:

- we're sticking with the "Boring Haskell" manifesto(https://www.snoyman.com/blog/2019/11/boring-haskell-manifest...) - using only the widely adopted compiler plugins and not going too crazy with the monad transformer stack, which keeps the code easy for others to contribute to.

- we've hired 2 founding engineers so far - none of them knew Haskell beforehand! But they were both senior engs well versed in different languages and I was surprised with how quickly they picked it up - within the first month they are at 90% productivity.

This resonates a lot! I've always considered myself a general software engineer (mostly doing algorithms and ML in uni), but then moved to industry and for every project needed to get into web. Over last 10 years I went through php, Java and Node on the backend and jquery/angular/react on the frontend. I understand and appreciate why and how these technologies developed, but it still felt I had to do a lot of re-learning to catch-up with the latest stack and build the similar thing all over again.

There is a lot of variance in how much time it takes for a startup to raise - some are already done before Demo Day, and some take a couple of months or they postpone it for later.

Although it looks like a waste of time from the distance, since it prevents you from building the product, in our case it was actually a very useful and formative experience, I'd dare to say even the most of all parts of YC. Being an OSS, developer and tech oriented startup with no revenue it made us very aware of that and forced us to learn about how we can get there. As the result, we solidified our vision and actually feel much more confident about it now than before the fundraising.

Re going back to school - def a good way to make friends and build long-term relationships. But I have also seen a lot od co-founders that used to work together. I guess it is all harder in a remote setting, maybe that is the main factor.

YC's Startup School has a service for this: https://www.ycombinator.com/cofounder-matching, but I haven't tried it.

There is also a program called Entrepreneur First (https://www.joinef.com/) which does it in a more structured way, like an incubator.

Yeah, it definitely isn't a standardized term. I've also been hearing "hard tech" but then got a feeling it has more and more been used for hardware projects, although I dont think that that was the original idea.

We actually never insisted on being called deep-tech, but we realised that was how others characterized us, especially when talking to investors (building a new programming language sounds pretty scary, although in our case it is a non turing complete DSL).

Thank you!

Wow, so glad you found it helpful! Yes, our compiler is written in Haskell and currently generates React/Node.js code. I will keep Hack-NY in mind, thanks for sharing!

The main idea with this is to build validation by showing that somebody else did similar/analogous thing and succeedeed. E.g. "What Y did for Z, we will do the same but for X". And then the key point is in explaining how it is related and why it makes sense in your case to apply the same strategy.

We learned that innovating on the product is already challenging enough, and if we also innovate on the business model / adoption strategy etc it just sounds too risky. The best thing here is just to follow on somebody else's footsteps, which also makes it much easier (both for investors and ourselves) to imagine what the future will look like.