Live data from Hacker News

Making the move from Scala to Go

movio.co

341–350 of 378 posts

Re: Making the move from Scala to Go

#341
post #335

Earlier quoted context omitted.

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 pr…

> Only recently has Perl5 introduced real function parameters instead of unrolling @.

Yet there have been modules that support it for years, and with much more features than what was recently rolled out (which was meant to be conservative).

Here's[1] what I said about this quite a while ago. Named parameters with type checking (unfortunately at runtime). I've been writing Perl using different modules (Function Parameters) which use the same syntax for about six years now (for functions, not all the sugar on Moose objects).

> Flattened lists are another one

Flattened lists never cause me a problem. If they cause someone problems, I think they've never really learned what context is in Perl. Once you know how context works in Perl and had a chance to use it to good effect, I can't imagine this complaint persisting. Perl is fundamentally different than most languages in this respect, even if it looks superficially similar to more procedural languages. This is actually a cause of a lot of problems for novice users, because they assume their experience in C/Algol derivatives will map exactly, and where it doesn't people get frustrated.

> but the worst is having to specify "use 5.020;" if I'm using Perl 5.20

What? You don't have to do that. If you want to use newer features that utilize keywords which may conflict with whatever you've written or whatever modules you are using, then yet, you need to opt into those. Perhaps you would have preferred if it silently just broke?

> They've even carried this "tradition" into Perl6 where you have to specify "use v6;" at the top of EVERY damned script.

No, you don't. If you do, and you run it in Perl 5, it will automatically swap out the interpreter for whatever Perl 6 interpreter you have in $PATH though.

> Prefixing every variable with "my" is another one which found its way into Perl6. Why can't an advanced language have default lexical scope?

The requirement to define your variables is not because it's not lexical by default (it is lexical by default, you can use no strict to see). .It's strictness which is enforced, which has been found by the Perl community to be vastly preferably to automatic instantiation of variables because it prevents bugs, and prevents a lot of confusion. You have to define your variable, because the Perl community found that a more sane default.

1: https://news.ycombinator.com/item?id=11633961

Re: Making the move from Scala to Go

#342
post #251
post #209

Earlier quoted context omitted.

I've used Scala, Clojure, and Go. I found Scala to be too feature-rich for its own good. It was fun to write (Look at me! I just spent two hours figuring out how to compress this old Java 7 function into a one-liner in Scala!), but reading someone else's Scala was almost as mind-numbing as reading another programmer's C++. Go is... meh. Quick to learn, easy to write (and read), but you quickly hit a plateau as far as…

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 likes it's superficial simplicity, syntactic irregularity & stubbornly refuses to accept that PL design has evolved since the 80-90ies, but I'm sure it's appealing to people who are used to languages from that era.

Not really. The largest proportion of Golang users come from relatively modern interpreted languages like Python and Ruby which arr widely used in server environments. I'm unable to find the survey results but I do recall this trend surprised the Go's original authors who were originally seeking to replace C++ & Java

Re: Making the move from Scala to Go

#343

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 studied Scala and 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.

I think this is precisely why a former eng director at Twitter is quoted as saying he'd do Twitter in Java if he started over again. You have to spend a lot of time studying Scala. This is a no-go for any big org that wants to be efficient at horizontally scaling up engineers.

It works great for small teams or orgs that don't need to hire engineers like crazy.

Re: Making the move from Scala to Go

#344

X = the current disliked language of the month on Hacker News Z = latest, most discussed language on Hacker News Making the move from X to Z, and why this is just a marketing campaign from a marketing group.

I've been on HN for years. Scala has been widely criticized with these exact same criticisms for years. These are all legitimate issues people have, even if you don't think they're valid.

Re: Making the move from Scala to Go

#345

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…

Is there something that you can express with Option that you cannot express with a nullable type?

There are many things you can express with ADTs that you can't express with nullable types, and once you have those, Option is simpler than extending the type system.

EDIT: Another thing you can do with Option is define generic abstractions that work on it and other types, like map/flatMap. This in turn means you can write generic functions over anything that can be flatMapped which work automatically for Options. (I don't know if there's anything equivalent in Kotlin though?)

