HackerTrans
トップ新着トレンドコメント過去質問紹介求人

throwaway38405

no profile record

投稿

Ask HN: Experience using dynamic languages for big projects

3 ポイント·投稿者 throwaway38405·2 年前·3 コメント

コメント

throwaway38405
·2 年前·議論
Thank you very much for your feedback and insights!

Two follow up questions:

You mention that functions/types are just values and can be created at runtime. IMHO you get the same with Java (8+) and everything running atop the JVM, Golang and some other programming languages. Why is this such a big differentiator for you?

The other thing I find interesting, that you didn't mention tooling at all. For me, navigation in bigger code bases is a killer feature ('one reads code more of ten than write it'). Code navigation/auto complete is IMHO much inferior in dynamic languages, even for small projects and with state of the art IDEs (IDEA...). (And not even mentioning deploying the software to servers/clients.) Did you find issues with the tooling in these projects, don't you care and just use VIM/Emacs or wasn't it just bothering you enough to mention?
throwaway38405
·2 年前·議論
Here we go again.

I am happy Plasma is focusing on stability, but I literally do not understand why it hasn't been a focus since the KDE 3 days.

Plasma 4 and Plasma 5 would have crashes within minutes of running with the default settings for me, using a non English language setting but running on stable/well supported distributions (Debian, Fedora, SUSE, Kubuntu). KMail is another story of neglect: Again stability problems and possibilty of data loss, not even thinking of the lacking QOL features like automatic setup of Google and/or Microsoft accounts.

Plasma 6 was the first one in many years which didn't immediatly crash, so some progress there.

This is one of the big reasons I would not even consider using KDE after 3 on my desktops.

I loved KDE 3 and I would love to return to Plasma/KDE, so I hope they succeed with improving the stability and get their KMail story sorted out.
throwaway38405
·2 年前·議論
IMHO the article misses at least one important thing: Microservice architecture.

I see Node.js/JavaScript in the backend most often used in microservice architectures where the applications are mostly trivial and the Node.js developers are at most in the middle of the experience spectrum.

Thing is, for every single microservice it is easier to just implement it with some libraries than to learn a proper framework, and the hype cicles in Node.js are so short, that developers never experience real proficiency with a library.

In combination, after having used Node.js in the backend, I will never touch it again for backend work, unless a lot of things change in the community and tooling. I am much happier and sane using Spring or Django.
throwaway38405
·2 年前·議論
... sorry, this sounds to good to be true.

Usually it works like this (forced to use macOS at work and Windows from time to time for special software): One installs some software from trusted websites (VSCode, VLC, Firefox, etc.) on macOS/Windows, and then when one just wants to get some work done: Update-PopUps, yay. They annoy the hell out of me, especially because there is no unified system for macOS/Windows. Break my flow, wait for download, privilege escalation, installation and starting again. Thank you very much. This happens multiple times a week especially for packages like VSCode, VLC, Office, Outlook, Firefox, KeepassX, Calibre... packages which you don't want to be outdated, ever. It is f*cking ridiculous that I have to take care of this BS in 2024.

On my Linux boxes I login and work. Updates have been silently downloaded and installed for the packages and/or flatpaks and everything is up to date, no annoying update-popups which break my flow and I know that I have the latest version of all software especially security sensitive packages.

At the end, you can pick your poison.

Having integrated/working package management with silent updates is one of my killer features of Linux/Flatpak. I want to set it up one time (automatically) and never have to think about or deal with it again.
throwaway38405
·2 年前·議論
Adding to this: I am very often surprised how little most developers of other stacks know and understand about the Java tooling: The IDEs, Frameworks, build tools and the JVM itself are by now so much ahead compared to everything else on the market (PHP, Node.js, Python, Golang, Ruby)... Add to this the stability of the Java platform, it is most of the time a no brainer to use it.
throwaway38405
·2 年前·議論
The Linux community is self-selected and highly opinionated on everything.

Concerning AppImages: I have no interest at all in them and although Flatpak still has its share of problems, basically all important communities adopted it (but Ubuntu).

Flatpak integrates in your system, has sandboxes, has automatic updates, shares dependencies etc.

Is Flatpak perfect or running w/o problems? Certainly not.

But IMHO AppImages add nothing over Flatpak, but lack the unified infrastructure and integration into packet managers etc.

We all would benefit from agreeing on one standard, and by now it looks like Flatpak is that one standard. So, I don't want to download random AppImages from the internet, I want a certified Flatpak which integrates with my system.

(Being a member of the Linux community for longer than most people using Linux are alive by now, of course and invetible, once Flatpak is working and established, it will be replaced by some broken other solution. :-P)