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

1–10 of 59 posts

Re: Why Go? Use Racket

#2

Post by nine_k »

No. Because static typing.

However much Go's type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language.

I'd rather say 'use OCaml' or 'use F#' or even 'use Haskell'.

Re: Why Go? Use Racket

#3

Post by wtetzner »

nine_k wrote: post #2

No. Because static typing. However much Go's type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language. I'd rather say 'use OCaml' or 'use F#' or even 'use Haskell'.

Or 'use Typed Racket'.

Re: Why Go? Use Racket

#5

Post by jamra »

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 not a hard concept. I don't like you writing off Go with that example. It sounds like you made an emotional decision against the language and are grasping for logical reasons to support your already made decision.

How many people programming with Go pass arrays around? It's an easy lesson to learn.

Re: Why Go? Use Racket

#6

Post by slashdev »

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…

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 is tremendously valuable.

Re: Why Go? Use Racket

#7

Post by tedsuo »

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 programs will run incorrectly.

Given that the OP mentions that they find the slower, more expensive execution of racket programs to be an acceptable trade-off, I'm surprised that they have a problem with this.

Personally, I prefer running in a language that allows me to reason about the memory allocation explicitly. I'd only prefer to give that up in favor of a declarative language that could compute the optimal execution for me. Unfortunately that language is a bit of a unicorn for general purpose programming.

Re: Why Go? Use Racket

#9

Post by rdtsc »

nine_k wrote: post #2

No. Because static typing. However much Go's type system might lack some means of expression, the type system is there, and it prevents many bugs that can easily crop up while using a dynamic language. I'd rather say 'use OCaml' or 'use F#' or even 'use Haskell'.

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 main problem with dynamic types just wasn't true.

Maybe my code is more complicated and dealing with distributed state, consistency, and protocols but what what kills everything is usually logic errors, network failures, files not being there, misconfiguration, segfaults, user-after-free, and the most evil ones, shared global states in a concurrent shared-heap environment.

Things like "oh I expected an int but got a string" are pretty trivial and easy discovered.

Moreover, in a recent service I implemented. I did in Python and I believe the faster development time and less code to write in general, gave me time to write better integration tests that exercises and covered the code a lot better. I would have had to write the tests anyway, even if this was written in Haskell.

Perhaps static typing helps a lot more in large code bases. Think of a large game, or a CAD application or some huge C++ back-end. But, if you buying into the whole micro-services fad, well, you shouldn't have large code bases if you can help it.

Another big motivation for types, which I think most people have in mind when they pick a strongly typed language is performance. Usually static typing and a very large performance increase would go hand in hand. Now with the effort put into v8 and PyPy we see that gap getting smaller.

Post reply on HN