Hey there, I'm going to check out your project because the comments here have me a little worried that OP's project might have some quality issues.
Two things I found a little confusing from the docs though:
I couldn't easily find a page describing what it can't do yet. I saw that it only works with a "strict, deterministic subset of TypeScript", but is there a page showing what's included and not included in that subset?
Also, what's an "ambient surface" in this context? Is that a compiler term I'm just not familiar with?
I'll add that page, thanks. Today, almost all of idiomatic TS is supported including most of its utility classes. Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc. I'll compile a list, and include it along with the large docs cleanup planned before v1.
> Also, what's an "ambient surface" in this context?
The idea is that when JS gets transpiled into C# (or Rust, upcoming), JS globals and built-ins are invalid. The native "surface" is C#, meaning the string is .Net's string type and the methods that you expect on JS strings would be missing. But when you opt in to a surface, such as the "JS surface", the compiler applies surface defined translations such as substring becoming SubString, either directly or via a companion helper class. This allows you to write against standard JS and Node APIs, instead of relying on the stdlib/builtins of the target framework (currently CLR). And you get the JS "stdlib" - console, JSON, Date, Map, Set etc.
> Dynamic JS-style code is not supported, for example adding a function or a field into an object, prototype-based class modifications etc.
FYI, just in case you didn't know, there is an ExpandoObject type in the System.Dynamic namespace that you could use to do this. IDK if you want to, but it's one of those less common .NET features that people tend to not be aware of.
tsonic uses NativeAOT by default, and DLR/System.Dynamic isn't supported in NativeAOT. There are switches in tsonic to give you MSIL, but that's used mostly for testing or for compat reasons.
This is such a refreshing policy. AI code is welcome as long as it's good, but comments have to be human.
If someone can't take the time to write their own replies (in their own words), then it feels fair to assume that they didn't take the time to test, review, and clean whatever code they submitted.
Yeah I really agree. There's no overage pricing on their website's main pricing page, which makes me think the jump from "Team" to "Pro" to negotiating an enterprise contract will really hurt. Going from $39/month to $199/moth because you needed slightly more is a really big jump in pricing. It's pretty much the opposite of what I would expect from a service that lets you scale to 0.
Props to them. That makes DeepSeek v4 Pro extremely cheap compared to others, even in the same category. Look at these prices per million outputs tokens:
It's actually even cheaper when you look at the cache read costs. Those costs can dominate in agent workflows and DeepSeek's cost for cache reads is insanely low comparatively. At $.003626/M tokens, the cheapest other thing on your list is >$.2/M tokens. That's on the scale of 100x cheaper.
Also, deepseek cache hit rates are pretty good. I use deepseek v4 flash model regularly for agentic tasks (more than 20 tool calls on average per run), and 70%+ of input tokens get served from cache.
The speed is absolutely bonkers too. I once misconfigured a mcp I was developing locally, and told it to use the tools provided by this mcp to get certain task done. It figured out that the mcp is misconfigured, and then automatically went ahead and started to fix the mcp, fixed it, and then started using it by passing raw jsonrpc messages using stdin/out, bypassing the harness integration (since it would have needed a restart).
It did all of this in under 30 seconds and made over 15 tool calls in all of this (yes, I use yolo mode in a container, so my agents have full access to everything in the container).
OpenCode Go is not DeepSeek. They may host the model but they're run by an entirely different organisation.
I imagine when onlyrealcuzzo said "they don't make the model worse once you have a subscription", he didn't mean OpenCode Go, otherwise they would have probably said so.
Right, but then whether the service degrades with a subscription or not is up to the service provider - not DeepSeek themselves. In this case, it would make more sense to say "OpenCode Go don't degrade the quality of the DeepSeek offering with the subscription", etc.
I'm aware I'm slightly nitpicking but your message more or less implied you could get a DeepSeek subscription.
Seems like a branding mistake to me. This new device doesn't target the same group of customers that the Flipper Zero did, so it will be much harder for them to market it effectively, since the first device is already famous enough that people know them for that market.
Stupid question: I was under the impression that object storage was super expensive compared to "normal" SSDs if the QPS numbers got high.
Is that not the case for DBs based on object storage because they cache data before sending it to the object storage? Or because they do some other processing on the DB server before it hits storage?
Not stupid at all. API cost (especially for writes) is indeed one of the main challenges of building for object storage. DBs mitigate this by aggressively caching reads and batching writes. There's a fundamental latency/cost tradeoff here - you accept higher latency to get enough batching to amortize PUT costs. This is a very reasonable tradeoff for search systems which typically aren't as latency sensitive.
Is that true? It just goes right into the code with no initialization of any other libraries needed?
reply