Hacker Newsnew | past | comments | ask | show | jobs | submitlogin
Ask HN: What are the least frustrating languages/technologies to work with?
10 points by owenpalmer on July 30, 2022 | hide | past | favorite | 17 comments
As a developer, I value my quality of life. I like to be as productive as possible, with as little frustration as possible.

I don't find challenging problems frustrating. I find unnecessary problems frustrating.

What industries, tools, and languages are the least frustrating to work in?

Do you believe "modern" programming is more mentally ergonomic? Web development, dynamically typed languages, IDEs, co-pilot, etc. Or do you take a more traditional and minimalistic approach?

I understand there will always be an element of frustration and difficulty in any given field, but I don't think the life of a developer has to be as low quality as it is currently.



I think this is highly personal, and for me it's Go. I just always have fun when I write it. I have fun with other languages as well, but if I had to pick one that "brings me joy" the most, it'd be this one.

I love the simplicity of it. Some think this results in overly verbose implementations or error checking, but I don't mind that. I feel like it fits in really well with my way of thinking when I write code. It makes me think about what I'm trying to do before I do it in a way that not all other languages do _quite_ as smoothly and intuitively. It just jives naturally with my way of thinking when I write it.

I also love the test tooling it comes with - it's one of my favorite parts. Not writing tests in Go just seems like a genuine waste. They are a pleasure to write and run. In some languages, writing tests seems like a chore you have to do because you know it's good practice. In Go, I feel like writing the tests as I write the implementation actually helps me produce better code from the beginning. I know that this is not exclusive to Go. I do write tests as I implement in other languages as well and find them useful, but something about the Go way just clicks with me really nicely.


It is going to be what you are used to. The more popular the language or technology the more help and docs and courses will be available.

You have to decide your preference on things like type system (runtime or compile time checking?).

Also what are you developing? Web CRUD will be less frustrating in Ruby than C++ for example.

I will bashfully admit I sort of prefer Typescript/Node to C# and Java. It think because JS/TS is a simpler language (Go might be a similar experience).

I have tried Haskell etc. and while fun to do the hard stuff there, I enjoy producing more than understanding complex type systems (libraries mean you can’t avoid the hard part). So I prefer imperative languages with functional features where needed.

All that said, pick one of Python, JS, Ruby, Go, C#, Java for high level stuff anyway and it is much of a muchness they each have their own bugbears and you wont know until uiu get deep into them which ones you will hate the most.

If I had to give a general answer … maybe Java as that gets you on JVM and then you can choose a different language and reuse the Java library skills there. Plus lots of jobs!

If you want to avoid frustrating problems entirely don’t be a programmer. Maybe do programming language research? Or something very low level embedded where you are writing the machine code so there isn’t heaps of cruft between you and what is going on. Real world commercial programming is 90% solving problems that 1000000 other people have solved slight variations on, swearing at the compiler and so on… it is in it’s nature ridiculous! (Like any other job …).


Erlang/Elixir and Kubernetes are, IMHO, the best platform to write distributed applications:

- who needs microservices when you have the OTP framework and gen_servers? - "let it crash" philosophy: supervisors will restart your processes automatically - design fault tolerant systems at the application level with supervisors and OTP applications - design fault tolerant systems at the infrastructure level with Kubernetes - bring the two together with Horde and libcluster - store in-memory distributed state with Mnesia (who needs Redis?) - Phoenix and Ecto for the web stuff


MS Access and its wizards make it easy to automate a database. Visual Basic 6.0 also had wizards. It was as easy as painting the forms to be used.


Just pray you dont have to do anything outside vanilla functionality. VBA is a disgusting language.


I have had my share of nightmares when maintaining pearl database built on some old and weird libraries... I would rather not do this again :)


My preferences are similar. For me, Go, neovim, zsh, PostgreSQL, vanilla JavaScript


What makes you prefer Javascript over Typescript? For me TS removes some of the frustrations of JS.


I find JavaScript not to be frustrating, and while typescript is fantastic I prefer a simpler tool tray chain. I am working on smaller projects of only 100,000 lines of code or so


This exists also the other way round: For me JS removes some of the frustrations of TS (and Java, C#, etc.)


Very well put. I should’ve mentioned it myself.


You need a transpiler for TS. That’s frustrating.


Since you can't, by definition, do anything in Typescript that you can't do in JavaScript what are the frustrations?


That's a weird way of thinking. Just because you can do the same things in two languages, doesn't mean they're as nice to work with. Everything you do in any compiled language, you can do in assembly. But I don't think many people would argue that building everything in assembly is the least frustrating way of writing code.

In the case of js and ts: they can do the same, but ts is less frustrating because the added types catches bugs when writing code, it gives useful info about what a variable is meant to do, and my IDE gives way more useful hints.


true


Ruby, typescript.


Ruby on rails




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: