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

371–378 of 378 posts

Re: Making the move from Scala to Go

#371

Post by pka »

abc_lisper wrote: post #362
pka wrote: post #353

Earlier quoted context omitted.

Have you tried what I'm talking about, i.e. prototyping something by specifying the types and iterating on the core design first before implementing large chunks of the required functionality? It's probably hard to see the benefits without having tried it first. This [0] is one of the bigger Clojure projects I've done (around 2.5kloc), also without spec/schema, and I really didn't dare refactor much, even when having…

I see what you are trying to say. You are saying Clojure is not the right tool to do top-down design. I agree with it. It is however a very good tool to do bottom up design. See https://www.youtube.com/watch?v=Tb823aqgX_0

I don't think this is top-dow design really, just an overengineered OOP monstrosity.

Top-down doesn't mean that you have to model the universe first before getting to model your problem :)

Re: Making the move from Scala to Go

#372

Post by nrjdhsbsid »

brangalina4eva wrote: post #189
Daishiman wrote: post #90

Earlier quoted context omitted.

In my experience, very experienced programmers end up converging towards very similar idioms: terse expressions for common patterns, clarity when the domain is complex through verboseness if necessary, and just keeping things as simple as possible unless there's evidence that complexity will reduce technical debt in the future. I don't really see highly competent devs doing the whole J2EE architecture astronautics an…

> nor using single-char variable names My pet hate.

We had a policy at my last place that any SQL joins alias the table name with a single character alias. The rule resulted in the most insanely confusing stored procedures I've ever seen. Whoever came up with that is a complete idiot

Re: Making the move from Scala to Go

#373

Post by lazyjones »

lentil wrote: post #256
lazyjones wrote: post #175

Earlier quoted context omitted.

I found the Go solution for that issue a bit odd - channels aren't for data processing, they're synchronisation primitives. Using them the way they did in the article ruined the piece for me, since it reads like a rather uninformed decision now.

Are you sure they aren't intended for data processing? I've never heard that claim before, and the Go documentation seems to have a lot of examples of using channels in that way. ( https://blog.golang.org/pipelines , for example; or https://tour.golang.org/concurrency/2 ).

Let me rephrase: not suitable for large amounts of data that need high throughput. It's easy to see that the overhead is prohibitive for applications such as in the article, if you just benchmark it.

https://groups.google.com/d/msg/golang-nuts/LM648yrPpck/tv40...

Re: Making the move from Scala to Go

#374

Post by dllthomas »

abc_lisper wrote: post #361
codygman wrote: post #355

Earlier quoted context omitted.

> 1. Types don't enforce meaning Why do you think this? > Haskell style types only work as far as they enforce meaning. Doesn't this contradict your statement above or are you saying Haskell style types never work because they don't enforce meaning? getUser :: IO (Maybe User) The above function enforces that getting a user can fail and you must contact the outside world to get a user.

Alright.. What I meant to say was, Types don't enforce all meaning ie., the enforcement of contracts through types go only as far as they mean something to the problem you are applying it to. It does not cover all the complexities of the problem, or the way the code is changed in the future. EDIT: This is also why it is easy (and nice) to implement parsers in strictly typed functional languages, because parsers are w…

Types don't enforce meaning, types are a tool I use to enforce consistency of meaning along certain important dimensions. I actually find that even more important when the situation is messy, because I'm likely to initially mischaracterize some aspects of it initially and when I go to change things it's very useful to be told what's now inconsistent.

Re: Making the move from Scala to Go

#375

Post by dllthomas »

codygman wrote: post #355
abc_lisper wrote: post #325

Earlier quoted context omitted.

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

> 1. Types don't enforce meaning Why do you think this? > Haskell style types only work as far as they enforce meaning. Doesn't this contradict your statement above or are you saying Haskell style types never work because they don't enforce meaning? getUser :: IO (Maybe User) The above function enforces that getting a user can fail and you must contact the outside world to get a user.

> The above function enforces that getting a user can fail and you must contact the outside world to get a user.

That seems sort of backwards. It enforces that the caller be able to handle failure (and similar for IO). It may well be that "getting a user" doesn't do either (e.g. `pure (pure defaultUser)`)

Re: Making the move from Scala to Go

#376

Post by enqk »

lacampbell wrote: post #309
enqk wrote: post #138

Earlier quoted context omitted.

Code is really hard to work with without the theory that surrounds it, and is alive in the people who worked on it. Peter Naur - Programming As Theory Building http://pages.cs.wisc.edu/~remzi/Naur.pdf

Legacy shitcode is legacy shitcode. If it's owned by someone at least we can push for a sane interface, which is better than the abandoned communal messes I encounter in the real world.

?

Re: Making the move from Scala to Go

#377

Post by abc_lisper »

dllthomas wrote: post #374
abc_lisper wrote: post #361

Earlier quoted context omitted.

Alright.. What I meant to say was, Types don't enforce all meaning ie., the enforcement of contracts through types go only as far as they mean something to the problem you are applying it to. It does not cover all the complexities of the problem, or the way the code is changed in the future. EDIT: This is also why it is easy (and nice) to implement parsers in strictly typed functional languages, because parsers are w…

Types don't enforce meaning, types are a tool I use to enforce consistency of meaning along certain important dimensions. I actually find that even more important when the situation is messy, because I'm likely to initially mischaracterize some aspects of it initially and when I go to change things it's very useful to be told what's now inconsistent.

I get what you are saying. What I'm trying to say is typing takes too much from me, in terms of complexity over-head, that I'm better without. I found this is true in practice now. As I said before, I write tests to do what you say types do - for me, that is enforcing meaning. Types do allow for easy refactoring, and I think that is weakness for untyped languages.

Re: Making the move from Scala to Go

#378

Post by tapirl »

joneholland wrote: post #333
tapirl wrote: post #248

Earlier quoted context omitted.

how about the deploy duration and memory consumption?

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

Deploy in seconds is too long. Most Go programs are deployed in less than one second.
Post reply on HN