4 ms·

I had a quick look at the language and checked about my two pet pieves. What does the code look like when handling JSON data? (that is when I slammed the door o

I had a quick look at the language and checked about my two pet pieves. What does the code look like when handling JSON data? (that is when I slammed the door on Golang) What does the code look like when starting an external process, supplying stdin, args and capturing return code, stdout, and stderr? (that is when I slammed the door on lua). Well, I must say that crystal-lang manages to dodge the bullet twice. It handles both situations quite elegantly. So, yes, I am interested.

013a 9y ago
What exactly frustrates you about Go's JSON handling? In my experience its among the best in typed languages. Define a struct (or just use an untyped map), optionally specify json tags for field names, pass it and the json to json.Unmarshal. Go is literally designed for this use case; systems programming, sharing messages between systems. Compared to other typed languages like Rust or Java, its at least as simple, if not simpler.
- aczerepinski 9y ago
  Agreed. Go is wonderful with JSON. Reasonable defaults and very flexible.
  - 3pt14159 9y ago
    It might be wonderful now, but I first used Go in 2009 and it was really hard to work with back then, so maybe the OP has a warped view of the current state?
    - ccccccccccccc 9y ago
      That was almost 9 years ago. Go has changed at a pretty rapid pace since then.
  - tigershark 9y ago
    From what I know about go and JSON and what is possible in other languages I would never call it wonderful.
- svs 9y ago
  Try having a default value for a key in a JSON document that isn't null. In Go, this is pure torture. Then compare with the serde library for Rust. Go's lack of generics makes this kind of use case much harder than reasonable.
- tigershark 9y ago
  Compare it with F# type providers where you don’t need to generate any struct and you can access the JSON object in a type safe way with autocompletion in your IDE and maybe you will understand what is frustrating...
  - deforciant 9y ago
    Hey, I found this tool very useful https://mholt.github.io/json-to-go/ https://mholt.github.io/json-to-go/ when working with large JSON structs :)
  - IshKebab 9y ago
    How is that possible? You either need to specify the types up front (like Go) or give up on static type safety (like Python). It's impossible to have both.
    - actsasbuffoon 9y ago
      Actually, you can have both. Many languages in the ML family (Haskell, F#, etc.) can ensure complete type safety without having to define the shape up-front. Your data comes out of the JSON structure wrapped in a functor, and you can only access it in ways that deal with missing data. It’s hypothetically possible to recreate this approach in Python, but I don’t think it would be Pythonic.
      - IshKebab 9y ago
        That sounds like how you have to access JSON data dynamically in any statically typed language.
        actsasbuffoon 9y ago
        But these other languages wouldn't necessarily remain type-safe. The functor approach doesn't involve any type casting, and null pointer exceptions are impossible.
StevePerkins 9y ago
There are basically two ways for a programming language to deal with JSON: (1) Expect it to conform to a contract. Marshal and unmarshal it to and from a backing data structure that represents that contract. Perhaps with some tolerance for missing or unexpected values. (2) Have no expectations of a contract. Parse the JSON string into a blob-tree of your programming language's "any" type. Just kinda yolo-wing-it with tree traversal, and hope that your language syntax is very null-tolerant. Try to overlook the fact that ultimately you DO have an expectation of contract after all (!)... it's just scattered through your tree-traversal logic, rather than consolidated in a data structure. I think pretty much all modern widely-used languages do a decent enough job with approach #1. While approach #2 is pretty much equally awful with all languages.
- nitrogen 9y ago
  Ruby does fine with #2. Fans of static type systems love to overstate perceived drawbacks of dynamic languages, but the simplicity of reading Ruby code built around JSON.parse vs. Scala or Kotlin with Jackson more than makes up for any type safety from the compiler. Also, there's a sort of intermediate step, a dynamic language with schema validation, for which I wrote a modestly well-used (within the overall schema validation gem market) gem a while ago. Then you can validate at the point of translation, without being beholden to a concrete data type (POJO, data class, case class, etc.) that has to be updated whenever the wire format changes.
  - sidlls 9y ago
    "but the simplicity of reading Ruby code built around JSON.parse vs. Scala or Kotlin with Jackson more than makes up for any type safety from the compiler." "Readability" and "simplicity" are except for trivial or outlandish cases subjective. For example, I rather enjoy reading code using Rust's serde crate: the code is quite readable and comes with all the benefits of Rust's static type system and safety.
  - yellowapple 9y ago
    Ruby also does a decent-enough job with #1, albeit with a bit of elbow grease required to massage arbitrary JSON data into Ruby class instances. Not as elegant as a static type system, sure, but still workable.

013a 9y ago

What exactly frustrates you about Go's JSON handling? In my experience its among the best in typed languages. Define a struct (or just use an untyped map), optionally specify json tags for field names, pass it and the json to json.Unmarshal. Go is literally designed for this use case; systems programming, sharing messages between systems. Compared to other typed languages like Rust or Java, its at least as simple, if not simpler.

aczerepinski 9y ago
Agreed. Go is wonderful with JSON. Reasonable defaults and very flexible.
- 3pt14159 9y ago
  It might be wonderful now, but I first used Go in 2009 and it was really hard to work with back then, so maybe the OP has a warped view of the current state?
  - ccccccccccccc 9y ago
    That was almost 9 years ago. Go has changed at a pretty rapid pace since then.
- tigershark 9y ago
  From what I know about go and JSON and what is possible in other languages I would never call it wonderful.
svs 9y ago
Try having a default value for a key in a JSON document that isn't null. In Go, this is pure torture. Then compare with the serde library for Rust. Go's lack of generics makes this kind of use case much harder than reasonable.
tigershark 9y ago
Compare it with F# type providers where you don’t need to generate any struct and you can access the JSON object in a type safe way with autocompletion in your IDE and maybe you will understand what is frustrating...
- deforciant 9y ago
  Hey, I found this tool very useful https://mholt.github.io/json-to-go/ https://mholt.github.io/json-to-go/ when working with large JSON structs :)
- IshKebab 9y ago
  How is that possible? You either need to specify the types up front (like Go) or give up on static type safety (like Python). It's impossible to have both.
  - actsasbuffoon 9y ago
    Actually, you can have both. Many languages in the ML family (Haskell, F#, etc.) can ensure complete type safety without having to define the shape up-front. Your data comes out of the JSON structure wrapped in a functor, and you can only access it in ways that deal with missing data. It’s hypothetically possible to recreate this approach in Python, but I don’t think it would be Pythonic.
    - IshKebab 9y ago
      That sounds like how you have to access JSON data dynamically in any statically typed language.
      - actsasbuffoon 9y ago
        But these other languages wouldn't necessarily remain type-safe. The functor approach doesn't involve any type casting, and null pointer exceptions are impossible.

StevePerkins 9y ago

There are basically two ways for a programming language to deal with JSON: (1) Expect it to conform to a contract. Marshal and unmarshal it to and from a backing data structure that represents that contract. Perhaps with some tolerance for missing or unexpected values. (2) Have no expectations of a contract. Parse the JSON string into a blob-tree of your programming language's "any" type. Just kinda yolo-wing-it with tree traversal, and hope that your language syntax is very null-tolerant. Try to overlook the fact that ultimately you DO have an expectation of contract after all (!)... it's just scattered through your tree-traversal logic, rather than consolidated in a data structure. I think pretty much all modern widely-used languages do a decent enough job with approach #1. While approach #2 is pretty much equally awful with all languages.

nitrogen 9y ago
Ruby does fine with #2. Fans of static type systems love to overstate perceived drawbacks of dynamic languages, but the simplicity of reading Ruby code built around JSON.parse vs. Scala or Kotlin with Jackson more than makes up for any type safety from the compiler. Also, there's a sort of intermediate step, a dynamic language with schema validation, for which I wrote a modestly well-used (within the overall schema validation gem market) gem a while ago. Then you can validate at the point of translation, without being beholden to a concrete data type (POJO, data class, case class, etc.) that has to be updated whenever the wire format changes.
- sidlls 9y ago
  "but the simplicity of reading Ruby code built around JSON.parse vs. Scala or Kotlin with Jackson more than makes up for any type safety from the compiler." "Readability" and "simplicity" are except for trivial or outlandish cases subjective. For example, I rather enjoy reading code using Rust's serde crate: the code is quite readable and comes with all the benefits of Rust's static type system and safety.
- yellowapple 9y ago
  Ruby also does a decent-enough job with #1, albeit with a bit of elbow grease required to massage arbitrary JSON data into Ruby class instances. Not as elegant as a static type system, sure, but still workable.