5 ms·

"every dev" = every JS/TS dev I'm not sure when it started, but I feel like there has been an recent increase of "for every dev" or "for everyone" in marketing

"every dev" = every JS/TS dev I'm not sure when it started, but I feel like there has been an recent increase of "for every dev" or "for everyone" in marketing copy of tools like these. Though, if you look into it for just a minute it's not a polyglot tool that at the core exposes e.g. a REST API that could be talked to in any language, but a "library + SaaS" for a very specific subset of developers (though not a small one). ------ To the founders/team: Sorry for the rant - you are not the only ones doing it. Congrats on the funding!

tonyhb 3y ago
Hah, I get it. We actually have an alpha Go SDK out, and an Elixir SDK in progress. The cool thing is you can switch languages and clouds, deploy a new endpoint, and function state carries over for zero downtime migrations. https://github.com/inngest/inngestgo https://github.com/inngest/inngestgo https://github.com/darwin67/ex-inngest https://github.com/darwin67/ex-inngest
- throwawaymaths 3y ago
  Just fyi: Neither are critical but I recommend your repo have underscore instead of hyphen for an elixir project, and using "ex" in the name of your project is generally (informally) considered to be a signal for low code quality in the community.
  - darwin67 3y ago
    Thanks for the note, it's changed to underscore now. Regarding the "ex" prefix, it's a common pattern for Elixir libraries. https://github.com/h4cc/awesome-elixir https://github.com/h4cc/awesome-elixir
    - throwawaymaths 3y ago
      I'm just relaying stuff that is quietly joked about at elixir conferences. Take it or leave it.
_ktx2 3y ago
I think a lot of these early companies have high ambitions in terms of serving various languages, then they find out how hard writing SDKs and tooling for each of them is.
- goodoldneon 3y ago
  > ... they find out how hard writing SDKs and tooling for each of them is. Absolutely. Each additional SDK adds a lot of maintenance effort. It isn't just a write-it-once thing: - More time spent writing/updating docs - More context switching in support channels - More time spent updating SDKs as new features are developed Staying focused on one SDK helps to keep velocity high in the early stages. But our product has matured enough that we feel comfortable gradually rolling out more language support, starting with Go soon
aliasxneo 3y ago
Yeah, this has been pretty universal, lately. As a primarily Go/Rust/Python developer, it continues to baffles me how these languages continue to be the "default."
- sv123 3y ago
  .net developer sitting over here in the corner watching all the cool things pass by.
  - dismalpedigree 3y ago
    You mean the herd?
  - belmont_sup 3y ago
    Isn’t life with aspnet easy enough because it actually can do multithreaded work right? So not really a problem for dotnet folks. Unless you really want the one-click experience. We use aws sdk, spin up sqs, add some env vars to aspnet, connect the client, enqueue and dequeue all from the same app without a 3rd party (short of the queue infra).
- goodoldneon 3y ago
  [Inngest engineer] Half of us are Go devs, so we definitely don't think TypeScript should be the default language everyone uses. We only chose to start with a TypeScript SDK!
- obiefernandez 3y ago
  Consider this a vote for Ruby!
goodoldneon 3y ago
Inngest engineer here! We started with the TypeScript SDK to help us stay focused while we iterated and learned. As Tony said, we'll gradually expand to other languages (likely Python in the near future too!). As for your "REST API instead of an SDK" concern, we invoke your functions so we need some code in your app. We need to handle things like memoizing steps within a function, so there needs to be some orchestration within the app
gumby 3y ago
Thank you.
dustingetz 3y ago
seed stage landing pages are for VCs

tonyhb 3y ago

Hah, I get it. We actually have an alpha Go SDK out, and an Elixir SDK in progress. The cool thing is you can switch languages and clouds, deploy a new endpoint, and function state carries over for zero downtime migrations. https://github.com/inngest/inngestgo https://github.com/inngest/inngestgo https://github.com/darwin67/ex-inngest https://github.com/darwin67/ex-inngest

throwawaymaths 3y ago
Just fyi: Neither are critical but I recommend your repo have underscore instead of hyphen for an elixir project, and using "ex" in the name of your project is generally (informally) considered to be a signal for low code quality in the community.
- darwin67 3y ago
  Thanks for the note, it's changed to underscore now. Regarding the "ex" prefix, it's a common pattern for Elixir libraries. https://github.com/h4cc/awesome-elixir https://github.com/h4cc/awesome-elixir
  - throwawaymaths 3y ago
    I'm just relaying stuff that is quietly joked about at elixir conferences. Take it or leave it.

_ktx2 3y ago

I think a lot of these early companies have high ambitions in terms of serving various languages, then they find out how hard writing SDKs and tooling for each of them is.

goodoldneon 3y ago
> ... they find out how hard writing SDKs and tooling for each of them is. Absolutely. Each additional SDK adds a lot of maintenance effort. It isn't just a write-it-once thing: - More time spent writing/updating docs - More context switching in support channels - More time spent updating SDKs as new features are developed Staying focused on one SDK helps to keep velocity high in the early stages. But our product has matured enough that we feel comfortable gradually rolling out more language support, starting with Go soon

aliasxneo 3y ago

Yeah, this has been pretty universal, lately. As a primarily Go/Rust/Python developer, it continues to baffles me how these languages continue to be the "default."

sv123 3y ago
.net developer sitting over here in the corner watching all the cool things pass by.
- dismalpedigree 3y ago
  You mean the herd?
- belmont_sup 3y ago
  Isn’t life with aspnet easy enough because it actually can do multithreaded work right? So not really a problem for dotnet folks. Unless you really want the one-click experience. We use aws sdk, spin up sqs, add some env vars to aspnet, connect the client, enqueue and dequeue all from the same app without a 3rd party (short of the queue infra).
goodoldneon 3y ago
[Inngest engineer] Half of us are Go devs, so we definitely don't think TypeScript should be the default language everyone uses. We only chose to start with a TypeScript SDK!
obiefernandez 3y ago
Consider this a vote for Ruby!

goodoldneon 3y ago

Inngest engineer here! We started with the TypeScript SDK to help us stay focused while we iterated and learned. As Tony said, we'll gradually expand to other languages (likely Python in the near future too!). As for your "REST API instead of an SDK" concern, we invoke your functions so we need some code in your app. We need to handle things like memoizing steps within a function, so there needs to be some orchestration within the app

gumby 3y ago

Thank you.

dustingetz 3y ago

seed stage landing pages are for VCs