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

331–340 of 378 posts

Re: Making the move from Scala to Go

#331

Post by kazinator »

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…

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 referring to the wrong variable.

The type system would be of donkey all use here, because everything has the correct type, with or without the mistake. The code referred to the wrong thing of exactly the right type.

A lot of code works with numerous variables or object elements that are all of the same type, and can be mixed up without a diagnostic.

Re: Making the move from Scala to Go

#332

Post by throwaway7645 »

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…

Interesting to hear. I like the idea of gradual typing as I'm coming from a predominantly python background and sometimes want to add types as I go. Perl6 looks really promising here. Curtis "Ovid" Poe has a good YouTube video on this. He starts with the Fibonacci function which can easily go wrong depending on a variety of inputs and keeps adding type restrictions such as it has to be a positive int between a range of #'s...i dunno, something along those lines.

Re: Making the move from Scala to Go

#333

Post by joneholland »

tapirl wrote: post #248
joneholland wrote: post #12

Sounds more like moving away from a big jvm monolith is how they gained their speed. Our Scala based microservices build in seconds. Anyway, no idea who movio is, but cool they like go. Not sure why they needed to write Scala FUD in the process.

how about the deploy duration and memory consumption?

Deploy in seconds as well. We create executable jars using grpc.

Re: Making the move from Scala to Go

#334

Post by scalatohaskell »

Daishiman wrote: post #80
joneholland wrote: post #12

Sounds more like moving away from a big jvm monolith is how they gained their speed. Our Scala based microservices build in seconds. Anyway, no idea who movio is, but cool they like go. Not sure why they needed to write Scala FUD in the process.

I think that if you have to move to microservices just to avoid atrocious compilation times that means there's something horribly wrong in the language stack. Microservices should be used to solve architecture problems, not a workaround for compiler slowness.

just cyclic dependencies between project's generated source codes of exposed interfaces/contracts. ez.

It's not hard to fuck up ur sw eng. practices and blame language.

Re: Making the move from Scala to Go

#335

Post by cutler »

kbenson wrote: post #291
christophilus wrote: post #268

Earlier quoted context omitted.

Ruby has something similar, and I can't stand it. I think the conditional is the most important item in the phrase, and it's shoved off to the right. If you lead with the conditional, it becomes immediately apparent that the assignment is predicated on the result of a branch.

Ruby (and Python) likely get that from Perl, which has post conditionals, but with specific qualities to prevent them from too much abuse, and which also prevents them from being used in the way presented here (which is why I didn't trot them out earlier, as much as I was tempted by the "you write what you mean" line). The limitations are that there is no else branch, and it only applies to a single statement , so yo…

Perl hung onto too many of its warts for too long to stand a chance of competing with Ruby and Python. Only recently has Perl5 introduced real function parameters instead of unrolling @. Flattened lists are another one but the worst is having to specify "use 5.020;" if I'm using Perl 5.20. They've even carried this "tradition" into Perl6 where you have to specify "use v6;" at the top of EVERY damned script. That's progress? Prefixing every variable with "my" is another one which found its way into Perl6. Why can't an advanced language have default lexical scope?

Re: Making the move from Scala to Go

#336

Post by jim_d »

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…

I haven't tried Go myself and I've been meaning to, but I have spent the last 3 years writing Scala code. Before learning Scala I didn't have any real experience with FP, and I think that was the real learning hurdle for me. Once I learned the FP ideas Scala became my preferred language. I think it's really funny but Java and C# have been becoming more Scala like, and to some extent the latest version of JavaScript are also starting to become Scala like. What I have come to accept is that Scala does take people time to learn, but it's not typically Scala the language, it's the FP aspects of it that are the stumbling blocks.

PS. I also work on a 100k Scala program and can go from clean to compiled in less than 2 minutes, and incremental compiles are extremely fast.

Re: Making the move from Scala to Go

#337

Post by jim_d »

unscaled wrote: post #174
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.

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…

completely agree. There is a certain beauty to the first version that once you've learned the concepts it seems a shame to have to write the second one.

Re: Making the move from Scala to Go

#338

Post by jim_d »

adriaanm wrote: post #140

[Scala team lead at Lightbend here] I'm always eager to learn how we can improve Scala, especially as we kick of the Scala 2.13 cycle (hard at work on compiler performance and standard library improvements). Email is 'adriaan.at("lightbend.com") Regarding Scala's growth, I will leave you with https://www.indeed.com/jobtrends/q-scala.html .

I just wanted to take this opportunity to thank you and the team at Lightbend. There is a clarity of thinking and expressiveness in Scala that I haven't found in other languages. I have used Scala professionally for the past 3 years and enjoy it immensely as a language.

Re: Making the move from Scala to Go

#339

Post by digitalzombie »

xutopia wrote: post #275
digitalzombie wrote: post #68

Earlier quoted context omitted.

Actors should be in a process no? If it's in a thread then it'll take the main process down with it. Erlang's BEAM VM every actor is in it's own process. So if something goes bad then it can be restarted via supervisor. Scala is on JVM and JVM isn't built with concurrency in mind and I think Erlang's BEAM is too good at this. Akka is gimped too, you have to write actor a certain way iirc other wise it takes over the…

Elixir makes Erlang look beautiful! You should check it out!

Yeah I'm actually learning Elixir and eventually Phoenix.

Erlang's syntax took a while to get used to but the community wasn't for me. There were no momentum really, it was really hard to convince anybody that Erlang needed some killer framework that people can get behind. Or hell anything to get excited about other than BEAM and that's behind the scene.

Elixir is beautiful but some of the syntax is meh for me.

Re: Making the move from Scala to Go

#340

Post by maloga »

diminish wrote: post #147

"..it felt quite empowering to have the confidence that, supported by type-checking and a few well-thought-out tests, my code was doing what it was meant to. " Does this mean that on what software is "meant to do" type checking covers most test cases and only few additional is needed to ensure iy does what it's meant to do?

That's not what I meant to emphasise, but kind of. I was contrasting the Scala programming experience to this: https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ which seems to be pretty much the point expressed by the Coursera people in the blogpost I quoted from them.
Post reply on HN