7 ms·

I think the important insight from these articles is not which language the author ends up using (OCaml[1]), but rather which languages he's managed to rule out

by tikhonj 13y ago

I think the important insight from these articles is not which language the author ends up using (OCaml[1]), but rather which languages he's managed to rule out by now. In particular, I think it's good advice to avoid both ATS (however much I like dependent types) and Go, both for completely different reasons. You probably wouldn't want to use Rust in the short term either. [1]: http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/ http://roscidus.com/blog/blog/2013/09/28/ocaml-objects/ ATS makes everything more difficult than it's worth except for some very specific use cases. Unlike some of the other languages like Haskell and OCaml, I don't think this is just because it's different; rather, it's because ATS is simply so much more demanding. It gives you extremely solid static guarantees and high performance, but it's a tool that really sacrifices expressiveness and programmability to get there. Haskell and OCaml may be difficult to learn, but ATS is actually difficult to use--a very different concept. Go, on the other hand, is neither difficult to learn nor difficult to use. But, more generally, Go has very little to commend itself and--compared to the other options--quite a few shortcomings. If you're willing to put in a little bit of effort to learn something new, there are a whole bunch of options which are simply better. And you should be willing to put in the effort: your programming language is your single most important tool; it affects not only how you write your code and how you maintain it but even how you think. So it seems extremely shortsighted to choose a language because it's easy to learn and similar to what you already know! Rust is awesome, but it's simply not ready yet. This is widely acknowledged by everyone in the project, and is part of their policy of open development. Once it is ready, it will be a very good choice for certain domains.

pron 13y ago
I think you may be overestimating the importance of the programming language over the whole programming environment. I think it is the programming environment that is the most important tool – not just the language. There are often many requirements that might lead you to choose a possibly inferior language because it lives in an altogether superior environment for your needs. I have been writing large, server side software for many years. These are long-running applications that require superb performance as well as first-class monitoring tools. So, for me, one requirement for a language is that it runs on the JVM. The JVM gives you superb performance as well as unparalleled monitoring tools (made even better by the inclusion of the flight-recorder and Java Mission Control in the latest version of the JVM); you also get a vast ecosystem with a huge selection of very high quality libraries (and some other important features like dynamic linking) – all that before you even choose a particular language. You can also buy commercial support for every single component you're using if you need it. On the other hand, if you're writing a command-line tool that needs a very fast startup time, or if your RAM is very constrained, then the JVM might be a bad choice for you, which would rule out the JVM languages no matter how good they are. My point is that there are more important issues to consider than the mere merits of the language itself. Also, you're putting a lot of emphasis on expressivity, while downplaying the importance of a short learning curve. I think the two are of similar importance. It's been my experience that programs written in some of the more expressive languages are actually harder to maintain than code written in the easy-to-learn ones. The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code. The easier-to-learn languages usually work at a lower level of abstraction, which can sometimes be easier for others to follow because its a well-understood common denominator. Now, I'm not saying that worse is better, or that more "primitive" languages are better, or even that one should pick them over more expressive ones. I'm just saying that, especially when working in a large team or writing code that would need to be maintained for a long time, there are other issues to consider.
- kazagistar 13y ago
  Agreed. For example, if your environment is Google App Engine, your choices are more limited, and Go suddenly becomes a very attractive performance option.
- fauigerzigerk 13y ago
  >The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code. I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less abstraction, even if it leads to more verbose code. That's the whole secret of Java. I've been implementing a small part of my current project in Go and it has similar benefits. That said, when working alone or with one or two others, I feel kind of dumb repeating some things over and over at the same level of abstraction. There are lots of things like this little piece of C++ code that I tried to translate into reasonably efficient Go: template<typename V, typename R> R defaulted(const V& val, const R& default_val) { return val == V() ? default_val : val; } I came away scratching my head a little, probably because I'm a Go newbie.
  - pron 13y ago
    As an aside, Go is also "a Java" in the same sense that Clojure is a lisp (similar syntax and concepts, same level of abstraction, same philosophy). In fact, Google seems to be turning out many of these "Javas" lately (Android, Go, Dart). While Java and its variants' appeal at most large organizations is considered by some a sign of their conservatism, Google is anything but when it comes to picking the best tools. Google's fondness of Java is evidence of the merits of the Java philosophy when it comes to maintaining large codebases by large teams. Creating a language that follows this philosophy while still boosting productivity (and maybe providing other benefits as well) is an interesting challenge. I think Go falls short. Kotlin looks interesting.
    - berntb 13y ago
