shikck200

Pure LOLPHP matrial

Other countries moving their gold out of the US, LOL

Companies pay for claude, devs not. IF i had to use AI from my own purse, i would never pay for a claude sub.

Lisp allows for some really, really complex and spaghetti code bases. I have seen the ultimate macro-hell from top to bottom. I know syntax does not matter, but i just cant honestly say i read lisp code as clear as something like Go. I guess it boils down to style. I have seen 100 lisp styles, and only one Go style.

Looking at the source i was not surprised. A shell html page, that uses a shittonne of javascript, and obviously does not even include the static content per page load. Its sad that this is the status quo of the AI slop you see.

"How do we finally get rid of trump?"

> Chat is unavailable right now.

> Criticise person X for being a "absolute scumbag"

> Yolo

> Switch to person X software anyway.

This is the most weak double standards i have seen in a while. IF you mock someone for what they did 10 years ago, have the balls to stand by it.

The fact that i would use 99% less dependencies, and overall have a WAY more simple deployment story. Also a typed language is always better than the PHP way, where you have functions that are hard to reason about, and edge cases llms miss easily.

I never had issues with token use at this scale. More so i would say a huge bloated framework uses more tokens as the LLM might read the source to understand why something works as it does. With stdlib only most LLM already knows it.

Also a laravel "rate limiter" sound suss. Its probably needs some extra dependency like redis + a supporting php library to work. On the contrary i can mock up a reasonably efficient in memory rate limiter in pure Go, and only go to redis when i need the scale.

You could. But thats rarely where the perf hit is. You rarely need more CPU juice than Go provides, and if you do you probably use Rust or C. There is little to gain from dropping down to ASM, as you most likely run on an OS that is more powered than a microkernel, where you would need ultimate low level control.

Sure. I like Rust. But i also know when not to use Rust.

Meh.. sure a DR is not the same as an RC, but i would class it as a subset of the same thing. You you cant have an RC, you cant have DR, but the other way around.

In the end its the same problem, dressed up differently.

Indeed.

Shared Go slices are a bad mix in concurrent code. This is a given. But its also not a fair comparison, you should instead compare java arrays to go arrays, not slices.

This goes for slices, strings and maps. Those a usually wrapped in a mutex, or used with sync primitives like sync.Map.

Neither Java or Go guarantees data-race freedom. A data race does not by itself make ordinary Java or Go code memory-unsafe in the C/C++ sense.

I fail to see how a racy Java program is more memory safe than a racy Go program?

I have not written a line of Java in 15 years. But im pretty sure Java has threads? Once you have threads, you pretty much have data races.

        Thread a = new Thread(() -> x++);
        Thread b = new Thread(() -> x++);

        a.start();
        b.start();