AI from China: DeepSeek; Open Source

DeepSeek claims its 'reasoning' model beats OpenAI's o1 on certain benchmarks | TechCrunch

Chinese AI lab DeepSeek has released an open version of DeepSeek-R1, its so-called reasoning model, that it claims performs as well as OpenAI’s o1 on certain AI benchmarks.

R1 is available from the AI dev platform Hugging Face under an MIT license, meaning it can be used commercially without restrictions. According to DeepSeek, R1 beats o1 on the benchmarks AIME, MATH-500, and SWE-bench Verified.

DeepSeek - Wikipedia

China’s Domestic AI Competition Heats Up

at the World Artificial Intelligence Conference in Shanghai, Baidu’s CEO, Robin Li Yanhong, asked a surprising question: Does China have too many AI startups? As he put it: “In 2023, intense competition among over 100 LLMs has emerged in China, resulting in a significant waste of resources, particularly computing power. … How about real-world applications? Who has benefited from them?”

DeepSeek R1 - o1 Performance, Completely Open-Source - YouTube

run TypeScript: tsx vs ts-node

TypeScript is complex. JavaScript ecosystem is complex.
Most things can be done in may different ways, and things break and stop working all the time.
When ts-node has some issues, often tsx works. That is helpful.
But is it enough to "switch"?

Frequently Asked Questions | tsx

GitHub - privatenumber/ts-runtime-comparison: Comparison of Node.js TypeScript runtimes

TSX vs. TS-Node and Nodemon. Which NodeJS runner is fastest for… | by Lincoln W Daniel | ModernNerd Code | Medium

"I wanted tsx to be faster since it's so much simpler, but it unfortunately is not... "

Migrating from ts-node to tsx · GitHub

• ts runtime comparison
• tsx GitHub   tsx - npm (1.7M/week)
• ts-node GitHub  ts-node - npm (9.2M/week)
  
  

• tsx is zero-config because it has smart detections built in. As a runtime, it detects what's imported to make many options in tsconfig.json redundant—which was designed for compiling matching files regardless of whether they're imported.
• It seamlessly adapts between CommonJS and ESM package types by detecting how modules are loaded (require() or import) to determine how to compile them. It even adds support for require()ing ESM modules from CommonJS so you don't have to worry about your dependencies as the ecosystem migrates to ESM.
• At the core, tsx is powered by esbuild for blazing fast TypeScript compilation, whereas ts-node (by default) uses the TypeScript compiler.

• ts-node incorporates type checking, tsx does not
• tsx handles package types automatically, ts-node does not

node --import tsx adds support for both Module and CommonJS contexts. To only import one, you can use node --import tsx/esm or node --require tsx/cjs.

node -r ts-node/register only supports a CommonJS context, node --loader ts-node/esm must be used for projects that are type Module.

"On average tsx was faster, (about twice as fast on medium sized projects), than ts-node. tsx also includes a watch option which automatically reruns when the codebase is changed, which can be useful in certain circumstances. 

Overall, it feels that losing type checking for a faster and more flexible runtime is a better choice ... for running tests and small dev scripts.