2 ms·

> It's incredibly fast and productive and has allowed me to create more as a single-person than entire teams using other languages. Another startup founder and

by zvrba 6y ago

> It's incredibly fast and productive and has allowed me to create more as a single-person than entire teams using other languages. Another startup founder and CTO here. Can confirm this. Once you get to know the framework, it's really hard to describe how productive you can become. Static type checking, fast compile times, LINQ!, ... It's a 10x ecosystem in the hands of competent developers. So, our back-end and business logic is in .netcore/C#. Our front-end is a desktop app written in Java 11/JavaFX. The two communicate with a thin IPC layer (stdio pipes). With "new" java (11 and onwards) I'm almost as productive as with C#. If C#/.net is 10x, I'd rate Java as 8x.

ablekh 6y ago
Thank you very much for sharing your thoughts and experiences. Please see my reply to the parent comment (by @manigandham) about one of .NET-side reasons for my contemplation. I'm curious about your opinion on this aspect.
- zvrba 6y ago
  In that comment you're comparing a statically-typed language (C#) with a dynamically-typed one (Python) and your main concern is that C# libraries feel "overengineered". This totally makes no sense to me because the whole development methodology will be different between the two. I.e., it makes no sense to me because your concern is the most shallow one. And yes, using a statically typed language with strict typechecking (i.e., no implicit integral conversions like in C and C++) leads to programs that feel "engineered" (I wouldn't say overengineered) but which are easy to confidently refactor and build upon. IOW, flexible/productinve language + static typing + good IDE (VS) = easy to develop "obviously correct" code that works when it compiles and which obviates the need for a huge battery of tests. IME.
  - ablekh 6y ago
    Thank you for sharing your thoughts. I certainly agree with you on benefits of using statically-typed languages (and this is one of the reasons for my potential selection of C# versus Python - though, mypy and pydantic packages seem to alleviate some/many/most(?) of Python's type-checking issues). However, that was not my point or concern. My reference to most C# code that I have seen felt as "overengineered" has nothing to do with language type systems and type checking (if anything, it leads to verbosity, but not overengineering). I thought that I clearly mentioned what specific aspects of the code produced that feeling for me: a "proper" implementation of design patterns, DDD and enterprise-focused features.

by zvrba 6y ago

ablekh 6y ago

Thank you very much for sharing your thoughts and experiences. Please see my reply to the parent comment (by @manigandham) about one of .NET-side reasons for my contemplation. I'm curious about your opinion on this aspect.

zvrba 6y ago
In that comment you're comparing a statically-typed language (C#) with a dynamically-typed one (Python) and your main concern is that C# libraries feel "overengineered". This totally makes no sense to me because the whole development methodology will be different between the two. I.e., it makes no sense to me because your concern is the most shallow one. And yes, using a statically typed language with strict typechecking (i.e., no implicit integral conversions like in C and C++) leads to programs that feel "engineered" (I wouldn't say overengineered) but which are easy to confidently refactor and build upon. IOW, flexible/productinve language + static typing + good IDE (VS) = easy to develop "obviously correct" code that works when it compiles and which obviates the need for a huge battery of tests. IME.
- ablekh 6y ago
  Thank you for sharing your thoughts. I certainly agree with you on benefits of using statically-typed languages (and this is one of the reasons for my potential selection of C# versus Python - though, mypy and pydantic packages seem to alleviate some/many/most(?) of Python's type-checking issues). However, that was not my point or concern. My reference to most C# code that I have seen felt as "overengineered" has nothing to do with language type systems and type checking (if anything, it leads to verbosity, but not overengineering). I thought that I clearly mentioned what specific aspects of the code produced that feeling for me: a "proper" implementation of design patterns, DDD and enterprise-focused features.