I suppose. And I'm not at all saying there's nothing better today, or that it would be possible to build today's web apps using that stack. Just at that point in time and with those technologies everything was clicking.
> As Feynman said, anything where they have to put science as a suffix is usually not science.
This is such an absurd thought-terminating cliche. Science suffixation seems more an indicator of the age of the field, not its scientific rigour. Are "climate science" and "computer science" not science?
On the flip side, just because it says "ology" at the end of a word does not mean it's a science.
Well, yes, but the courses I've taken for the computer science portion of my degree feel much more like math or engineering than science; experimental/empirical verification of natural facts are hardly present.
I keep hearing this statement, and it always makes me wonder if people have actually used Grok…
I have a Claude Max plan I use for coding, but I also have a Grok Lite plan I use for web search type tasks (similar to Perplexity) because I like how the Grok harness handles searches and I don’t need a SOTA model for that use case. I’d never pay $30/mo for a full SuperGrok account but to me it’s worth the $10/mo for Lite as I was hitting limits on the free tier.
I’ve never noticed it to be particularly biased at least for anything I’ve been searching for on it. And on the other side, I’ve never noticed it to be particularly less censored or anything compared to other models either (also a claim I’ve heard a lot about Grok but I think because it is/was part of their marketing).
I don’t really use Twitter so I’ve never used it via the bot, I’ve only ever used it via the web app.
I bounced back and forth between Grok and Perplexity for web search type tasks and at least for the moment am preferring Grok mostly because it seems to perform more searches and check more results per query vs Perplexity and their $10/mo plan covers my usage vs $20 for Perplexity Pro.
However I’m not married to any LLM service and will switch to another one the moment I get better results from it.
At least in my usage I haven’t noticed any obvious bias, but I don’t really search for politically related stuff so maybe I just haven’t seen it.
Opposed to all other models being the bastion of objectivity? Must be truly vindicating to have to hear other peoles opinions after decades in the silicon valley bubble.
There is a difference between when somebody openly instructs their model to infer disproven lies vs who doesn’t do this. And it’s quite tiring that this is even a question because of politics.
As somebody from Hungary: the biggest impact of my mood was that this kind of thinking went back with the collapse of far right there to where it belongs: to a deep hole which is not in front of normal people. Average people suddenly don’t ask illogical questions or answer stupid things because there is nobody who would tell them that they need to think stupidly, there is nobody who tell them what stupid thing they should think that week. It’s marvelous when you get the proof that the whole “stupid thinking” is completely controlled from above.
In end user perspective, it’s the same. The difference is probably volume. I have no clue in which direction. Both in trained lies by models and in number of people defending the indefensible. But one for sure, there are probably 10s or 100s of millions of Chinese who try to do the same. I encountered with it quite frequently. Sometimes with flat out doublespeak.
As a non-US AI user I do not particularly like using a US model following the recent political events, but I specifically do not want to use a model made by an ex-member of the current administration.
It is always great fun using a model via API without search/web access and quoting a recent development, being told that it must be hamfisted satire, then providing access. The reasoning traces are a delight, Opus 4.6 and GPT-5.4 during the administrations war with Anthropic were prime grade A kobe beef.
This comment is very similar to what russian propaganda does.
It's not aimed at convincing you to support them, but to convince you everyone is lying and there is no meaningful difference between each position, so you stay apathetic.
I'm not the person you asked, but for me, it's the package identifiers. Demo puts URLs to web infrastructure in source files, like Go. In my opinion, this is a huge mistake. There should be a mapping from logical package identifier to web infrastructure, and this mapping should happen outside of the source files. I believe in this very strongly.
Deno supports import maps, which are the mapping outside of the source files.
But yes, URL imports have a variety of other issues (duplicated dependencies, no resource integrity), though Deno solved them in later versions (npm registry support, lock files).
The only benefit of Deno is its permissions system, which has been great for safely letting agents write and run scripts on my file system.
Thanks, this is a good correction. I haven't looked seriously at Deno since way before late 2024. The "URLs as package identifiers" issue is what initially attracted me to Bun over Deno, but it may not be relevant anymore.
The core issue is philosophical. Whether you happen to have public infrastructure which provides a web front-end for your git repository, and what exact server that web front-end happens to be hosted on, ought to be completely incidental to compiling source code. But since you ask, Go is the best example of how this can go terribly wrong in practice, IMO. Here are just a few scattered pain points I've encountered:
* In order to follow convention, you need to decide on git web hosting infrastructure before you start writing code. The tooling asks you for a URL the moment you run 'go mod init'. My preferred way of doing things is to start work on a project just on my computer and then maybe put it on one or more online git web host eventually, if the project goes anywhere. That order doesn't work with ideomatic Go. To work around this, I write mostly non-ideomatic Go where I use the name of the project instead of a URL as a package name.
* I view hosting infrastructure as incidental. I may throw a project on GitHub. I may change my mind and move it to Codeberg. I may move it to my own git forge. I may get tired of hosting my own git forge and move it to sr.ht. With Go, each of these moves requires a huge "touch a bunch of lines in every file" style commit if you're using the ideomatic "git web host as package identifier" style required to work with 'go get'. In other languages, it requires at most a readme change, and for dependencies, it requires at most a git submodule or package manifest change.
* Go requires that you use a Go-compatible git web host. Because Go decided to make URLs look like 'example.com/foo/bar/baz/qux', it has no way to determine which part of that is the git repo and which part is a subdirectory of the repo; should it 'git clone example.com/foo/bar/baz.git' and look at the 'qux' subfolder or should it 'git clone example.com/foo.git' and look for 'bar/baz/qux'? The only solution is for Go to make an HTTP request to 'example.com/foo/bar/baz/qux?go_get=1' and parse the response HTML and look for a Go-specific meta tag which tells Go what part is a git repo. This is an immense "layering violation" and extremely ugly hack in my opinion. This feels so unnecessary too, since this is an easily solvable problem: just make URLs look like 'example.com/foo/bar/baz:qux', so that Go knows to look for 'qux' in 'example.com/foo/bar/baz.git'.
* Private repos are a horrible experience. You need to convince Go to not look them up in Google's package checksum database, you need to convince Go to not get them from Google's caching infrastructure, you need to make a ~/.netrc file with credentials, you need a git host web frontend which understands and supports the way Go + .netrc makes authenticated GET requests. If any of these things are misconfigured, you get a cryptic error message about how terminal prompts are disabled on Google's servers. It's all very brittle and hard to debug, and the guidance has changed drastically over time (editing your global .gitignore to rewrite relevant HTTP sources to use SSH used to be the advice, but that had its own significant problems).
* It has the "feeling" of being decentralized since it's all just git URLs, but in reality, Go's tooling depends heavily on Google's centralized package cache and checksum infrastructure which has been introduced over time to smooth over foundational issues with the design.
I was once part of separating a complex project out of a company and moving it to its own infrastructure on a different domain name and git host. The Rust and C++ repositories were a breeze, just change the URL in a CI job. The node.js repositories required changing some references in the source code from one NPM org name to another but were otherwise painless. The Go repositories were absolute hell.
I have considered writing a blog post about all this.
* The `require` directives from the `go.mod` files of your dependencies are always ignored.
Those two combined, mean that there's no easy way to fork a dependency. It's doable, but some of the maintenance overhead could have been avoided.
We don't even get a `go mod tidy` flag that lets us say, "yes, I understand the risks, just copy any `replace` directives that you find in my dependencies". With a flag like that, even if the `replace` directive is still copied everywhere, at least it's automatically copied during a routine `go mod tidy` invocation.
They already have `// indirect` comments, so those could have a `// indirect, replaced by X` comment or something like that.
Thanks, I am lucky to avoid those issues working with go, but now I’m annoyed that those decisions were made, I have honestly never thought about the trouble that assigning URLs as import locators could cause but yea that would be a pain if we ever had to deal with any of that.
Thanks for your time writing that. A blog post would be great.
> Demo puts URLs to web infrastructure in source files, like Go.
This is optional, but also really, really handy for standalone scripts that don't need to come with a package-lock.json or deno.lock file (if you're not aware, Deno did a lot of changes to package management in later versions).
Semantics drift over time. Whether we like it or not, spectacular and awesome both mean something different today than they did 100 years ago. It's hard to argue that "spectacular" doesn't have a positive connotation today.
"Given a long, slow flyover of Kuwait City and its environs by his Air Force pilots, Baker saw firsthand the awesome destruction allied and Iraqi forces unleashed on the emirate, sweeping past scores of scorched Iraqi tanks and the hundreds of burning oil wells that blackened large portions of the afternoon sky."
reply