Why Go? Use Racket
cxwangyi.wordpress.com
cxwangyi.wordpress.com
You should know about how your types are passed around if you are using any language.
The example given was arrays in Go. Arrays are passed by value, but slices (pointers to arrays) are passed by reference. This is very simply described in the Effective Go reading. It's not a hard concept. I don't like you writing off Go with that example. It sounds like you made an emotional decision against the language and are grasping for logical reasons to support your already made decision.
How many people programming with Go pass arrays around? It's an easy lesson to learn.
I can't help but be amused to see the complaint that Go's type system is, of all things, too complex.
At the time I first picked up Go, Racket was my favorite language of choice[0]. One of the biggest things I noticed about Go was how little I needed to think about types and implementation. Part of this was simply having a static typechecker[1], but part of it is how the rest of the tooling is designed as well.
> How many people programming with Go pass arrays around?
Most people using Go shouldn't be using arrays at all, since they really don't fit most use cases (fixed size and size is part of the type).
[0] For the record, I still like Racket, but I've found I'm undeniably far more productive in Go.
[1] Type Racket exists, but at least at the time, most libraries were untyped, which meant I had to write typed wrappers for everything.
"However, the type system of Go is so complex"
The type system is anything but complex, even in the non-system complaints expressed.
Regardless of this, I learned Go during the last Stripe CTF and placed top 5 in one of the rounds with it sooo... I don't believe learning to be effective with it takes all that long. It was quite enjoyable to learn as well.
I think the essence of my point still stands in that the example the author provides is very shallow and hardly something that stops you from writing Go or even writing any kind of protocol in Go.
From "Effective Go":
"We must return the slice afterwards because, although Append can modify the elements of slice, the slice itself (the run-time data structure holding the pointer, length, and capacity) is passed by value."
The slice, however, is a small structure to pass to a function in that you are not performing a copy of each individual element in the slice.
However much Go's type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language.
I'd rather say 'use OCaml' or 'use F#' or even 'use Haskell'.
BTW both Clojure and Erlang allow a form a gradual typing.
From personal experience. I've used both static (C#, C++, Java) and dynamic typing (Python, Erlang), and have to say, the prevents-many-bugs excuse as the main problem with dynamic types just wasn't true.
Maybe my code is more complicated and dealing with distributed state, consistency, and protocols but what what kills everything is usually logic errors, network failures, files not being there, misconfiguration, segfaults, user-after-free, and the most evil ones, shared global states in a concurrent shared-heap environment.
Things like "oh I expected an int but got a string" are pretty trivial and easy discovered.
Moreover, in a recent service I implemented. I did in Python and I believe the faster development time and less code to write in general, gave me time to write better integration tests that exercises and covered the code a lot better. I would have had to write the tests anyway, even if this was written in Haskell.
Perhaps static typing helps a lot more in large code bases. Think of a large game, or a CAD application or some huge C++ back-end. But, if you buying into the whole micro-services fad, well, you shouldn't have large code bases if you can help it.
Another big motivation for types, which I think most people have in mind when they pick a strongly typed language is performance. Usually static typing and a very large performance increase would go hand in hand. Now with the effort put into v8 and PyPy we see that gap getting smaller.
(I generally agree with the gist of your comment, I think. This just stuck out.)
I don't believe Clojure belongs in that class (as "proven" for writing reliable software), but whatever.
If you want truly reliable software and have the budget, then you just need to throw process at the problem -- it doesn't matter much which language you use. Several (if not all) the Mars landers were programmed in C -- with very few critical flaws experienced/discovered[2]. The Ericsson switches that achieved previously-unheard-of reliability were programmed in Erlang, but they used process and a huge number of engineers to achieve that. (Plus they're mostly stateless and so can just reset if they do it fast enough and don't lose important state when doing so.)
For large-scale software which has to evolve fast, I belive strong type systems do win out. It's not so much that they prevent bugs which could be caught by test suites, but having a strong type system means that you can be certain that there are a lot of tests that you actually will never have to write or, more importantly, rewrite as the system evolves.
There have been actual studies which may be of interest[1], but even if I'm on the "winning" side, I don't think I would put too much stock in the methodology/analysis of this particular study. (E.g. concluding that JavaScript suffers from few concurrency bugs relative to other languages is kind of being oblivious of the fact that JS is single-threaded (semantically) and that all the other languages in the comparison permit "real" concurrency/parallellism, and that it should thus perhaps be excluded from the category or at least treated separately.)
[1] http://macbeth.cs.ucdavis.edu/lang_study.pdf
[2] https://www.usenix.org/conference/hotdep12/workshop-program/...
(Sorry, references out of order because edited-post-facto)
I also generally agree with your comment, but I have to take issue with this statement. If this were true, Ericsson wouldn’t have had to abandon the AXE-N project.
Quoting from Joe Armstrong’s PhD thesis[1]:
“1995: The AXE-N project was a project to build a “next generation switch” to replace the Ericsson AXE-10. This extremely large project ran from 1987-95. After the AXE-N project collapsed a decision was made to “restart” the project using Erlang. This project eventually resulted in the development of the AXD301 switch.”
“During the period 1996–1997 a three-person group (myself, Magnus Fröberg and Martin Björklund) redesigned and implemented the OTP core libraries.”
“1998: Ericsson delivered the first AXD301. The AXD301 is the subject of one of our case studies in Chapter 8. At the time of writing (2003) the AXD301 has over 1.7 million lines of Erlang code which probably makes it the largest system ever to be written in a functional style of programming.”
[1]: http://www.erlang.org/download/armstrong_thesis_2003.pdf
XenSource/Citrix is another great example[1]:
“In 2002, members of Cambridge University released the open source Xen project to provide free high-performance virtualization technology for the masses.”
“In 2004, the team founded the company XenSource and began developing the enterprise-level distributed management software that would make virtualization easy and form the backbone of their products in the years to come. A team of thirty dedicated programmers in Palo Alto California began developing the software in C, Python and Ruby.”
“Two years later, the US team had succeeded in burning tens of millions of dollars funding but had failed to produce any product. So XenSource, under new management, took the bold step of replacing their large team of US developers with a team of only four British OCaml developers. Within months, all of the Python and Ruby was replaced, both reliability and performance were dramatically improved and the company shipped their first product. One year later, XenSource sold to Citrix for $500M.”
[1]: http://ocamlnews.blogspot.co.uk/2008/11/stunning-slides-abou...
I think it's imperative to question the "reliability and performance were dramatically improved" kinds of statements with quantitative research. It's just that this kind of research is insanely hard.
(Disclosure: I'm definitely on the FP team, but I want do be able to argue objectively and quantitatively for the benefits of my approach.)
“A simplified version of real-world problem was chosen by the Naval Surface Warfare Center (NSWC). This problem, a geometric region server (geo-server) is one component of a much larger system, NSWC’s AEGIS Weapons System (AWS), which NSWC is in the process of redesigning.”
“The participants, each considered an expert programmer in one of the programming languages being tested, was asked to write a fully functional prototype of the geo-server, while keeping track of software development metrics such as development time and lines of code and documentation.”
“The results indicate that the Haskell prototype took significantly less time to develop and was considerably more concise and easier to understand than the corresponding prototypes written in several different imperative languages, including Ada and C++.”
[1]: http://www.cs.yale.edu/publications/techreports/tr1049.pdf
As I said, I'm not sure I buy into the whole design/classification/statistical scheme of the study myself, so YMMV.
Gradual typing that Erlang and Clojure (both excellent languages) introduce is also a tradeoff: you usually want strict static checks on the outer interfaces of your modules, and/or along the most critical chains of computation. So you build it on top of your dynamic language; I've seen such things done in Python, too.
I didn't know about Typed Racket; I suppose it might be a kind of gradual / optional typing somehow simila to what Clojure has.
https://twitter.com/ambrosebs/status/262387983339098113
For more information, see Ambrose Bonnaire-Sergeant' dissertation:
A Practical Optional Type System for Clojure
https://cloud.github.com/downloads/frenchy64/papers/ambrose-...
Go is always "pass by value", and it's true that I've watched developers struggle to grasp the full ramifications of what that means regarding memory usage. But not understanding the subtlety of memory allocation usually means your programs will simply run slower and consume more memory. It does not usually mean that your programs will run incorrectly.
Given that the OP mentions that they find the slower, more expensive execution of racket programs to be an acceptable trade-off, I'm surprised that they have a problem with this.
Personally, I prefer running in a language that allows me to reason about the memory allocation explicitly. I'd only prefer to give that up in favor of a declarative language that could compute the optimal execution for me. Unfortunately that language is a bit of a unicorn for general purpose programming.
"Pass by reference" means that the runtime will convert what looks like an instruction to copy a value (such as a data structure) into an instruction to copy only the address. Go has no such concept. You cannot make a new value that is a "reference" to another value. If you make a new variable that takes a value, that variable allocates a new block of memory the size of that value. Assigning a value to the variable (or passing a value to a function) makes a copy of the value into the new memory address. You can make a "reference" only by explicitly making a pointer and copying the address of another object.
"Pass by reference" languages treat everything as a pointer by default, forcing you to make a copy operation when you do not want this behavior. This may seem like an equivalent programming model, and possibly simpler because this pointer business if confusing at first. However, basic concepts such as a call stack or an array of values can no longer be expressed easily, because with "pass by reference" languages you have removed the concept of a value from the language. So pass-by-reference languages can lead to confusion in large programs, even if they seem simpler at first.
Basically, go is "pass by value" because the language forces you to always be explicit about when you are copying an entire value, and when you are only copying a pointer.
One of the major advantages of Go is that it is easy to learn for existing programmers as there are very few different abstractions/features.
Yet plenty of companies are now requiring prior experience in Go, erasing most of the benefits of using Go.
How to Design Programs, Second Edition
> P.S. As noted in [link], Racket programs build and run much slower than Go programs.
[1] https://groups.google.com/forum/m/#!topic/racket-users/LLB6o...
[1] http://planet.racket-lang.org/
That said, Go -> Racket is a pretty big jump. Even though I think Go is terrible, I can at least take the time to see the problems it's solving and offer comparable languages. I suggest Rust as a Go replacement.
Don't get me wrong, Racket is pretty good. It's not the Lisp I would pick (I really like Gambit Scheme) but it's at least a Lisp. But a high-level language like Racket isn't really comparable to Go. They're just in different spaces.
There are plenty of problems where one might consider using Go or Rust. The same cannot be said of Go and Racket, or Rust and Racket. I wouldn't consider using Racket for a situation where I need high performance or low memory usage--the numbers just don't work. Likewise I wouldn't look at Go or Rust for building a data-presentation type webapp.
It certainly seems like the more lower-hanging fruit than what the usual advice for getting a fast programming language is - make memory management explicit/manual (though it seems that if you have pervasive manual memory management, you end up with a clear and explicit distinction between values and pointers to values anyway).
Sending email
#lang racket ; Sending email from racket
(require net/sendmail)
(sleep (* (- (* 60 4) 15) 60)) ; 4h - 15m
(send-mail-message
(getenv "EMAIL") "Parking meter alert!"
(list (getenv "EMAIL")) null null
'("Time to go out and move your car."))
> "To run the example, install Racket, start DrRacket, paste the example program into the top area in DrRacket, and click the Run button. Alternatively, save the program to a file and run racket on the file."
That section of the landing page is meant for people who have not been exposed to Racket before. It is meant to sell those people on the expressiveness/power of the language. The explain button is meant to explain exactly what that code snippet is meant to be demonstrating. Very few of those seem to touch on syntax at all.
It seems insane to me that somebody could spin user-consciousness on a language's website as as indicative of a low-quality language.
Without trying to be insulting, I find Racket aesthetically unappealing.