6 ms·

Why Go for decision trees? (2013)

36 points by rgbrgb 11y ago

jerf 11y ago
It sometimes raises eyebrows, but this sort of post is why I classify Go as a modern take on a scripting language. With GC and interfaces standing in for duck typing, it's got a lot of the good characteristics of the scripting languages, but it's also got just enough low-level performance stuff going on (real structs, real arrays, the slices the blog post mentions) that rather than taking the 50-100x hit you can easily take with Python you can take merely a 2-3x hit over C, and you'll write the code significantly more quickly than C or Rust too. The result is that where you might not need something that allows you, and correspondingly, requires you to deal with all the issues of memory management or ownership that C, C++, or something like Rust may, but you might not be able to afford Python's performance issues or the general difficulty the scripting languages have with true concurrency and multicore, you have a viable choice in Go. Go's not alone... it seems to me there's many languages taking a swing at this niche now. All the best to all of them... I love me the flexibility of Python or Ruby sometimes and may not need total system-level control but I can't always afford the resource gluttony of the older-school scripting languages.
- Dewie3 11y ago
  This development/trend seems to show that the value of the "dynamicity" of scripting languages have perhaps been overrated. There seems to be a set of abstractions with reasonably/very good mechanical sympathy that are both easy to understand and use, and that doesn't constrain you that much with regards to factorability and coding iteration.
  - LanceH 11y ago
    For me it seems to be hitting that niche of "one off" programs that have a nack for sticking around forever. Once I figure out something needs to become software and not be truly one off, then I find myself reaching for Go.
  - pekk 11y ago
    If there was a time when dynamic typing was overrated, then it is certainly possible that this time is a time when static typing is overrated.
    - frik 11y ago
      :) Another kind of typing system is a mixture of dynamic and static typing named: gradual typing (PHP/Hack, JS, ActionScript, etc.) http://en.wikipedia.org/wiki/Gradual_typing http://en.wikipedia.org/wiki/Gradual_typing There is also the difference between strong and weak typing: http://en.wikipedia.org/wiki/Strong_and_weak_typing http://en.wikipedia.org/wiki/Strong_and_weak_typing It's certainly possible that there was a time when virtual machine based language implementations where overrated.
    - Dewie3 11y ago
      I didn't really mean dynamic typing (that's why I wrote "dynamicity" with question mark). To be clearer: the ability for things to change at runtime, i.e. for the programmer to do things like monkey patching. I guess dynamic typing is related to this, at least in the sense that you'll have to give up on some static typing in order to get more flexible dynamic behaviour. And yeah, I realize that Python et. al. is used for real apps, and certainly not just for scripting tasks.
    - jerf 11y ago
      "If there was a time when dynamic typing was overrated, then it is certainly possible that this time is a time when static typing is overrated." I think that's actually a very important aspect of understanding where dynamic typing as a hugely popular thing came from. Today, I favor static typing. However, given a choice of Python or 1990s-C++, I'll take Python. It could be argued that the static typing world needed to be dethroned and be forced to improve itself in the face of the dynamic competition to become what it is today. On the other hand, pretending that "static typing" is the same today as it was 20 years ago is merely the complementary failure that people too bedazzled by static typing 20 years ago and dismissed the oncoming dynamic typing wave made.
  - throwaway1240 11y ago
    The real value of dynamic languages can only be realized in dynamic, image-based, live programming environments like the kind you have with Lisp and Smalltalk. Whether "scripting" languages, as in languages used to write small, one-off programs, or programs to automate systems administration tasks or to glue other programs together, benefit from that type of power is debatable, but Ruby, Python, and Perl have never been particularly good representatives of the dynamic language paradigm as a whole, either conceptually or implementation-wise.
    - frik 11y ago
      > like the kind you have with Lisp and Smalltalk ...and PHP and JavaScript
    - Dewie3 11y ago
      There's a reason that I wrote 'scripting languages' instead of dynamic languages. Python, Ruby etc. seem to be more regarded as scripting languages than Lisp and Smalltalk.
