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

351–360 of 378 posts

Re: Making the move from Scala to Go

#351

Post by _Codemonkeyism »

adriaanm wrote: post #110
_Codemonkeyism wrote: post #104

Maintaining a Scala code base for some years, I've learned a lot. I would not go back to a language that does not support Option/Maybe and map/flatMap. These really changed my coding style. My largest problems [1] are all still there after years, developers only payed lip service and that killed Scala I think. The largest bad design decision was to support inheritance which leads to it's own problems with type infere…

The only thing on your list on your blog [1] that's still true is that we care about PL research. Since 2.10, we've worked really hard on improving the migration between major versions, and the feedback has been very positive. We'll keep working on finding the right balance between ease of migration and fixing issues in the libraries. Scala 2.13 will be a library release, with further modularisation of the library (t…

Another site note: I would never argue with my users and tell them how wrong they are about the product and that their perception of the lack of some feature or quality is wrong.

Re: Making the move from Scala to Go

#352

Post by GFK_of_xmaspast »

majkinetor wrote: post #316
moosingin3space wrote: post #288

Earlier quoted context omitted.

Not profane, but condescending nonetheless and not appropriate in a professional/code review setting.

Its FOSS setting, not a professional setting. Being a jerk to people that do excelent stuff for your project for free is far from appropriate in any setting on the other hand.

Professionalism doesn't get left at the door at 5:00.

Re: Making the move from Scala to Go

#353

Post by pka »

abc_lisper wrote: post #325
pka wrote: post #239

Earlier quoted context omitted.

> If I am facing a problem that I have never faced before, I like to start off without any types in my code, and then, as I understand the problem more, I like to add in more contract-enforcement. This seems to be a widespread sentiment. In practice, I've found that prototyping anything remotely complex without types is so painful that I'd rather settle for an inferior design than trying to come up with the best poss…

> 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 a clear understanding of how things could be done better. It was just too much work.

With types I'd go through 10 design iterations before settling for something I'm satisfied it, and even halfway through the project changing things radically isn't a problem (I've worked on a 50+ kloc Haskell backend service, and changing core data structures used pervasively throughout the codebase was a 10min job, literally.)

[0] https://github.com/pkamenarsky/tellme

Re: Making the move from Scala to Go

#354

Post by eliwjones »

galacticpony wrote: post #263
edejong wrote: post #247

Earlier quoted context omitted.

I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks. But, lets discuss the 'for clause' and 'do loop': these constructs were made specifically for one kind of simple loop. It is not a systematic solution for an…

"I agree with todd8, but would like to add that the next paragraphs were not added for two simple reasons: the quote itself was already too long and I felt it summarizes well enough the gist of the argument: programming languages should not allow 'clever' tricks." It still seems intellectually dishonest to leave it out. Clearly, what Dijkstra in 1972 considers too "clever" may in fact be tools that are now basic buil…

My working definition of "too clever" is:

If you have to spend time explaining 'what' the code is doing, it is "too clever".

If you have to spend time explaining 'why' the code is doing something.. then "them's the breaks working in a complicated world".

Code should only be as complex as the problem domain.

Re: Making the move from Scala to Go

#355

Post by codygman »

abc_lisper wrote: post #325
pka wrote: post #239

Earlier quoted context omitted.

> If I am facing a problem that I have never faced before, I like to start off without any types in my code, and then, as I understand the problem more, I like to add in more contract-enforcement. This seems to be a widespread sentiment. In practice, I've found that prototyping anything remotely complex without types is so painful that I'd rather settle for an inferior design than trying to come up with the best poss…

> 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.

Re: Making the move from Scala to Go

#356

Post by neilparikh »

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…

So the issue you faced was that you used z twice, and x not at all? In that case, linear types (http://edsko.net/2017/01/08/linearity-in-haskell/) may have caught that.

Re: Making the move from Scala to Go

#357

Post by neilparikh »

PopsiclePete wrote: post #259
oelang wrote: post #251

Earlier quoted context omitted.

The way you describe your experience with Scala makes me think you only had a very superficial look at it. At it's core Scala is very simple & the syntax is very regular, far more than Go or Java and a lot less complex than C++. It's the most expressive typed language on the JVM, so if you like to think in types & you're on the JVM it's your best option. Clojure is untyped, I hear many people praising it but I don't…

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…

> Awesome progress that brought us Java, SOAP, C++, Javascript-on-the-server, and a slew of other tech some of us want to stay far, far away from.

When people talk about progress from PL design, they aren't talking about any of those things. If you notice, all of those things were made in industry, not in PL research/academia. Not to mention that those languages are also ones that ignored the PL design progress! (although C++ finally seems to be adding some ideas from PL research in C++17)

They're talking about things like parametric polymorphism, dependent types, modules, macros etc. (I've mostly been reading about work in the types/ML family languages, but I'm sure there's progress been made outside that as well)

Re: Making the move from Scala to Go

#358

Post by matt_kantor »

nunobrito wrote: post #210
unscaled wrote: post #174

Earlier quoted context omitted.

Lucky bunch indeed. I'm 9 months in and still missing map(), flatMap(), let alone more advanced FP. I guess this is a matter of personal preference, but I definitely consider: users.filter(_.active).map(_.email) to be easier to read (and not a pain in the ass to type) than: emails := make([]string, 0) for _, u := range users { if u.active { emails = append(emails, u.email) } } return email The first style is more exp…

The second example is vastly more readable in terms of understanding what it is supposed to do. I mention this as neither a programmer on either Scala nor Go. If it is of any relevance, I've been writing code for about 20 years across C, Java, Javascript, PHP and shell scripts. I'm sure other FP developers will roll their eyes to a traditional developer like me but the one-liner you mention is simply not self-explana…

Out of curiosity, what specifically do you find unreadable about the first example?

Re: Making the move from Scala to Go

#359

Post by spion »

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…

CS really botched variable scope IMO, and the whitespace rules made it a bit of an error-prone word-soup language.

The rest was pretty great.

Re: Making the move from Scala to Go

#360

Post by kazinator »

neilparikh wrote: post #356
kazinator wrote: post #331

Earlier quoted context omitted.

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…

So the issue you faced was that you used z twice, and x not at all? In that case, linear types ( http://edsko.net/2017/01/08/linearity-in-haskell/ ) may have caught that.

x not being used at all can be caught by a simple unused variable warning.

In this situation, the variable's value was used somewhere, so that didn't go off.

Post reply on HN