Re: Making the move from Scala to Go

#346

Earlier quoted context omitted.

IMHO it's a wrong approach. Every programming language, just like the spoken ones, has it's common shortcuts and idioms. The fact that they're commonly accepted and used is what makes them easy to understand. Your brain learns to recognize them quickly, often much quicker then the long version. With newbies and programmers who switched from other languages problem is that their brain is just not yet trained to do tha…

Your underlying assumption that everyone working on the code will be skilled is wrong in any large team. It's not like it takes a lot longer to read a 3 line if statement than a ternary operator. Terse code isn't much faster to read, the difference between a 300 and 400 line file isn't significant. Your attitude of "he isn't 1337 enough to understand my code" is the logic that leads to no comments and horrible to mai…

> It's not like it takes a lot longer to read a 3 line if statement than a ternary operator.

It doesn't take a lot longer to sit down and understand how ternary operators work, either. C'mon, it's not differential equations, it's just a notation, and a fairly simple one. It might take a newbie slightly more time at first to understand the logic. We've all been there once, you stop and stare at it for 15 minutes, but after a few times of deciphering it you get used to it. It's not about being 1337 (I surely hope that it's not what's considered elite this days), it's about learning new stuff and any averagely intelligent person can do it. Honestly, would you really hire someone who is not capable to (in a reasonable amount of time) teach him/herself how to read a ternary operator? What programming would that person be capable of doing in future?

Re: Making the move from Scala to Go

#347
post #216

Earlier quoted context omitted.

Developers have been using C and a bunch of other imperative languages for years. They obviously, created software two order magnitudes more complex than CockroachDB (or Docker, or Kubernetes, or etcd). We used to write entire operating systems in assembly, heavens forbid. Just look at the PostgreSQL codebase (all C) and compare that to cockroach DB. Being "a better C" was the original battle cry of Go. It's definite…

> The amount of calls for generics from Go users tell a different story I think it is from Non-Go users who would use Go if only it had generics.

Some of it, probably. But some are probably using Go out of necessity (your company enforces Go), or because they still think Go is their best pragmatic option, lack of generics notwithstanding.

Re: Making the move from Scala to Go

#348

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…

Not really. Emacs works great because of tools like godef and gofmt. If guis is your thing https://www.jetbrains.com/go/

I explicitly mentioned Gogland (the Jetbrains IDE). I'm not a fan of heavyweight editors (including emacs), and I'd gladly just use vim for Go if vim-go had refactoring support beyond the useless gorename.

Gofmt works nicely across the board, but godef needs your entire package to compile as far as I remember. Neither of them gives you refactoring support, and gorename doesn't give you much either.

You seem to think godef/gofmt is enough which is fine, but in this case Scala has the same level of support as Go.

Re: Making the move from Scala to Go

#349
post #231

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.

Gogland's non-standard formatting is one of my pain points. But the standard go* tooling doesn't offer any proper refactoring.

Unless if by refactoring you mean "Jus' renaming my functions and variables and nothing else, and only when all my packages compile correctly, with 80% guranteed success" then Gorename is a good tool, I guess. YMMV.

This is what I have in mind when I talk about good refactoring (Resharper on Visual Studio being the gold standard IMHO): https://es137custom.files.wordpress.com/2012/12/resharperref...

It's a huge productivity boost for me, enough that I'm willing to live with the subpar experience of IDE Vim Plugins.

Again, you can argue that YOU don't need this IDE fanciness, but OP claimed this is a major reason for them wanting to ditch Scala.

Re: Making the move from Scala to Go

#350

Earlier quoted context omitted.

What does it mean to make tooling a first class citizen?

From the start they decided to ship with a standard formatter / linter for example. A standard cross platform build system, optimized for build speed from the start, etc. I think a better word would of been a 'top priority'.

That is not a lot of tooling, actually. I am thinking about IDE integration, static analysis, code generation, package management. What are aspects of the tooling experience I am missing?
Post reply on HN