belmont_sup

it’s possible to still hit cors and https issues from the terminal.

Viewed from a different lens, these achievements seem intended for new GitHub users.

I recall merging my OWN pr into my own new repo. I was surprised with a badge. No harm in that.

ocaml.org’s new website is packed with lots of great early intros.

most learners eventually gravitate towards Real World OCaml https://dev.realworldocaml.org/ for additional learning.

Unfortunately, the learning resources for different domains out there isn’t as highly curated or prolific as, say, rust. If you do web dev like me, it takes a bit more work to find the tools and put them together. But the language itself lends itself well to systems level programming.

Fortunately, the forum is a great help.

If you truly believe that this is a 10-yr+ journey, then learning Rust just for fun and exploration seems worth it.

Any language that forces me into a new domain, whether by the goal it wants to solve, its paradigms, or environment, seems highly worth it.

P.s. try OCaml

It’d be really interesting to see if it gets picked up into the ocaml community github org.

I’ve wanted to make PRs but know they’re not being accepted.

Ecstatic! I’ve been playing with the concurrent eio primitives and it feels great, comparable to working with Go’s channels and goroutines.

You can equate Go channels to the Eio.Stream type. Goroutines to Eio.Fiber type.

They’re enums that can hold additional data types.

But they’re additionally great because the compiler does exhaustive pattern matching.

I don’t entirely agree with the original comment too but hydration has always been an issue when TTI is discussed.

Aside from the inefficient rendering of SSR due to data aggregating data, another inefficiency here is the need to re-render them again client side all that same JavaScript and json server side.

React tries to solve this issue with its concurrent mode, and streaming ssr, and server components.

I argue hydration is near to the core problem that many of today’s popular tools like graphql relay and react’s concurrent mode are trying to solve. Or Remix, Marko, Nextjs’s layout RFC. Each tool solves the problem slightly differently. Some try to make sure all data are loaded in parallel as much as possible so that hydration doesn’t cause a waterfall of requests. Others lazy load islands of JavaScript.

We’ve tried this line of reasoning ever since the plastic industry had pushed for recycling as a means of reusing plastic when they know it’ll never be economically feasible to do so.

So might as well try something new and fix excessive plastic waste at a different point in the lifecycle.

There are a few threads here that discussed options for distributed databases. If you don’t need a single logical cluster for the entire system, it’s totally fine to deploy primary dbs at each region you need. You still gain some of the edge deployment benefits by virtue of no work required for multiregion app deployment. Otherwise, you’re configuring route53 to route requests to servers closest to them. But if you need a single logical database shared globally, any new distributed “new-sql” products work: Fauna, Cockroach, TiDB, and I’m sure many others. These are just the few I know that’s used heavily and publicly.

There with you. We chose cockroach and fly to achieve our global needs in the simplest manner. But to use their cloud multiregion offer, it costs ~3400usd/mo at their recommended specs and 3 regions. Pricey depending on how you see it.

We hope their serverless tier meets feature parity soon.

Believe they've called it their own proprietary runtime since they've announced their Deploy service. Their runtime supports TCP connections, so I can actually make db connections, unlike cf workers.

If I had known this…

I was recently excited to try F# and prototype a web service within falco. Ionide worked until it didn’t in between switching from .net 6 to 7. Built fine but ide errors everywhere about missing modules

Partially agree here with the syntax error thread in that it’s mildly annoying to lose intellisense when you’re declaring a new variable before the “in” keyword is in place. But that’s about the only time I commonly see syntax errors.

New user of cockroach. We’ll find out! If this startup ever makes it to any meaningful user sizd

Unfortunately I have to agree with your inner voice that there's no perfect language out there.

I'm building my first library in OCaml for a number of great reasons: 1. the type system we all want 2. multicore is here (but in RC) 3. algebraic effects is here (but in basically RC) 4. build system is pretty good after you warm yourself up a bit. i ran into some weird dep issues recently but overcame it by vendoring deps directly.

A hard requirement for me is to be able to generate native executables, and only OCaml / Rust / Swift has this with a more modern type system. If I wasn't so focused on learning in an fp language, I'd use Rust for my needs.

If you asked for a vote, I'd say give 2 weeks for each of your top 3 languages. Opinions and anecdotal experience will always be beaten by personal experience.

What's the supposed difficulty to just use Cabal and not Nix? I had alot of difficulties running into Nix installation issues not along ago.

What resources does Nix handle for IHP? I can guess ostgres and the sql ui.

You should try again and reconsider if your team truly doesn't have an answer.

Most everyone using React should be using Nextjs or similar level of frameworks. Server rendering comes out of the box. On the other hand, it really isn't too complex anymore. With Next, Sveltekit, Remix, Nuxt, and friends, you get simple, hardened tooling out of the box. And you've decoupled frontend from api which many teams find very helpful to split responsibilities and allow certain features to move at different paces.

walking and movement beyond what you’re used to will build muscle throughout your body, mainly lower half, to compensate for the increased activity.

The benefits of tools built into the functional programming world with complete access to all C# libraries.

But it's hard to convince a C# dev to use F# when they're so comfortable and see no obvious need to switch.

I abstain from writing graphql apis now because they’re too much work for me when toy apps are simple and I can render json.

But if a team does want graphql without the fuss of openapi, json schemas, and swagger docs, I recommend tools like Hasura that autogenerates graphql apis over my db. Auto generation of graphql resolvers are the way to go for productivity. Supabase even created a Postgres extension to perform graphql directly within postgres https://supabase.com/blog/2021/12/03/pg-graphql

Fresh in both languages. But on studying the Effective Haskell book, there's a whole chapter (chp 14) on learning how to read and write efficient and faster Haskell code. Training that mental model of understanding how IO gets evaluated didn't seem too difficult. It feels akin to remembering how to write fast SQL code - you just practice a bit and measure.

In chp 7 on understanding IO, there's also another great section that explains how IO evaluation is often confused. I share an example from the book that reads, writes, and prints files.

    Memory intensive func because it attempts to read _all_ files at once because the execution of reading and writing actually only happens when the print fn is called (putStrLn files). makeAndReadFile is actually doing both reading and writing - a normal task in all other languages.

    slow =  
      let  files = mapM makeAndReadFile [1..500] ::  IO  [ String ]     
      in  files >>= (putStrLn . show)


    Efficent version. Here we force reads and writes to actually occur per file instead of waiting til the print. Seems like a pretty easy step to misunderstand.

    safe ::  IO  ()  safe =    
    foldl ( \ io id ->   io >> makeAndShow id  ) (return ()) [1..500]

Another day, another surprisingly large discussion around OCaml whenever it comes up on hn.

You've done your fair share of trying!

Your assessment reflects mine entirely. Elixir has that charm in that it leads you to productivity quickly, just as Go does. Someone could argue that's only because of much larger pool of users that's paved the path before.

Picking up Haskell again for fun, and the Effective Haskell book has been a fun learning experience. Not too beginner-ish, and doesn't take too much time to explain concepts.

I'll have to try esy and dune again sometime when OCaml 5's stable. Their commands are just different enough from go/cargo/npm to be annoying.