When you talk about Go I think you should start with C.
One of my professors used to tell us, that C was built by people who wanted to use it and didn't care about academic style.
In many ways Go is just the next step of C. C did not have object orientation and even passing functions around was kinda hard. While C++ tried to bring object orientation to C (total failure) Go decided to keep the core values of C and instead improved the rough features (e.g. easier binding of functions to structures, faster build times).
By making it easier to pass around functions Go enables functional programming styles, but at its core, it is still just an improved C. The only revolution within Go (as a language) is the concurrency and channel concept and I think that was taken from some functional language (not sure).
I really like Go, because it just feels right. It might not be as clean as Smalltalk or Lisp, but it has data structures and functions, teaches you how important interfaces are and lets you build highly concurrent applications with ease. In addition, it brings a nice set of tools which integrate well into a shell driven workflow.
After all, the whole thing should not surprise anybody as Ken Thompson[1] was part of the Team which invented Go.
I'm not a Go programmer, but I have a lot of respect for it.
If you're wondering "why Go"? Think of it as a modern version of C, at a slightly higher level, developed by the same people for slightly higher-level tasks. They made C for low-level stuff, and then picked up with Go for higher-level stuff. It's like C+.
C has been very successful in part because it's so simple in certain respects (although not in others) and I think Go will be successful for many of the same reasons. Go does what it does very well.
I think Rust is actually a great choice for something like Tor, but I wouldn't use Rust for some of the things I'd use Go for.
Go doesn't have faster build times than C. Rather, it has a de facto single implementation that's fast because it doesn't do the same level of optimization that modern C compilers do.
The one improvement over C related to build time in Go is that you don't need include files. Granted, that's a big one. But modern C compilers make header parsing extremely fast.
I am now sure if I can put it into words, but here are some comparisons:
- In Scheme/Lisp, you write the function name before the opening parenthesis. In languages related to C, you write the function name before. For me, the second one feels better. In general, I like the C syntax pretty much.
- In C++ you easily provoke very long compiler error messages. Go compiler messages are much shorter and much more to the point. I like the ones where I do not have to search the real error in the error messages themselves. (I heard Rust compiler error messages are even better).
- To run a go program on a computer you just need the binary, done. To compile a program you need the compiler which comes with a few cli tools, done. For java, you have to decide if you need the JRE or JDK, agree to some license before being allowed to download it from their website. In addition, you have to place the jre on every computer which should run your program. I like the simple way.
- When I design a program there are a few parts. One is the Entity Relationship Model. Sometimes I think about it as something that has to be saved to an SQL database, sometimes as an object oriented inheritance hierarchy. For both there are reasons, but even simpler is it to just think about it as a struct or JSON. This fits pretty good for designing JS and go apps.
- When I write bash script I know what a slow language feels like. I know there are faster languages than go (e.g. fortran), but I am also aware that much of the performance is in the hand of the developer (e.g. memory management). When I write go programs I feel like my efforts to make the program efficient are worth my time and the tools support me while doing so.
- Last but not least go supports then functional programming style when needed. I like that. Sometimes I miss object orientation a little, but that mostly happens when I forget what interfaces are for. And while I truly respect Alan Kay I think object orientation has been overused/misused enough, so that its ok for me, that go didn't build it into the language.
So maybe I just like 'simple'. I am sure, that for every example I listed you can find a language which does even better than go, but I think it becomes harder when you consider all examples together. Nonetheless, the list is far from complete, I just tried to write down out of my head, what I like about go.
I hope you realize that you are arguing against an explicitly subjective statement.
Nevertheless, please elaborate. What do YOU think is the difference here between feeling and looking? Do you mean that your favorite editor (or the majority of editors) better supports outside parenthesis?
Even original Vi from AT&T Unix (never mind Vim) better supports outside parentheses:
If the cursor is here
(foo bar)
^
I can cut the whole thing using just d%: combine d)eletion with the % cursor movement (jump to opposite parenthesis). Then you can paste it elsewhere with p.
That's just a crap editor for sysadmin tasks I wouldn't use for development.
If the syntax is:
foo(bar)
^
then we jump only over the argument list, not the whole expression.
Another thing is the damned comma disesase in f(x, y) languages. Say we are in Vi:
(foo abc def ghi)
^
We want to swap the last two parameters. Easy: type deep. Done! d)elete to e)nd of word, go to e)nd of word, p)aste.
Now try it with
foo(abc, def, ghi)
^
Annoying!
Imagine if your operating system shell forced you to use commas between command line arguments. Nobody would use such an idiotic thing. Why do we put up with languages that do that?
$ ls, -l, *.foo # just kill me now
Move second argument to third position: "parens outside" together with "no commas between arguments" makes it a breeze:
(foo (a b c) (d e f) (g h i) (j k))
^
Instead of deep we just do d%%p. Done.
(foo (a b c) (g h i) (j k))
^ d%
(foo (a b c) (g h i) (j k))
^ d%%
(foo (a b c) (g h i) (d e f) (j k))
^ d%%p
Thank you very much for your explanation, I see your point.
I think I will still prefer the C style for parenthesis (as I would care more for the LOOK than for the FEEL ;-), but regarding the commas, I agree that skipping them would make the life a easier. I mean besides lisp and bash/shell other languages have done so too (e.g. Smalltalk) and spaces aren't allowed anyway inside parameter names.
> I hope you realize that you are arguing against an explicitly subjective statement.
Yes.
> Nevertheless, please elaborate. What do YOU think is the difference here between feeling and looking? Do you mean that your favorite editor (or the majority of editors) better supports outside parenthesis?
Lisp has a two-level syntax. The first level is the syntax of s-expressions. On top of s-expressions we have the actual Lisp syntax.
S-expressions have a few features:
* it's a data syntax for lists/trees, numbers, characters, symbols, strings, ...
* delimiter surround the data, it is always clear where the expression begins and where it ends
* whitespace is used to delimit the elements
* s-expressions are not sensitive to lines and whitespace
* s-expressions can be automatically formatted by simple rules, according to different widths
* the tree structure is explicit, not implicit. It is visible, based on the s-expression nesting.
For an s-expression editor it makes not much difference to edit a data list like ((berlin germany) (rome italy) (paris france)) or code like (defun collide (object wall) ...) .
The first level of editor support you get for editing s-expressions.
Thus editing on this level FEELS like you manipulate data: create, transpose, delete, list, de-list, flatten, copy, indent, format, ...
That every list has explicit delimiters makes clear where the expression begins, where it ends and what its contents are. The parentheses also serve as 'handles' for the thing. If you use some more advanced Lisp system, the s-expression creates a region and moving the cursor into this region enables context sensitive commands. This is possible in other systems, too. But here the relationship between the s-expression and the region is visually clear: each expression has explicit delimiters, front and end.
So, the first level of Lisp editing is data manipulation. That's a big difference to editing many other languages, where your program is not also a simple data-structure. There you are always on a language level, maybe on a primitive token-scanner level. You can reconstruct the tree structure, but it is not visible, explicit and delimiting like in Lisp. If you refactor a program, you work on the programming level - in Lisp you can work on a plain data level, too. This makes code and data interchangeable and when you work with a Lisp listener (running a read eval print loop), you will work with code as data and the listener helps you: you get support on the language level & the s-expression level on the editor side. But at the same time you can cross the the border into the programming language: you can let Lisp manipulate your program. Thus programming becomes a mix of manipulating text and data. The s-expression syntax helps to make that simple - because of the features above.
A typical example would be writing a macro (Lisp code which transforms code) based on some existing expressions. You would take the expressions, convert them into data, create the transformation code, define the macro. Then you would test the code generator. Thus suddenly from writing code, you switch to writing code-writing-code and the input and output is no longer data, but code as data. Thus while programming you will interact with the code generator. This can be done in many languages, but in Lisp it FEELS different, because you work on s-expressions - easily delimited hierarchical pieces of code as data, which can be transformed by your editor and your underlying Lisp system.
After a while, editing conventional code FEELS less direct. It feels like you manipulate the code with instruments, while a good Lisp system feels direct. That's it direct manipulation of code and data.
A Lisp programming will learn this code manipulation side and then is willing to give up some looks for that. Originally Lisp had a more traditional surface syntax, but it turned out to be more practical to use the s-expression based code representation not only internally, but also using it externally on the display or textual side.
Is there any good starting point to use lisp in the same way as I would use go? I mean I write web servers and command line tools in go. As an editor I use vim.
Some time ago I used DrScheme (now Racket) to write Scheme but I never found it to fit easily into my workflow/use-cases.
So I would I like to use the language with the following workflow (100% terminal):
- write code with vim: vim main.lisp
- simply compile the code to binary: lisp build main.lisp
- execute the compiled program: ./main
I wouldn't propose to do it in Lisp. Batch programming is done better in languages like Go, especially if you are already feeling comfortable with a batch workflow. You can write web servers and command line tools in Lisp, but it would be a huge investment to learn that and it is not clear if it pays back for you.
Essentially for anything slightly complex one would use an interactive programming style and 'only' deliver the application in a batch style.
Racket is more oriented towards batch programming, compared to popular Common Lisp development environments.
You can edit a Lisp program strictly in files, and run a build step to produce a clean image which is tested, using a REPL just as a debugger, to "go in" and find out what is wrong.
Ok, so the definition of batch programming means that debugging is only allowed by print statements (or other side effects from which we infer what happened in an actual run of the program and work backwards). For instance, using a breakpoint debugger on C isn't batch.
Still, Lisp is good for that. I've debugged Lisp programs with print statements and it was at least as good an experience as debugging programs in other languages using print statements.
For instance, if we compare to C, C has no trace, and generally no easy way to wrap any function with a wrapper that takes the arguments. Ecosystems built around C, like the Linux kernel, have developed things like that: Linux has a function tracing thing in it (more than one, I think).
One of my professors used to tell us, that C was built by people who wanted to use it and didn't care about academic style.
In many ways Go is just the next step of C. C did not have object orientation and even passing functions around was kinda hard. While C++ tried to bring object orientation to C (total failure) Go decided to keep the core values of C and instead improved the rough features (e.g. easier binding of functions to structures, faster build times).
By making it easier to pass around functions Go enables functional programming styles, but at its core, it is still just an improved C. The only revolution within Go (as a language) is the concurrency and channel concept and I think that was taken from some functional language (not sure).
I really like Go, because it just feels right. It might not be as clean as Smalltalk or Lisp, but it has data structures and functions, teaches you how important interfaces are and lets you build highly concurrent applications with ease. In addition, it brings a nice set of tools which integrate well into a shell driven workflow.
After all, the whole thing should not surprise anybody as Ken Thompson[1] was part of the Team which invented Go.
[1] https://en.wikipedia.org/wiki/Ken_Thompson