martypitt

Slightly OT, but sincere thanks from me to you for creating Lombok.

It's a tool that sparks strong opinions, which is a testament to its significance and the impact it has made. You've created something that people are passionate about, whether they're for or against it.

Personally, I'm firmly in Team Lombok. I believe the negative feedback it receives is disproportionate.

For those of us who use it, Lombok significantly improves our coding experience. For those who don't, it's entirely optional and doesn't interfere with their workflow.

Thanks again for creating something that made me enjoy coding in Java :)

I was curious, given the feedback on this page, so I ran the lighthouse test:

Performance: 81 / Accesssibility: 93 / Best Practices: 96 / SEO: 100

Performance is on the lower side, but the others are all tracking pretty well!

Discussed previously here:

https://news.ycombinator.com/item?id=39777267

Nice work! This addresses many of the issues I've had with SSE.

Another problem we've never worked out the solution to, is how to send a termination - signalling "there are no more events coming". We always end up having to roll our own, though it felt like something that should've been handled at the protocol layer.

The Taiko link you posted doesn't work - I think it's missing an s at the end - here's the working link:

https://www.youtube.com/watch?v=i-sMXPV547s

Not the OP, but BSL is Source License that gives you access to use the source, with specific restrictions.

Most commonly the restrictions prevent you from launching a competing offering. In their case, you can't offer database-as-a-service using their code.

BSL typically also restricts production use - though it looks like ReadySet has relaxed that restriction.

Finally, BSL reverts to a traditional open source license after a set period of time - in their case Apache 2 after 4 years. This means that code written today is licensed under BSL for 4 years, then automatically reverts to Apahce 2 thereafter.

Is this real? The "Click on the Laptop", along with the rickroll suggests that this is a gimmick.

The only other thing is to log in, with an email address. Given how questionable the site seems, I bailed.

I'm struggling to see the distinction here.

Sure, Podcast ≠ Spotify, just as Git ≠ Github. But people choose to distribute their code on Github for exactly the same reason the people choose to distribute their podcasts on Spotify - reach.

That exact reach is what Drew argues so articulately against - in fact he expressly calls out marketing on Twitter and Facebook as a "mistake", and damaging against the FOSS community. He goes on to encourage people to prefer open infrastructure with lesser reach, even if that comes at the expense of effectiveness:

> Such projects would prefer to exacerbate the network effects problem rather than risk some of its social capital on a less popular platform. To me, this is selfish and unethical outright.

It's hard to see how that same argument doesn't extend to promoting your software on podcasts which are primarily distributed via Spotify, Apple Podcasts, etc.

On the topic of Activism, I think I'd agree with you, if he was on Spotify podcasts promoting other "Free" podcast platforms.

But he's not - he's promoting a programming language.

> No, that feels like living in an imperfect world and trying to make it better.

Fair call.

You may be right, Zealot may not be the right word here.

But after reading that article, I was definitely left feeling judged because I choose to do exactly the things he's talking about, for exactly the reasons he's suggesting. Maybe that's on me, but I certainly felt his standards imposed on me, disclaimer or not.

Also, given the conviction with which he argues with in the article, that disclaimer feels a little weak -- kinda like when someone says "No offence, but... <very offensive thing>".

Wow - that article was a tough read. I like a LOT of what Drew has to say, but this seems over the top.

He claims that authors promoting their open source software on channels like Twitter, Hacker news, LinkedIn or even Github is "selfish and unethical outright":

> Many projects choose to prioritize access to the established audience that large commercial platforms provide, in order to maximize their odds of becoming popular, and enjoying some of the knock-on effects of that popularity, such as more contributions.

> To me, this is selfish and unethical outright, though you may have different ethical standards.

I find Zealotry like this tough, and promotes a definition of FOSS that feels hostile against those who want to simply build something cool, and share it with the world - (or even more controversially, make money from FOSS).

Given such a strong view, it's really surprising that he then posts stuff like "Can I be on your podcast"[1] to try to promote Hare - his programming language.

He didn't ask for podcasts that aren't distributed on platforms like Spotify or Apple Podcasts. In fact - he's right there with several appearances promoting Hare.

That feels like hypocrisy.

[1]: https://drewdevault.com/2023/11/09/Can-I-be-on-your-podcast....

