S1ngleM4lt

I do definitely think temporal is a good product, and I hope my original comment didn’t come across as overly negative. I also only have production experience with the go sdk, so maybe some of the pain points are less relevant in other languages. The main thing is that in order to accomplish all of the things it does, using temporal effectively adds a second runtime to your application. A runtime that most developers in your language of choice are not familiar with and, at least in my experience, has a fraction of the documentation.

I’d still definitely recommend temporal if your use-case involves long running workflows. I’ve just seen a decent number of developers viewing temporal as some sort of silver bullet but, as always, there are trade offs.

Yes, it is a “capital F” Framework. Meaning, at least using the go sdk, I felt like a lot of my existing go knowledge (was developing go professionally for about 6 years before my first temporal project) wasn’t as much of a help when learning temporal as I thought it would be. Mainly I was very comfortable using things like go routines and channels, but picking up the temporal versions of these in order to avoid non-determinism took a while. So there were a number of situations where another dev would ask me “how do I do X in go”, and frequently I knew the answer but had to figure out how to make it work in a temporal workflow. This wasn’t helped by the fact that, at least as of recently, their documentation was incredibly lackluster (the sdk is well commented though).

Additionally error handling is significantly more difficult in temporal than in normal go code in my experience, and I ended up needing to toss a lot of patterns around returning errors to avoid making handling on the caller side incredibly verbose. And I mean verbose by go error handling standards.

I will say that the overall product is really good, and I would definitely recommend it for use cases where you have long running workflows. We have workflows running for several months and being able to do things like call ‘time.sleep(10 days)’ in normal code, without having to think about the internals of scheduling resumption ourselves, is huge. I’ve just heard other teams in my org wanting to use temporal when there isn’t the same time (or “temporal”) component to the problem they’re trying to solve, usually just because they heard about auto retries, and I’m not convinced it’s worth it in those cases

This was an opinion article though right? The NY Times seems to have always had a fairly diverse range of opinion writers. I know I have even read criticism recently saying that the times shouldn’t be giving such writers a platform, particularly when the writers are on the opposite end of the political spectrum usually associated with the paper, but I personally find it commendable. Mainly if you have an opinion section, but all of the writers have roughly the same opinion, that only contributes to the “echo chamber” effect. With that given example of the Iraq war being noble, even though many (but certainly not all) would strongly disagree in hindsight, it was definitely not a fringe opinion at the time. Would it really be better to have an opinion section that didn’t include popular sentiments at the time of publication, even if many readers disagree with them?

Obviously there’s a lot of grey area here, and I don’t think The NY Times always strikes the right balance, but the example of publishing a pro Iraq War opinion in 2003 doesn’t seem particularly unhinged.

Thanks, learned something new today with return-from! I’d be curious how different cl implementations implement it.

The first few examples are what I was more familiar with, and it is precisely your note “and this /progn/ form would possibly be extracted to a new function if it was too long” which makes me want to just return early in some cases. Sometimes a case is common enough that it warrants a separate function, but having to define functions for incredibly specific cases just to avoid excessive indentation is not ideal for me.

As someone who had recently started going the other direction, from C and C-based languages to those more influenced by lisp, it took a bit of getting used to but I’ve grown to appreciate the expressiveness and composability. The only thing I can think of that statements allow, but as I understand it pure expressions don’t, would be early returns. The closest replacement I’ve seen is to just make “return” raise an exception and wrap the whole expression with the try/catch equivalent, which isn’t terrible but was a bit surprising coming from a C-based background where returning early is a fairly common pattern.

My guess was always that a post on a particular topic might make someone interested to learn more about that topic. If that person then finds a related link interesting, they are more likely to share it if the original post did well enough to indicate that other members of the community are interested in the topic. In some ways it feels a bit like the meme culture of other communities, where users are more likely to post items that are related to previous successful posts.

The main interesting thing to me is when the “topic de jour” has very little to do with what I’d normally associate with HN (language genealogy, Neanderthals, and ancient currencies are some examples from recent memory).

That’s still slightly different though. If the bots were just for today’s word, and I were the type of person who likes posting my streaks, I could realistically avoid checking twitter until I’ve solved today’s puzzle. If instead the bots are posting future solutions, it’s much harder to avoid having something spoiled.

It’s not too hard to imagine in a larger code base, where maybe libfrontend is relatively stable but libbackend has active development. Now if I want to update libbackend (maybe a new feature was added, maybe there’s been a critical bug fix) I shouldn’t have to wait for the libfrontend maintainers to update their dependencies, sort out any breaking changes, and verify there were no regressions to do so.

Prior to go modules this was even worse with third party packages. I’ve had cases where my app has integrations with a few google services like maps, sheets, and text-to-speech. It turns out the libraries for all of these services, understandably, also have certain dependencies in common. If you run in to the unfortunate situation where you need to update one of the google libraries, and that updated library now relies on an updated version of a dependency required by others, you’ll end up needing to update all of the other libraries. Granted it’s usually a good idea to update, but it turns a theoretical 1 hour task (update library to use new feature) in to a headache that might take several days depending on how big the changes were to the other libraries