- doomrobo 11y ago
  For a scripting language, Go is very strict with compile-time errors that could just as well be warnings. Unused variables, unused imports, dead code, etc. Other than that, I could see Go as a pretty useful scripting and systems language.
  - desdiv 11y ago
    In case anyone else is wondering why doesn't the Go compiler have error ignore flags for scripting/prototyping purposes: http://weekly.golang.org/doc/faq#unused_variables_and_imports http://weekly.golang.org/doc/faq#unused_variables_and_import...
- aaron-lebo 11y ago
  This middle ground is also why I think Go would be/is a great learning language at colleges or in general. You've got something which has a lot in similar with dynamic languages, doesn't require much to learn Hello World (in comparison to Java), but has higher-level features like GC, first-class functions, etc. You also learn something C-ish in pointers which you might be aware of but not truly know in dynamic langs. Concurrency is only a benefit. It is a really simple language that anyone can learn quickly and then take that knowledge higher level with a Python or even Clojure or Haskell or lower level with a C. Is anyone aware of Go being used as a teaching tool in an academic environment?
- pekk 11y ago
  Another view is that things like GC sacrifice low-level performance stuff (you reference not having total system-level control) while the similarity to languages like C sacrifices some of the good characteristics of scripting languages.
- throwaway1240 11y ago
  All of what you said about performance could just as easily be said for modern implementations of Common Lisps. SBCL, for example, fairs quite well against Go despite being much more dynamic than either Python or Ruby: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=sbcl&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
  - gillianseed 11y ago
    Not as well when we use more than one core: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=sbcl&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
    - deleted 11y ago
      [deleted]
    - pjmlp 11y ago
      I wonder if that would still be the case against commercial Lisp compilers like Allegro Common Lisp.
- bayesianhorse 11y ago
  Using the term "scripting language" for either Go or Python is a complete misnomer. Back in the day, languages called as such where so slow, that there was a feeling that they were used "in lieu" of "real" programming languages. They were there to extend "real" software. Today? Much the opposite. Computing power is almost always cheaper than brain power, and we use C to extend Python rather than the other way around. For that matter, I think Go is great for networked infrastructure, but bad for interfacing with other languages and still significantly harder to learn than Python, Julia and R. That is why I caution on the use of Go in projects which have "scientific" bent to them...
  - NateDad 11y ago
    Go is way easier to learn than Python for real applications. Python might be easier for your first few times playing with a programming language, but the complexity ramps up fast. There are a lot of features in python - classes, decorators, all the __foo__ stuff... I think it's a lot easier to understand all of Go than all of Python. I can't comment on R or Julia, since I haven't used them, but I would doubt they're simpler than Go.
  - jerf 11y ago
    I understand pushing back against the idea that Go is a scripting language. Arguing that Python isn't a "scripting language" is a complete waste of time. That ship sailed at least 5 years ago, if not 15. And Python is still very, very slow, and very difficult to make multicore (if you disagree, compare with Go), and there are plenty of domains where it should not be chosen as a result. Yes, I know about PyPy, but that project's performance characteristics are very strange and certainly isn't "it just speeds up Python code by 10x, all the time"... sometimes it does that, sometimes (rarely) it slows it down, mostly it does something in the middle that certainly doesn't bring Python anywhere near C.
    - bayesianhorse 11y ago
      For me, a scripting language is used to extend a larger more inflexible software project. Like scripting in Office Suites, Blender or similar. Python is growing in popularity, and in the majority of cases it is used as the "primary" language now. That's why "scripting" is a misnomer, even if technically CPython is not compiled to machine language.
mkoryak 11y ago
why go? why is go being so heavily featured on HN lately? reminds me of that effort to ask a ton of R questions on stackoverflow. We should have more stories about languages people actually get paid to use, like java! jk (kind of)
- pekk 11y ago
  Unlike some other languages I won't name this isn't astroturf, a fair number of people are using Go as an alternative to C++ or Java or Node.
- sethammons 11y ago
  i'm paid to write go :)
  - mkoryak 11y ago
    I wonder how many here are in your boat
