Edit: 310fps vs 240fps
464 karma · joined March 2, 2008
[ my public key: https://keybase.io/alec; my proof: https://keybase.io/alec/sigs/EwhDB5ZFYHetGQT4QBxryMKudydFlHx6vfI2ZbYaXTY ]
hnchat:M7diobfazxWsK0TZ9aVm
Edit: 310fps vs 240fps
I'd be interested to know what metric you're basing this on.
Outside the Apple ecosystem, LLVM seems to have made very little inroads that I can see. No major Linux distribution that I'm aware of uses LLVM, and Windows is still dominated by MSVC.
Edit: Oh I see, ivm itself relies on Cargo to build inko rather than downloading binaries.
Still, it would be nice if it didn't need another language's toolchain just to use Inko :(
I'm guessing it's dormant because the level of discourse on HN has devolved to a point where nearly every comment on HN would now qualify.
Edit edit: from this comment it sounds like it is, as you say, just the general overhead of managing goroutine stacks. I wonder if TinyGo is more performant.
Here's their operating model, which sounds like a mix of paid brand manager subscriptions and advertising: https://support.productreview.com.au/hc/en-us/articles/36000...
[1] https://github.com/bytecodealliance/wasmtime [2] https://github.com/bytecodealliance/wasmtime-go
> Say I called a bunch of goroutines when I was in the Add function of the example you gave, would this be a problem?
The Go runtime is initialised once only in c-shared mode for the lifetime of the application - it would make no sense to do it on every function invocation, and be incredibly slow. So the answer to this section and the next one are just largely bogus.
ie. this response
> However, once you call a function via a C or Swift bridge, it becomes a synchronous operation and will block the calling thread until all goroutines have completed execution. Therefore, you would need to effectively manage the synchronization of these goroutines to avoid unnecessary blocking of the calling thread.
And the response to this question:
> You said in 4 the Go runtime may not keep running, does this mean that every invocation of the Add function has to spin up the whole Go runtime every time? Why cant it just stay alive inside the Swift process?
Are completely incorrect.
grpcurl[1] combined with gRPC server reflection[2]. The schema is compiled into the server as an encoded proto which is exposed via server reflection, which grpcurl reads to send correctly encoded requests.
[1] https://github.com/fullstorydev/grpcurl [2] https://github.com/grpc/grpc/blob/master/doc/server-reflecti...
Do you mean like Confluent do? https://www.confluent.io/blog/exactly-once-semantics-are-pos...
It is erroring on `*.html`, which is reasonable because `.html` is an invalid anchor identifier, though the error is not that useful. The parsing of the unquoted version numbers also seems to be "correct", in that things that look like numbers are supposed to be parsed as numbers.
This is rarely the case. Most monorepos shard tests such that wall time is minimised and have dependency analysis that only runs tests affected by the changed code.
More of a problem is that IDEs and LSPs often don't deal well with having to index and navigate very large codebases.
I've maintained both monorepo and polyrepo environments and there are pros and cons to both, and they vary _wildly_ based on the language being used.
Edit: typo
I would expect > 0 results for the above search
Same search on SourceGraph: https://sourcegraph.com/search?q=context:global+kong.New&pat...
https://searchcode.com/?q=kong.New+lang%3Ago
Same search on GitHub:
https://github.com/search?type=code&q=kong.New
Edit: there also doesn't seem to be any ranking at all, such as exact word matches being boosted
$ curl -fsSL 'https://ap-playerservices.streamtheworld.com/api/livestream?station=NOVA_919&version=1.9' | xq -x //transport
http
hls
hlsts
http
http
hls
hlsts
http
hls
hlsts