3 ms·

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

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.

kgeist 5y ago
>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.
hsn915 5y ago
> 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).
- lifthrasiir 5y ago
  > 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.
konart 5y ago
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.
handrous 5y ago
> 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.

kgeist 5y ago

>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.

hsn915 5y ago

> 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).

lifthrasiir 5y ago
> 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.

konart 5y ago

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.

handrous 5y ago

> 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.