- bayesianhorse 11y ago
  If you are lurking on hacker news to improve your productivity, I think you're in the wrong place ;-)
- detaro 11y ago
  If you think so, submit interesting posts about those ;) New and shiny always has an edge in getting interest
- NateDad 11y ago
  I've been paid to write go for the last two years :). From the articles I've read, a lot of companies are starting to use go for part of their systems.
micro_cam 11y ago
Hah, I wrote this article ages ago when we were experimenting with a data science blog. Surprised to see it pop up here. I think most of it still holds true but we did do some benchmarks on public data and the implementation is competitive with or faster then other implementations including scikit-learn's cython implementation which wins a lot of benchmarks. Code and some benchmark results in the README are here: https://github.com/ryanbressler/CloudForest https://github.com/ryanbressler/CloudForest
- rgbrgb 11y ago
  I submitted it because I'm playing with CloudForest right now. I really appreciate your work, it's fun to use. I'm co-founder of a digital real estate brokerage[1] and as a weekend hack, I'm using CloudForest to predict sale prices for residential real estate using data from the MLS. A lot of the predictions are really good with a few that are terrible (like double the list price, which is a feature). Any way to get a certainty value for each prediction? Perhaps I could look at the variance of values from each tree? I'm kind of a noob with decision trees so I'm probably totally off base but maybe that question makes sense. :) [1]: https://www.openlistings.co/ https://www.openlistings.co/ (YC W15)
  - pigscantfly 11y ago
    Yes, you should be able to estimate a confidence interval by looking at the distribution of votes from each tree. [1] http://arxiv.org/pdf/1311.4555.pdf http://arxiv.org/pdf/1311.4555.pdf
chenzhekl 11y ago
We need generics!
pkroll 11y ago
Don't know if the link was at a different place earlier, but it's now at: http://datascience.systemsbiology.net/data-notebook/ http://datascience.systemsbiology.net/data-notebook/
- dang 11y ago
  Thanks, we've updated the URL to that.

36 points by rgbrgb 11y ago

jerf 11y ago

It sometimes raises eyebrows, but this sort of post is why I classify Go as a modern take on a scripting language. With GC and interfaces standing in for duck typing, it's got a lot of the good characteristics of the scripting languages, but it's also got just enough low-level performance stuff going on (real structs, real arrays, the slices the blog post mentions) that rather than taking the 50-100x hit you can easily take with Python you can take merely a 2-3x hit over C, and you'll write the code significantly more quickly than C or Rust too. The result is that where you might not need something that allows you, and correspondingly, requires you to deal with all the issues of memory management or ownership that C, C++, or something like Rust may, but you might not be able to afford Python's performance issues or the general difficulty the scripting languages have with true concurrency and multicore, you have a viable choice in Go. Go's not alone... it seems to me there's many languages taking a swing at this niche now. All the best to all of them... I love me the flexibility of Python or Ruby sometimes and may not need total system-level control but I can't always afford the resource gluttony of the older-school scripting languages.

Dewie3 11y ago
This development/trend seems to show that the value of the "dynamicity" of scripting languages have perhaps been overrated. There seems to be a set of abstractions with reasonably/very good mechanical sympathy that are both easy to understand and use, and that doesn't constrain you that much with regards to factorability and coding iteration.
- LanceH 11y ago
  For me it seems to be hitting that niche of "one off" programs that have a nack for sticking around forever. Once I figure out something needs to become software and not be truly one off, then I find myself reaching for Go.
