- Go is compiled, garbage collected, strongly typed, OO
- Lower level than Ruby, but still aimed at web
- Go has an agenda
- Not welcome to a lot of styles of writing code
- Prodded to write code in a certain way
- Ruby doesn't have an agenda, but it does have idioms
- What are the design goals here?
- Declaration different than assignment
- This eliminates stray variables and dependencies
- Export values from packages controlled by case
- Packages are like namespaces
- This forces you to focus on package API
- Interface-oriented type system --compile-time duck typing
- Emphasize polymorphism and composition over inheritance
- Go doesn't really have inheritance
- Functions often return multiple values; used for error handling
- Often returns a value, then 2nd value is the error
- Do not treat errors as unusal or exceptional
- Treat them as part of your normal control flow
- This is pretty controversial
- So how do you handle errors?
- If you write middleware, what happens when a lower class raises something? Handle it, or propagate?
- Where does this push us?
- Small, composable packages that do one thing well
- Focus is on design of package API
- Questions
- Who does error handling and how?
- Where does business logic live?
- Presentation logic is business logic
- Many layers of business logic (often called MVC)
- But Go's packages are so general, it's like they're all libraries
- Can be more verbose, since it explicitly checks for errors
- Probably harder to read output
- Ruby either works well, or blows up
- Go seems to work more consistently, but not as clean
- Why learn new languages?
- You aren't better because you can now write +1 languages
- You're better because exposure to more examples allows you to generalize your understanding of what you're doing
- Go back to old languages and appply new paradigms, styles, idioms
- Understand style of old language
- PL communities and their discontents
- They have diferent practices, styles, and idioms
- Difficult to judge practices until fairly deep into languages
- Be deliberately humble when entering a new community
Working with programming languages is a social act; you are influenced by the way your fellow programmers behave. Nowhere is this more obvious than in what is considered "idiomatic" code. Do language designers have idioms in mind when specifying and language?
- Idiomatic code uses language semantics and syntax to get greatest possible leverage on a problem
- Better definition: It's the comunity standard way of doing something
- Familiarity perhaps more important than anything else
- C++ has 66 keywords, so everyone just chooses their favorite 20%, and there's no standard practice
- Why is familiarity important?
- You have to read and understand not just what the code does, why the code is written the way it is
- Is the goal of a language designer to push programmers into writing good code naturally?
- Minor syntactic decisions in ruby can make code beautiful (no need to sprinkle commas, parens, etc)
- Go try writing some Go, wrap your head around error handling
- Be critical of your language
- Give mad props when it does things well