We run our own consulting practice - Notional (https://notional.uk) -- terrible, unmaintaned website, as all the love goes to orbital these days.

I've been bootstrapping orbitalhq.com for a few years now.

Pretty standard bootstrap story - used consultancy to get us out the door. These days, we're (nearly) self sustained through license revenue, with a small amount of consulting (1-2 projects a year).

It's been a tough ride, and in hindsight, I wish I hadn't pivoted away from consulting quite as early as I had, however we've managed to stay alive, so - so far - independent, which has been nice.

The Wilhelm Scream is a sound effect of a man screaming from the 1950's, that has become an in-joke for sound designers.

It's appeared in every Star Wars and Indianna Jones movie, along with countless others.

Really cool 4-minute documentary on BBC for those who can view it:

https://www.bbc.co.uk/iplayer/episode/p07p5l6y/inside-cinema...

I love Supabase, commercial open source in general, and agree with lots of this post.

However this comment feels off:

> In software ideas are cheap. Value is almost always created in execution of ideas.

I've heard this phrase around things like "I have this cool idea for a startup - will you sign my NDA before I tell you about it?"

However, when you're open sourcing your software, you're not just providing an idea, but a significant portion of execution of that idea too.

Sure, code isn't the full execution - that expands to sales / marketing / support / etc.

However, the article is a little glib towards the value of the code, suggesting it's worthless without sales / marketing /etc. I don't think that's true.

I went hunting on DanHulton.com for some more gold. I was fascinated by the "I Paid The Most" site, and was disappointed it wasn't a real thing (anymore).

@DanHulton - tell us all the tale.

Looks like it's bundled with everything else in their templates collection. I purchased all access a while ago, and have found it incredibly helpful.

It's definitely worth the one-off price tag, and the fact they include future updates (like Catalyst) is incredible.

I read somewhere that "fake" stars get pruned pretty quickly.

Regardless, imperfect as it is, a GH project with 20k stars feels more credible than one with 200.

(I write this as someone who works full time on a GH repo with 200 stars! :D)

This was a really good read. As the maintainer of a large GH OSS repo, I really loved their "This worked / This didn't" sections.

20k stars in a single year is a very impressive feat.

Congrats to the team at Plane, and thanks for this.

Github stars are a distribution channel, which leads to awareness, and drives adoption.

Also, it's an informal social proof, which drives trust. The more stars, the more legit something seems.

I'm a fan of Tyk, but not sure how this relates to API Gateways. (Even having read the "How this relates to API gateways" section

This feels like a "we need to be doing something in AI" play.

> Or try using your mouth IN FRONT of your keyboard

You're gonna have to walk me through that one.

Nice. Downloaded and installed.

Clean UI (almost bordering on a rip-off of Postman.. but I guess familiarity helps users get going faster).

Lovely to see that things aren't held behind a Login button, ala Postman and Insomnia (Kong really misread the room on their latest update).

Login and accounts seem like they're there, but very clearly optional.

Nicely done, Hoppscotch team!

Great post. Bonus points for introducing TSX (the other TSX), which also seems really cool.

Also, importing JSON in typescript is another cool thing I learnt about.

Thanks for writing this up!

These libraries seem really cool, and I can clearly see why that have such popularity.

It's a little less clear to me how you monetize this type of stack. Given such an impressive fundraise, in a tough climate, I wonder what the market opportunity the VC's have backed is.

BTW: At the time of writing, the link to Charm Cloud in your blog post is broken.

For teams that want to adopt GraphQL, I think those tools are pretty great (and I've sent customers to them). However, we know from our customers there's lots of teams who don't want the shift of GraphQL (which tends to lead to GraphQL everywhere), but still want API composition.

At a language-to-language feature level, there's some core differences:

GraphQL-without-resolvers still relies on imperative joins defined somewhere. AFAIK, Wundergraph pushes this to the query layer. GraphQL Mesh pushes this to .yaml files. This means that as the sources change, there's centralized config needs to be updated in lock-step, or things break. This means the API producer is now obligated to work closely with consumers to release changes.

TaxiQL infers join logic by introspecting the schemas. This is especially powerful where joins require hops across multiple sources (eg., Id resolution where services use different ID schemes). Because type metadata is embedded at the producer schemas, producers are free to make changes and the query layer adapts.

GraphQL promotes a single graph that everyone cherry-picks from. TaxiQL lets query authors define their own data contract, and own data shapes. This moves transformation of code into the query layer, which we think is a better place for it.

GraphQL doesn't allow extensibility in the language. (We've seen others hack around this with framework-specific annotations, but that's always felt quite awkward). TaxiQL supports extensibility, adding custom functionality into the query layer, and ships with a pretty rich stdlib for things like avg(), first(), last(), etc.

Generally, data that comes from two different sources, and has different values, aren't semantically equivalent, and so get assigned different types.

eg:

   type ImdbFilmReview extends FilmReview
   type RottenTomatoesFilmReview extends FilmReview

Which allows you to query for either "All film reviews", or just a subset.

We've found that actually covers about 80% of use cases.

However, some users have asked for more control in the query langugae, which we're working on improving the TaxiQL query syntax for this right now.

Here's what it looks like:

   find { Film[] } as {
     id : FilmId
     rottenTomatoesReviews : RottenTomatoes::FilmReview[]
     imdbFilmReview : Imdb::FilmReview[]
   }

This is a fair comment, and something I think we could do better at... bear with us, we're moving from entirely closed source, to Open Core.

I've partially tried to address this with the FAQ[0]. Maybe we could move the codebase around, so there's community/ and commerical/ top-level dirs, and associated licenses under there. (Naming TBD).

[0]https://github.com/orbitalapi/orbital/blob/develop/LICENSE_F...

Currently, we don't have validations implemented.

We've spiked it in the past, and had some nice designs that attached validation rules semantically to the scalar types (which are very sharable), and models (which are more system-specific).

The early designs felt nice (albeit early), but the deal we were working on didn't eventuate, so we didn't push it through.

I think Validations become really interesting in both evaluation flows (ie., ingesting in a pipeline or through a mutating API), as well as quality scoring for data-at-rest.

I'm excited to explore these in more detail, given a use-case.

We've been playing with LLM's and OpenAI to build integration from plain text.

There's a video of an early version of it in action here: https://www.loom.com/share/a78c70f0e2bd42a28b7cb0a5d175c3aa

I think what's nice about using LLM's to build Taxi queries (which is what's actually happening here) is that we're not having to push things like API Specs and DB Schemas to the LLM. Instead, we train it on the Taxi types that are available, get the LLM to build a Taxi query, and let Orbital generate the integration.

It means a lot less information is pushed out.

Still quite early, but it's really powerful.