4 ms·
There is - Go is a terribly fun language in the domains that it's good at. Like some other fun languages, if you take the time to get into 'the go way' of doin
by dgacmu 11y ago
There is - Go is a terribly fun language in the domains that it's good at. Like some other fun languages, if you take the time to get into 'the go way' of doing things, you'll get a new perspective on some kinds of programming that'll help you in general.
Go is drastically less bloated than Java. Stupidly fast compilation and running lets you use it almost (but not quite) like you might Python for some things.
A recent example for me: Writing a quick & dirty server that talked to a device that was spouting a stupid binary serial-over-TCP protocol. Goroutines made handling the bidirectional communication trivial, and go being a bit on the low-level side makes it easy to cope with binary protocols without worrying that your chars and bytes and unicode characters are getting all mixed up. You can do all this in Java - but it's so clean in Go.
My current playbook looks something like:
Network servers: Go. Go go go and more go. Things that talk to lots of other things and involve interesting communication are a natural match. I rewrote my pi searcher in Go a year or so ago, for example - http://da-data.blogspot.com/2013/05/improving-pi-searchers-speed-by-moving.html http://da-data.blogspot.com/2013/05/improving-pi-searchers-s... - and this year was able to run the thing through Pi day on only a single (larger) AWS instance. Woot. We use it for research, such as writing Paxos derivates. Great stuff.
Go's also pretty amazing for little utilities if you want them to be faster than Python -- particularly if you want the launch time to be faster than Python. Which can be great for utilities you build to use in loops in shell scripts, etc. The fact that they're purely statically linked makes a lot of otherwise hairy cross-platform nastiness just go away.
The fact that it's statically typed and includes great, easy-to-use parsing support for itself also makes it much better for refactoring than Python is. The tools aren't as mature as those for Java, but the language is well-designed to support it (think "go fix" -- which can automatically port forward much old code to newer versions of the language). The tooling for this kind of thing is great for Java, good for C and Go, and absolutely horrible for Python. As a consequence, Go can more roubustly handle being worked on in very large codebases and teams. What would be a slightly scary regexp replace in Python can be a much more syntactically and semantically safe change in Go (at the cost of a little more writing of the replacement code).
Tensorflow (and most things numeric): Python. Because it was pre-decided. :) But, more seriously, Go's lack of generics hurt it here (you can't express matrix/tensor manipulation natively, and saying A * x is about as right as it gets when you're talking math). The ML community has adopted Python to a pretty strong degree, particularly because of NumPy, and so it fits in really well there. I still get grumpy about it -- I've lost count of the number of times I've messed things up that static checking could have caught, requiring quite a long time for tests/running it to finally do so. But I do like Python, to the point of:
Beginners: Python. I pushed hard to switch CMU's intro course for non-majors to it, and succeeded with a lot of help from others. It's awesome seeing what a bunch of motivated, smart first-years can accomplish in Python in one semester. Damn. And they can 'take it with them' -- scientists/engineers and numpy are a pretty good match, for example.
Fast as hell: C++, light on the ++, heavy on the C. A lot of our research code is very low-level. I'm still finding Rust incredibly annoying, but I may just be a slow learner, and it's on my list to take a really serious look at it after I'm back from Google.
(You'll note that nothing that I do involves a UI. I'm a unix & systems person through and through, which helps explain the utter lack of Java, C#, Swift, etc. in my life.)
- austinz 11y agoIt's possible to write non-GUI command-line Swift programs that run on Linux (and certain other platforms). In terms of 'close to the metal', Swift is probably much closer to Rust or C++ than C# or Java, and is at least at the same level as Go.
- SiVal 11y agoCan this headless Swift be compiled to a simple, self-contained, statically-linked, no-runtime-required binary like Go? (A real question, not some sort of advocacy.)
- pjmlp 11y agoAny AOT compiler to native code allows for self-contained, statically-linked, no-runtime-required binaries. There is nothing special in Go about it.
- fauigerzigerk 11y agoIs your 'close to the metal' claim based on any concrete experience with Swift? I like Swift as a language but I found its String/unicode support way too slow for the text processing stuff I do on the server side. I also tried using arrays instead, but in my text parsing micro benchmarks Swift is always four times slower than Go, Java, C++ and even two times slower than JavaScript/V8. I don't really see a reason why this should be the case, so I hope it will improve over time. But using mandatory reference counting does limit the sort of tasks for which Swift will ultimately be suitable. I wouldn't put it in the same category as C++ and Rust for that reason.
- austinz 11y agoMy (highly speculative) guess is that your String issues were due to either/both: - Swift performance issues involving working with strings, some of which have been ameliorated by later releases; - 'Hidden' bridging between NSString and String, which can be expensive and might have something to do with some of String's APIs actually being Foundation APIs in disguise. There is much to be done with regards to Swift performance, though. If you have any sample benchmarks I would be interested in writing/running them myself, just for personal edification. In terms of 'close to the metal', I freely admit this is a ill-defined term I am using for my own benefit. Swift code doesn't execute on something akin to the JVM or CLR; it still requires a heavier runtime than (e.g.) Rust. It is AOT-compiled to machine code. (But then again, this is possible to some degree for Java as far as I can tell, although it is certainly not the most popular way to run Java code.) I agree that mandatory RC for classes and boxed types makes Swift impractical for a certain definition of 'systems software' typically written in C++ and occasionally Rust. For a different definition, one that encompasses the garbage-collected Go, Swift is theoretically suitable. The language designer has mentioned that he would personally like to see Swift gain some form of borrowing/lifetimes, although even if that did happen Swift would not get it for years to come.