nasretdinov

IMO it's competition that makes better products in the end. If either party becomes a full monopolist the progress will stall (as already happened with Intel I guess)

Depending on what you're working on, moving slowly and thoughtfully might be a feature. Just saying

Definitely not my experience. No matter the model, if I'm working on something important (and there is little reason on working on something not important) I do care about correctness and understandability. While LLMs are great for throwaway one-time code (although that's also debatable), they cannot compete with code written by a seasoned professional. No matter how many times I've tried delegating writing code to LLMs I've always regretted it in a few months' time, because it is more buggy and I don't really know what is happening there.

The future is using LLMs for what they are good for. What that is still being found out. I've had great experience with LLMs reviewing the code (matches with Primagean's ~50% accuracy at finding bugs, which is really good) and for explaining unfamiliar concepts to me.

I firmly believe that the code itself needs to be 100% organic, and if it's not and you're relying on LLMs to generate tons of code, you haven't built enough abstraction to make it unnecessary.

That is true. Moreover, in general the performance of generic code in Go isn't any better than interface-driven one. Generics are there in Go just for better type safety, and IMO that's sufficient already :)

The only really confusing part to me is that SQLite has separate STRING and BLOB type.ls. I always thought SQLite only really supports INTEGER, REAL and TEXT (aka BLOB) types. And even then the types aren't enforced. So it's really interesting to see that you still somehow can distinguish TEXT from BLOB for example.

P.S. I meant default settings -- I know that strict mode, etc, exists, but it's not the default, so few people change it

if you have some complex config instead of a simple default

Yup, exactly that. You don't always control the environment in which your software is going to run...

Given that even on Linux DNS resolution in Go can be quite... interesting without CGO being enabled, honestly it's hardly surprising that on iOS it would also be quite challenging.

I imagine that one more interesting thing to consider is that on iOS you can't fork() or spawn sub-processes, so your Go mobile app is indeed running simultaneously as a Go binary and the UI, and there probably can exist countless interactions between the two being unaware of each other that might cause issues

As others have already pointed out, the issue is too high concurrency — IMO that should be the main outcome of the analysis. E.g. InnoDB has innodb_thread_concurrency setting that applies for internal operations to prevent exactly kinds of issues like these. Yet MySQL isn't perfect in any regard either, it's also very much possible to hit lock (or latch as they're called in DB world) contention if you hit the same rows in a table too hard from too many different threads. It's a fundamental limitation of the CPUs that they can't do too much of parallel read-modify-write, and it starts to break down very quickly with the number of cores

I can trivially copy any code even without an LLM though with a simple tool called rsync!

Value types do indeed reduce the GC pressure, however large Virtual Memory usage (in my understanding) is mostly due to large thread count by default (one per core), and some unavoidable GC overhead in general.

I can agree with Dan on two things: LLMs do often produce incorrect results and that it's still useful for productivity when used in moderation. For me the wrong results actually cause some kind of ragebait response so I become much more motivated to learn more about the subject to actually generate correct response. After I've learnt the subject area enough I find I'm better off having LLM review my code instead of writing it.

I haven't even begun to try to comprehend how to use fuzzing testing to improve the ability to find bugs, but it sounds really interesting. I've seen mutation testing to be very useful for finding gaps in tests, so I can only imagine that fuzzing + LLMs might produce insane results.

You probably could limit the bloating of Go programs by setting GOMAXPROCS to something like 1 or 2 on smaller machines, but then again you wouldn't get the best performance. So IMO good call here to rewrite it in a language without GC.

Codeberg is smaller than GitHub and, you know, Go is slightly more efficient than Ruby :)

I must say I'm quite pleased to see how well Go version works. It does only use 1.5x the CPU and (predictably) much more RAM/VRAM, but not a crazy amount either (the expected increase is 2x).

Of course you can write a more optimal version in C / C++ / Zig / Rust, but at the same time Go is much easier to write and you don't pay for the convenience with an absurd performance loss like in Python or PHP

It's interesting how on a server 2 GiB of RAM can get you quite far, however on a desktop that's pretty much the minimum feasible amount. It used to be the opposite: servers needed plenty of RAM and CPU compared to desktops

