Download as PDF, PPTX
Uploaded bySveta Bozhko
Golang from Scala developer’s perspective
The document discusses the Go programming language from the perspective of a Scala developer, highlighting its simplicity, effective concurrency features, and productivity-focused philosophy. It contrasts functional programming practices with Go's approach, noting advantages such as cleaner code and easier debugging. The author emphasizes that while Go has limitations, understanding functional programming principles can enhance programming skills.
Golang from Scala developer’s perspective
- 1. Golang from Scala developer’s perspective
- 2. About me Svetlana Bozhko Backend Scala Developer @ Adform
- 3. The goal Is Go really so bad imperative?
- 4. Content Short intro into Go Tooling FP vs. Go IMHO
- 5.
- 7.
- 8.
- 9. Go is actually a pretty simple language!
- 10. Even too simple for 2015
- 12.
- 13. “Build time matters more than anything else” -‐ Rob Pike
- 14.
- 15. Quite good tools build-‐in (version, get, build, …) editors (vim, intellij, sublime, …)
- 16. Concurrency • Channels send data between threads easily, asynchronously or synchronously • GoRoutines spin up another thread, just like that!
- 17. No Language Is Perfect...
- 18. Go Mentality • Smallest possible feature set • It’s okay to copy some code • Productivity instead of hyper-‐elegant code
- 19. Let’s get rid of • Implicit numeric conversion (int != int32) • ‘Implements’ keyword • ‘Classes’ • Constructor/destructor • Function overloading • Pointer arithmetic • Exceptions and try/catch • Generics • …
- 20. Strict compiler which interrupts you sometimes
- 21. Wait, Go has ‘goto’?
- 22. Wait, how to debug? GDB, but it’s not very good way
- 23.
- 24.
- 25. Wikipedia: “Functional programming is a programming paradigm — a style of building the structure and elements of computer programs — that treats computation as the evaluation of mathematical functions and avoids changing-‐state and mutable data.”
- 26. What it means? No mutable data (no side effect) No mutable state (no implicit, hidden state) Same result returned by functions called with the same inputs Functions are pure functions in the mathematical sense
- 27.
- 28. Referential transparency Memoization Cache results Idempotence Modularization We have no state Ease of debugging Functions are isolated and very easy to debug
- 29. Referential transparency Parallelization Functions calls are independent We can parallelize in different process/CPUs/computers/... res = func1(a, b) + func2(a, c)
- 30. Referential transparency With no shared data, concurrencygets a lot simpler: No semaphores No monitors No locks No race-‐conditions No dead-‐locks
- 31. Nonetheless Golang has built-‐in “sync” package with mutexes
- 32.
- 33.
- 34.
- 35.
- 36.
- 37.
- 38.
- 39.
- 40.
- 41.
- 42.
- 43. Currying and Partial Functions
- 44. Eager vs Lazy Evaluation Golang channels and goroutines enable the creation of generators that could be a way to have lazy evaluation
- 45.
- 46. FP & OOP It is possible do FP in OOP? Yes it is! OOP is orthogonal to FP. At least in theory…
- 47. Exercise! What is the sum of the first 10 natural number whose square value is divisible by 2?
- 48.
- 49. Learn at least one functional language It will open your mind to a new paradigm becoming you a better programmer
- 50. Conclusion Technologies are awesome! The problem is people how we use them.
- 51. Thank you! Questions? Svetlana Bozhkoaka @SBozhko http://devzen.ru/ svt.bozhko@gmail.com
- 52.