NumberSearch VS winforms

I used this stack to replace a Django/Python app that was built over 2 years by another dev in 2 weeks. We regularly have 1 hour turn arounds between when an issue/feature is filed on Github and when a new build is live with that code. The self-contained deployments have made it simple to deploy this app, and now its supporting apps, to our linux-based cloud instances.

As proof: https://github.com/AccelerateNetworks/NumberSearch

I've built on many stacks and although I agree that iteration speed is important; It has more to do with how you organize your project and the quality of your tooling than with the specific language/framework.

If you don't like the OOPy style, don't write in it. Pattern matching in C# is quite nice, and you can always mark you functions as static. As a bonus, simple functions are easier to test to.

Windows Forms[0] is still alive and will never die, and very low overhead to start with, and works on new and shiny .NET 8.

If Linux or macOS, you can use AvaloniaUI[1] instead which is sufficiently advanced but assumes some prior knowledge.

[0] https://github.com/dotnet/winforms/blob/main/docs/getting-st...

[1] https://docs.avaloniaui.net/docs/get-started/

Winforms: Licencia MIT.

3. Therefore reified generics are not possible to implement in a backwards compatible way.

Ok, sure, but if you instead a new generic collection types and leave the old ones alone, you don’t have to worry about breaking existing compiled code.

This comment about C# suggests a lack of familiarity with the approach C# took:

> C# made the opposite choice — to update their VM, and invalidate their existing libraries and all the user code that dependend on it.

All of the pre-generic C# libraries continue to exist to this day (ArrayList, HashTable, and the non-generic IEnumerable). Applications that used them never stopped working. New code uses the generic collections (List and Dictionary).

Anyways, I think the costs that Java is currently paying for non-reified generics (reflection, performance, and type safety mentioned in the article) is not worth the backwards comparability with the 20 year old J2SE 1.4. The price C# pays for making a backwards incompatible generics (mostly some minor annoyance when designing a collection class implementing IEnumerable) is worth it at this point.

P.S. ok, I do admit that C# forking the collection library is still causing ongoing maintenance work 18 years later: https://github.com/dotnet/winforms/pull/8673

No, it is fully supported and in active development. https://github.com/dotnet/winforms

No, it's still under active development/maintenance. https://github.com/dotnet/winforms/graphs/contributors

The image is kept in-memory— https://github.com/dotnet/winforms/blob/main/src/System.Windows.Forms/src/System/Windows/Forms/PictureBox.cs

Appears that this has been broken for a while. Seems it has something to do with the new designers being run out of process.

Also, the runtime that C# runs on, is also completely open source as well (https://github.com/dotnet/runtime); ASP.NET which is used to create web apps in C# is open as well (https://github.com/dotnet/aspnetcore). WinForms/WPF, used to make desktop apps in C# is also open source (https://github.com/dotnet/wpf, https://github.com/dotnet/winforms). All of the source code for these are on the dotnet Github page: https://github.com/dotnet and most are all MIT-licensed.

You'll likely have to open an issue against https://github.com/dotnet/winforms. If you've already opened an issue here, then feel free to link and I might be able to provide suggestions on how to improve the triage process.