shurcooL 13y ago
> So it seems extremely shortsighted to choose a language because it's easy to learn and similar to what you already know! But the benefits are that many new people will be able to pick it up quickly and easily. Other people's code will be easy to understand and maintain. So it's good for everyone in the long run. Being able to express complicated ideas in simple ways is very valuable. If you think it's an advantage that it'd take someone else years of learning a language before they can understand the code you wrote, Go is not for you. [1] [1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...
- tikhonj 13y ago
  In other words, Go is yet another "lowest common denominator"language,a spiritual successor to Java. If you're not working with the lowest common denominator, Go is not for you.
  - NateDad 13y ago
    That is a huge mischaracterization and borderline flamebait.
    - sanderjd 13y ago
      Not even borderline! "Flamebait" was practically invented for that exact type of comment.
  - pjmlp 13y ago
    Yes, in terms of concepts, Go is pretty much a Java 1 with a native compiler as default implementation. However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language.
    - oscargrouch 13y ago
      >> However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language. Yeah, only that you wont do this sort of things in a memory managed language like Go. They make you think is low level(PR ?), only that it isnt THAT low level ;) Go should be able to switch off the GC, and allow people do to manual memory management if it really want to be that low-level.. Also, a way to take off the runtime, and work as skinny as any C program could.. Only than, you could make real low-level programming like OS, device drivers and the like.. The use cases for Go right now in its current incarnation, are things like: cloud/distributed stuff(against C++), or command line tools (against Python) To make it a contender against C, there's a long road.. and im sure its one route they dont want to go..
Dewie 13y ago
Can you think of some niches/circumstances where ATS might be worth using? EDIT: might it be possible to develop ATS programs that are easily called from other languages? ATS seems to have strong ties to C, so maybe one could call ATS code like one calls C code, or call C code that is a thin wrapper around the ATS code? Then you hopefully could have efficient, statically verified (to a high degree) code that can be use by other languages.
- tikhonj 13y ago
  I've always thought it would be a perfect language for things like aerospace. NASA, for example, uses unsafe languages like C and compensates for that with extremely rigorous processes. Of course, this means that it takes forever to get anything done. I can't help thinking that using a better tool like ATS would actually increase productivity without compensating safety. If anything, the types would provide an extra sanity check! Of course, just using ATS won't be enough--most of the existing checks and reviews will still be necessary, but I do think it would be some improvement.
  - luikore 13y ago
    If the mission is critical, choosing programmers matters more that choosing languages. If ATS is hard to use, then it's the right choice because the users who mastered such difficult technique must be the smartest guys...
    - oscargrouch 13y ago
      Or the dumbest, because you dont pick something that is more difficult than its need to be.. well designed languages should help you to focus on the problem domain with little effort possible.. not on the language itself and its caveats.. Languages, as means to create programs that express some sort of logic, must get out of your way.. So i dont think its smart to pick a language because its hard, unless its for create new sorts of mind games and puzzles, and not by the sake of the final objective that is coding itself.. to create programs
NateDad 13y ago
You didn't really say why you think Go is a bad choice. I think there are a lot of things Go has going for it, including clarity, productivity, native cross platform support, and a best of both worlds static typing system with implicit interfaces.
- steveklabnik 13y ago
  > best of both worlds I'm just curious, how much time have you spent with a really strongly statically typed language like Haskell or OCaML?
  - chimeracoder 13y ago
    I've done a decent amount of work in both - I've written a compiler in OCaml and a few applications in Haskell. I do find Go to have the "best of both worlds" when it comes to the type system (ignoring all other features of the languages). As you know, one of the advantages of writing in dynamic languages like Ruby and Python is that you don't have to think much before writing down the first few lines of (working, runnable) code. This makes it really easy to sit down at a keyboard and bang out a prototype, or even a one-off utility script. With Haskell, I have to spend a lot of time thinking up-front about how to design my types, because the arrangement of the datatypes largely determines the functionality of your program. The upside is that, once you've sketched out what you need your types to look like in Haskell, the entire structure of your application has essentially been stubbed out - you simply need to fill in the gaps. This is really nice when making incredibly polymorphic functions - as has been pointed out, you can implement an entire Haskell library without understanding anything about the logic, operating solely off of the type annotations[0]. The downside is that it takes longer to get those first few lines of (working, runnable) code down. Maybe that's not a big loss, or maybe it is. But Go does provide a lot more type safety than any of C or Java (and certainly a lot more than any dynamic language than Ruby or Python). I'm a functional programmer at heart, and given my druthers, I'd probably prefer a little more type safety in Go, rather than less. But having written a lot of Go over the last year, I don't find myself commonly running into the sorts of errors that a stronger type system would have prevented. In short, (IMHO), the biggest additional benefit to strengthening a type system like Go's to resemble Haskell's would be in how it forces you to change the code-formulating process, not in how it prevents more errors. Unfortunately, this is also the biggest drawback to strengthening the type system - it means one can no longer use the same programming workflow that one uses for Python, Ruby, Java, etc. [0] http://r6.ca/blog/20120708T122219Z.html http://r6.ca/blog/20120708T122219Z.html
NateDad 13y ago
You didn't really say why you think Go is a bad choice. I think there are a lot of things Go has going for it, including clarity, productivity, native cross platform support, and a best of both worlds static typing system with implicit interfaces.
burntsushi 13y ago
> But, more generally, Go has very little to commend itself and--compared to the other options--quite a few shortcomings. By what standard of measure? I personally appreciate the simplicity that Go brings to the table, usually at the cost of features we've come to expect in other programming language environments. Do I miss those features? Sure. But do I like simplicity and straight-forwardness? Definitely. Do I believe there is a way to combine them? I'm not sure. Rust is probably the closest contender. But certainly, languages like Haskell or Java don't do it for me (as frequently as Go does, anyway). What I'm trying to say is that I won't tell you which side of the trade-off you should take in every instance, and maybe you shouldn't either.

by tikhonj 13y ago

pron 13y ago

I think you may be overestimating the importance of the programming language over the whole programming environment. I think it is the programming environment that is the most important tool – not just the language. There are often many requirements that might lead you to choose a possibly inferior language because it lives in an altogether superior environment for your needs. I have been writing large, server side software for many years. These are long-running applications that require superb performance as well as first-class monitoring tools. So, for me, one requirement for a language is that it runs on the JVM. The JVM gives you superb performance as well as unparalleled monitoring tools (made even better by the inclusion of the flight-recorder and Java Mission Control in the latest version of the JVM); you also get a vast ecosystem with a huge selection of very high quality libraries (and some other important features like dynamic linking) – all that before you even choose a particular language. You can also buy commercial support for every single component you're using if you need it. On the other hand, if you're writing a command-line tool that needs a very fast startup time, or if your RAM is very constrained, then the JVM might be a bad choice for you, which would rule out the JVM languages no matter how good they are. My point is that there are more important issues to consider than the mere merits of the language itself. Also, you're putting a lot of emphasis on expressivity, while downplaying the importance of a short learning curve. I think the two are of similar importance. It's been my experience that programs written in some of the more expressive languages are actually harder to maintain than code written in the easy-to-learn ones. The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code. The easier-to-learn languages usually work at a lower level of abstraction, which can sometimes be easier for others to follow because its a well-understood common denominator. Now, I'm not saying that worse is better, or that more "primitive" languages are better, or even that one should pick them over more expressive ones. I'm just saying that, especially when working in a large team or writing code that would need to be maintained for a long time, there are other issues to consider.