One other feature of memcache that is rarely mentioned is that all operations are O(1) by design, which is a conscious design choice from the authors: yes, it is limiting, but it also ensures no random stalls on simple operations, whereas Redis with its single-threaded core design can't guarantee that since you can run operations of arbitrary complexity (which surely as a developer make you feel very smart about it) and everything else will be waiting for them to complete

Yeah I kinda agree about Go. CockroachDB didn't catch on nearly as much as it should, and I wonder how much it has to do with the fact that optimising code in Go (both in terms of memory usage and performance) is just much harder than C

Proving something is correct doesn't automatically make it obvious though. For it to be obvious it needs to either be intuitive or it needs to be (reasonably) simple

I think you're underselling your own level of intelligence Fil. If even you would be confused by an implementation (and you're the author of the concept) what chances do you think this PR has to actually work correctly?

Compilers aren't made equal either. E.g. compare Visual Studio C++.NET compiler and something like Go. And Go isn't that simple either to be fair

I think LLVM is a perfect example of what happens when it's too complicated: it's slow, it's bug-ridden when you stray away from the beaten path (e.g. Rust hits bugs in LLVM like this one https://www.reddit.com/r/rust/comments/l4roqk/a_fix_for_the_... ), and it's really hard to use and understand.

It's obviously not useless because of that, but it's a great example of what happens when you cannot fully control the implementation complexity

I think it's also worth distinguishing _problem complexity_ and _solution complexity_. The problem might be really really hard (and it very obviously is in the case of adding multi-threading to JavaScript). But it does not mean that the solution has to be hard to understand. It doesn't mean that any average PHP developer (I can say that, I started with PHP) should be able to verify the correctness of the patch, but for a person who is well familiar with the area there shouldn't exist areas they can't understand.

Look at the description of your own Fil-C: it focuses on clarity of explanation of how it works, and it actually does make sense (and, hopefully, works well enough too). Compare that with the pull request sent here. I'll wait

IMO the very minimum requirement should be that you've demonstrated effort to reduce unnecessary complexity of the problem. Sure, some problems are complex enough that there might not exist an obvious solution, yet usually after a while once you're familiar with some topic the existing solutions do start to appear obvious. If they're not I'd argue we're doing something very very wrong

The code needs to be not in the state of "no obvious bugs", but "obviously no bugs". Especially the programming language runtime. Otherwise there is no hope you can sustain any development whatsoever

That feature is central for ClickHouse Cloud offering which essentially is what lets others have (the rest of) ClickHouse for free. If you need that feature I think it's quite obvious you'll have to pay. I don't think it's an unreasonable stance at all.

P.S. I don't believe you are right to call it "zero copy" either. The object storage itself is replicated and definitely does copy and/or split data a lot under the hood. In some sense it's no different from ClickHouse's replication, apart from that ClickHouse can't use erasure codes to reduce the data footprint, whereas many advanced object stores can

I think the main advantage of ClickHouse over DuckDB is *MergeTree family. It lets you sort data in the background, which allows for absurd levels of compression and performance when done right. ClickHouse can easily be 10x as performant as DuckDB querying Parquet when querying non-indexed columns, and obviously infinitely faster than DuckDB when you're touching primary key.

There are so many comparisons between the two, but realistically ClickHouse and DuckDB occupy completely separate niches, where DuckDB is just a really powerful analytics _engine_, and ClickHouse is a full database management system, with replication, MergeTree engine, etc.

No, in fact I do not use TS at all :).

However they did mention this in the article, and hopefully that also means they'll make the package accessible to others too:

The watcher is a self-contained package that has allowed us to keep a clean separation of concerns between what we care to watch and why.

This sounds really great. As a Go developer I'm also really looking forward to their Go port of the filesystem watcher package — I agree that the existing packages don't fully allow to do a reliable recursive directory watch and it would be great to have something where you don't rely on C dependencies just for this thing.

Isn't it still the case then? I used the basic HTML version when I was working at Google to try to understand whether or not it was slow because of the (unoptimal) frontend or not (it was the backend that sometimes took >=600ms to load messages unfortunately, not the frontend).

Local food markets offer much better options than Pret to be fair