This sort of thing is available using utilities like spec kit/spec kitty/etc. But yes it does make it do better, including writing its own checklists so that it comes back to the tasks it identified early on without distraction.
Certainly the “unsupervised agent” workflows are getting a lot of attention right now, but they require a specific set of circumstances to be effective:
- clear validation loop (eg. Compile the kernel, here is gcc that does so correctly)
- ai enabled tooling (mcp / cli tool that will lint, test and provide feedback immediately)
- oversight to prevent sgents going off the rails (open area of research)
- an unlimited token budget
That means that most people can't use unsupervised agents.
Not that they dont work; Most people have simply not got an environment and task that is appropriate.
By comparison, anyone with cursor or claude can immediately start using this approach, or their own variant on it.
It does not require fancy tooling.
It does not require an arcane agent framework.
It works generally well across models.
This is one of those few genunie pieces of good practical advice for people getting into AI coding.
Simple. Obviously works once you start using it. No external dependencies. BYO tools to help with it, no “buy my AI startup xxx to help”. No “star my github so I can a job at $AI corp too”.
Honesty this is just language models in general at the moment, and not just coding.
It’s the same reason adding a thinking step works.
You want to write a paper, you have it form a thesis and structure first. (In this one you might be better off asking for 20 and seeing if any of them are any good.) You want to research something, first you add gathering and filtering steps before synthesis.
Adding smarter words or telling it to be deeper does work by slightly repositioning where your query ends up in space.
Asking for the final product first right off the bat leads to repetitive verbose word salad. It just starts to loop back in on itself. Which is why temperature was a thing in the first place, and leads me to believe they’ve turned the temp down a bit to try and be more accurate. Add some randomness and variability to your prompts to compensate.
Absolutely. And you can also always let the agent look back at the plan to check if it is still on track and aligned.
One step I added, that works great for me, is letting it write (api-level) tests after planning and before implementation. Then I’ll do a deep review and annotation of these tests and tweak them until everything is just right.
Can you help me understand the difference between "short prompt for what I want (next)" vs medium to high complexity tasks?
What i mean is, in practice, how does one even get to a a high complexity task? What does that look like? Because isn't it more common that one sees only so far ahead?
Using nano banana does not require arcane prompt engineering.
People who have not learnt image prompt engineering probably didn't miss anything.
The irony of prompt engineering is that models are good at generating prompts.
Future tools will almost certainly simply “improve” you naive prompt before passing it to the model.
Claude already does this for code. Id be amazed if nano banana doesnt.
People who invested in learning prompt engineering probably picked up useful skills for building ai tools but not for using next gen ai tools other people make.
Its not wasted effort; its just increasingly irrelevant to people doing day-to-day BAU work.
If the api prevents you from passing a raw prompt to the model, prompt engineering at that level isnt just unnecessary; its irrelevant. Your prompt will be transformed into an unknown internal prompt before hitting the model.
> Claude already does this for code. Id be amazed if nano banana doesnt.
Nano Banana is actually a reasoning model so yeah it kinda does, but not in the way one might assume. If you use the api you can dump the text part and it's usually huge (and therefore expensive, which is one drawback of it. It can even have "imagery thinking" process...!)
Did we step into a dimension where only "How do I print('hello world')?" is a valid question while I wasn't watching, because it has a trivial one-line answer?
Hard questions doesn't mean they're bad, it just means many people aren't competent answer them. The same goes for obscure questions; there might just not be many people who care, but the question itself is entirely valid.
Does that mean they're not suitable for S/O?
I... can't believe anyone seriously believes that hard niche problems are too obscure or too hard for S/O to be bothered to grace themselves with.
It's absurd.
It just baffles me that a question that might take some effort to figure an answer out to might 'not be suitable' to S/O.
Almost any hardware, .NET runs on x86, AMD64, ARMv7 and ARM64 processors. Almost any desktop or server OS, .NET runs on reasonably modern versions of Windows, Linux and MacOS.
The complete source code of the server is in the question.
> .NET runs on x86, AMD64, ARMv7 and ARM64 processors. Almost any desktop or server OS, .NET runs on reasonably modern versions of Windows, Linux and MacOS.
I'm not really asking where .NET runs; I'm asking what is the environment to reproduce it in? If it only affects certain ones it's a waste of time to just make people guess.
> The complete source code of the server is in the question.
The .NET runtime is cross-platform, the lower level asp-net infrastructure is included in the runtime. The higher level CoreWCF RPC library OP uses is written fully in C#. I would expect it to run in all environments supported by the .NET runtime.
Personally, I have reproduced the bug on Windows 10 running on AMD64 processor. BTW, the code in the question only communicates to localhost address i.e. doesn’t need any networking on the computer.
The problem with the question as originally asked is not the difficulty or "obscurity".
The problem is complexity and scope.
We don't debug code for others. We expect them to find the specific part of the code that is causing a problem and showcase a minimal reproducible example. For performance issues, we expect them to profile code and isolate bottlenecks - and then they can ask a hard, obscure question about the bottleneck. Or a very easy one, as long as it's something that could make sense to ask after putting in the effort.
In short: we're looking for a question, not a problem. Stack Overflow "can't be bothered to grace itself with" hard niche problems, or with easy common problems. But it is about answering the question that results from an analysis of a problem. Whether that's understanding the exact semantics of argument passing, or just wanting to know how to concatenate lists.
And we're looking for one question at a time. If there are multiple issues in a piece of code, they need to be isolated and asked about separately. If the task clearly breaks down into a series of steps in one obvious way, then you need to figure out which of those steps is actually causing a problem first, and ask about whichever steps separately. (Or better yet, find the existing Q&A.)
(Questions seeking to figure out an algorithm are usually okay, but usually better asked on e.g. cs.stackexchange.com. And usually, an algorithm worth asking about isn't just "do X, then do Y, then do Z".)
Stack Overflow is full of highly competent people who are yearning for questions that demand their specific expertise - recently, not just in the 2010s.
Most questions I've asked since 2020 were deliberate hooks to deal with common beginner-level issues or close FAQs that didn't already have a clear duplicate target. (I've stopped contributing new Q&A, but still occasionally help out with curation tasks like editing.) But I asked https://stackoverflow.com/questions/75677825 because I actually wanted an answer, and it's an instructive example here.
Answering it required detailed expert-level knowledge of modern CPU architectures and reverse engineering of the Python implementation. Asking it required noticing a performance issue, then putting extensive effort into simplifying the examples as much as possible and diagnosing the exact qualities of the input that degrade performance - as well as ruling out other simple explanations and citing the existing Q&A about those.
But demonstrating it requires nothing more than a few invocations of the `timeit` standard library module.
If that is the current culture on SO, that's very unfortunate. Back when I was active on it - in late 00s to mid 10s - I absolutely did "debug code for others" when the problem was interesting enough to warrant it.
> Back when I was active on it - in late 00s to mid 10s - I absolutely did "debug code for others" when the problem was interesting enough to warrant it.
Yes, lots of people did, including myself.
When I got tired of it, and then came back years later and seen what had happened to the Q&A, I understood that it had been a mistake to do so, and eventually realized - through extensive research on the site meta, Stack Exchange meta, etc. - that it was the same mistake that the site had originally specifically sought to avoid.
And I saw that there had been years of arguing over the labels for close reasons - leading for example to the retirement of "not a real question", and the more or less direct replacement of "too broad" with "needs more focus", and the rather more approximate replacement of "too localized" with "not reproducible or caused by a typo" - because of a collective realization of the real purpose of closing questions, and of the value of being selective. Not just in terms of answer-writers getting frustrated - because we also discovered that some people just don't, and are happy to spend amazing amounts of time trying to read the minds of people who can barely put together a coherent sentence and turn out to be asking about the same common issue for the N+1th time.
And I saw that there had been years of arguing over whether expecting a "minimum level of understanding" was the right phrasing (it's really about the effect that has on question-writing, not just on whether the OP is likely to be able to understand a correctly-written answer - although that does weigh in the calculation), which led to a trial close reason being implemented for a couple of weeks in 2013.
And I saw that by the time I got back, quite a few things had been more or less settled and reasoned out, but that the general community was not on the same page as the people who had been actually thinking about these things. Obviously I didn't agree with everything immediately, and obviously there are still disagreements among those who are broadly speaking on the same page. But I could see the vision.
And I realized that before I left, I had been using the site without putting any effort into trying to understand it. Like most users, I had been "the general community".
(And then I saw that there was tons of unpleasantness between users and the company itself, and unfit-for-purpose site software, and a totally broken reputation system that had never been properly reconsidered. Which is how I ended up checking out Codidact as an alternative. But most of what I say about Stack Overflow isn't really about Stack Overflow; it's about "the Stack Exchange model" - the "Q&A site" as I understand it - which alternative sites still implement.)
We didn't get here spontaneously. Everything was extensively discussed and the discussion is extensively documented, with carefully considered rationale where possible.
> If that is the current culture on SO, that's very unfortunate.
You’re being down voted because you’re not saying anything meaningful.
Yes, you can argue that [person] is [performing an action] because they believe, from their POV that [reason1, reason2, reason3].
> Or does [what person believes] not matter when they act upon it?
Yes.
What people choose to believe is distinct from fundamental baseline reality.
Let me put it another way for you; if I believe that fairies have invaded from space and I go out smashing peoples cars because, I personally, believe that this will make the fairies go home…
…does it help to argue about whether I believe in fairies or not?
It does not.
The arguement must be about whether fairies exist in baseline reality or not.
What I believe is not a point worth discussing.
…so, to take a step back to your argument:
Does he believe this will help? Who. Gives. A. Flying. Truck? Does it matter what he believes? Can we speculate what he thinks? It’s a useless and meaningless exercise and a logical fallacy; because anything can be justified if the only criteria are “you believe it will work”.
The discussion worth having is, in baseline reality, will it actually help?
Which is what the post you are replying to is addressing; but instead or following that up, you’ve moved this discussion into a meaningless sub thread of unprovable points about what people may or may not believe.
This is a concept that is seemingly alien to Americans.
The consequences of your actions matter even if you disagree. When your actions hurt people, you've still hurt people. Doesn't matter what you thought you were doing.
You see this kind of thinking through all levels of American life. You, personally, are the only person on the planet who matters, fuck everyone else and let them deal with the consequences. You run a red light and someone else gets T-boned and killed? That's their problem, you got to your destination 3 minutes faster.
The trump administration is simply the manifestation of how sick our country is.
It's going to take us generations to recover from this kind of societal illness, if we ever can.
They are experts in this field, and, unlike “random person on the internet who spent 2 minutes on google”, have informed opinions on this topic.
If you want a serious discussion on why fluoride is good or bad, that’s where you need to go.
Random person on the internet is very easy to disagree with, because we’re all idiots right? It’s a very easy lazy way of self confirmation.
…but if you are serious about critically considering the issue and facing your own biases, talk to an actual topic expert.
My dentist told me he had carefully reviewed the literature and determined to his satisfaction that public fluoridated water was in the best interests of public health, currently. He offered to share some reading that he was convinced by.
You can’t really ask for more that that.
Discussing this here is a bit like protesting by posting on social media; yes, I suppose it’s better than doing nothing and not engaging with the topic at all… but only barely, and not in any meaningful way.
That study is taken grossly out of context. It doesn’t claim what people claim it does and even the study states that the quality of the data on which the weaker claim was made is suspect.
The bigger issue is that we have vast amounts of scientific data and empirical evidence around fluoride toxicity. People are injured and die due to fluorine exposure, we understand how it interacts with biology. Any mechanism of action that can support the hypothesis that fluorine causes brain damage necessarily invalidates all of this evidence and is difficult to explain as a matter of basic chemistry.
And then we have to explain why fluoride in water has this effect but the much higher levels of fluoride in food does not.
Fluoridating municipal water may not offer much benefit but there is no credible science that it is actually harmful. Large regions of the world have water that naturally has far higher fluorine content than municipal water and there is no evidence of IQ reduction in these regions either.
If you're not prepared to listen to an expert, and that's what your dentist is on this topic, then nothing I, or anyone else can say, makes any difference to you.
At some point, you have to accept that your random wikipedia page and 5 minutes on google is not a convincing argument.
This is right up there in the conspiracy theory territory.
Rational discussion means listening to experts and admitting that you are not an expert.
What do you want me to say?
You aren't a qualified expert on this topic. If you want an expert opinion, talk to an expert, not some dubious fucking provenance wikipedia page.
Your dentist is not an expert in this — that’s like saying the guy implementing your frontend is an expert in design. Yes, they’re working in the space, but their job isn’t understanding the whole system.
If you’re this deep on the appeal to authority train, the NIH released a report in the last year linking fluoride exposure to moderate drops in IQ with moderate confidence.
It’s probably not the worst thing in the world, but is definitely not inert.
I am competent on this particular subject matter, I have worked in fluorine chemistry and am familiar with the biology and medical literature of fluorine toxicity. The report made much weaker claims than people seem to think.
There is a very serious mechanism of action problem. Fluorine poisoning is a thing that happens. The observed effects and empirical evidence, as well as the mechanisms of action that cause them, are incompatible with any mechanism of action that supports the hypothesis that it causes brain damage. Basically, it would invalidate the entire history of actual fluoride exposure.
The other serious problem is that people are exposed to far more fluorine through what they eat than through water. What is special about trace levels in municipal water? And many parts of the world have far higher natural fluoride levels in their water than any municipal water supply with no evidence of adverse consequences. This has been studied many times in many countries! In fact, the only consistent correlation with naturally high fluoride levels is better cardiovascular health (for which there is a known mechanism of action).
This notion that trace levels of fluoride in some municipal water is adversely impacting IQ based on thin evidence from the developing world is just the public health version of “faster than light neutrinos”. Someone thinks they measured it but it contradicts everything we know about the subject. The rational approach isn’t to discard everything we know without a hell of a lot more evidence.
I don’t think adding fluoride to municipal water does much these days but it also isn’t harming anyone.
It also seems to mirror the rhyme with the vaccine "debate."
That debate is framed around being vaccinated vs the scare of "vaccine caused autism" (or myocarditis), but that frame is missing the risk of things like measles.
Likewise tooth decay is not only expensive, but it can have dreadful health consequences if left unaddressed. Missing teeth is also socially costly. Being poor or "ugly" or poor looking is a serious adverse health consequence. Imagine parents barely making ends meet or working multiple jobs. It's easy to imagine disadvantaged kids missing out on dental care.
I also explicitly remember reading multiple reports of poor tooth health correlating with dementia development. I've also read that serious infections of any sort can harm IQ.
Sure, but we need to look at this from the other side, too. Does fluoridating water provide benefits? I think it's safe to say it did way back when we started doing it. But we didn't have fluoride toothpaste back then. Putting fluoride in the water is presumably more costly than not doing it. If it's actually providing benefits, and the risk of harm is below some very low threshold, then sure, let's keep doing it. But is it actually providing benefits?
I would be really surprised if dentists had much expertise on the impact of fluorine on physiology or the mechanisms of action for its toxicity. They know what it does to your teeth, and maybe that it is known to have positive effects for cardiovascular health, but that is about the extent of it. The systematic effects on the rest of your body are outside their domain.
Chemists who work in fluorine chemistry on the other hand have to become experts on the biological effects of fluorine exposure. Small and seemingly innocuous exposures can do a lot of damage and kill you, though not in a way that lends any support to the idea that municipal fluoridation will harm you. If you do understand how it kills you (basically by being exceptionally narrowly focused on making free calcium ions and to a lesser extent magnesium ions biologically unavailable), it is hard to describe a chemically plausible scenario that somehow avoids this basic fact of chemistry. Fluoride behaves the same way outside the body.
Municipal water exposure is far below the noise floor for fluoride. Food has far higher levels of fluoride than municipal water and the body has ample excess calcium and magnesium to absorb the loss of bioavailability of a microscopic amount of those minerals. Humans consume calcium measured in grams per day, multiple orders of magnitude more than can be lost via municipal fluoridation. Natural dietary variation will have a far larger effect.
Who do you think conducted those peer-reviewed systematic reviews? I'm sorry if I don't take the word of some random guy's dentist over multiple meta analyses in major medical journals.
And I don't need an expert to tell me people should have the right to make their own medical decisions.
And finally, I live in a country where public health experts have decided against water fluoridation. This is represents the vast majority of countries. What now? Should I pick some other experts to listen to?
Who do you think conducted those peer-reviewed systematic reviews? I'm sorry if I don't take the word of some random guy's dentist over multiple meta analyses in major medical journals.
I don’t understand what you mean here. Are you just wholly rejecting the concept of expert knowledge, trials, meta analyses, basically the foundations of science, just because in order to participate in it you have to have tainted yourself by rigorously studying it?
You are not an expert in this field, and cherry-picking random articles in random journals does not make you an expert.
> Should I pick some other experts to listen to?
I think it's reasonably clear that you haven't spoken to an expert in this field.
> I'm sorry if I don't take the word of some random guy's dentist over multiple meta analyses in major medical journals.
Are you certain you're competent to review and understand the literature on the topic? It takes a lot of time and effort; that's what dentists do as a job. That's why they have to go to school. That's why random people on the internet do not do dentistry.
If you don't trust my dentist, then talk to your dentist.
This is literally my point: I'm not telling you how it is; I'm telling you, talk to someone who knows what they're talking about; and, don't believe that you are an expert because you put some trivial amount of effort into investigating it yourself.
I'm also not convinced that a dentist is credibly an expert here. Sure, I would absolutely expect my dentist to understand what benefits fluoridated water might provide to my teeth. I would not, for example, expect my dentist to be an expert in whether or not fluoridated water could cause damage to other parts of my body.
My previous dentist pushed these $80 (not covered by insurance) fluoride treatments on every cleaning visit. There's no research that shows much of anything about their effectiveness (good or bad). Yet they push them anyway, because it (their words) might help and probably won't harm. That doesn't give me a good feeling about their competence to have an expert opinion on this sort of thing.
I would, however, trust the opinion of someone who is doing medical/dental research, and holds a doctorate in a relevant field.
> Talk to your dentist. They are experts in this field
No they are not. The are experts are filling cavities and treatment. They have no additional knowledge of fluoride in water vs any other interested person.
For that you need to talk to someone in research, which is not someone seeing patients.
The vast majority of dentists are not public health experts, and will have little to offer other than “exposing your teeth to fluoride regularly is good”.
> However, what's wrong with allowing another app to post messages to my messages?
> If I don't want it, let me turn them off.
Can you it off for anyone sending you messages too?
That's the issue; you not wanting to use it does not mean that spammers won't use it.
That's the problem. You can't have nice things if some people can use it to abuse the system; and there are a lot of people who will.
> But my point is this isn't something unreasonable for a user to want.
This ignores the reality which is that doing it in a way that gives a nice user experience without an enormously painful security issue is really non trivial.
Maybe it's OK to have the choice?
...
If you love your android phone, don't care about iOS, don't like iphones.... why do you care? I mean, why does it upset android users when they see this sort of thing for people using iphones?
It mystifies me. If you love you phone, and you think it's better, then use it.
Automating imessages has been an official thing in macos since ages that i know of, but it is done on a computer rather than a phone. The argument that opening up automation for imessage will increase spam does not hold, just because automation is already opened up, thus whatever spam this allows or not is already here.
EDIT: example script to run from a mac terminal:
osascript -e 'tell application "Messages" to send "$message" to buddy "+12345678" of (1st service whose service type = iMessage)'
Because running a parallel process is often difficult. In most cases, the question becomes:
So, how exactly is my app/whatever supposed to spin up a parallel process in the OS and then talk to it over IPC? How do you shut it down when the 'host' process dies?
Not vaguely. Not hand wave "just launch it". How exactly do you do it?
How do you do it in environments where that capability (spawning arbitrary processes) is limited? eg. mobile.
How do you package it so that you distribute it in parallel? Will it conflict with other applications that do the same thing?
When you look at, for example, a jupyter kernel, it is already a host process launched and managed by jupyter-lab or whatever, which talks via network chatter.
So now each kernel process has to manage another process, which it talks to via IPC?
...
Certainly, there are no obvious performance reasons to avoid IPC, but I think there are use cases where having the compiler embedded makes more sense.
> So, how exactly is my app/whatever supposed to spin up a parallel process in the OS and then talk to it over IPC?
Usually the very easiest way to do this is to launch the target as a subprocess and communicate over stdin/stdout. (Obviously, you can also negotiate things like shared memory buffers once you have a communication channel, but stdin/stdout is enough for a lot of stuff.)
> How do you shut it down when the 'host' process dies?
From the perspective of the parent process, you can go through some extra work to guarantee this if you want; every operating system has facilities for it. For example, in Linux, you can make use of PR_SET_PDEATHSIG. Actually using that facility properly is a bit trickier, but it does work.
However, since the child process, in this case, is aware that it is a child process, the best way to go about it would be to handle it cooperatively. If you're communicating over stdin/stdout, the child process's stdin will close when the parent process dies. This is portable across Windows and UNIX-likes. The child process can then exit.
> How do you do it in environments where that capability (spawning arbitrary processes) is limited? eg. mobile.
On Android, there is nothing special to do here as far as I know. You should be able to bundle and spawn a native process just fine. Go binaries are no exception.
On iOS, it is true that apps are not allowed to spawn child processes, as far as I am aware. On iOS you'd need a different strategy. If you still want a native code approach, though, it's more than doable. Since you're on iOS, you'll have some native code somewhere. You can compile Go code into a Clang-compatible static library archive, using -buildmode=c-archive. There's a bit more nuance to it to get something that will link properly in iOS, but it is supported by Go itself (Go supports iOS and Android in the toolchain and via gomobile.) Once you have something that can be linked into the process space, the old IPC approach would continue to work, with the semantic caveat that it's not technically interprocess anymore. This approach can also be used in any other situation you're doing native code, so as long as you can link C libraries.
If you're in an even more restrictive situation, like, I dunno, Cloudflare Pages Functions, you can use a WASM bundle. It comes at a performance hit, but given that the Go port of the TypeScript compiler is already roughly 3.5x faster than the TypeScript implementation, it probably will not be a huge issue compared to today's performance.
> How do you package it so that you distribute it in parallel? Will it conflict with other applications that do the same thing?
There are no particular complexities with distributing Go binaries. You need to ship a binary for each architecture and OS combination you want to support, but Go has relatively straight-forward cross-compiling, so this is usually very easy to do. (Rather unusually, it is even capable of cross-compiling to macOS and iOS from non-Apple platforms. Though I bet Zig can do this, too.) You just include the binary into your build. If you are using some bindings, I would expect the bindings to take care of this by default, making your resulting binaries "just work" as needed.
It will not conflict with other applications that do the same thing.
> When you look at, for example, a jupyter kernel, it is already a host process launched and managed by jupyter-lab or whatever, which talks via network chatter.
> So now each kernel process has to manage another process, which it talks to via IPC?
Yes, that's right: you would have to have another process for each existing process that needs its own compiler instance, if going with the IPC approach. However, unless we're talking about an obscene number of processes, this is probably not going to be much of an issue. If anything, keeping it out-of-process might help improve matters if it's currently doing things synchronously that could be asynchronous.
Of course, even though this isn't really much of an issue, you could still avoid it by going with another approach if it really was a huge problem. For example, assuming the respective Jupyter kernel already needs Node.JS in-process somehow, you could just as well have a version of tsc compiled into a Node-API module, and do everything in-process.
> Certainly, there are no obvious performance reasons to avoid IPC, but I think there are use cases where having the compiler embedded makes more sense.
Except for browsers and edge runtimes, it should be possible to make an embedded version of the compiler if it is necessary. I'm not sure if the TypeScript team will maintain such a version on their own, it remains to be seen exactly what approach they take for IPC.
I'm not a TypeScript Compiler developer, but I hope these answers are helpful in some way anyways.
Thanks for chiming in with these details, but I would just like to say:
> It will not conflict with other applications that do the same thing.
It is possible not to conflict with existing parallel deployments, but depending on your IPC mechanism, it is by no means assured when you're not forking and are instead launching an external process.
For example, it could by default bind a specific default port. This would work in the 'naive' situation where the client doesn't specify a port and no parallel instances are running. ...but if two instances are running, they'll both try to use the same port. Arbitrary applications can connect to the same port. Maybe you want to share a single compiler service instance between client apps in some cases?
Not conflicting is not a property of parallel binary deployment and communication via IPC by default.
IPC is, by definition intended to be accessible by other processes.
Jupyter kernels for example are launched with a specified port and a secret by cli argument if I recall correctly.
However, you'd have to rely on that mechanism being built into the typescript compiler service.
...ie. it's a bit complicated right?
Worth it for the speedup? I mean, sure. Obviously there is a reason people don't embed postgres. ...but they don't try to ship a copy of it along side their apps either (usually).
> Not conflicting is not a property of parallel binary deployment
I fail to see how starting another process under an OS like Linux or Windows can be conflicting. Don't share resources, and you're conflict-free.
> IPC is, by definition intended to be accessible by other processes
Yes, but you can limit the visibility of the IPC channel to a specific process, in the form of stdin/stdout pipe between processes, which is not shared by any other processes. This is enough of a channel to coordinate creation of a more efficient channel, e.g. a shmem region for high-bandwidth communication, or a Unix domain socket (under Linux, you can open a UDS completely outside of the filesystem tree), etc.
A Unix shell is a thing that spawns and communicates with running processes all day long, and I'm yet to hear about any conflicts arising from its normal use.
This seems like an oddly specific take on this topic.
You can get a conflicting resource in a shell by typing 'npm start' twice in two different shells, and it'll fail with 'port in use'.
My point is that you can do not conflicting IPC, but by default IPC is conflicting because it is intended to be.
You cannot bind the same port, semaphore, whatever if someone else is using it. That's the definition of having addressable IPC.
I don't think arguing otherwise is defensible or reasonable.
Having a concern that a network service might bind the same port as an other copy of the same network service deployed on the same target by another host is an entirely reasonable concern.
I think we're getting off into the woods here with an arbitrary 'die on this hill' point about semantics which I really don't care about.
TLDR: If you ship an IPC binary, you have to pay attention to these concerns. Pretending otherwise means you're not doing it properly.
It's not an idle concern; it's a real concern that real actual application developers have to worry about, in real world situations.
I've had to worry about it.
I think it's not unfair to think it's going to be more problematic than the current, very easy, embedded story, and it is a concern that simply does not exist when you embed a library instead of communicating using IPC.
> It is possible not to conflict with existing parallel deployments, but depending on your IPC mechanism, it is by no means assured when you're not forking and are instead launching an external process.
Sure, some IPC approaches can run into issues, such as using TCP connections over loopback. However, I'm describing an approach that should never conflict since the resources that are shared are inherited directly, and since the binary would be embedded in your application bundle and not shared with other programs on the system. A similar example would be language servers which often work this way: no need to worry about conflicts between different instances of language servers, different language servers, instances of different versions of the same language server, etc.
There's also some precedent for this approach since as far as I understand it, it's also what the Go-based ESBuild tool does[1], also popular in the Node.JS ecosystem (it is used by Vite.)
> For example, it could by default bind a specific default port. This would work in the 'naive' situation where the client doesn't specify a port and no parallel instances are running. ...but if two instances are running, they'll both try to use the same port. Arbitrary applications can connect to the same port. Maybe you want to share a single compiler service instance between client apps in some cases?
> Not conflicting is not a property of parallel binary deployment and communication via IPC by default.
> IPC is, by definition intended to be accessible by other processes.
Yes, although the set of processes which the IPC mechanism is designed to be accessible by can be bound to just one process, and there are cross-platform mechanisms to achieve this on popular desktop OSes. I can not speak for why one would choose TCP over stdin/stdout, but, I don't expect that tsc will pick a method of IPC that is flawed in this way, since it would not follow precedent anyway. (e.g. tsserver already uses stdio[2].)
> Jupyter kernels for example are launched with a specified port and a secret by cli argument if I recall correctly.
> However, you'd have to rely on that mechanism being built into the typescript compiler service.
> ...ie. it's a bit complicated right?
> Worth it for the speedup? I mean, sure. Obviously there is a reason people don't embed postgres. ...but they don't try to ship a copy of it along side their apps either (usually).
Well, I wouldn't honestly go as far as to say it's complicated. There's a ton of precedent for how to solve this issue without any conflict. I can not speak to why Jupyter kernels use TCP for IPC instead of stdio, I'm very sure they have reasons why it makes more sense in their case. For example, in some use cases it could be faster or perhaps just simpler to have multiple channels of communication, and doing this with multiple pipes to a subprocess is a little more complicated and less portable than stdio. Same for shared memory: You can always have a protocol to negotiate shared memory across some serial IPC mechanism, but you'll almost always need a couple different shared memory backends, and it adds some complexity. So that's one potential reason.
(edit: Another potential reason to use TCP sockets is, of course, if your "IPC" is going across the network sometimes. Maybe this is of interest for Jupyter, I don't know!)
That said, in this case, I think it's a non-issue. ESBuild and tsserver demonstrate sufficiently that communication over stdio is sufficient for these kinds of use cases.
And of course, even if the Jupyter kernel itself has to speak the TCP IPC protocols used by Jupyter, it can still subprocess a theoretical tsc and use stdio-based IPC. Not much complexity to speak of.
Also, unrelated, but it's funny you should say that about postgres, because actually there have been several different projects that deliver an "embeddable" subset of postgres. Of course, the reasoning for why you would not necessarily want to embed a database engine are quite a lot different from this, since in this case IPC is merely an implementation detail whereas in the database case the network protocol and centralized servers are essentially the entire point of the whole thing.
What, I ask, is the point of having laws and rules if you can just ignore the ones you don't like?
Its just a name, who cares?
Not me.
…but, if you break the law, you break the law. Not maybe maybe who cares, its not me being water boarded, I dont care…
If you break the law. You break the law.
Otherwise, who gives a duck what congress says?
Just fire them all and crown Trump King of America.
I’m being facetious. …but maybe its more of a big deal than you superficially pretend it is.
It’s just another case of the administration blatantly breaking the rules.
…so, you know. If youre ok with no laws or rules, I guess its fine.
Seems a bit chaotic to me. I prefer my governing body to be… marginally bound by some kind of responsibilty to something or someone.