Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

1. Python. I was amazed at how awkward it was to scale a Python program and coming from C type strictness, how much time I would spend running a program again and again to get over silly typos and stuff. I absolutely refuse to use Python for anything beyond one page long program. It's still awesome for transforming data, but nothing beyond. It really felt to me like "the king is naked" because everyone around me was/is heavily using Python and I just couldn't stand it (and I've been using Python here and there for over 15 years now). I felt like I was doing something wrong - no, guys, you were doing something wrong. Not even talking about the pathetic performance and the abysmal concurrency; just the quality of tooling and static checks. (much of the critcism obviously applies to other dynamic, scripted languages like JS, but at least everyone admits JS is shit up front, not so with heavy Python users).

2. C# and its tooling. I consider it the apex language. If there's a useful feature or convention somewhere else, Microsoft will make sure it makes its way into the C# standard in the next version. Super elegant, readable, straightforward and powerful. Superb tooling all around, from the blink fast compilation to catching most issues with static analysis before you even get to build. Linq and fantastic abstractions. Now that .NET Core is open source, there's very little reason left not to use it as the go-to language for backend programming. It got me excited about programming again, because my ideas would translate nearly instantly into high quality, high performance code that I could almost always rely on to run right the first time.

3. The Linux kernel. I've been doing kernel development in many opportunities for the last two decades and it's always a great example of an elegant, no bullshit codebase. It's a window into the working of many great minds. Early on, it got me educated on proper error handling in low level code (goto stacks).

4. Actors for concurrency. I started using the actor pattern in a commercial embedded RTOS I designed, and it was the answer for all my concurrency needs lots of time later. If you're extensively calling lock/unlock in your user code, you're doing it wrong and it won't scale.

5. Functional programming principles, most notably immutability and avoiding stateful objects. It makes complicated logic so much more scalable and avoids ripple effects when doing modifications to the program flow.



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: