Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Ruby is dying. What languages are cool now?

2,279 views

Published on

A quick journey through new, trending programming languages.

Published in: Software
  • Be the first to comment

Ruby is dying. What languages are cool now?

  1. 1. Ruby is dying What languages are cool now? Michał Konarski u2i.com
  2. 2. Seriously, is Ruby dying?
  3. 3. Ruby Go https://blog.whoishiring.io/hacker-news-who-is-hiring-thread-part-1/ Who is hiring?
  4. 4. But let’s look from a different angle...
  5. 5. http://www.tiobe.com/ TIOBE Index
  6. 6. Well, not exactly. But what languages are cool now?
  7. 7. Let’s look at six of them
  8. 8. Swift
  9. 9. Swift ● designed by Apple ● released in 2014 ● created for iOS, macOS, tvOS ● multi-paradigm ● statically, strongly typed ● compiled
  10. 10. namespacesgenerics closures tuples operator overloading native collections type inference pattern matching multiple return types Read-Eval-Print-Loop (REPL) Swift features
  11. 11. Nothing really outstanding. So, what’s the story behind Swift?
  12. 12. “We absolutely loved Objective-C, but we had to ask ourselves a question - what would it be like if we had Objective-C without the baggage of C?” Tim Cook
  13. 13. It’s mainly because Objective-C is bad. And they had nothing else.
  14. 14. @interface Foo : NSObject @property (readonly) int bar; - (instancetype)initWithBar:(int)bar; + (instancetype)fooWithBar:(int)bar; @end @implementation Foo - (instancetype)initWithBar:(int)bar { self = [super init]; if (self) { _bar = bar; } return self; } + (instancetype)fooWithBar:(int)bar { return [[self alloc] initWithBar:bar]; } @end How bad is Objective-C? http://www.antonzherdev.com/post/70064588471/top-13-worst-things-about-objective-c
  15. 15. Swift is easier to read Objective-C if (myDelegate != nil) { if ([myDelegate respondsToSelector: @selector(scrollViewDidScroll:)]) { [myDelegate scrollViewDidScroll:myScrollView] } } Swift myDelegate?.scrollViewDidScroll?(myScrollView)
  16. 16. Why also Swift is better? ● no need to have two separate files (code and headers) ● it’s safer (runtime crash on null pointer) ● it has automatic ARC (Automatic Reference Counting) ● it’s faster ● it requires less code ● it has namespaces
  17. 17. It’s not only a language XCode 8 https://developer.apple.com/xcode/
  18. 18. It’s not only a language Swift Playgrounds http://www.apple.com/swift/playgrounds/
  19. 19. ● sponsored by Mozilla ● announced in 2010 ● first release in 2012 ● stable release in 2015 ● statically, strongly typed ● multi-paradigm ● compiled
  20. 20. “The goal of the project is to design and implement a safe, concurrent, practical systems language” Rust FAQ
  21. 21. There are not such languages? Apparently not.
  22. 22. Current languages are wrong ● there is too little attention paid to safety ● they have poor concurrency support ● they offer limited control over resources ● they stick too much to paradigm
  23. 23. So let’s create a new high-low level language!
  24. 24. Rust is a high level language! ● generics ● traits ● pattern matching ● closures ● type inference ● automatic memory allocation and deallocation ● guaranteed memory safety ● threads without data races
  25. 25. Rust is a low level language! ● no garbage collector ● manual memory management ● zero-cost abstractions ● minimal runtime ● as fast as C/C++
  26. 26. Guaranteed memory safety? How?
  27. 27. Ownership fn foo() { let v1 = vec![1, 2, 3]; let v2 = v1; println!("v1[0] is: {}", v1[0]); } error: use of moved value: `v
  28. 28. You can’t have two references to the same object!
  29. 29. Ownership stack heap [1, 2, 3] v1 v2
  30. 30. There are more such mechanisms.
  31. 31. Future of Rust ● currently two big projects: servo and rust ● other smaller projects: redox, cgmath, Iron, rust-doom ● it changes very quickly ● it has a good opinion in the community ● it will be hard to replace C/C++ ● It has a steep learning curve
  32. 32. Go
  33. 33. Go ● designed in Google in 2007 ● first release in 2009 ● stable release in 2016 ● statically, strongly typed ● multi-paradigm, concurrent ● compiled
  34. 34. Standard languages (Java, C++) ● are very strong: type-safe, effective, efficient ● great in hands of experts ● used to build huge systems and companies
  35. 35. Standard languages (Java, C++) ● hard to use ● compilers are slow ● binaries are huge ● desperately need language-aware tools ● poorly adapt to clouds, multicore CPUs
  36. 36. Simpler languages (Python, Ruby, JS) ● easier to learn ● dynamically typed (fewer keystrokes) ● interpreted (no compiler to wait for) ● good tools (interpreters make things easier)
  37. 37. Simpler languages (Python, Ruby, JS) ● slow ● not type-safe ● hard to maintain in a big project ● very poor at scale ● not very modern
  38. 38. What if we had a static language with dynamic-like syntax?
  39. 39. A niche for a language ● understandable ● statically typed ● productive and readable ● fast to work in ● scales well ● doesn't require tools, but supports them well ● good at networking and multiprocessing
  40. 40. Features of Go ● syntax typical for dynamic languages ● type inference ● fast compilation ● garbage collector ● memory safety features ● built-in concurrency ● object oriented without classes and inheritance ● lack of generics ● compiles to small statically linked binaries
  41. 41. Interfaces type Animal interface { Speak() string } type Dog struct { } func (d Dog) Speak() string { return "Woof!" } func SaySomething(a Animal) { fmt.Println(a.Speak()) } func main() { dog := Dog{} SaySomething(dog) }
  42. 42. Built-in concurrency!
  43. 43. Goroutines func main() { go expensiveComputation(x, y, z) anotherExpensiveComputation(a, b, c) }
  44. 44. Channels func main() { ch := make(chan int) go expensiveComputation(x, y, z, ch) v2 := anotherExpensiveComputation(a, b, c) v1 := <- ch fmt.Println(v1, v2) }
  45. 45. Future of Go ● it’s popularity constantly raises ● it’s backed by Google ● it’s used by Docker, Netflix, Dropbox, CloudFare, SoundCloud, BBC, New York Times, Uber and others ● it’s seen as a good balance between Java-like languages and Python-like ● it easy to learn and powerful ● it runs well in cloud environments ● might be a good choice for microservices approach
  46. 46. ● created by José Valim ● released in 2012 ● functional ● dynamically, strongly typed ● compiled to Erlang VM byte code
  47. 47. Erlang? Processes!
  48. 48. Elixir = Erlang with Ruby syntax
  49. 49. Elixir features ● massively concurrent ● scalable ● fault-tolerant ● great performance ● functional, but practical ● nice Ruby-like syntax ● metaprogramming via macros
  50. 50. Ruby has Rails.
  51. 51. Elixir has Phoenix.
  52. 52. Controllers in Rails class PagesController < ApplicationController def index @title = params[:title] @members = [ {name: "Chris McCord"}, {name: "Matt Sears"}, {name: "David Stump"}, {name: "Ricardo Thompson"} ] render "index" end end http://www.littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails/
  53. 53. Controllers in Phoenix defmodule Benchmarker.Controllers.Pages do use Phoenix.Controller def index(conn, %{"title" => title}) do render conn, "index", title: title, members: [ %{name: "Chris McCord"}, %{name: "Matt Sears"}, %{name: "David Stump"}, %{name: "Ricardo Thompson"} ] end end http://www.littlelines.com/blog/2014/07/08/elixir-vs-ruby-showdown-phoenix-vs-rails/
  54. 54. Future of Elixir ● new Erlang for the masses ● fits highly concurrent niche ● attracts Ruby developers ● no big company behind ● used by Pinterest ● will fly on the wings of Phoenix?
  55. 55. ● created by data scientists ● released in 2012 ● dynamically, strongly typed ● compiled
  56. 56. Compiled one for fast stuff. Interpreted one for visualisation. Data scientists’ two languages problem:
  57. 57. Julia features ● solves scientists’ two language problem ● familiar syntax ● extensive scientific library ● user-defined types ● multiple dispatch ● built-in parallelism ● good performance (comparing to C)
  58. 58. Single dispatch (Ruby) a.do_something(b, c) Only a decides which method to choose.
  59. 59. Multiple dispatch julia> f(x::Float64, y::Float64) = 2x + y; julia> f(2.0, 3.0) 7.0 julia> f(2.0, 3) ERROR: MethodError: `f` has no method matching Here everything decides!
  60. 60. Future of Julia ● R, MATLAB and C competitor ● unifies scientific software stack ● not mature enough yet ● small, but growing number of libraries
  61. 61. ● created by Google ● released in 2011 ● optionally typed ● interpreted ● translated to JavaScript
  62. 62. Let’s replace JavaScript!
  63. 63. Dart vs JavaScript ● class-based (not prototype-based) ● normal foreach ● named parameters ● operator overriding ● string interpolation ● optional typing ● false is false ● easy DOM operations
  64. 64. Looks familiar class Point { num x; num y; Point(this.x, this.y); distanceFromOrigin() { return sqrt(x * x + y * y); } } main() { var p = new Point(2, 3); print(p.distanceFromOrigin()); }
  65. 65. Cascade operator querySelector('#button') ..text = 'Confirm' ..classes.add('important') ..onClick.listen( (e) => window.alert('Confirmed!'));
  66. 66. Future of Dart ● 2016 AdWord UI built in Dart ● no Dart VM in browsers ● fragmented community ● client-side future is dim ● backend future looks much better
  67. 67. Sources ● developer.apple.com/swift ● rust-lang.org ● golang.org ● elixir-lang.org ● julialang.org ● dartlang.org
  68. 68. Any questions? @mjkonarski michalkonarski michal.konarski@u2i.com

×