Live data from Hacker News

Why Go? Use Racket

cxwangyi.wordpress.com

41–50 of 59 posts

Re: Why Go? Use Racket

#41
post #15

It's a chicken and egg problem, but the real reason for me to use Go vs Racket is that learning the former will further my career significantly, while latter won't at all. Sad, but true.

It depends. Learning Racket and the design methodology taught by Felleisen, et al. could help you become a better programmer in general , and thus significantly further your career. How to Design Programs, Second Edition http://www.ccs.neu.edu/home/matthias/HtDP2e/

Sure, I agree. But the impact is much less direct. Most interviews go like this: "Have you worked with Angular?". And you just don't really need to be a very good programmer to have a well-paying job.

Re: Why Go? Use Racket

#42

Earlier quoted context omitted.

> Or Clojure or Erlang. Funny enough out of "functional" languages those have probably just as much (or even more) been used to develop distributed, fault tolerant systems than F# or Haskell. Just saying. (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 so…

In the study you linked to Clojure code is basically as bug free as Haskell and Scala code and Erlang code isn't far behind.

As I recall they conclude that the general stats show that "static-functional" is more bug-free than "dynamic-functional" which is more bug-free than "static-procedural/dynamic-procedural", which is more bug-free than...

As I said, I'm not sure I buy into the whole design/classification/statistical scheme of the study myself, so YMMV.

Re: Why Go? Use Racket

#43
post #7

The OP's complaint about Go's type system seems to mainly be that memory allocation is explicit. 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…

In Go you can pass a pointer, and a pointer to a pointer. I understand both cases are usually called "pass-by-reference". If you call "pass-by-value" to passing a pointer, then the notion of "pass-by-value" and "pass-by-ref" are not very useful.

Re: Why Go? Use Racket

#44
post #34

Earlier quoted context omitted.

> 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. 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 “n…

Thanks for digging out the history. I don't think we can conclude from your excerpts that the deciding factor was Erlang. However, I accept that my statement that it was "just engineers and process" may have been exaggerated or mistaken.

The deciding factor, as always, is the ability to manage complexity. There are many ways to improve this ability, and process is certainly one of them, however, the choice of programming language is, to my mind, the most important one.

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...

Re: Why Go? Use Racket

#45
post #44

Earlier quoted context omitted.

Thanks for digging out the history. I don't think we can conclude from your excerpts that the deciding factor was Erlang. However, I accept that my statement that it was "just engineers and process" may have been exaggerated or mistaken.

The deciding factor, as always, is the ability to manage complexity. There are many ways to improve this ability, and process is certainly one of them, however, the choice of programming language is, to my mind, the most important one. 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…

Indeed. I must admit that my pro-FP inner geek giggled just a little bit at this bit of "money talks".

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.)

Re: Why Go? Use Racket

#46
post #15

It's a chicken and egg problem, but the real reason for me to use Go vs Racket is that learning the former will further my career significantly, while latter won't at all. Sad, but true.

It is incredibly sad and reflective of a broken industry. 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.

...use your words... not your down votes

Re: Why Go? Use Racket

#47
post #19

Earlier quoted context omitted.

If using dynamic typing like Python's is being drunk, then at least Go is like being tipsy - not quite sober, but quite functioning.

Only if you make a habit of using reflection (you shouldn't). Otherwise it's designated driver all the way.

> Only if you make a habit of using reflection Or type switches. Or nearly anything involving interface{}.

Re: Why Go? Use Racket

#48
post #44

Earlier quoted context omitted.

The deciding factor, as always, is the ability to manage complexity. There are many ways to improve this ability, and process is certainly one of them, however, the choice of programming language is, to my mind, the most important one. 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…

Indeed. I must admit that my pro-FP inner geek giggled just a little bit at this bit of "money talks". 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 ben…

I fully agree. Have you seen the 1994 Hudak study[1]?

“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

Re: Why Go? Use Racket

#49
post #39
post #5

I'm sorry you lost me after your outrageous claim that one must learn everything about the standard types of Go before one can program effectively. 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 n…

Just a nit, everything is passed by value in Go including slices. Here is an example highlighting why it may be important to keep this in mind: https://play.golang.org/p/VOUJI88PNj . 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.

Not just a nit. You are right. I wrote my comment in haste. Had to take someone to the airport.

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.

Re: Why Go? Use Racket

#50
post #48

Earlier quoted context omitted.

Indeed. I must admit that my pro-FP inner geek giggled just a little bit at this bit of "money talks". 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 ben…

I fully agree. Have you seen the 1994 Hudak study[1]? “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…

Yes, indeed, I've read it. Unfortunately, I think we should regard the early studies (such as Hudak's) as basically preliminary and mostly not-well-founded. I know that's horribly conservative, but y'know...
Post reply on HN