ihp VS ghc-proposals

Hey everyone! I wanted to play with Haskell ([IHP](https://ihp.digitallyinduced.com/)), and Rust (Cloudflare workers), so I decided to make a product with them. This is the MVP I’ve come up with. It supports teams, projects, environments, flag variations, scheduling and expiry, and a reasonably complete targeting system that support Boolean logic combining user ID targets, arbitrary metadata targeting, rollout targets, and default fallthrough variations. There’s a typescript and react SDK, and swagger API docs. The website runs on IHP, and the actual flag resolving API is deployed on cloudflare workers, so response times are generally 40-100ms. Coming soon: reusable groupings of users, and a dashboard showing all the users that have been targeted, what flags they evaluated, and what they evaluated to.

Let me know what you think!

Thin is also open source already. The client code can be found here https://github.com/digitallyinduced/thin-backend and the server code can be found mostly here https://github.com/digitallyinduced/ihp/tree/master/IHP/DataSync

You might want to check out IHP https://ihp.digitallyinduced.com It’s the same design principles that power thin, but designed for Multi page apps.

Yep exactly, you can find it mostly here https://github.com/digitallyinduced/ihp/tree/master/IHP/IDE/SchemaDesigner But no Haskell is needed for using Thin itself

Haskell is famous for it's quite an academic nature. But the ecosystem has drastically improved in recent years, so that that image is really outdated by now.

E.g. with Haskell Language Server we have nice autocompletion. Recently dot-notation has been added, so you can now write `someValue.someField` as in other languages. And the documentation is improving as well.

If you're doing web development, a good starting point is IHP (https://ihp.digitallyinduced.com/). IHP is Haskell's version of Laravel/Rails/Django. It's really a superpower to have Haskell's type system combined with the rapid development approach of Rails :) (Disclaimer: I'm founder of the company that makes IHP)

If this post got you interested in learning more about Haskell and you want to see type classes in some real code, a great starting point for Haskell is IHP :)

IHP is a new Haskell framework with a focus on actual building applications. Imagine the productiveness of rails combined with the typesafety of Haskell.

It's now already the biggest Haskell web framework, we just hit 3200 GitHub stars. I belive Haskell can reach a lot more than it's currently doing if we get things easy to use.

If you want to build a web app with Haskell and play with type classes check it out: https://ihp.digitallyinduced.com/ GitHub: https://github.com/digitallyinduced/ihp

Do you think making it more open source would solve the issue?

Thin is mostly based on IHP DataSync. You can the source code here https://github.com/digitallyinduced/ihp/blob/master/IHP/Data... Thin itself is just a "thin" wrapper around IHP and IHP DataSync.

Hey there, Founder of digitally induced here. Happy to share what've been working on with Thin Backend over the last months.

Thin is a version of the [IHP Framework](https://ihp.digitallyinduced.com/), designed to be used by frontend developers. Instead of building APIs with low-level `fetch` calls, we provide high-level APIs like `createRecord('tasks', { title: 'Hello World' }`, `updateRecord(..)` and `deleteRecord(..)` to update your database.

To simplify state management (which is typically hard and lot's of boilerplate), we provide realtime APIs so that all app state is always in sync with the actual database. Previously your react app might have been rendered from the redux state, now it's rendered directly from the server state.

The Schema Designer and the migration tools make it really easy to get going with a project.

Happy to hear everyone's feedback! :)

u/Evidencebasedonly (did i get that right) you are a Haskell dev no? I saw this framework recently, it looks cool, has code generators and a integrated JSX style DSL and all

There is the RecursiveLet proposal.

I believe simplified subsumption is required to implement quick look impredicativity and that is the only practical reason for this change.

This led me to the proposal and I found with simplified subsumption:

We have modifiers with the % symbol, they are currently only used in linear types: a %1 -> b, but they are not limited to that.

Was this not implemented? https://github.com/ghc-proposals/ghc-proposals/pull/240

I understand that the linked Explicit Splice Imports could help with that, but in theory would there be anything preventing us from tracking automatically exactly which functions make it into a splice for optimally fine-grained recompilation avoidance?

These differences via eta expansion/reduction are probably due to simplified subsumption introduced in GHC 9.0 (also see the linked GHC proposal.

As for unifying type and term: I think we're headed in that direction. According to https://github.com/ghc-proposals/ghc-proposals/pull/448, we will accept your "foo" example, and so it makes sense also to do so in types.

Inferred variables as a concept seems to be against "Explicit Variable Principle (EVP)" (mentioned in https://github.com/goldfirere/ghc-proposals/blob/type-variables/principles.rst, linked from https://github.com/ghc-proposals/ghc-proposals/pull/448). I agree with that priciple.