kazagistar 13y ago
Agreed. For example, if your environment is Google App Engine, your choices are more limited, and Go suddenly becomes a very attractive performance option.
fauigerzigerk 13y ago
>The reason seems to be that programmers use the expressivity of the former (which seems to be of a particular nature or natures: functional construct, higher-order types, meta-programming) to model their own thought-process, which may be hard to replicate for someone else maintaining the code. I agree with that. Working on code in a large and ever changing team is very difficult, and it seems to benefit from less abstraction, even if it leads to more verbose code. That's the whole secret of Java. I've been implementing a small part of my current project in Go and it has similar benefits. That said, when working alone or with one or two others, I feel kind of dumb repeating some things over and over at the same level of abstraction. There are lots of things like this little piece of C++ code that I tried to translate into reasonably efficient Go: template<typename V, typename R> R defaulted(const V& val, const R& default_val) { return val == V() ? default_val : val; } I came away scratching my head a little, probably because I'm a Go newbie.
- pron 13y ago
  As an aside, Go is also "a Java" in the same sense that Clojure is a lisp (similar syntax and concepts, same level of abstraction, same philosophy). In fact, Google seems to be turning out many of these "Javas" lately (Android, Go, Dart). While Java and its variants' appeal at most large organizations is considered by some a sign of their conservatism, Google is anything but when it comes to picking the best tools. Google's fondness of Java is evidence of the merits of the Java philosophy when it comes to maintaining large codebases by large teams. Creating a language that follows this philosophy while still boosting productivity (and maybe providing other benefits as well) is an interesting challenge. I think Go falls short. Kotlin looks interesting.
  - berntb 13y ago

shurcooL 13y ago

> So it seems extremely shortsighted to choose a language because it's easy to learn and similar to what you already know! But the benefits are that many new people will be able to pick it up quickly and easily. Other people's code will be easy to understand and maintain. So it's good for everyone in the long run. Being able to express complicated ideas in simple ways is very valuable. If you think it's an advantage that it'd take someone else years of learning a language before they can understand the code you wrote, Go is not for you. [1] [1] http://commandcenter.blogspot.com.au/2012/06/less-is-exponentially-more.html http://commandcenter.blogspot.com.au/2012/06/less-is-exponen...

tikhonj 13y ago
In other words, Go is yet another "lowest common denominator"language,a spiritual successor to Java. If you're not working with the lowest common denominator, Go is not for you.
- NateDad 13y ago
  That is a huge mischaracterization and borderline flamebait.
  - sanderjd 13y ago
    Not even borderline! "Flamebait" was practically invented for that exact type of comment.
- pjmlp 13y ago
  Yes, in terms of concepts, Go is pretty much a Java 1 with a native compiler as default implementation. However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language.
  - oscargrouch 13y ago
    >> However, it may still be quite good to move developers not doing kernel/drivers/embedded stuff, away from C into a more secure language. Yeah, only that you wont do this sort of things in a memory managed language like Go. They make you think is low level(PR ?), only that it isnt THAT low level ;) Go should be able to switch off the GC, and allow people do to manual memory management if it really want to be that low-level.. Also, a way to take off the runtime, and work as skinny as any C program could.. Only than, you could make real low-level programming like OS, device drivers and the like.. The use cases for Go right now in its current incarnation, are things like: cloud/distributed stuff(against C++), or command line tools (against Python) To make it a contender against C, there's a long road.. and im sure its one route they dont want to go..

Dewie 13y ago

Can you think of some niches/circumstances where ATS might be worth using? EDIT: might it be possible to develop ATS programs that are easily called from other languages? ATS seems to have strong ties to C, so maybe one could call ATS code like one calls C code, or call C code that is a thin wrapper around the ATS code? Then you hopefully could have efficient, statically verified (to a high degree) code that can be use by other languages.

