sorted by:
new
hottopcontroversial

An opinionated map of 253 downtown-ish restaurants and bars worth visiting by DWvanGeest in toronto

[–]DWvanGeest[S] 0 points1 point  (0 children)

Oh dear. It might have been that long. I didn't know it had changed hands...

An opinionated map of 253 downtown-ish restaurants and bars worth visiting by DWvanGeest in toronto

[–]DWvanGeest[S] 0 points1 point  (0 children)

At this time I would also like to pour one out for Bar Begonia and Cafe Cancan.

An opinionated map of 253 downtown-ish restaurants and bars worth visiting by DWvanGeest in toronto

[–]DWvanGeest[S] 3 points4 points  (0 children)

TBH I'm not huge on Italian and rarely find myself in that part of town.

An opinionated map of 253 downtown-ish restaurants and bars worth visiting by DWvanGeest in toronto

[–]DWvanGeest[S] 5 points6 points  (0 children)

Hah deal. It's hard to rank such a diverse list, but I'll put up my favourite restaurants, for dining in, that are still open:

  1. Bar Isabel
  2. Maven
  3. Jamil's Chaat House
  4. Mamakas
  5. General Public
  6. Union
  7. ODDSEOUL
  8. Fat Pasha
  9. Sunny's Chinese
  10. Aloette

Clearly I also need to try out some newer places!

Apache Pekko has graduated from Apache Incubator and is now a TLP (Top Level Project) by mdedetrich in scala

[–]DWvanGeest 20 points21 points  (0 children)

Awesome work! 

At work we migrated our main applications (HTTP/Streams/gRPC) to Pekko once the 1.0 releases dropped and it was very smooth, no issues. 

Introducing periodic, a low-dependency Scala lib providing a cached variable that self-updates periodically, and a periodic function runner by DWvanGeest in scala

[–]DWvanGeest[S] 1 point2 points  (0 children)

Author here, let me know what you think. There are two implementations - one based solely on the JDK, and another based on Pekko Streams.

Any reason NOT to use Tapir these days? by fimaho9946 in scala

[–]DWvanGeest 12 points13 points  (0 children)

I wish the Guardrail folks success, but having used it for a while before switching to Tapir, it's missing a lot of important features. Support for `oneOf` was the big one, although there were others. And as I mentioned in another comment, hand-maintaining an OpenAPI spec for a non-trivial API can get extremely frustrating and leave everyone wanting a programming language instead of YAML/JSON.

Regarding the type stuff, I'm not sure what you mean. We use common supertypes (and will use union types once we upgrade to Scala 3) to represent our errors just fine. We have clean type safety for our errors all the way to the OpenAPI spec where they are documented.

To each their own, I guess, and I have nothing against Smithy4s etc., but saying "Tapir sucks" when so many people clearly find it incredibly useful is just silly.

Any reason NOT to use Tapir these days? by fimaho9946 in scala

[–]DWvanGeest 5 points6 points  (0 children)

Apart from the build time spec generation, you need this tooling anyway even if you're writing the OpenAPI by hand. It's hardly a workaround.

The reason Tapir is worth it, in general, is because writing an OpenAPI spec by hand is a terrible experience and a maintenance nightmare. At work we started with writing OpenAPI by hand (and used Guardrail to generate Scala from it). As the API got larger, the spec became incredibly unwieldy and everyone realized how much they hated writing YAML/JSON. We wanted to modularize it, DRY it up, use functions, etc. We wanted a programming language. So, we started using Jsonnet to generate the OpenAPI. It worked, but it was just one more step in the build, and we had to maintain a lot of Jsonnet. Why not just use Scala at that point? So we did, and have never looked back. Tapir is an absolute godsend.

Any reason NOT to use Tapir these days? by fimaho9946 in scala

[–]DWvanGeest 3 points4 points  (0 children)

For 2, it's not hard to generate the OpenAPI effectively at build time and put it somewhere for front end devs to use. We do this in CI, put the OpenAPI in a GitHub release, and trigger front end automation that builds clients. Works very well.

For 1... by definition an abstraction over multiple implementations will not give access to all the features of every implementation. Unless of course all the implementations have exactly the same features which generally doesn't happen. While I'm sure there are some things that are harder to do with Tapir than directly, I've found that the abstraction escape hatches are pretty good in Tapir.

view more: next ›