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

91–100 of 378 posts

Re: Making the move from Scala to Go

#91

Post by fspear »

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.

Re: Making the move from Scala to Go

#92

Post by kev009 »

I would consider Scala a far better language from a safety, syntax and design perspective. Go is compelling due to the low GC pause times, and to some extent the community for some types of software. I would imagine switching between these to be quite rare. I would expect more movement from Scala to Swift or perhaps Rust.

Re: Making the move from Scala to Go

#93

Post by abc_lisper »

andrewvijay wrote: post #16

Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.

More importantly, how much time did it take to rewrite code that took 15m to compile! Are the machines working for the man, or the man for the machines ;)

Re: Making the move from Scala to Go

#94

Post by andrewvijay »

abc_lisper wrote: post #93
andrewvijay wrote: post #16

Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.

More importantly, how much time did it take to rewrite code that took 15m to compile! Are the machines working for the man, or the man for the machines ;)

3 person effort for 4 months. Compile time was just one of the advantages though.

Re: Making the move from Scala to Go

#95

Post by andrewvijay »

namelezz wrote: post #38
andrewvijay wrote: post #16

Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.

> the build time has reduced from 15m to 3.6m. Is 3.6m the build time of the remained Java code, the rewritten Go code, or both remained Java and rewritten Go code together?

java ~ 3.4 mins, go - 3-4 secs :D

Re: Making the move from Scala to Go

#96

Post by andrewvijay »

howeman wrote: post #22
andrewvijay wrote: post #16

Really well written. We have a similar story where we re wrote parts of our Java code in go and the build time has reduced from 15m to 3.6m! Coffee break to reading a small medium article.

How much code do you have that compilation is 3 minutes?

Its not go code fully. Its java that takes 3 mins. Go takes very less time like 3-4 secs. Multiple smaller services so we compile only what we change.

Re: Making the move from Scala to Go

#97

Post by justicezyx »

true_religion wrote: post #87
nrjdhsbsid wrote: post #15

Earlier quoted context omitted.

I always work with a few developers that complain about my long variable names and aversion to certain shortcuts like ternary operators. They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. Some of their code is so "clever" that I've refactored the line with 7…

> They don't understand that unclear code is probably the number one cause of technical debt. Nobody wants to waste time trying to understand it so they start to attach workarounds and it just keeps getting worse. True, but once get into the length of variable names in iOS and Android development, you're in a whole new territory. 38 character variables have no place in life. And extreme's like: outputImageProviderFro…

The thing is that, shorter names do not help in this case either...

Re: Making the move from Scala to Go

#98

Post by pjmlp »

jghn wrote: post #50
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.

When I was first introduced to scala my very favorite thing was the existence of map. I'd been using java for a while and missed it dearly

Not allowed to use Java 8?

Re: Making the move from Scala to Go

#99

Post by runT1ME »

geoka9 wrote: post #69
kod wrote: post #44

Earlier quoted context omitted.

No, there's a huge difference in quality of programmers. I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. I've been on other teams where some of the guys still couldn't understand closures after 6 months.

> I've led a team that was productive (by which I mean shipping code that met business goals) within weeks of starting with scala. Personally, I like to measure things like that by how fast a team/developer can get up to speed on maintaining an already existing non-trivial codebase in the language. Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Sca…

     Shipping greenfield projects is often easier than adding features to an existing one, particularly in languages like Scala.
I don't agree. I work on an incredibly large Scala team and a powerful type system gives you a lot more confidence to make everything from minor bug fixes to sweeping refactors.

The price paid for having to learn the complexities and power of Scala (which I'll admit is much harder than other languages) pays off in that it lowers the overall application complexity by reducing the need for a plethora of frameworks/libraries.

If you write Scala like you'd write a java/python/Go application, you'll have better type inference and a worse IDE, along with slower compile times. Not a great proposition. If you write Scala like a pure functional language that allows you to create powerful libraries and DSLs that make it possible to hack together very reliable applications, you'll be amazed.

Re: Making the move from Scala to Go

#100

Post by pjmlp »

skybrian wrote: post #45
WkndTriathlete wrote: post #13

Earlier quoted context omitted.

Agreed, but they also complained about map() and flatMap(). I have to think that eventually every developer can understand the more straightforward monads, functors, and Either - which, along with type aliases, IMO, can make code a lot more readable. I think the more esoteric features should be reserved for complex code, especially if it's possible that those features can prove runtime correctness at compile time and…

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.

No it doesn't, because map, flatMap, and reduce can be lazy, distributed across local processors, or even the network.

They describe the intent of what to do with the data, not how it is done.

Just like using SQL versus an old xBase database to access data records.

Post reply on HN