Go is not a good example of a type system - its types are limited and restrictive and really will stop you writing some good code that you wanted to write in Python. If you want a Pythonic language with static types, maybe take a look at OCaml (or my personal favourite, Scala - though that language suffers from a bunch of warts for the sake of JVM compatibility). http://roscidus.com/blog/blog/2014/06/06/python-to-ocaml-ret... is one example of someone making the move.
I see Go and OCaml recommended to people fed up with Python's lack of static typing, and I just cringe. I love experimenting with programming languages, and Go seems to be picking up momentum but unfortunately for both Go and OCaml, they have this ridiculously restrictive syntax to them respectively which it makes it deeply unattractive for prototyping anything.
If you're looking for a statically typed Python that can be grokked in a matter of minutes, and compiles down to a static binary like Go does, and runs as fast as C in benchmarks, you should definitely check out the Nim compiler [1].
Code example:
import rdstdin, strutils
let
time24 = readLineFromStdin("Enter a 24-hour time: ").split(':').map(parseInt)
hours24 = time24[0]
minutes24 = time24[1]
flights: array[8, tuple[since: int,
depart: string,
arrive: string]] = [(480, "8:00 a.m.", "10:16 a.m."),
(583, "9:43 a.m.", "11:52 a.m."),
(679, "11:19 a.m.", "1:31 p.m."),
(767, "12:47 p.m.", "3:00 p.m."),
(840, "2:00 p.m.", "4:08 p.m."),
(945, "3:45 p.m.", "5:55 p.m."),
(1140, "7:00 p.m.", "9:20 p.m."),
(1305, "9:45 p.m.", "11:58 p.m.")]
proc minutesSinceMidnight(hours: int = hours24, minutes: int = minutes24): int =
hours * 60 + minutes
proc cmpFlights(m = minutesSinceMidnight()): seq[int] =
result = newSeq[int](flights.len)
for i in 0 .. <flights.len:
result[i] = abs(m - flights[i].since)
proc getClosest(): int =
for k,v in cmpFlights():
if v == cmpFlights().min: return k
echo "Closest departure time is ", flights[getClosest()].depart,
", arriving at ", flights[getClosest()].arrive
Statistics (on an x86_64 Intel Core2Quad Q9300):
Lang Time [ms] Memory [KB] Compile Time [ms] Compressed Code [B]
Nim 1400 1460 893 486
C++ 1478 2717 774 728
D 1518 2388 1614 669
Rust 1623 2632 6735 934
Java 1874 24428 812 778
OCaml 2384 4496 125 782
Go 3116 1664 596 618
Haskell 3329 5268 3002 1091
LuaJit 3857 2368 - 519
Lisp 8219 15876 1043 1007
Racket 8503 130284 24793 741
Nim is nowhere near the maturity of OCaml, and everything I've seen about it has the whiff of zealotry. I'll wait until I see more nuanced talks about it, and an established ecosystem that doesn't rely on C libraries.
If something is compiled to native code, what's the point of writing a library that's not just a binding? In python it makes sense, because you get the pure-python installation of your app - it doesn't depend on the OS, python versions, etc.
But once you're going to compile your app for a target platform... what's the point of not relying on C libraries?
If your app uses C libraries then it inherits the problems of C: there will almost surely be bugs in the library that mean your app might segfault, or worse, have security problems. Thus e.g. the recent effort to write a full SSL stack in OCaml.
