Transportability is an oft under-valued quality when comparing languages. Yes you could write something highly performant/compact/domain-specialized in perl,scala,lisp etc but when the time comes that your product is successful and your team needs to scale or you want to transfer ownership to another team how easy is that transition going to be?
Scala vs Go
11–20 of 109 posts
Re: Scala vs Go
#12The language complexity comparison based on the number of pages in the spec is incredibly not useful and disingenuous. The Java specification is actually a fairly good specification and also covers a great deal of the runtime (of which Scala gets a free ride). The C specification is 500 or so pages. IMO the Go specification is sorely lacking in details (albeit I must confess written in a much more modern and pithy wa…
> The Java specification is actually a fairly good specification and also covers a great deal of the runtime (of which Scala gets a free ride). but isn't the java spec split in two: the java language specification and the java virtual machine specification? (honest question)
There is overlap and there sort of has to be because of the memory model and reflection if I recall correctly. Certainly the documentation could be more pithy though.
Re: Scala vs Go
#13The language complexity comparison based on the number of pages in the spec is incredibly not useful and disingenuous. The Java specification is actually a fairly good specification and also covers a great deal of the runtime (of which Scala gets a free ride). The C specification is 500 or so pages. IMO the Go specification is sorely lacking in details (albeit I must confess written in a much more modern and pithy wa…
As I read the author's comparison, OCaml came to my mind as well. Reading Minsky's posts and the Real World OCaml book got me really interested in its capabilities for modern software development. I've heard mixed reviews about the object-oriented features, but the functional ones are solid, expressive, and easy to understand.
At home, I started using it as my primary language just a few weeks ago.
Re: Scala vs Go
#14I don't care much about the comparison of these two languages (there's some interesting points though), but the "general observations" intro explains very precisely things that I always struggle to communicate.
Read it, it's a few lines, you've already heard it but it never hurts to be reminded it.
Re: Scala vs Go
#15> Scala code can be very dense and hard to grok at the early stages of learning.
This seems to be the crux of his argument, and I think it's a rather poor one. I have used both Go & Scala professionally. Yes, it took less time for me to start writing real code in Go. However, I found Go's "simplicity" to be limiting and frustrating when it came to building production applications. Things like the weird split between functions returning errors but occasionally panicking, lack of inheritance, and poor dependency management through github links make Go a poor choice for applications within a business setting. Scala does allow for more variance in individual coding styles, but not so much that an experienced Scala programmer can't read & understand other peoples' code with relative ease. It's a non-issue during development as long as the team agrees to follow the same set of conventions, just like any other language.
Re: Scala vs Go
#16The language complexity comparison based on the number of pages in the spec is incredibly not useful and disingenuous. The Java specification is actually a fairly good specification and also covers a great deal of the runtime (of which Scala gets a free ride). The C specification is 500 or so pages. IMO the Go specification is sorely lacking in details (albeit I must confess written in a much more modern and pithy wa…
As I read the author's comparison, OCaml came to my mind as well. Reading Minsky's posts and the Real World OCaml book got me really interested in its capabilities for modern software development. I've heard mixed reviews about the object-oriented features, but the functional ones are solid, expressive, and easy to understand. At home, I started using it as my primary language just a few weeks ago.
I use the OCaml utop REPL as my day to day calculator (booting up excel gets old). I honestly think it has the best REPL.
Re: Scala vs Go
#17The scala example is plain wrong.
import play.api.mvc.RequestHeader
def getUserId()(implicit request: RequestHeader) = { request.cookies.get("uid").map(_.value.toLong).filter(_ > 0) }
Return type is missing, it will throw exception (toLong).
Re: Scala vs Go
#18As a fan of Scala and a developer who has been distancing himself from anything C-like for a decade, I found this post to be pretty fair. Go seems to force explicitness; Scala can be explicit or implicit depending on who uses it. In general, I find explicit to be preferential to implicit when I'm trying to learn a code base. BUT, some cases I hate handling explicitly, such as NULL. For those cases, you can limit the need to handle them using Scala.
Re: Scala vs Go
#19Earlier quoted context omitted.
As I read the author's comparison, OCaml came to my mind as well. Reading Minsky's posts and the Real World OCaml book got me really interested in its capabilities for modern software development. I've heard mixed reviews about the object-oriented features, but the functional ones are solid, expressive, and easy to understand. At home, I started using it as my primary language just a few weeks ago.
I use the OCaml utop REPL as my day to day calculator (booting up excel gets old). I honestly think it has the best REPL.
Thanks for the tip. I see utop referenced all the time, but I just haven't fired it up.
Currently I'm designing a small language so I can learn OCaml better. I'm planning to use the ocamllex and menhir tools for lexing and parsing. I'm sure utop will come in handy for testing out ideas.
Re: Scala vs Go
#20The language complexity comparison based on the number of pages in the spec is incredibly not useful and disingenuous. The Java specification is actually a fairly good specification and also covers a great deal of the runtime (of which Scala gets a free ride). The C specification is 500 or so pages. IMO the Go specification is sorely lacking in details (albeit I must confess written in a much more modern and pithy wa…
As I read the author's comparison, OCaml came to my mind as well. Reading Minsky's posts and the Real World OCaml book got me really interested in its capabilities for modern software development. I've heard mixed reviews about the object-oriented features, but the functional ones are solid, expressive, and easy to understand. At home, I started using it as my primary language just a few weeks ago.
I've been playing around with OCaml a fair bit in my spare time too. I've been using Go at work full time for about 4 years so that's my main comparison.
I love OCaml as a language but the ecosystem is really pretty bad. There is just too much fragmentation and lack of libraries. I would have expected more from a language that is over 20 years old.
Don't get me wrong, I want it to succeed since I agree it has a really nice mix of features.. I just have my doubts given its track record so far.