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

311–320 of 378 posts

Re: Making the move from Scala to Go

#311

Post by hyperpape »

macintux wrote: post #306
hyperpape wrote: post #221

Earlier quoted context omitted.

There just isn't that much to get wrong in pure for-each loops: def filter_broken(widgets): broken_widgets = [] for widget in widgets: if widget.is_broken(): broken_widgets.append(widget) return broken_widgets The actual errors with loops and mutable objects come from complex nested loops, continues/breaks (multi-level ones especially!), extra boolean conditions, and sharing mutable objects between parts of the code…

Hm. Wouldn't your code reverse the order of the list? Maybe that's right, maybe that's wrong, but it's indeterminate from the code whether it's desired, whereas a filter function and a reverse function would make it explicit.

Append is a function that adds it to the end of the list. (I think my code is working Python, but I haven't actually run it).

Btw: I'd venture to guess that you're not a Python person, and that's why it's not obvious that it constructs the method in the same order. In imperative languages (where Python isn't the perfect example b/c it has filter and list comprehensions), you get so used to these loops that you don't have to worry about questions like that.

If you wanted a reversed list, you'd either name your function appropriately, or call reverse after you run the filter method. It's a little painful to do the first bit.

Re: Making the move from Scala to Go

#312

Post by extempore »

bad_user wrote: post #120

Some notes: - the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn't orthogonal either, since an actor's mailbox interactions are definitely not pure, with actors being stateful and at the same time non-deterministic; in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual f…

Paul Phillips here. I searched my tweet archive for my tweets about Go. Draw your own conclusions.

- Kill me before I look at go.

- Nobody shot me first so I looked at go. Sigh. After maybe an hour of go I was ahead of where I was after a week with rust.

- The first audible WTF with go: cuddled else is mandatory. Parse error otherwise.

- go is a terrible, terrible language, yet still a major productivity boost. Amdahl's law in another context.

- You often see languages which are fighting the last war. Go is fighting the War of 1812.

- If someone had made up Go within a work of fiction, they'd have been laughed out of the room.

- I had thought Blub was a rhetorical device, but Go is more Blub than Blub.

- reduce: what you will do with your expectations after you start with Go

- Did they miss any chance to introduce an ad hoc inadequate non-solution? Tool directives in comments! What could go wrong!

- Comical levels of confirmation bias in proglangs. Guy doesn't get it, poor impl, isn't useful, "see?" Examples: scala, python, go.

- Some specifics are enumerations in scala, closures in python, and anything devised since 1980 in go.

- Go: compiler directives in comments is "an elegant design". https://t.co/DjCO1UxgC2 http://t.co/BR3kFxRZvc

- Rust and Scala drown you in complexity. Go drowns you in simplicity.

- This comment sums up Go pretty well. https://t.co/Td9Q3wOW43

- go logging package lets you set the global Writer, but not query it. So you can't save/restore it. Nice job.

- This year's gold medalists in type safety's missing-the-point olympics: Go! https://t.co/ktrlBUEwP9

- Turns out Go is the result of a bar bet between Rob Pike and Robert Heinlein. Everybody lost.

- It’s incredible how far Go has lowered my estimation of the vaunted Google engineer. What an institutional failure.

- Go is what you might come up with if your definition of programming was “shuffling electrons”.

- A Go discussion thread is “how to build a space station with crayons” up to homotopy.

- A supposed selling point of Go is that you can learn it in a day. Think of what that tells you about what it can do.

- The existence of Go leads me to realize the infamous Google technical interview is designed to weed out out-of-the-box thinking.

- I added a second file to https://t.co/ktrlBUEwP9 further explaining how go's casting requirements are broken by design.

- But little did I know, I’m just a “lesser” programmer because I enjoy Go’s simplicity" says a commenter. Well, yeah.

- The Go string type can't be passed as a fmt.Stringer. You apparently have to accept interface{} and type match. Amazing.

- An example of go upside: "go get ...gocov" and code coverage instantly worked. In scala it has always been painful/fragile at best.

- Any go code which has error in parameter position which tests err against nil will silently miss a bunch of errors.

- Hostility to abstraction: the Go story

- Sad that google waited this long to put a deep mind on go.

Re: Making the move from Scala to Go

#313

Post by extempore »

extempore wrote: post #312
bad_user wrote: post #120

Some notes: - the actor model, along with the Akka implementation, has nothing to do with functional programming; and it isn't orthogonal either, since an actor's mailbox interactions are definitely not pure, with actors being stateful and at the same time non-deterministic; in general if you place those in the same article, there's a high probability that you never did functional programming; and if you did actual f…

Paul Phillips here. I searched my tweet archive for my tweets about Go. Draw your own conclusions. - Kill me before I look at go. - Nobody shot me first so I looked at go. Sigh. After maybe an hour of go I was ahead of where I was after a week with rust. - The first audible WTF with go: cuddled else is mandatory. Parse error otherwise. - go is a terrible, terrible language, yet still a major productivity boost. Amdah…

I missed a couple which didn't mention go:

- Rob Pike is like Henry Ford, except when people said “faster horses” he said “that is the best idea I’ve ever heard.”

- Rob Pike is the Antonin Scalia of programming language design - an Originalist. Except 1970s not 1770s.

Re: Making the move from Scala to Go

#314

Post by macintux »

hyperpape wrote: post #311
macintux wrote: post #306

Earlier quoted context omitted.

Hm. Wouldn't your code reverse the order of the list? Maybe that's right, maybe that's wrong, but it's indeterminate from the code whether it's desired, whereas a filter function and a reverse function would make it explicit.

Append is a function that adds it to the end of the list. (I think my code is working Python, but I haven't actually run it). Btw: I'd venture to guess that you're not a Python person, and that's why it's not obvious that it constructs the method in the same order. In imperative languages (where Python isn't the perfect example b/c it has filter and list comprehensions), you get so used to these loops that you don't…

Yeah, sorry, got my mental model mixed up. I worry about reversing lists a lot since I deal with TCO so much.

Re: Making the move from Scala to Go

#315

Post by AzzieElbab »

wrt to programming languages, going from scala to go is like going from english professor to honey boo boo. go is basically new php with lots of ftm features baked in. scala, for all it's flows stays true to it's goal - it is a scalable language. use as mush of it as you are comfortable with and keep growing. here is btw one of the "coolest" features of go in scala http://storm-enroute.com/coroutines/docs/0.6/101/

Re: Making the move from Scala to Go

#316

Post by majkinetor »

moosingin3space wrote: post #288
majkinetor wrote: post #228

Earlier quoted context omitted.

In general context yes, but if you tell your top contributor that besides doing full day job work for entire year for free (while main author also has commercial offering) he should also babysit "dumb" users (making entire job not fun) and you get the tip multiple times that such behavior will alienate him from the project, you can be sure there is a way better approach to project management. Since I left it, the PRs…

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.

Re: Making the move from Scala to Go

#317

Post by sanjayts »

geodel wrote: post #216
unscaled wrote: post #181

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.

I do competitive programming using Go and sorely miss "generics" so I'm pretty sure that your thought is not entirely correct.

Re: Making the move from Scala to Go

#318

Post by stcredzero »

lacampbell wrote: post #105
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. "…

I'd much rather deal with concise, clever code that has a sane interface and works, rather than sprawling long winded code where everything is void and the same low level constructs are used everywhere. And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

And honestly, sometimes I don't know if code is too "clever" or the reader is just too "dumb".

This is not an absolute, and needs to be answered in the context of the question: "Does my team work?"

Re: Making the move from Scala to Go

#319

Post by jerven »

andrewvijay wrote: post #204
jerven wrote: post #160

Earlier quoted context omitted.

As this is the 3rd language in your code base, 1st there was java, then there was Scala and now GO. I do hope all Scala code is gone by now! I assume this decision and investment was extremely well supported, but that is not obvious from your blog post and supporting comments here. So 12 months of effort -> at Bay area salaries and costings that is in the order of magnitude of 300,000USD. Your parent company had 6.6…

I'm sorry we never used Scala.it was a pure Java code base.

Sorry I was confused between your experience and the opening post which was moving from Scala to GO. So I assumed you were working for Movio and used their numbers. Therefore my post does not make any sense :)

Then it was a Java to GO move. I wonder where your compiles take the most time. For our work building the jar files are the most expensive part. Javac is about 20 seconds all in for about 3000 files to compile on my 2009 macbook.

Re: Making the move from Scala to Go

#320

Post by realharo »

_Codemonkeyism wrote: post #289
realharo wrote: post #267

Earlier quoted context omitted.

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

For me nullable type expresses something semantically different than Option. Option is a higher concept expressing optionality - duh ;-) - contrived example - it might make semantical sense to express Option[Option[A]] as a type, it does not make sense to have wrapped nullable types (except as a result of nested function calls). Nullable types feel like a bugfix to null, Options fell like a concept to model business…

I think you're only meant to use nullable types in Kotlin for exactly that purpose - expressing a value that may or may not be there (aside from the compatibility with Java libraries of course).

For things that just cannot be initialized directly in a constructor, you have more idiomatic constructs, such as the `lazy` property delegate, or in the worst case, the `lateinit` keyword (though at that point it may be better to rethink the design of your interfaces).

For indicating that an error occurred, you have exceptions.

Post reply on HN