- pekk 11y ago
  If there was a time when dynamic typing was overrated, then it is certainly possible that this time is a time when static typing is overrated.
  - frik 11y ago
    :) Another kind of typing system is a mixture of dynamic and static typing named: gradual typing (PHP/Hack, JS, ActionScript, etc.) http://en.wikipedia.org/wiki/Gradual_typing http://en.wikipedia.org/wiki/Gradual_typing There is also the difference between strong and weak typing: http://en.wikipedia.org/wiki/Strong_and_weak_typing http://en.wikipedia.org/wiki/Strong_and_weak_typing It's certainly possible that there was a time when virtual machine based language implementations where overrated.
  - Dewie3 11y ago
    I didn't really mean dynamic typing (that's why I wrote "dynamicity" with question mark). To be clearer: the ability for things to change at runtime, i.e. for the programmer to do things like monkey patching. I guess dynamic typing is related to this, at least in the sense that you'll have to give up on some static typing in order to get more flexible dynamic behaviour. And yeah, I realize that Python et. al. is used for real apps, and certainly not just for scripting tasks.
  - jerf 11y ago
    "If there was a time when dynamic typing was overrated, then it is certainly possible that this time is a time when static typing is overrated." I think that's actually a very important aspect of understanding where dynamic typing as a hugely popular thing came from. Today, I favor static typing. However, given a choice of Python or 1990s-C++, I'll take Python. It could be argued that the static typing world needed to be dethroned and be forced to improve itself in the face of the dynamic competition to become what it is today. On the other hand, pretending that "static typing" is the same today as it was 20 years ago is merely the complementary failure that people too bedazzled by static typing 20 years ago and dismissed the oncoming dynamic typing wave made.
- throwaway1240 11y ago
  The real value of dynamic languages can only be realized in dynamic, image-based, live programming environments like the kind you have with Lisp and Smalltalk. Whether "scripting" languages, as in languages used to write small, one-off programs, or programs to automate systems administration tasks or to glue other programs together, benefit from that type of power is debatable, but Ruby, Python, and Perl have never been particularly good representatives of the dynamic language paradigm as a whole, either conceptually or implementation-wise.
  - frik 11y ago
    > like the kind you have with Lisp and Smalltalk ...and PHP and JavaScript
  - Dewie3 11y ago
    There's a reason that I wrote 'scripting languages' instead of dynamic languages. Python, Ruby etc. seem to be more regarded as scripting languages than Lisp and Smalltalk.
doomrobo 11y ago
For a scripting language, Go is very strict with compile-time errors that could just as well be warnings. Unused variables, unused imports, dead code, etc. Other than that, I could see Go as a pretty useful scripting and systems language.
- desdiv 11y ago
  In case anyone else is wondering why doesn't the Go compiler have error ignore flags for scripting/prototyping purposes: http://weekly.golang.org/doc/faq#unused_variables_and_imports http://weekly.golang.org/doc/faq#unused_variables_and_import...
aaron-lebo 11y ago
This middle ground is also why I think Go would be/is a great learning language at colleges or in general. You've got something which has a lot in similar with dynamic languages, doesn't require much to learn Hello World (in comparison to Java), but has higher-level features like GC, first-class functions, etc. You also learn something C-ish in pointers which you might be aware of but not truly know in dynamic langs. Concurrency is only a benefit. It is a really simple language that anyone can learn quickly and then take that knowledge higher level with a Python or even Clojure or Haskell or lower level with a C. Is anyone aware of Go being used as a teaching tool in an academic environment?
pekk 11y ago
Another view is that things like GC sacrifice low-level performance stuff (you reference not having total system-level control) while the similarity to languages like C sacrifices some of the good characteristics of scripting languages.
throwaway1240 11y ago
All of what you said about performance could just as easily be said for modern implementations of Common Lisps. SBCL, for example, fairs quite well against Go despite being much more dynamic than either Python or Ruby: http://benchmarksgame.alioth.debian.org/u32/benchmark.php?test=all&lang=go&lang2=sbcl&data=u32 http://benchmarksgame.alioth.debian.org/u32/benchmark.php?te...
- gillianseed 11y ago
  Not as well when we use more than one core: http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all&lang=go&lang2=sbcl&data=u64q http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?t...
  - deleted 11y ago
    [deleted]
  - pjmlp 11y ago
    I wonder if that would still be the case against commercial Lisp compilers like Allegro Common Lisp.
