kasajian

On the bright side, I now know about your product. Had never heard of it prior to this.

Nah, you're just twisting things around. We are criticizing and calling out the rationale he's giving. Not even interested if he hears it. It's message to the public of the maintainers behavior. Not to him. He's got a right to do what he wants.

The critique is not about the demands for his time as a maintainer, which is what he is addressing, that no one here is complaining about. In fact, post folks have made it clear that they have no issue with it.

That b.s. It has to do with the fact that the project is not making it clear that it's not interested in PRs.

Don't have Issues. Don't have PRs. Just push your code to github. Add to the README that this is a mirror of the actual development branch that follows an internal process. The Github repo is only used as a way to publish the latest snapshot of the source.

The "going closed source" because of harassment is just an knee-jerk punitive reactionary response. It's akin to taking your ball and going home.

He has a right to do anything he wants with hit source, but Open Source is nothing more than a license. We had GPL 2 before there was github. All you had to do is either deliver the source with your software, or make the source available upon request, even if it's by snail-mail.

My only exception to this article is the section, "People underestimate what open source costs from the maintainer side. It’s not just writing code. It’s issues, pull requests, discussions, people demanding things from you for free. I got spammed like crazy. And now with AI, spamming a maintainer is so easy: low effort issues, generated pull requests, and every single one of them takes a bit of your time and energy"

This is all self-inflicted. Don't take Issues. Don't take PRs. Make the repo read-only to everyone but you. There's zero effort, unless you're planning on keeping all the source on your computer and never push it anywhere. Well, I guess, in that case you're saving yourself from doing a push.

So if you don't want to do all that stuff, that's fine. You don't have to. But don't pretend the only alternative is to close the source.

Someone explain to me why this product is unique. If Mozilla never came out with it, does that mean businesses are stuck with using cloud-based AI? C'mon. There's a lot of products that already offer local-AI. What am I missing?

Content should be in a github org.

I'll check back every few years to see if either this project, Wine or ReactOS can run Visual Studio 2026 (or 2022) and .NET Framework 4.

Not talking about the cross-platform versions of .NET and VS-Code. I'm specifically talking about the Windows-specific software I mentioned above.

I don't see this happening, despite the fact that by now, these types of porting efforts were supposed to be trivial because of AI. Yeah, I'll wait.

Yes, but you are not giving people anyway to close their account, nor make it obvious to unsubscribe. That's not very good.

Yep, also Microsoft Dev Box: https://azure.microsoft.com/en-us/products/dev-box

The article wasn't proof-read. Too many basic English errors are too distracting and makes it hard to read.

I don't agree. I don't think of Oracle at all when I think of JavaScript. And I also don't care whether they own the trademark.

There's no hypocrisy.

I don't get why this is so important. I don't love Oracle. I do love JavaScript. I couldn't care less who owns the trademark, and not sure what if anything would make me care.

Are you experiencing any perf issues when using "Blazor Server"?

The Popular Mechanics article talks about it as if it was just "discovered" Both the original blog post and the video linked from the article are 5+ years old. Not exactly news.

Since you mentioned SBCL, I thought this announcement about ECL and WebAssembly would be worth mentioning for those who are curious. It was announced just last month: https://ecl.common-lisp.dev/posts/Web-ECL-Grant-Announcement... (2025-07-29)

Funny. I was just thinking about dismissing Clojure for a project I'm going to work on because I was concerned about it's lack of ability to work with async calls. I'm too used to how async in JavaScript and C#, and I'm not sure I'd want to work in an environment that doesn't have a simple way to structure async calls. It doesn't necessarily have to be async / await. Just some attention to the issue rather than completely ignoring it.

The product with fewer features being recommended makes sense if they do those things well. The customer buying it is aware of the limitation, whereas the customer buying your unit getting a broken display is a disappointment. Maybe it was an unfair review, but this comparison is lame.

Do View Source -- just take a look lol

I think you're assuming people who are thinking of going beyond the original "point" of edit missed that point. We didn't. We're looking new directions it can go.

why would the binary size be big to support this? Scintilla has been doing syntax color for decades -- it's pretty small.

I'm just waiting for this thing to turn into an IDE like Turbo C 2.0 ( https://imgur.com/5vyPZdO ) I don't see why this shouldn't turn into a sophisticated code editor. I get that that's not the goal, but there's nothing else like it available -- all other text based editors do their own thing, completely ignoring the common-user interface as if it's a thing they've never heard of ( https://en.wikipedia.org/wiki/IBM_Common_User_Access )

Not sure what the question is. The License is clearly stated.

Not your fault, but I'm curious how is it that in the last 10 years, you haven't heard of .NET running on Linux? And for the last three years, the resulting binaries can be pure native code not requiring a runtime.

I don't know if this is the case now, but about a decade ago, in order to report a Bug to Microsoft you had to create a Premier Support ticket, which cost $1000+, but free if it's a Bug. So basically, if what you report is not a Bug, determined by them, it's treated like a Tech Support ticket and no longer free. I recall discussing this with a representative and let them know that I'm basically doing them a favor by reporting the bug -- why would I want to take the chance to possibly have to pay for it if they happen to determine "it's not a bug -- it's a feature". I got the standard corporate-speak answer which I just waved off as ridiculous: "Look, we will absolutely not charge you if it's determined to be a bug"... :|

I've since have seen Microsoft use User Voice and the products (at least Visual Studio) has a great way to give feedback to the team, something I've used multiple times, including for feature requests. And of course, for their Open Source products, they have Github Issues, which is awesome.

I wish there was a way to transpile this to C. That way it can be both an escape hatch, and a way to target unusual platforms not directly supported by C3 lang.

This seems a big silly. This is not a language issue. You can have a C++ library that does exactly all the things being shown here so that the application developer doesn't worry about. There would no C++ language features missing that would accomplish what you're able to do on the Rust side.

So is this really a language comparison, or what libraries are available for each language platform? If the latter, that's fine. But let's be clear about what the issue is. It's not the language, it's what libraries are included out of the box.

Even the first of Visual C++ was a professional C/C++ compiler. That's been the same Microsoft compiler they've been selling for years for $500. The previous version was just called Microsoft C/C++ 7.0.

It wasn't in any way a "toy". What I think you're talking about is that Microsoft was pushing the "Visual" aspect of the IDE that it was trying to copy from Visual Basic, but with MFC, and was doing a sucky job at it. You didn't have to use it. Most of us didn't.

Clojure could never really be a thing since it ignores the most important rule: fast startup. Because of this, and for no other reason, Clojure will always be an "also ran". It's not about competency of the people working on it. It's a solvable problem the community doesn't acknowledge exists, unless you press them on it, in which case they think "graal" and "babashka" is a valid response, and you're back to square 1.

"I shouldn't have to read code to understand comments"

That's fair, but that's not universally agreed. Some say comment the "why" not the "what" because you can always read the code to understand the what. Also, code will likely be more correct than the comments if code is modified, and the comment isn't. And finally an entirely different school of thought is that you don't need comments if you name your functions right, breaking every few lines, the thing you would have otherwise commented on, into its own function with a good name.

I think all of these are good suggestions to some degree. I'm somewhere in between, leaning toward more comments to help the AI

One minute into it, the article says, "The dmac and smac are pretty self-explanatory fields"

This immediately turns off anyone reading it who doesn't know what those things mean. The thought process will be, "Oh, this article is for those for whom these fields are self-explanatory. Since it's not for me, I'll stop reading"