Hacker News Reader

Comment by hsn915 | Hacker News Reader

I started using dynamic languages since around 2008 (Python and Javascript). Before that I was more into C/C++.

Granted, I've only written C in University settings where I'm writing small programs. I had no idea how to write "real" programs. But with Python and Javascript it felt like I could more easily write "real" programs.

What I found out is that I quickly burned out. Around 2011 I felt like I don't know how to start making programs. Programming basically became dreadful. I taught myself to wade through it anyway, convinced I would find the joy again when I get more proficient.

What eventually made me redisocver the joy of Programming is switching to procedural programming and static typing.

First it was with Typescript. Now with Go.

Writing programs with just structs and functions is really enjoyable.

Programming in dynamically typed languages is dreadful. There's no joy in it.

View on HN

This is my experience as well. Working with dynamic languages soured my experience with programming so far that I stopped doing projects of my own when I was in jobs requiring them. Sounds like hyperbole, but it's something I didn't realise until several years later, after having recovered the joy of programming (which happened because I moved jobs and started using a static language again).

I guess that in part it's a matter of mentality or personal style (I know that I think mostly in terms of guarantees, invariants and so on, which is why types are so useful to me; I feel like other people think more in terms of operations when they program, and maybe dynamic programming suits them more). But there are some huge advantages as well. The tooling is far better (like the incremental compilation in Eclipse, also available in IntelliJ but turned off by default IIRC, which highlights compilation error while you are still writing the code); there are fewer unit tests required because there are fewer things that can go wrong, since a lot of them can be enforced by the type system; most important of all, reading someone else's code is far easier because mandatory documentation, in the form of type names, is all over the place (yep, not a fan of type inference either). And there are more and more advantages.

I just don't see myself working on even a moderately sized code base in a dynamic language. The pain is too real; I have been there.

Have you wrangled with JSON using Go? Absolutely dreadful.

Have you written multiple microservices in Go? The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code. The learning-curve to understand how each service's code is organized gets old fast. With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic.

When writing one-off scripts, I can see the advantages of dealing with just structs and functions.

>Have you wrangled with JSON using Go? Absolutely dreadful.

What's dreadful about it? I use it all the time and find it easy to use. I love static typing though and prefer my JSON to have a proper schema (to automatically generate transport layers in both Go and JS from the same source)

>The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code.

Our organization has a microservice generator tool which creates a new microservice for you so that you could start writing business logic immediately and didn't have to think about how to organize your code. It doesn't really do much - it defines a source generator for the transport layer (from protobuf descriptions so you don't have to deal with JSON), creates a bunch of folders ("put domain logic here" etc.), and adds some infrastructure code to connect to DB, RabbitMQ etc. while also adding imports to our org-wide common utils Go library. It took like a few days to create this tool, but the author already had a lot of experience writing microservices so he knew how to structure code and what dependencies to use.

> Have you wrangled with JSON using Go? Absolutely dreadful.

That was my first semi-serious project. It was around 2012. Yes it was dreadful. The problem is I was still programming with mentality of someone who wants to use dynamic typing.

I would read JSON from an http endpoint, and then just make assumptions as to what keys are availabe, and just read them off like this:

    data['key1']['key2']

Just like with dynamic typing, when the keys don't exist for whatever reason, your program crashes.

I don't do that anymore. When programin in Go, JSON is just a serialization format for a struct. You have a concrete struct type and you just use json to fill it with data. It's so easy and trivial.

> Have you written multiple microservices in Go?

God no! Why would I do that? I hate microservices. I like Go because I can make a self contained application.

> The lack of an opinionated framework often means that each microservice contains code that is organized in its own unique ad-hoc way with lots of repeated boiler-plate code.

So you're talking about working within an organization with multiple insulated teams, each writing services that are supposed to communicate with each other, but the teams themselves don't follow any standard.

Well, that's just one of the awful things about microservices. I don't think the language matters.

> With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic.

Having to debug a RoR codebase was the worst experience in my programming life. It's all magic. Trying to read the code helps you with nothing. You can't read the code to understand the program. You have to read the RoR documentation to understand all the magic. Worse, you can't just read a part of it: you have to read all of it. Because nothing in the code will give you any hint as to _which_ magical aspects of RoR this codebase is using. So unless you know all the magic that RoR does, you have no idea what's going on.

> When writing one-off scripts, I can see the advantages of dealing with just structs and functions.

It's the exact opposite. When writing one off scripts, I can see why someone would not want to bother with structs. You usually are dealing with strings any way (filenames, paths, keys in a json/yaml file, etc).

> I don't do that anymore. When programin in Go, JSON is just a serialization format for a struct. You have a concrete struct type and you just use json to fill it with data. It's so easy and trivial.

This does mean that you should know and define your schema in advance, which is not always doable. An alternative is to use a sum type and pattern to safely deconstruct `interface{}` but Go has a notably poor support for sum types. Static typing is not really a culprit here, but Go would make a bad example for anonymous JSON parsing.

I'm the different guy but here is my opnion:

>Have you wrangled with JSON using Go? Absolutely dreadful.

No it is not. You just take a json object, put it down as Go struct. Yes, it takes more time unlike in JS or Ruby but it makes this code much more readable. You can open a project and see what kind of json it expects as an input. All contracts are there. Not need for any kind of schemas or yml definitions (though you can generate one if you need to).

>Have you written multiple microservices in Go?

We currectlly have more than a hundred of those. The lack of an opinionated framework is a bad thing only from the management point of view. Once you and your team is done with this - there is really no difference from using a framework.

Again - yes, it requires more time and most likely not a great option for a small company without a developed background (ie no preferred ways for doing different kind of things) but no a problem for a relatively big company. We have a number of teams solving different problems and thus using different ways of building their services (micro or not).

>With Ruby and with RoR I never have to waste time with this and I can get straight to the business logic.

Yes, until you face a problem were your favourite gem is not enough to do the job and you have to go the hacky root.

PS: But honestly this whole topic is getting old. I've build apps in both Ruby (mostly not Rails though, we've had Roda) and Go and while RoR\Ruby\etc are great for one set of tasks I'd never use them for some other tasks. For example systems integrations which is my main job for the last ~5 years.

People often forget the web dev is not just your clients' browser to server communication.

> Have you wrangled with JSON using Go? Absolutely dreadful.

Yes. Of course it's dreadful. It's JSON. It's way better in Go than Ruby or Javascript, though.

:) I love typed languages and my current favorite is Rust. I got my most recent position because when asked what I if I preferred procedural style programming or OOP. I told them I tend to lean heavy on simple single inheritance schemes rather than complicated hard to trace architectures and over-engineered design patterns, the occasional interface class for OOP that makes sense, and mostly procedural concentrating on bending to the data rather than bending the data to your needs. It was the only thing that separated me from the other c++ candidates as we all had similar levels of experience and coding skill.

Dynamic languages start becoming problematic as more the size of the codebase increases. It becomes very hard to maintain.

Use whatever language you want; there is no large codebase that's easy to maintain.

I agree, but maintaining a large codebase in a statically typed language as compared to a dynamic language is magnitudes easier.

As the codebase grows larger, if people dont have the discipline to write proper code, the code will get more and more complicated since you will not know what exactly you will get. Mostly dynamic languages are easy to get into (which is a strength) but this becomes a weakness as the project becomes larger.

Reply on news.ycombinator.com