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

361–370 of 378 posts

Re: Making the move from Scala to Go

#361

Post by abc_lisper »

codygman wrote: post #355
abc_lisper wrote: post #325

Earlier quoted context omitted.

> In practice, I've found that prototyping anything remotely complex without types is so painful Just to offer a counter-point, I have a Clojure project here with 3k LOC, without using spec/schema. All I have is 700 LOC tests. The tests enforce semantic meaning, along with (some) contracts. I miss types from time to time, but it is no where near as bad as you mention. Against me is the fact is that my app is mostly s…

> 1. Types don't enforce meaning Why do you think this? > Haskell style types only work as far as they enforce meaning. Doesn't this contradict your statement above or are you saying Haskell style types never work because they don't enforce meaning? getUser :: IO (Maybe User) The above function enforces that getting a user can fail and you must contact the outside world to get a user.

Alright.. What I meant to say was,

Types don't enforce all meaning ie., the enforcement of contracts through types go only as far as they mean something to the problem you are applying it to. It does not cover all the complexities of the problem, or the way the code is changed in the future.

EDIT: This is also why it is easy (and nice) to implement parsers in strictly typed functional languages, because parsers are well studied theoretically. The problems in the real world are not studied well enough for contracts enforced via types to work completely.

Re: Making the move from Scala to Go

#362

Post by abc_lisper »

pka wrote: post #353
abc_lisper wrote: post #325

Earlier quoted context omitted.

> In practice, I've found that prototyping anything remotely complex without types is so painful Just to offer a counter-point, I have a Clojure project here with 3k LOC, without using spec/schema. All I have is 700 LOC tests. The tests enforce semantic meaning, along with (some) contracts. I miss types from time to time, but it is no where near as bad as you mention. Against me is the fact is that my app is mostly s…

Have you tried what I'm talking about, i.e. prototyping something by specifying the types and iterating on the core design first before implementing large chunks of the required functionality? It's probably hard to see the benefits without having tried it first. This [0] is one of the bigger Clojure projects I've done (around 2.5kloc), also without spec/schema, and I really didn't dare refactor much, even when having…

I see what you are trying to say. You are saying Clojure is not the right tool to do top-down design. I agree with it. It is however a very good tool to do bottom up design. See https://www.youtube.com/watch?v=Tb823aqgX_0

Re: Making the move from Scala to Go

#363

Post by michaelchisari »

atilaneves wrote: post #176
michaelchisari wrote: post #4

Earlier quoted context omitted.

I don't agree that all languages are created equal in this regard. I think that there are cultural norms and expectations that come with certain languages that make them more or less susceptible to "cleverness." For instance, python has never had the problems that ruby or perl had.

I've seen Ruby-like Python. Just because Ruby makes it easier to do metaprogramming doesn't mean you can't do it in Python.

Of course it's not impossible.

Re: Making the move from Scala to Go

#364

Post by justinhj »

alexbanks wrote: post #282
justinhj wrote: post #236

Some experience to share: I studied Scala and FP on the side before jumping to a team that was using it in production. Most of the engineers on the team have an enthusiasm to learn about and use fp. Bi-weekly we have a book club where we take turns presenting a topic from functional programming in Scala, functional reactive domain modelling and others. We program as simply as possible but when a new technique is disc…

What magical place do you work that allows for this level of engineering quality? > all code is reviewed and unreadable code does not pass Sounds quite nice.

I work at a mobile games company called IGG

Re: Making the move from Scala to Go

#365

Post by lewapkon »

alexbanks wrote: post #282
justinhj wrote: post #236

Some experience to share: I studied Scala and FP on the side before jumping to a team that was using it in production. Most of the engineers on the team have an enthusiasm to learn about and use fp. Bi-weekly we have a book club where we take turns presenting a topic from functional programming in Scala, functional reactive domain modelling and others. We program as simply as possible but when a new technique is disc…

What magical place do you work that allows for this level of engineering quality? > all code is reviewed and unreadable code does not pass Sounds quite nice.

Thorough code review is a great process that should be used in every company.

Re: Making the move from Scala to Go

#366

Post by PopsiclePete »

oelang wrote: post #327
PopsiclePete wrote: post #259

Earlier quoted context omitted.

Go is a language that is a bit tedious to write , no doubt about that, but it's very easy to read . I spend a lot of my time reading other people's code and I really appreciate that. The fact that Scala as a language allows something like SBT to not only be created, but accepted, means I don't want anything to do with it. I've suffered long from the Ruby ecosystem's mentality of "look at what I can do!" of self-servi…

> Go is a language that is a bit tedious to write, no doubt about that, but it's very easy to read. I spend a lot of my time reading other people's code and I really appreciate that. Figuring out 1000 lines of code that could have been 10 and verbosity caused by a lack of generics is not going to help you understand code quicker. Figuring out what 10 lines of Scala do may take more time compared to 10 lines of go, bu…

I like Rust too. I re-wrote a parser I had implemented in Go in Rust and got almost an 8x speed-up. Having said that, the two almost have no overlap for me. I don't see how Rust replaces Go in 9/10 of Go use-cases. And vice-versa.

Re: Making the move from Scala to Go

#367

Post by easuter »

extempore wrote: post #313
extempore wrote: post #312

Earlier quoted context omitted.

Paul Phillips here. I searched my tweet archive for my tweets about Go. Draw your own conclusions. - Kill me before I look at go. - Nobody shot me first so I looked at go. Sigh. After maybe an hour of go I was ahead of where I was after a week with rust. - The first audible WTF with go: cuddled else is mandatory. Parse error otherwise. - go is a terrible, terrible language, yet still a major productivity boost. Amdah…

I missed a couple which didn't mention go: - Rob Pike is like Henry Ford, except when people said “faster horses” he said “that is the best idea I’ve ever heard.” - Rob Pike is the Antonin Scalia of programming language design - an Originalist. Except 1970s not 1770s.

Enjoy your horse then; I'll just speed off into the sunset with the latest model Generics Motors has to offer. :)

Re: Making the move from Scala to Go

#368

Post by spraak »

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…

Very eloquently put, I wholly agree

Re: Making the move from Scala to Go

#369

Post by codygman »

kazinator wrote: post #331
abc_lisper wrote: post #325

Earlier quoted context omitted.

> In practice, I've found that prototyping anything remotely complex without types is so painful Just to offer a counter-point, I have a Clojure project here with 3k LOC, without using spec/schema. All I have is 700 LOC tests. The tests enforce semantic meaning, along with (some) contracts. I miss types from time to time, but it is no where near as bad as you mention. Against me is the fact is that my app is mostly s…

Today I caught a bug in a macro-expanding code walker, where it was expanding the wrong form. The syntax being walked is (foo-special-operator x y z . rest). x and z are ordinary forms that need to be expanded; y is a destructuring pattern (irrelevant here). The walker was expanding z in the place of x: that is to say, expanding z twice, and using that as the expansion of both x and of z. That's simply due to a typo…

If you used newtypes for z and x it would have been caught.

Re: Making the move from Scala to Go

#370

Post by alexbanks »

lewapkon wrote: post #365
alexbanks wrote: post #282

Earlier quoted context omitted.

What magical place do you work that allows for this level of engineering quality? > all code is reviewed and unreadable code does not pass Sounds quite nice.

Thorough code review is a great process that should be used in every company.

Keyword: Should
Post reply on HN