bayesianhorse 11y ago
Using the term "scripting language" for either Go or Python is a complete misnomer. Back in the day, languages called as such where so slow, that there was a feeling that they were used "in lieu" of "real" programming languages. They were there to extend "real" software. Today? Much the opposite. Computing power is almost always cheaper than brain power, and we use C to extend Python rather than the other way around. For that matter, I think Go is great for networked infrastructure, but bad for interfacing with other languages and still significantly harder to learn than Python, Julia and R. That is why I caution on the use of Go in projects which have "scientific" bent to them...
- NateDad 11y ago
  Go is way easier to learn than Python for real applications. Python might be easier for your first few times playing with a programming language, but the complexity ramps up fast. There are a lot of features in python - classes, decorators, all the __foo__ stuff... I think it's a lot easier to understand all of Go than all of Python. I can't comment on R or Julia, since I haven't used them, but I would doubt they're simpler than Go.
- jerf 11y ago
  I understand pushing back against the idea that Go is a scripting language. Arguing that Python isn't a "scripting language" is a complete waste of time. That ship sailed at least 5 years ago, if not 15. And Python is still very, very slow, and very difficult to make multicore (if you disagree, compare with Go), and there are plenty of domains where it should not be chosen as a result. Yes, I know about PyPy, but that project's performance characteristics are very strange and certainly isn't "it just speeds up Python code by 10x, all the time"... sometimes it does that, sometimes (rarely) it slows it down, mostly it does something in the middle that certainly doesn't bring Python anywhere near C.
  - bayesianhorse 11y ago
    For me, a scripting language is used to extend a larger more inflexible software project. Like scripting in Office Suites, Blender or similar. Python is growing in popularity, and in the majority of cases it is used as the "primary" language now. That's why "scripting" is a misnomer, even if technically CPython is not compiled to machine language.

mkoryak 11y ago

why go? why is go being so heavily featured on HN lately? reminds me of that effort to ask a ton of R questions on stackoverflow. We should have more stories about languages people actually get paid to use, like java! jk (kind of)

pekk 11y ago
Unlike some other languages I won't name this isn't astroturf, a fair number of people are using Go as an alternative to C++ or Java or Node.
sethammons 11y ago
i'm paid to write go :)
- mkoryak 11y ago
  I wonder how many here are in your boat
bayesianhorse 11y ago
If you are lurking on hacker news to improve your productivity, I think you're in the wrong place ;-)
detaro 11y ago
If you think so, submit interesting posts about those ;) New and shiny always has an edge in getting interest
NateDad 11y ago
I've been paid to write go for the last two years :). From the articles I've read, a lot of companies are starting to use go for part of their systems.

micro_cam 11y ago

Hah, I wrote this article ages ago when we were experimenting with a data science blog. Surprised to see it pop up here. I think most of it still holds true but we did do some benchmarks on public data and the implementation is competitive with or faster then other implementations including scikit-learn's cython implementation which wins a lot of benchmarks. Code and some benchmark results in the README are here: https://github.com/ryanbressler/CloudForest https://github.com/ryanbressler/CloudForest

rgbrgb 11y ago
I submitted it because I'm playing with CloudForest right now. I really appreciate your work, it's fun to use. I'm co-founder of a digital real estate brokerage[1] and as a weekend hack, I'm using CloudForest to predict sale prices for residential real estate using data from the MLS. A lot of the predictions are really good with a few that are terrible (like double the list price, which is a feature). Any way to get a certainty value for each prediction? Perhaps I could look at the variance of values from each tree? I'm kind of a noob with decision trees so I'm probably totally off base but maybe that question makes sense. :) [1]: https://www.openlistings.co/ https://www.openlistings.co/ (YC W15)
- pigscantfly 11y ago
  Yes, you should be able to estimate a confidence interval by looking at the distribution of votes from each tree. [1] http://arxiv.org/pdf/1311.4555.pdf http://arxiv.org/pdf/1311.4555.pdf

chenzhekl 11y ago

We need generics!

pkroll 11y ago

Don't know if the link was at a different place earlier, but it's now at: http://datascience.systemsbiology.net/data-notebook/ http://datascience.systemsbiology.net/data-notebook/

dang 11y ago
Thanks, we've updated the URL to that.