re: The whole original post was about Go design is silly and all your objections are that’s by design. That’s smart because that statement immediately ...
 

I wasn't just saying it's "by design", I gave reasons why that design might be desirable. If you're referring to my lack of followup on the key checking in Go, it's because the followup is it's functionally no different than wrapping it in a try/except/catch/whatever and dealing with it then. Tell me, how does Elixir handle a missing key?

We surely have a very different sense of beauty.

Clearly.

Go is pretty darn readable, even for someone who's never written a line of code in it before. The same cannot be said for Elixir. What the hell is %{} or [_|_] supposed to mean?

The whole original post was about Go design is silly and all your objections are that’s by design. That’s smart because that statement immediately puts me out of further arguments.

Someone with an argument would ask questions to lead into their argument, no? Question my assertions. Poke holes in my arguments. I don't write this shit because I want other people to agree with me. I write as a way to understand my own thoughts more and learn more in the process.

Tell me, how does Elixir handle a missing key?

Besides syntactic sugar, the core ways are: Map.fetch/2 to return nil, Map.fetch!/2 to raise and Map.get/3 to return a default value.

Go is pretty darn readable, even for someone who's never written a line of code in it before.

I hear this kōan from almost everybody who likes Go and I am most likely an exception. I can read and understand more than 20 languages, I can write the code professionally in more than 10. 4–5 on senior level. I still having difficulties reading Go, despite I already wrote 1000+ LOCs in it.

How is map[string]int pretty darn readable?

Besides syntactic sugar, the core ways are: Map.fetch/2 to return nil, Map.fetch!/2 to raise and Map.get/3 to return a default value.

Similar(ish) to Python, I agree this is a better way to handle in general. This is a spot where static typing (and not generics) hurts a bit, as you can't cleanly define an interface/method that can return values of arbitrary types without using interface{}. When you declare a map, it's full structure becomes a type. Meaning map[int]string is a different type from map[string]string. I found a pretty good explanation of what's actually going on with Go's maps. What's funny is the standard lib has list and heap implementations that use interface{}, and I'm not sure why they don't also have a dict package that does the same thing. Here, I just did it.

kōan

Sorry, I'm not sure what language this is so I can only guess that it means something like "banal" in English.

I can read and understand more than 20 languages, I can write the code professionally in more than 10. 4–5 on senior level. I still having difficulties reading Go, despite I already wrote 1000+ LOCs in it.

All those languages knockin' around in your head must be confusing you 😉

I would stick with it and write a few small web applications in it, or don't. It's hardly the best language out there, I just happen to like it a lot.

How is map[string]int pretty darn readable?

I'll agree it's one of the uglier constructs in go. Again, it's worth calling out that I've used maps maybe 2 or 3 times in the 3+ years I've been programming in Go. structs tend to get used more often than in dynamic languages (Python dict hell!!)

code of conduct - report abuse