Where can one find the stack that is currently planned? I poked around and didn’t see it here or on the wiki.
Details of that are spread around Discord at the moment. We’re planning on using C#/ASP.NET Core with PostgreSQL.
1 Like
Art, in your copious free time, could you assemble some highlights on the wiki? It’d be more efficient for you to do it than for me to try to divine which details are or are not important to pull out from Discord. Thanks.
2 Likes
I see concerns in this thread, but no conclusion. Art’s project has two major benefits: it exists, giving us something to build on; and the author is around to help. It has two downsides: performance and dynamic typing.
Performance: I don’t have a good picture of the architecture of the server. How modular is it? Would it be possible to start with this RoR code, run some small communities, and progressively replace the performance-critical parts by a program written in a compiled language?
Typing: Sorbet (which has some capabilities for static type checking) will be in Ruby 3. How close is that? Does it work on Rails?
1 Like
I think the final conclusion was that we’re not going to build off of it but we will use it for inspiration and basically as a proof of concept during the development process. Correct me if I’m wrong though.
@gilles Ruby 3 itself is a ways off yet, but, Sorbet can apparently be added manually to projects now. It’s akin to TypeScript or Python type hints - it doesn’t make the language statically typed, but it does eliminate the vast majority of potential errors introduced by dynamic typing. Personally, this would eliminate pretty much completely the concerns of using a dynamic language, but others have expressed stronger viewpoints - @Marc.2377 @MasonWheeler @manassehkatz what say you?
As for performance, we’re not talking about a huge difference in performance. Rails can handle scale, certainly at the sort of scale we’re talking about (which is unlikely to be particularly significant for years to come).
Given all this, I’d like to make a proposal: we use qpixel for now, but bring it up to date. We focus our initial development efforts on adding type signatures to the codebase so that we can verify type correctness, and on generally modernising the project (I’m thinking particularly of mobile support and of AJAXifying actions so they don’t all involve a page load). We launch our initial communit(y|ies) using the result. While those communities are getting off the ground, we can be, if we wish to, continuing development into a new platform, which can be written in the stack we’ve chosen.
This would offer us the major advantage of getting software running and communities off the ground much sooner, and it would also mean we have already done the majority of the front-end development when we build our own new software (views and CSS can just be copied over, rather than re-written - it’s just the server side we’d have to do).
Paging @Contributor for feedback. Please weigh this up anew; gilles’ suggestion means we would almost not be writing in a dynamic language.
10 Likes
Sorry, I have some catch up to do here and at What other platforms exist and why won't they do?. Will be able to post a thoughtful answer next Wednesday.
1 Like
I think we can benefit from the already made stack here and build upon it. It’s true that we have carefully decided on C# but we can also benefit the same from ruby which we could from C#. The Dynamically typed code base is not easy to maintain is not a good point and drives people away from using dynamically typed languages. For a whole large codebase like Codidact, it’s hard to maintain it be it any language but we can document everything with comments to keep track of things.
Ruby does scale, dev.to is a site for software developers https://dev.to/about and it was made by software developers, what do you think made them use ruby? Their stack - https://dev.to/ben/the-devto-tech-stack also, did anyone used dev.to? It’s crazy fast.
My point is that there’s nothing bad with ruby or C# but as we already have a clone already built, we can work upon it. We have the benefits C# gave in ruby too.
1 Like
I agree. From a non-technical point of view, something that gets us up and running quicker is a major definitely short-term positive.
If we are to go ahead with this, my question would be: do we have folks who are fluent enough or who can otherwise become fluent quickly enough with Ruby to move forward in the direction @ArtOfCode proposes?
The biggest advantage of doing so short term is that it lets us discover pitfalls, drawbacks and mistakes as we go with little risk of them getting ‘baked in’. This is a very useful thing. We can experiment, test and refine with real world data and make the final C# product better from that; while we can do this as we go with C#, there’s less of an expectation of that sort of radical change.
8 Likes
This is what I wanted, @ArtOfCode. We need to get something out soon, because our time is NOW. Let’s polish up your work and put it out there.
SE communities (statistics, codegolf, etc) wont wait on a promise. They are unhappy, and they want out. They are jumping as we speak, and we need to have something for them to land on, because once they land somewhere else, getting them on Codidact is not an option. One migration will already cost them a fraction of the community, and two migrations is too much to ask. They will scatter away, and the opportunity will be lost.
6 Likes
Adding a vote for moving forward with the existing codebase with an eye toward a future migration to something else, if that proves necessary.
I like C# and don’t know ruby, so this is a vote to impede my own ability to effectively contribute, but I think that time is of the essence here in several ways. We currently have the potential to capture disaffected SE users or entire communities, and also a high degree of interest in lifting this project. Both of those potentials erode with every passed day.
9 Likes
So, folks, time for a vote - there’s been a mixed bag of opinions here, so let’s decide:
Should we use an existing Stack Exchange clone instead of starting from scratch?
- Advantages of Yes: We start earlier.
- Advantages of No: We have more control about tools and technology.
- Yes
- No
0 voters
[Note: there’s also a vote going on in Discord - you need only vote in one of the two polls. You may vote in both if you wish, but your vote will only be counted once.]
4 Likes
I have pinned this during the vote.
Now that there’s a second proposed starting point, are we voting on a starting point or this specific starting point (the Ruby one)?
1 Like
(originally posted as an answer to another post - now edited to make sense on its own and appear non-confrontational)
I admit to this being a tad unclear to me.
On the one hand, the way the poll itself is worded clearly indicates we are voting on whether an existing implementation should be used instead of starting from scratch.
On the other, the post linked to by Art above also directly states:
– which is in contradiction with the poll text.
It’s safe to assume that what matters is the text righ there within the poll itself. (which, in my opinion, should be in a separate topic - I’d like for us to move it.)
Thus, it looks fair enough to me that: If “yes” wins (and among contributors, it’s behind, so far), we’ll at least do another vote for which implementation to use. That much I guarantee.
I believe to have been some oversight in the quoted post - certainly no evidence of malice though - and that would benefit from a clarification in my opinion.
4 Likes
I’m cross posting this here from the other SE clone post for visibility.
With regards to starting from scratch, or using an existing code base, I’d like to share the following thoughts. (This isn’t a criticism of anyone’s code, project or approach, it’s just some observations about trying to start a project from an existing, unproven, start point. Please don't take any offence from this post, I'm just trying to be constructive, in offering this opposing point of view.)
With any large scale project like this, its very important to consider the maintainability of the project from the start. You need to get all of the key decisions in place before you consider writing any code. First and foremost, you should establish coding standards for each technology that will be used within the project. You should also establish best practices that should be followed. This very important in a highly controlled business environment where everyone is in the same office, it’s even more vital for a decentralised team of volunteers.
I feel uneasy about using an existing codebase, because it’s effectively bypassing these initial steps, and forcing decisions upon us that weren’t necessarily in the best interests of this project. True, we’re talking about another Q&A clone, how different can it be from our Q&A clone? But how similar were the objectives of the clone, to the objectives of our product? Was it also intended to be a large scale replacement for Stack Overflow and other network sites? Was it just a proof of concept, or something that the developer could learn from? Was it designed in a way where the front end can be split off for an independent team to work from? These are just some of the questions that we not only need an answer to, but we need the correct answer to.
The compatibility of an existing codebase to our objectives, requirements, and yet to be agreed, coding standards and best practices, is unlikely. I understand the desire of people to “just get something out there”, but if we don’t get the organisational groundwork in place correctly, the project will likely encounter problems that it cannot overcome, and ultimately fail. I think it’s fair to say that we all want this to be a success.
4 Likes
How many votes were there before this had been made clear? There might be a bunch of people who now voted for something they didn’t want. Also there’s a bunch of options in between. What if I favour a solution of using QPixel for now and in the mean time build something from scratch?
What I actually want to vote for right now is redo the vote properly. By which I mean identifying the decisions first, and then putting those to a clearly described vote. Decisions I can see right now:
- Are we going to use an in-between solution?
1.1 If yes, which? - Are we going to build the real project on something else?
2.1 If yes, which? - Will we do a literal code fork - or are we just using something as a guiding example while building from scratch? (Or possibly something in between, like using an architecture, but redoing the functionality?)
And guess what, now I’m in full-on project mode; we can’t even make informed decisions about this yet. Right now, I can say QPixel already does everything we need - and nobody can point me to a document where it says otherwise.
We first need a spec.
Not a fully written out, corporate level description of every detail - but we do need to manifest the general idea. Right now, I can promise you there are no 2 devs on this project who have exactly the same idea.
Let’s start out with just a dumb list of possible actions if necessary, but let’s not run forward if we don’t know where we’re heading.
6 Likes