I still have high praises since one of my clients use it in production.
I personally use it's tooling part which is screamingly fast.
8,063 karma · joined February 13, 2017
https://pastebin.com/raw/bmTqd9eR
Sample output:
02 /\bErlang\b/
04 /\bHaskell\b/i
12 /\b(Angular|Angular5|Angular6)\b/i
13 /\b(PHP|PHP5|PHP7)\b/i
15 /\b(Kotlin)\b/i
15 /\b(Scala)\b/i
15 /\b(Swift)\b/i
16 /C#/i
16 /\b(Vue|VueJS)\b/i
18 /\b(Rust)\b/i
36 /\b(Java)\b/i
37 /\b(Ruby)\b/i
39 /\b(Go|GO|Golang|golang|GOLANG)\b/
47 /\bC\b|C\+\+/i
60 /\b(Node|NodeJS)\b/i
84 /\b(JS|JavaScript)\b/i
95 /\b(Python)\b/i
147 /\b(React|ReactJS)\b/iI personally use it's tooling part which is screamingly fast.
I think there is a valid insight here which many already know: LLMs are much more reliable at creating scripts and automation to do certain tasks than doing these tasks themselves.
For example if I provide an LLM my database schema and tell it to scan for redundant indexes and point out wrong naming conventions, it might do a passable but incomplete job.
But if I tell the LLM to code a python or nodejs script to do the same, I get significantly better results. And it's often faster too to generate and run the script than to let LLMs process large SQL files.
No tooling, no animation, no hidden features, no explanation of how things work upon clicking them.
But I'm glad to be proven wrong if you know a static analysis tool I can point to the repo and come up with comparable result.
Which is fair but just be honest about it.
/r/programming was already unappealing because they tend to be late to surface interesting content in comparison to HN.
Their JSON even does cross-platform SIMD and their Kestrel stack was top 10/20 on techempower benchmarks for a while without the ugly hacks other frameworks/libs use to get there.
stdlib is the science of good enough and sometimes it's far above good enough.
Libraries also don't get it right the first time so they increment minor and major versions.
Then why is it not okay for built-in standard libraries to version their functionality also? Just like Go did with JSON?
The benefits are worth it judging by how ubiquitous Go, Java and .NET are.
I'd rather leverage billions of support paid by the likes of Google, Oracle and Microsoft to build libraries for me than some random low bus factor person, prone to be hacked at anytime due to bad security practices.
Setting up a large JavaScript or Rust project is like giving 300 random people on the internet permission to execute code on my machine. Unless I audit every library update (spoiler: no one does it because it's expensive).
But realistically this will bring you so much bitterness that, even if the money is good, you might want to search for your next client or a "normal" dev job while working for this client.
A more apt comparison is vs Windows and macOS.
And Linux offer more than these two with regards to security.
These models are dumber and slower than API SoTA models and will always be.
My time and sanity is much more expensive than insurance against any risk of sending my garbage code to companies worth hundreds of billions of dollars.
For most, it's a downgrade to use local models in multiple fronts: total cost of ownership, software maintenance, electricity bill, losing performance on the machine doing the inference, having to deal with more hallucinations/bugs/lower quality code and slower iteration speed.
In fact it even gives the user more security tools.
So I fail to reason on you singling out Linux here.
Linux has the most powerful native process isolation arsenal at the user disposal.
And some distros use even more isolation mechanisms on top of the ones provided by the kernel like snap and flatpak.
And then you can recreate the entire thing like a spellbook with nix.
Docker works natively in it. Do I need to say more?
Linux is a decade ahead here with regards for security options available to the user.
I won't even ask for an example of otherwise, but feel free to provide a repo where a human did that.
But to the rest of the world variable refresh rate existed for years by then. As is with most Apple "inventions".
In this case the patent goes back to 1982: https://patents.google.com/patent/US4511892A/en
There are various reasons for this, major one being that the 9800X3D has more L3 cache per thread than the 9950X3D.
And also wrong that a 9950X3D is 2x 9800X3D combined. A quick glance would tell you that, since 9950X3D has 128MB of L3 cache shared between more threads while 9800X3D has 96mb for half the threads, so more L3 per thread.
And most of the times, even when a 9800X3D loses to 9950X3D in games, it's usually within 1-4% margin for most games.
It's a monster for games and some workloads.
It's funny that people who blindly buy 9950X3D for gaming+office workloads without checking benchmarks often end up with similar or slower performance.
Much smarter to use the price difference on other hardware to speedup other things such as faster NVMEs, efficient silent cooling, faster GPUs, etc.
1) That is relatively very slow.
2) Can also be done, simpler even, with SoTA models over API.
Not only it is screamingly fast (the fastest on earth for some workloads), but I can upgrade it easily. And is dead silent too.
The best thing is it runs native Linux and it just works.
Hah! I'll use that argument if I ever get PIP'd.
No but seriously, constantly moving doesn't mean fast enough. Swift took took long to have cross-platform support.
And it is still uberslow to compile. To the point of language servers giving up on analyzing it and timeout.
Plus Swift is arguably too unnecessarily complex now.
And there's Rust/Zig so why use Swift for low level?