Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why Go? Use Racket

cxwangyi.wordpress.com

Post reply on HN
Print view View original

31–40 of 59 posts

Re: Why Go? Use Racket

#31

Post by tel »

Dewie wrote: post #19
slashdev wrote: post #6

Earlier quoted context omitted.

There are many valid criticisms of go, but the one presented in this article make no sense. Or maybe only make sense if you're a huge dynamic languages fan and can't stomach static typing. Personally, as someone who used to be a huge fan of dynamic languages like Python, I've sobered up as I've grown older and had to fight with large python and JavaScript code bases. A compiler that is fast with clear error messages…

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

Tipsy is probably the most dangerous mode. People feel like they can probably still drive when they're just tipsy.

Re: Why Go? Use Racket

#32

Post by sheepmullet »

lomnakkus wrote: post #14
rdtsc wrote: post #9

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. BTW both Clojure and Erlang allow a form a gradual typing. From personal experience. I've used both static (C#, C++, Java) and dynamic typing (Python, Erlang), and have to say, the prevents-many-bugs excuse as the mai…

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

Re: Why Go? Use Racket

#33

Post by copsarebastards »

I'll come right out and say that I despise Go. It's a terrible language that ignores decades of language research and brings nothing new to the field, but has become popular due to Google hype.

That said, Go -> Racket is a pretty big jump. Even though I think Go is terrible, I can at least take the time to see the problems it's solving and offer comparable languages. I suggest Rust as a Go replacement.

Don't get me wrong, Racket is pretty good. It's not the Lisp I would pick (I really like Gambit Scheme) but it's at least a Lisp. But a high-level language like Racket isn't really comparable to Go. They're just in different spaces.

Re: Why Go? Use Racket

#34

Post by mietek »

lomnakkus wrote: post #14
rdtsc wrote: post #9

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. BTW both Clojure and Erlang allow a form a gradual typing. From personal experience. I've used both static (C#, C++, Java) and dynamic typing (Python, Erlang), and have to say, the prevents-many-bugs excuse as the mai…

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

> 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 “next generation switch” to replace the Ericsson AXE-10. This extremely large project ran from 1987-95. After the AXE-N project collapsed a decision was made to “restart” the project using Erlang. This project eventually resulted in the development of the AXD301 switch.”

“During the period 1996–1997 a three-person group (myself, Magnus Fröberg and Martin Björklund) redesigned and implemented the OTP core libraries.”

“1998: Ericsson delivered the first AXD301. The AXD301 is the subject of one of our case studies in Chapter 8. At the time of writing (2003) the AXD301 has over 1.7 million lines of Erlang code which probably makes it the largest system ever to be written in a functional style of programming.”

[1]: http://www.erlang.org/download/armstrong_thesis_2003.pdf

Re: Why Go? Use Racket

#35

Post by nulltype »

jamra wrote: 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…

I think slices are actually passed by value.

From "Effective Go":

"We must return the slice afterwards because, although Append can modify the elements of slice, the slice itself (the run-time data structure holding the pointer, length, and capacity) is passed by value."

Re: Why Go? Use Racket

#36

Post by sheepmullet »

vvpan wrote: 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.

Re: Why Go? Use Racket

#37

Post by [deleted] »

bkeroack wrote: post #30
Dewie wrote: 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.

[deleted]

Re: Why Go? Use Racket

#39

Post by Rapzid »

jamra wrote: 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.

Re: Why Go? Use Racket

#40

Post by lomnakkus »

mietek wrote: post #34
lomnakkus wrote: post #14

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…

> 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.
Post reply on HN