tikhonj 13y ago
I've always thought it would be a perfect language for things like aerospace. NASA, for example, uses unsafe languages like C and compensates for that with extremely rigorous processes. Of course, this means that it takes forever to get anything done. I can't help thinking that using a better tool like ATS would actually increase productivity without compensating safety. If anything, the types would provide an extra sanity check! Of course, just using ATS won't be enough--most of the existing checks and reviews will still be necessary, but I do think it would be some improvement.
- luikore 13y ago
  If the mission is critical, choosing programmers matters more that choosing languages. If ATS is hard to use, then it's the right choice because the users who mastered such difficult technique must be the smartest guys...
  - oscargrouch 13y ago
    Or the dumbest, because you dont pick something that is more difficult than its need to be.. well designed languages should help you to focus on the problem domain with little effort possible.. not on the language itself and its caveats.. Languages, as means to create programs that express some sort of logic, must get out of your way.. So i dont think its smart to pick a language because its hard, unless its for create new sorts of mind games and puzzles, and not by the sake of the final objective that is coding itself.. to create programs

NateDad 13y ago

You didn't really say why you think Go is a bad choice. I think there are a lot of things Go has going for it, including clarity, productivity, native cross platform support, and a best of both worlds static typing system with implicit interfaces.

steveklabnik 13y ago
> best of both worlds I'm just curious, how much time have you spent with a really strongly statically typed language like Haskell or OCaML?
- chimeracoder 13y ago
  I've done a decent amount of work in both - I've written a compiler in OCaml and a few applications in Haskell. I do find Go to have the "best of both worlds" when it comes to the type system (ignoring all other features of the languages). As you know, one of the advantages of writing in dynamic languages like Ruby and Python is that you don't have to think much before writing down the first few lines of (working, runnable) code. This makes it really easy to sit down at a keyboard and bang out a prototype, or even a one-off utility script. With Haskell, I have to spend a lot of time thinking up-front about how to design my types, because the arrangement of the datatypes largely determines the functionality of your program. The upside is that, once you've sketched out what you need your types to look like in Haskell, the entire structure of your application has essentially been stubbed out - you simply need to fill in the gaps. This is really nice when making incredibly polymorphic functions - as has been pointed out, you can implement an entire Haskell library without understanding anything about the logic, operating solely off of the type annotations[0]. The downside is that it takes longer to get those first few lines of (working, runnable) code down. Maybe that's not a big loss, or maybe it is. But Go does provide a lot more type safety than any of C or Java (and certainly a lot more than any dynamic language than Ruby or Python). I'm a functional programmer at heart, and given my druthers, I'd probably prefer a little more type safety in Go, rather than less. But having written a lot of Go over the last year, I don't find myself commonly running into the sorts of errors that a stronger type system would have prevented. In short, (IMHO), the biggest additional benefit to strengthening a type system like Go's to resemble Haskell's would be in how it forces you to change the code-formulating process, not in how it prevents more errors. Unfortunately, this is also the biggest drawback to strengthening the type system - it means one can no longer use the same programming workflow that one uses for Python, Ruby, Java, etc. [0] http://r6.ca/blog/20120708T122219Z.html http://r6.ca/blog/20120708T122219Z.html

NateDad 13y ago

burntsushi 13y ago

> But, more generally, Go has very little to commend itself and--compared to the other options--quite a few shortcomings. By what standard of measure? I personally appreciate the simplicity that Go brings to the table, usually at the cost of features we've come to expect in other programming language environments. Do I miss those features? Sure. But do I like simplicity and straight-forwardness? Definitely. Do I believe there is a way to combine them? I'm not sure. Rust is probably the closest contender. But certainly, languages like Haskell or Java don't do it for me (as frequently as Go does, anyway). What I'm trying to say is that I won't tell you which side of the trade-off you should take in every instance, and maybe you shouldn't either.