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

Making the move from Scala to Go

movio.co

Post reply on HN
Print view View original

181–190 of 378 posts

Re: Making the move from Scala to Go

#181

Post by unscaled »

kjksf wrote: post #112
nine_k wrote: post #108

Earlier quoted context omitted.

They only missed these features for 2 weeks? Good for them! Their problem domain is likely so simple and neat that it fits the Go's limited built-in types well, and does not lead to frequent copy-paste programming. If so, Scala has been an overkill.

As simple as a distributed, horizontally scalable SQL database, perhaps? ( https://github.com/cockroachdb/cockroach ). Those dumb Go programmers and their toy programs ( https://quicknotes.io/n/1XB0 ).

Developers have been using C and a bunch of other imperative languages for years. They obviously, created software two order magnitudes more complex than CockroachDB (or Docker, or Kubernetes, or etcd). We used to write entire operating systems in assembly, heavens forbid. Just look at the PostgreSQL codebase (all C) and compare that to cockroach DB.

Being "a better C" was the original battle cry of Go. It's definitely better than C (well, at least for some thing), but it doesn't mean all of these complex C software people used to write are toys.

Go is obviously not a useless toy language either. But that doesn't mean you won't miss features from more expressive languages. The amount of calls for generics from Go users tell a different story.

Re: Making the move from Scala to Go

#182

Post by dagw »

jiaweihli wrote: post #143
Daishiman wrote: post #78

Earlier quoted context omitted.

Well Coffeescript was refreshing in being very terse and introducing a lot of niceties that were missing in JS. It was also trivial to introduce footguns given its whitespace rules and some pretty radical syntax rules. New Javascript has basically taken the best that CS had and wrapped it in the necessary turd that is backwards compatibility in a hastily designed language, but the results speak for themselves and mod…

Yes, the frustrating thing was that people previously praised the language _despite_ its obvious footguns. A language where 'dropping parentheses where you can' is idiomatic is a disaster waiting to happen. I don't know about you, but I never want to be holding a footgun, ever.

Coffeescript worked pretty great when using it on solo projects, because I could use the bits I liked (which where very nice) and ignore all the footguns that I didn't like. The problem as such was that any coffeescript I wrote turned out not be all that idiomatic.

Re: Making the move from Scala to Go

#183

Post by ludicast »

Daishiman wrote: post #78
ludicast wrote: post #10

Scala is the latest whipping boy(1). It's a great language with tons of warts, but it actually acknowledges the warts. Case in point, when (2)Paul Phillips went after Scala (mentioned in the article), Odersky took some of that criticism to heart for the next iteration/rewrite of the Scala compiler. In an industry where everyone doubles down, that's extremely refreshing. Scala's cognitive footprint can lead to misbeha…

Well Coffeescript was refreshing in being very terse and introducing a lot of niceties that were missing in JS. It was also trivial to introduce footguns given its whitespace rules and some pretty radical syntax rules. New Javascript has basically taken the best that CS had and wrapped it in the necessary turd that is backwards compatibility in a hastily designed language, but the results speak for themselves and mod…

Sorry if my footnote's sarcasm was unclear. I really liked coffeescript, I still do. It never had the support it needed to succeed but was a decent enough improvement to be worthwhile. Plus being included in the rails Gemfile was the shot across the bow transpilers needed.

Typescript/ES6 took a lot of the goodness from CS, but I wish they took more. Hell, I wish the typed coffeescript became a thing.

Re: Making the move from Scala to Go

#184

Post by unscaled »

ptx wrote: post #179
skybrian wrote: post #45

Earlier quoted context omitted.

A for-each loop is only slightly longer, more familiar (just about every language has it), and more flexible - it covers map, flatMap, and reduce. So why have three or more specialized constructs when one will do? There are cases when the restrictions of map() and reduce() are necessary, most famously for a map-reduce in distributed programming, but that's not really relevant for implementing a simple function.

And a goto statement is even more general, covering all kinds of looping constructs, exceptions and even the eliminating the need for functions! Why not just use those?

For loops are yet another of these useless abstractions introduced by the academia, this time straight from the design-by-committee language ALGOL 60.

We all know real programmers used gotos.

Re: Making the move from Scala to Go

#185

Post by hocuspocus »

Some points might be valid it's really hard not to dismiss the whole article when you write things like this:

> The funny part is that, because dependency hell is so ubiquitous in Scala-land (which includes Java-land), we ended up using some of the projects that we deemed too complex for our codebase (e.g scalaz) via transitive dependencies.

First, I've just checked, there are 237 dependencies in my classpath, and it never caused me any issue. Dependency management is a complex problem, but the JVM ecosystem does a pretty good job at it. Binary incompatibilities that are specific to Scala are pretty much non-existent today outside of very specific cases.

Secondly, why use stuff that you deem too complex and then complain that it is? Transitive dependencies are just that, transitive. I have Cats and Shapeless in my classpath and I haven't found yet the need to use them in my own code.

Re: Making the move from Scala to Go

#186

Post by unscaled »

This mentions weak IDE support as one of Scala's pain points, but Go has very much the same problem, and the language is vastly less complex.

The two best IDEs for Go right now IMO are VS Code and the EAP Gogland, but both of them are not yet on par what you get with Java. VS Code has only support for very rudimentary refactoring (renames) and relies on a rather slow horde of external CLI linters (executed on save) to provide code analysis. Gogland has pretty nice refactoring, but its built-in code analysis is still too shallow.

Both will get better, but I can't take the claim that you'd move to Go from another language due to "lack of a good IDE". If you want the best IDE move to Java (or Kotlin, or C#) and never look back.

Re: Making the move from Scala to Go

#188

Post by sfifs »

lacampbell wrote: post #105
stcredzero wrote: post #2

As it turned out, more flexibility led to devs writing code that others actually struggled to understand. This is what happens in almost every language. Niftyness and the prospect of impressing your coworkers distorts the cost-benefit calculation. This is in addition to the true costs appearing months or years after the code is written, involving the interaction of complex factors, like increased cost of debugging. "…

I'd much rather deal with concise, clever code that has a sane interface and works, rather than sprawling long winded code where everything is void and the same low level constructs are used everywhere. And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

> And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

If you ever wonder this, then it's definitely a problem with your code and not the reader. Code that cannot be easily read and understood by others is worthless in any commercial setting.

Re: Making the move from Scala to Go

#189

Post by brangalina4eva »

Daishiman wrote: post #90
jghn wrote: post #83

Earlier quoted context omitted.

Sure but I'm talking about things like "break things down into lots of small functions to make things more readable!" vs "keeping code together makes it easier to read!" or "make things verbose so it is easier to read!" vs "conciseness makes code easier to read!" On a lot of those I know what makes code easier for me to read. It's not the same as some of my coworkers. Based on some of your phrasing I suspect we'd agr…

In my experience, very experienced programmers end up converging towards very similar idioms: terse expressions for common patterns, clarity when the domain is complex through verboseness if necessary, and just keeping things as simple as possible unless there's evidence that complexity will reduce technical debt in the future. I don't really see highly competent devs doing the whole J2EE architecture astronautics an…

> nor using single-char variable names

My pet hate.

Re: Making the move from Scala to Go

#190

Post by brangalina4eva »

fspear wrote: post #91
imh wrote: post #23

Looking through the really abstract scala code they linked brings up a problem that really frustrates me in haskell. Why doesn't anybody document their really abstract code? You know it's going to be confusing, so why not help out? If I have a type like def foreignKey[P, PU, TT It's not sufficient to document the function's arguments. You also need to document the type variables! Likewise in haskell with code like f…

This is what I really hate about functional programming (specially Haskell), is almost as if the more obscure and unreadable your code is the more competent you are deemed to be.

It's like someone's run code through an obfuscator before committing.
Post reply on HN