Hacker News new | ask | show | jobs
by throwawuy222 4081 days ago
(throwaaway here)

Before you waste the next few months of your life learning a corrupt programming language:

- Typesafe co-founder quits: https://www.youtube.com/watch?v=uiJycy6dFSQ - https://vimeo.com/64716826: Paul Dix - Why Node and Scala will dry up: Go will drink their milkshake

- I can personally tell you, scala is awful at handling large codebases and is so filled with idioms, you have a difficult time reading it. I remember opening scala code, seeing english, but it felt impossible to decipher.

- You feel clever when you write it. No doubt about that. Other programmers and your customers don't care.

- Compilation time: It's atrocious, we're talking 1 to 10 minutes to compile web apps.

- Package dependencies: You end up incorporating java at the end of the day. Version mismatches.

- As for the "functional language" thing, just pick real Haskell or Ocaml. Don't fall prey to scala being a functional language.

- You need to rely on a huge, laggy IDE with missing / out of date plugin packages to get autocompletion.

On the other hand, Golang:

- compiles these massive applications in line 2 seconds.

- It's highly lintable.

- The syntax is just... dumb.

- Yet you don't feel limited at all.

- It runs fast-fast-fast without having to rely on JVM.

- Familiar syntax... like a hybrid between Python and C

- You can import packages from github / git repos, automatically grab dependencies with one command.

- The build system and tooling is simple and genius

- Autocompletion (https://github.com/nsf/gocode)

OP: I hope you don't waste your time on a scala venture. Scala has it's die hard fanboys, especially those who spent 15 years in java and have too much of an ego-investment to think anything else, but even the co-founder of typesafe, the most prolific committer says the language is a mess.

1 comments

> the most prolific committer says the language is a mess

This is a lie. He says the compiler implementation is a mess. he's still a contributor and involved in the language.

Second, your argument is basically you aren't smart enough to write/read scala. I love it. I have more faith in the OP.

Not everyone needs idiotic languages that ignore 30 years of programming research to coddle their fragile ego. We're not all like you.

  He says the compiler implementation is a mess. he's still a contributor and involved in the language.
The implementation is a mess because the specification permits so much grammar and syntactic idioms. The moving target and bloated spec is worsened by package version, language mismatches and incomplete repositories.

Of course your compiler is going to be an unmaintainable jungle when you treat the language itself the way most others leave for standard library or even separate projects.

Golang does the opposite, and lives in splendor. Compilation times are imperceptible. Syntax is simple. Standard libraries are solid. Third-party projects are importable via git repositories. Golang is about keeping it tight, staying out of your way, helping you where it counts most, and trying to minimize the downsides.

  Not everyone needs idiotic languages that ignore 30 years of programming research to coddle their fragile ego. We're not all like you.
Golang is written by Rob Pike. Both languages build upon a legacy and have their pragmatic elements.

  Second, your argument is basically you aren't smart enough to write/read scala. 
The job is to ship features. Clever code and arithmetic bring little value.

I'm happy to see that Java programmers can have a cleaner language and some nice functional features. I wish they'd spec things out with more forethought and reigned in the idioms.

You fail to understand that you cannot extrapolate simplicity in the small to simplicity in the large. It's a common mistake people make, but the sooner you realize it the better you'll be as a programmer. Go is simpler than Scala. Scala has more warts than Go. But Scala is more powerful than Go.

If I write a sort algorithm, I'm going to have to reimplement that x number of times for each custom collection I write. You think this makes for a simple app? No. It makes for a convoluted mess. You can have a lot of features in a language and rely less on custom frameworks and duplicated bloated code, or you can prefer the inverse.

Are you familiar with the advantages of parametric polymoprhism? If you think the job is to ship features that work, you should google this, along with theorems for free.

  Are you familiar with the advantages of parametric polymoprhism?
What problem does it solve? How does it help give my startup more runway? How does this impact my bottom line?