Another imageboard software enters the fray https://gitgud.io/rb/FinalSolution written in python.
Julay's admin Robi just posted this. What do you think, how far will it go and will it take off? He has good coding knowledge based on his efforts at Julay.
why are feds so cringe
I don't think something made in python is a final solution to anything.
This will turn out just like futatsu did, calling it.
>like futatsu did
I'm sure it will be better than anything written by Stephen Lynx for sure. My money's on Tom's deal tbh in fact of course.
Ah, I see. I don't think you know Robi very well then tbh. He's a busy fucker tbh.
Well why not just use/update Uchan or Picoboard?
what's wrong with lynxchan?
Stephen Lynx. Other than that, there are at least a few technical problems like pronounced vulnerability to triggering MongoDB topology destruction crashes.
Could we please make this the Imageboard engine thread? JSchan is lacking but Lynxchan is cursed. Would like to see others to step up the plate and show that they can replace Lainchan's PHP engine (yuck)
So what would be a good list of things an IB engine should have, and (maybe even as important) things an IB engine shouldn't have anon?
For example I don't think PHP is a good language to build any larger system on, but obviously there are lots of web software devs who feel otherwise. That's not an IB 'feature' ofc, but more of an underlying architectural choice.
Even though I enjoy C++, and PHP is sort of a 'C-with-classes' approach to the web, I don't find PHP to be a very maintainable language for programming in. But I find well-written C++ to be much more so.
I don't know of any IB engines written in modern C++ however (or even the shitty 'C-with-classes' approach so many non-C++ devs write for that matter). But one thing I'm definitely convinced of; A well-written IB engine using good C++ in the backend would be both very fast, and very scalable.
over-optimization is a bad idea, it should have a scripting language core front and center for ease of adding in new features to be on par in a short amount of time.
Pretty sure these are a dime-a-dozen already no? Doesn't seem to have helped out much yet IMO. I'm hopeful Tom will turn that around tbh.
Obviously my view is that a core backend engine is written in a powerful language like C++, while the front-end remains (a variety of) scripting interfaces.
>meguca written in go
True, but it started in nodejs (doushio is a fork still in nodejs), then they realised it works better if they have it multi-threaded with shared memory, etc. Stateful application, wouldn't really scale or work well in nodejs or across multiple servers. Thats probably why its in go.
C++ has fewer libraries for web work, less community, less devs, compile times, etc. But the performance is very good obviously. Unfortunately, many developers will just get a bigger budget and its easier to scale than improve the codebase or use a more efficient language.
If you like c/c++ for everything, you would probably have an orgasm over https://dietchan.org/c/
>Proudly made without PHP, Java, Perl, MySQL, Postgres, MongoDB and Node.js.
No, actually I pretty much loathe dealing with the average C code out there I did it for years and really only think of C++ as the deep core engine of an Imageboard system I imagine. The front-end would literally support all the languages and databases you mentioned. I'll also add that the frontend should ride smoothly on top of either Apache or Nginx ofc.
Those are fair points in general, but the C++ community has interests in a vast array of areas--obviously including the Internet--and there are roughly 5 million men earning a living daily programming in the language professionally. I wouldn't exactly call that a small community tbh.
No doubt its much easier for a PHB to decide the cost of dev time is more important that process run times from his narrow view. Try telling that to the likes of Jewgle or Amazon however. Much of their datacenter code is strictly C++ today. Turns out the limited supply of, and cost of the electricity itself is the chief limiting factor in their business models. They decide on languages based on how much wattage per instruction is needed at scale, and so naturally not only choose C++, but are heavily involved in driving it into new directions via their participation in the ISO C++ Standards Committee.
I realize we're not trying to reach that kind of scale just yet but it's still a worthy effort in my estimation.
Thanks for the input anon.
Consider that Golang is just Typescript for Python IDK.
So a two pronged C++ API backend and JS frontend?
The one thing to gaining imageboard traffic:features are king...
therefore if C++ slows your ability to implement all the features in Lainchan you should reconsider your choice of programming language.
The speed from lab to market is the key.
OK I went and had a once-over but I don't see a lot different about the place tbh. Am I missing something anon? Just curious what makes it different than other IBs.
Check their code base, they seem to have a lot of secret sauce in them that makes them unique from the rest.
Alright will do, thanks.