10 ms·
In praise of Go or "Why I moved from Python and C++ to Go"
- BarkMore 16y agoAlthough the library coverage for Go is growing, it's tiny compared to what's available in Python. Otherwise, I much prefer Go to Python for many of the reasons given by the author.
- stcredzero 16y agoI've been toying with the idea of doing massive rewrites of Python libraries to Go using syntax directed translation. Getting to somewhere like 98% fidelity is a very practical goal (I've done it and been paid for it!) and gives a tremendous boost to programmer productivity.
- contextfree 16y ago"- It is "garbage-collected" (which is uncommon for a compiled language: The only other example is "D") " wat?
- ramchip 16y agoNot sure why the downvotes - perhaps the "wat" sounded too trollish - but yes, this strikes me as a very ignorant statement... even good old Java is another example. So are many compiled Lisps, Haskell, Lua...
- deleted 16y ago[deleted]
- ramchip 16y agoAll the examples I gave have at least one native compiler. In order: gcj, SBCL, GHC, llvm-lua.
- deleted 16y ago[deleted]
- silentbicycle 16y agoDon't let the facts get between you and faint praise! Also: Common Lisp, Scheme, Erlang, SML, OCaml, Haskell, Lua, Prolog, and Java, and no doubt numerous others. For all of the above, many (if not most) implementations compile natively.
- aaronblohowiak 16y agoI didn't know about llvm-lua (an AOT compilation option for lua.) Neat!
- stcredzero 16y agoSomething which has been neglected, but which has clearly shown its value in VMs is the information gained by runtime tracing. We should make this more available to the programmer! It should be possible for a programmer to highlight a section of code in an IDE and choose "Apply Trace," whereupon the IDE will apply static type annotations based from saved runtime trace information. The IDE should be also able to present the same information as profiling data to let the programmer quickly home in on the 15% or so of the app which is most performance critical. Using techniques like this should let us get C-like speeds from many dynamic languages. (Admittedly, this sort of thing would also be highly dangerous. One couldn't apply such semi-automated annotations in ignorance. This could also break otherwise correct programs.)
- silentbicycle 16y agoDirecting programmers to hotspots based on programming info is pretty reliable. In your case, it depends on how confident the annotations are. The Self papers have a lot about that - JIT compilers can nonchalantly make riskier optimizations, because they can also easily undo them.
- stcredzero 16y agoMy idea is that the programmers can add expert knowledge and human intelligence into the mix. They have the ability to just let the VM know: "Okay, in this part these things are always going to be this type and things go like that, so just go to town and optimize the bejesus out of it!" In other words, a good programmer should be able to just let the VM know ahead of time what's up in critical sections of stable production code. Even better, we should be able to combine datasets from many different runs of many VM instances! This sort of technique would allow us very high degrees of confidence for things like web apps in server farms, where getting 10's of thousands of runtime tracing datasets would be easy to do. This is where a dynamic language with optional type annotations would really shine.
- andolanra 16y agoI'm not sure about Go specifically (as I have yet to write a non-trivial project in Go) but D at least allows you to do manual memory management, if you so desire--down to using std.c.stdlib.malloc, which is exactly what it sounds like--although garbage collection is on by default. I usually tell people it's "...mostly garbage-collected," which tries to convey the flavor of a choice between fine-grained systems-level control and instantiate-and-forget application-level control. To be fair to the author, I'm going to assume that the most esoteric (read: non-C-like) language he knows is probably Python, because he doesn't compare it to anything besides Python, C, C++, or Java. I also assume he left out Java because by "compiled languages" he meant "compiled to native code without relying on a runtime which is external to the compiled application." He's still missing a whole swath of compiled languages, but there is a point of view from which his comment makes sense, i.e. native-code compilation of C-like systems or applications languages. ("...you will find that many of the truths we cling to depend greatly on our own point of view.")
- dadkins 16y agox = new(foo) ... x = nil There. Manual memory management. What? It's not as if when you free() something that was malloc()'ed, it gets returned to the operating system right away. It just goes back on the free list. Garbage collection amortizes that.
- andolanra 16y agoWell, by the same token, you can take Python's x = Foo() ... del x as manual memory management, after a fashion (which it is). The kind of manual memory management I'm concerned about is less about having precise control over when memory passes in and out of my program's control, and more about controlling fragmentation and time spent searching for unused memory. For example, would slab allocation--an extremely useful technique for operating systems, databases, &c--be possible in Go? Addendum: I'm not trying to denigrate Go, and I don't mean to suggest having or not having fine control over memory makes or breaks a programming language, because it's a valuable tool in certain instances and a hindrance in others. I honestly don't know whether or not it's possible in Go; I suspect it is, to some extent, although it would no doubt be discouraged by the design of the language.
- jpr 16y agoYep. I still haven't read one article from Go aficionados that hasn't made me bang my head against a wall repeatedly.
- kingkilr 16y ago> "It is only superficially object-oriented (no classes, no inheritance, just interfaces) so it is more transparent" What does that even mean?
- BarkMore 16y agoFrom the FAQ: " Although Go has types and methods and allows an object-oriented style of programming, there is no type hierarchy. The concept of “interface” in Go provides a different approach that we believe is easy to use and in some ways more general. There are also ways to embed types in other types to provide something analogous—but not identical—to subclassing. Moreover, methods in Go are more general than in C++ or Java: they can be defined for any sort of data, not just structs." http://golang.org/doc/go_faq.html#Is_Go_an_object-oriented_language http://golang.org/doc/go_faq.html#Is_Go_an_object-oriented_l... The lack of type hierarchy makes code easier to understand.
- jamesaguilar 16y agoAlso, an "interface" is more of an enforced duck type annotation than an interface or ABC in Java or C++ terms respectively.
- aaronblohowiak 16y agoIIRC, the duck-type mode uses implicit interface creation but you can force an explicit interface if you want (please correct me if i am wrong.)
- BarkMore 16y agoInterfaces are explicitly defined in Go as they are in Java. The difference is that you do not declare the interfaces implemented by a type. If a type has methods that match an interface, then the type implicitly implements the interface.
- aaronblohowiak 16y ago
- megaman821 16y agoThe only thing I could see myself leaving Python for is Haskell. Go seems to fall into a very small niche. The inclusion of a GC means it is not appropriate for a lot tasks that C/C++ are suited for. Also, it is verbose enough where you can't bang out stuff as fast as in Python/Ruby.
- tel 16y agoIt's really a big deal for Haskell to sit in that position now instead of "that weird language with Spacesuitmonads". I hear the sentiment a lot and every time I'm somewhat surprised and happy to realize it.
- BarkMore 16y agoI find that I can write working code with Go as fast as I can with Python. Although I need to type more with Go, the static typing helps me iterate faster to working code. With the exception of the library problem that I mention in another comment, Go can cover much of the space covered by Python.
- silentbicycle 16y agoHave you used OCaml or Haskell, beyond Fibonacci trivialities? How about J?
- kjksf 16y agoGo, today, is a niche language by usage but is not niche by features. It's designed as a server-oriented (i.e. aimed at a still growing programming category) language that is close in syntax to C/Java (i.e. already familiar to many), almost as easy to write in as Python/Ruby (both very successful, non-niche languages) but order of magnitude faster and much memory efficient that either. As a bonus it has much better concurrency support. It's designed for the same "niche" that Python/Ruby/Java serves on the server, with many important improvements over them. Having written code in Python and Go, Go seems to me an improvement over Python in many important areas (speed, memory efficiency, concurrency) and the parts that are not as good are both not as important and not significantly worse (static vs. dynamic typing is a toss (it's nice not to declare types but it's also nice if compiler tells you about a type mismatch typo that Python will only complain about at runtime), Python still has slightly cleaner syntax etc.). I didn't experience Go being more verbose than Python to a degree that it mattered. In some aspects the syntax is actually less verbose (Python class require more typing than Go interfaces). Go is still a young language and young implementation. On one hand it means it's anyone's guess whether it'll become non-niche at some point but at the same time I'm pretty sure at year one both Python and Ruby were much less polished and much less popular than Go is at the same stage. Personally, I'm bullish on Go and if I were writing server side code, I would use Go (even though at the moment I know Python better).
- grovulent 16y agoHaving picked up python as my first programming language earlier this year I am always really surprised to hear how so many programmers hate the indentation. I don't ever have indentation errors - or if I do, they aren't ever of a sort that pyscripter can't spot them. Must be a what-you're-used-to thing...
- FraaJad 16y ago"So the danger to paste stuff at the wrong indent level is far less than in Python. " I would argue that this is actually a feature of the language. This "danger" actually forces the programmer to read through the code he is pasting by indenting. Also, how many pairs of source code fragments share the same variable names? This argument is quite shallow.
- yesimahuman 16y agoThe biggest error I have with pasting is that the pasted code uses spaces where I use tabs. They look like the same indent level but they are not. A good old ggVG= solves that though in vim
- hasenj 16y agogg=G also works; one less character
- chunkbot 16y agoI use Emacs, and I can't remember the last time I manually indented a line of code. Most of my non-web programming is in Erlang, Lisp, and C. My editor does the indentation for me.
- Daishiman 16y ago:retab is your friend.
- jeberle 16y ago:set expandtab | retab
- deleted 16y ago[deleted]
- WalterBright 16y agoI don't see where he got the impression that D is not actively maintained. See http://www.digitalmars.com/d/2.0/changelog.html http://www.digitalmars.com/d/2.0/changelog.html, which is the record of frequent, active and extensive updates.
- andralex 16y agoAlso traffic in the digitalmars.D forum (the main hangout of D developers and users) is roughly twice the traffic on go's mailing list.
- budwin 16y ago"- It is compiled into machine code (no interpreter, unlike Python)." anyone have any kind of measure on how bytecode compares to machine code these days? (most "interpreted" languages have a hidden compile step these days). I understand that this question is largely subjective to the runtime and the task being executed.
- mikeklaas 16y agoYour question is relatively meaningless, since 'bytecode' covers such a wide gamut of possibilities. Python's bytecode is very high-level and basically just saves the expense of parsing the code. The interpreter is not JIT-ed and thus very slow (compared to machine code). Java's bytecode is much less dynamic. 'a + b' can execute arbitrary code in python, but in java it is known at compile-time whether it is addition between native types or string concat. Java has a very good JIT compiler and thus can be as fast as 1.5x the speed of c.
- dkersten 16y agoYeah, Python is bytecode compiled and run in a virtual machine. Hell, you can even JIT it into machine code (psyco, Jython with a JIT-enabled JVM, IronPython with a JIT-enabled CLR). Python never had a traditional interpreter.
- stcredzero 16y agoThere were tons of people who were walking around 10 years ago thinking Smalltalk ran on "traditional" bytecode interpreters, when the majority of VM instances used back then running were JIT VM. There was also widespread ignorance about Lisp implementation and performance. The sad part: the degree of misconception is still surprisingly bad. (Much the same held and holds true for Lisp.) The Interpreter/VM distinction had become hazy and lost its meaning years ago. I think people still hold onto it only as a means of excusing poor language performance.
- kjksf 16y agoCompare on what basis? Speed? http://shootout.alioth.debian.org/ http://shootout.alioth.debian.org/ is an up-to-date, super detailed answer to that question. A rule of thumb simplification I go by is: current Python and Ruby implementations are at least 10x slower than C doing algorithmic work. A really good bytecode VM can, of course, get much closer to C performance (as shown by Java, C# or even modern JavaScript implementations) especially if JIT is given enough time to profile the app at runtime and generate highly optimized code based on that profile data. There are of course other aspect you can compare. Bytecode is, inherently, cross-platform and machine code isn't. Bytecode is usually more compact than equivalent machine code (but then you need the constant overhead of the runtime to interpret that bytecode).
- Kilimanjaro 16y agoI got rid of the shackles of curly braces, and once tasted freedom, it will be damn hard to put me back in chains. Over my dead body!
- kjksf 16y agoIt's very poetic sentiment but doesn't really address the issue of trade-offs. Is writing if a { .. } else {} so much worse than if a then .. else .. end (Ruby requires then/end instead of {}. Python's indentation based syntax (which I think is great) cleverly solves the problem of requiring explicit statement delimiters but it's also a reason why lambda: is limited to one-liners. There's no free lunch. To Go's credit they did put a lot of effort and design thought into removing line noise from syntax (compared to C) by e.g. adding an automatic semi-colon insertion rule, eliminating braces around if argument etc. Overall, while syntax is not as clean as Python's, it comes pretty damn close.
- andralex 16y agoI'm not so sure about giving credit. Consider: package main import "fmt" func blah() bool { return false } func main() { x := 5 if(blah()) { x++; } fmt.Printf("%d\n", x) } (which prints 5) and then this: package main import "fmt" func blah() bool { return false } func main() { x := 5 if(blah()) { x++; } fmt.Printf("%d\n", x) } (which prints 6). Looks like a major problem to me, and at any rate it's a far cry from having made real (or any) progress. Python _did_ get whitespace right.
- stcredzero 16y agoPython's approach has always been highly pragmatic. Go's is as well, but with somewhat different goals. The Go team's goal seems to involve putting together a clean-enough syntax with fast-enough for systems programming performance combined with powerful-enough high-level concurrency model. They don't want to win the gold in any one category. They're going for the decathalon! In any case, language syntax should always take into account the expectation of programmer communities. If you push syntax too far, you lose too many people.
- xiongchiamiov 16y agoSeveral of the things he cites are a matter of preference (and using the right tool for the job) - namely dynamic vs. statically typed, compiled vs. interpreted. > The documentation is very good and can be consulted instantly form the command line or from a browser, indifferently. I can't speak for Go, but I've always found Python's documentation to be fantastic. And very few things make me as happy as docstrings.
- deleted 16y ago[deleted]