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

231–240 of 378 posts

Re: Making the move from Scala to Go

#231

Post by geodel »

unscaled wrote: post #186

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) t…

Go can be written without good IDE. I just use Sublime with Go plugin it works great. Also Gogland gives sub-par experience to many experienced Go users. E.g. it does not use `gofmt` but their own formatter which they use for all IDEs. Not sure about their refactoring tool but `gorename` seems to me fine refactoring tool.

Re: Making the move from Scala to Go

#232

Post by [deleted] »

kaoD wrote: post #220
nunobrito wrote: post #210

Earlier quoted context omitted.

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…

The second one is so readable it contains a subtle bug nobody noticed.

[deleted]

Re: Making the move from Scala to Go

#233

Post by justinhj »

didibus wrote: post #43
unoti wrote: post #42

Earlier quoted context omitted.

Leading teams to victory and accomplishing business objectives is an even more important litmus test, in my book. But different strokes for different folks I guess!

But the best thing you can do to improve the team's chances of accomplishing business objectives is to choose its members more carefully.

I don't know why this comment is downvoted, it's absolutely true in my experience.

Re: Making the move from Scala to Go

#234

Post by voidlogic »

pjmlp wrote: post #227
edejong wrote: post #199

Earlier quoted context omitted.

This (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD. EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I ha…

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." -- Alan Kay, The Computer Revolution hasn't happend yet — 1997 OOPSLA Keynote

While this may have a lot of truth to it, the ironic thing here is you are posting this in response to a Dijkstra quote urging us down the path of humility.

Re: Making the move from Scala to Go

#235

Post by DonaldFisk »

edejong wrote: post #199
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. "…

This (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD. EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I ha…

Good advice.

More on cleverness from an old AI textbook (Artificial Intelligence Programming by Charniak, Riesbeck and McDermott):

"1.12.5 Cleverness

Avoid it . Clever tricks ... [Lisp specific stuff omitted.]

To paraphrase Samuel Johnson, we advise you to look over your code very carefully, and whenever you find a part that you think is particularly fine, strike it out."

Re: Making the move from Scala to Go

#236

Post by justinhj »

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 discovered we go ahead and use it after it's been presented to the team and everyone is comfortable with it.

all code is reviewed and unreadable code does not pass

Compile times haven't been an issue. As an example a 100k line Scala program with around 900 files takes around 2 minutes to rebuild whilst incremental changes are immeasurably fast. Reloading code while a local server is running is easy by default in IntelliJ.

Using worksheets for playing is often useful.

we don't use actors where streams would make more sense and vice versa, know the purpose of your tools

I've had bad experiences with Go. I know that for the application I'm working on it would not scale to 10 programmers working and constant refactoring due to business goals changing.

Re: Making the move from Scala to Go

#237

Post by noelwelsh »

I think this team was doomed from the start.

If you come from an imperative programming background, as this team did, (typed) FP is a new way of thinking. It takes a long time to adjust to this new mindset, particularly if you've been programming in imperative languages for a long time. Go, on the other hand, is more of the same. It doesn't seem that anyone on the team had a background in typed FP, and it doesn't seem that they had any support from the organisation to make this shift. I'm not surprised it took them a long time and didn't end well.

Learning new things is hard and until universities and other training providers start teaching FP these kinds of stories will continue. (The alternative, to have companies investing in training and mentoring [plug: my company provides these services for Scala] doesn't appear to be likely en-masse, even though it would be radically cheaper than throwing away code.)

Re: Making the move from Scala to Go

#238

Post by TeMPOraL »

voidlogic wrote: post #234
pjmlp wrote: post #227

Earlier quoted context omitted.

"I don't know how many of you have ever met Dijkstra, but you probably know that arrogance in computer science is measured in nano-Dijkstras." -- Alan Kay, The Computer Revolution hasn't happend yet — 1997 OOPSLA Keynote

While this may have a lot of truth to it, the ironic thing here is you are posting this in response to a Dijkstra quote urging us down the path of humility.

Humility sometimes isn't, as currently discussed in https://news.ycombinator.com/item?id=13480255.

Re: Making the move from Scala to Go

#239

Post by pka »

lkrubner wrote: post #57

Since they cite me (and my essay from 2014) as part of their decision making process, I want to throw in 2 cents here. They ended up deciding on Go, whereas I have ended up preferring Clojure, yet I agree with a lot of what they say, so I'll try to clarify why I ended up with a different decision than what they made. I understand what they mean when they write: I think the first time I appreciated the positive aspect…

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

In Haskell, I come up with a coherent skeleton without having to implement mundane details, hit a wall in the design space because of some case I didn't think of, come up with a better idea and then go back to the code and refactor with confidence. The type system always guarantees that my prototype is coherent as a whole. And I can do that dozens of times.

In Clojure, even with spec, I'd have to implement all my functions fully before being even able to test the design as a whole (sure, testing individual functions works fine in the REPL.) And after hitting a wall, having to reimplement everything every time is just too much work.

Re: Making the move from Scala to Go

#240

Post by todd8 »

galacticpony wrote: post #205
edejong wrote: post #199

Earlier quoted context omitted.

This (lengthy) quote comes to mind. If you think it is interesting, please read the whole EWD. EWD 340 (Prof. Edsgar Wybe Dijkstra) [1]: "The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I ha…

I think it is interesting that you left out the very next few sentences, which provide very relevant context: "I see a great future for very systematic and very modest programming languages. When I say “modest”, I mean that, for instance, not only ALGOL 60’s “for clause”, but even FORTRAN’s “DO loop” may find themselves thrown out as being too baroque." While I agree with the general sentiment, it's very important to…

I agree with Dijkstra, the looping constructs of FORTRAN's DO and ALGOL 60 were too baroque. Dijkstra's comments were written in 1977, at that time FORTRAN IV and ALGOL 60's loop semantics were a mess and were common sources of errors.

Without qualification, Dijkstra was one of the greatest computer scientists in our field's short history. While I don't agree with every single one of his ideas, I would encourage budding computer scientists and professional programmers to look over what he accomplished. He most certainly was not unproductive.

Wikipedia says that Dijkstra is known for:

- Dijkstra's algorithm (single-source shortest path problem)

- DJP algorithm (minimum spanning tree problem)

- First implementation of ALGOL 60 compiler

- Structured analysis

- Structured programming - Semaphore

- Layered approach to operating system design

- T.H.E. multiprogramming system (one of the first operating systems)

- Concept of levels of abstraction

- Concept of layered structure in software architecture (layered architecture)

- Concept of cooperating sequential processes

- Concept of program families

- Multithreaded programming

- Concurrent programming

- Concurrent algorithms

- Principles of distributed computing

- Distributed algorithms

- Synchronization primitive

- Mutual exclusion

- Critical section

- Generalization of Dekker's algorithm

- Tri-color marking algorithm

- Call stack

- Fault-tolerant systems

- Self-stabilizing distributed systems

- Resource starvation

- Deadly embrace

- Deadlock prevention algorithms

- Shunting-yard algorithm

- Banker's algorithm

- Dining philosophers problem

- Sleeping barber problem

- Producer–consumer problem (bounded buffer problem)

- Dutch national flag problem

- Predicate transformer semantics

- Guarded Command Language

- Weakest precondition calculus

- Unbounded nondeterminism

- Dijkstra-Scholten algorithm

- Smoothsort

- Separation of concerns

- Program verification

- Program derivation

- Software crisis

- Software architecture

This quote by galactipony is really offensive to me:

> Such people, while very smart, make for very unproductive software engineers. They also have a way of sounding deceptively smart and thoughtful, when really they're just talking out of their ass. Beware.

It is quite clear to me that Dijkstra wasn't "just talking out of [his] ass."

Learn more about Dijkstra at https://en.wikipedia.org/wiki/Edsger_W._Dijkstra or in any resource on the history of Computer Science.

Post reply on HN