You know, this really needs to be said:
Does this company have 'adult' technical supervision or what?
Making the move from Scala to Go
241–250 of 378 posts
Re: Making the move from Scala to Go
#242Earlier quoted context omitted.
All good points. Java 8 has captured a lot of things that people were missing, and new languages have sprung up that have tried to strike a good balance between terseness and complexity, with Kotlin currently being the new hotness in the JVM. Scala was in the right place at the right time, but its features lack orthoginality and coherency.
Which non-orthogonal and/or incoherent features do you have in mind?
I get this feeling when looking at the OO and functional styles continuously clashing. Implicit classes make some reasoning about functionality non-local. There's a horrendous amount of complexity in the OO side: case classes, traits, mixins, and a complex type hierarchy to boot.
Most languages just don't have that many features, and you could take different, non-overlapping subsets of features have something that could have an idiomatic style of its own and is good enough to solve most problems tersely.
Re: Making the move from Scala to Go
#243Having this smartness disparity between devs is really bad for team dynamics, and complexity leads invariably to this. More and more I believe this to be a profound truth.
This seems like an argument for the lowest common denominator.
What should programmers who enjoy working with more powerful abstractions do?
Re: Making the move from Scala to Go
#244Earlier quoted context omitted.
> aversion to certain shortcuts like ternary operators. > They don't understand that unclear code is probably the number one cause of technical debt. At the same time, verbosity can have an obfuscation quality all of its own. For simple assignment , I find a ternary operator very clear and concise, and much preferable to a 5-9 line (depending on style) if/else for a simple assignment. It also might keep you from usin…
OP is about Scala, where you write directly what you mean, without special operators: val usefulMetric = if (wantComplexCalc) { complexCalc(foo) } else { simpleCalc(foo) }
I'd rather have Python's way of doing it, which plays with the order for the sake of readability:
useful_metric = complex_calc(foo) if want_complex_calc else simple_calc(foo)Re: Making the move from Scala to Go
#245I 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 see…
They just want a language more efficient to do develop/test/deploy loops. Yes, Go does much better than JVM based langauges from this point.
Re: Making the move from Scala to Go
#246Earlier 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…
Erlang's processes are green threads, they're just called "processes". Neither Erlang, nor Akka run 1 thread or process per actor, they just schedule multiple actors over N native threads inside the single process (ignoring multi-node situations).
Two notable differences: Akka Actors concurrency is done at library level and an actor can block a JVM thread if not coded carefully. Erlang processes concurrency is support at VM level and there's no way an Erlang process can block a VM scheduler (native code aside, but with native code all bets are off)
Re: Making the move from Scala to Go
#247Earlier 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 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 iterative process. To me it seems Dijkstra specifically aims for languages such as LISP (which, with the renewed interest from Clojure is one of the most oldest successful (semi-) functional programming languages).
Re: Making the move from Scala to Go
#248Sounds 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?
Re: Making the move from Scala to Go
#249I don't know, types help me think. I get lost real soon without them and the reason why I could never pick up any Lisps. In Scala/Haskell I can come up with a solution incrementally and types are the biggest reason why. I always have that feeling that I am missing out on the trumpeted awesomeness of Lisps but I can never justify using them. Maybe there is a personal angle to language selection but I just can't help but feel types are the future and a real advancement of technology.
Re: Making the move from Scala to Go
#250And they could have just used Java from the beginning.
And how do you propose to offset the benefit of smaller image size and lower memory usage?