Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

3.5 Years, 500k Lines of Go

npf.io

Post reply on HN
Print view View original

171–180 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#171

Post by grey-area »

goatlover wrote: post #158
grey-area wrote: post #154

Earlier quoted context omitted.

Well exactly, this is why languages like Lisp are so seductive and powerful - they let you write languages within the language. When you have a really flexible language like Lisp, it's tempting to produce a meta-language to describe your problem which is specific, terse, and powerful. However there's an interesting trade-off here. At first this seems like a wonderful solution, but if you ever work with a few other pe…

That's a legitimate concern. But then again, the world is full of programming languages. Sometimes you really appreciate what an R gives you when needing to do a lot of statistical computing and data wrangling, or what C or Rust offers for systems programming, and so on. And speaking of DSLs, the Pandas and Numpy libraries in Python are super useful, and they're possible because Python offers enough metaprogramming f…

I think the point is that Lisp lets you create an ad-hoc, poorly-specified version of any language you like, or perhaps several mashed together, which feels great at the time, but feels horrible when you come back to it later.

DSLs/Jargon/New Languages are constructing a new world, and you need to be really sure the costs of that abstraction are outweighed by concrete and lasting benefits in the domain (sometimes they are, oftentimes they are not), crucially, this sort of language is often best used for a very specific domain and nowhere else (say R for statistics).

Re: 3.5 Years, 500k Lines of Go

#172

Post by pjmlp »

jy3 wrote: post #167
pjmlp wrote: post #122

Earlier quoted context omitted.

a := Sum (b, c) How can you be sure that Sum actually does a sum without looking at its implementation?

I think you are missing the point. Of course you can't assume what a function will do with certainty.

From CS point of view + is just a function name just like any other.

A concept used in lambda calculus, introduced in computing since Lisp exists.

Also part of abstract mathematics field, where operator symbols get defined for the proofs.

Re: 3.5 Years, 500k Lines of Go

#173

Post by woah »

k__ wrote: post #79

Are generics really that big of a thing if you got structural typing? I mean, you don't have to implement all the interfaces explicitly, you just have to get your structure right and be done with it. Am I missing something?

I think generics would mostly be useful for container types, like putting methods on slices (like .map) without caring what's inside.

Re: 3.5 Years, 500k Lines of Go

#174

Post by [deleted] »

kuschku wrote: post #102
NateDad wrote: post #61

Earlier quoted context omitted.

functions and methods are the original abstraction. Interfaces allow you to abstract implementations of sets of methods. I fail to see how that is saying that abstraction and usability are overrated. They're not. They're important.

And go can not write abstract functions and methods. I can not write a function dealing with arbitrary values. Somethind I’d do in Java with public static T increment(T val) { val.increment(); return val; } is impossible to do in Go. You can not abstract over types, and write metric fucktons of duplicated code. I’ve tried porting some of my Java code, and it quickly grew to some classes being duplicated hundreds of t…

[deleted]

Re: 3.5 Years, 500k Lines of Go

#175

Post by pcwalton »

NateDad wrote: post #112
kasey_junk wrote: post #29

Earlier quoted context omitted.

> That lack of magic I have a really hard time understanding what people mean when they say magic. In every language I've ever worked in I spend a fair bit of time saying "how does this work". Go doesn't seem any different in that regard to me.

one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the…

> How much memory will it cause to be allocated?

In Go, it's impossible to tell because "a" might be captured by a closure, in which case it will be heap-allocated. But if escape analysis promoted it to the stack or a register, then it will not allocate memory.

Re: 3.5 Years, 500k Lines of Go

#176

Post by slrz »

CJefferson wrote: post #124
NateDad wrote: post #112

Earlier quoted context omitted.

one of the things that go eschews is operator overloading. a := b + c What's the runtime complexity of this statement? How much memory will it cause to be allocated? In go there's only two possibilities for what this code is doing... either this is string concatenation, or it's adding two numbers. Both of which are immediately comprehensible for impact on run time and memory. In C#, you can overload operators, so the…

I honestly don't understand the difference with ' a := add(b,c) '. Does it really make things that much difference? And lack of overloading makes maths heavy code horrible to read. Of course, you can go to the C extreme, no overloading, specialisation or anything, every function name means one thing. That does add some nice features, but is a pain in the ass when naming things!

The difference is more apparent in the other (non-overloaded) case. When in Go (or C, …) you see an expression "x << y" you know immediately that this is just a shift operation, mapping to at most a couple machine instructions. In certain other languages it's most likely an integer shift, too. Still, you have to carefully consider the context lest this simple shift expression causes synchronous I/O to some space probe near Mars

Re: 3.5 Years, 500k Lines of Go

#177

Post by maxxxxx »

dasil003 wrote: post #150
greenhouse_gas wrote: post #132

I happened to believe that a language should have one style. You want a functional language? Use it. You want a procedural language? Use it. You want an OOP language? Use it. They're all good, but not in one language. For example, you like FP idioms, and program everything with maps. I like for loops. You have to fix my code one day I'm on vacation. You think that it's ugly, and rewrite it as a map. I get back, bug c…

Even though I've written more ruby than anything else over the last decade, I have to agree with this. Ruby is nice OO language, but it's unabashedly multi-paradigm, and that leads to a lot of mess when you get a team with varying backgrounds the result is potentially a byzantine mix of procedural, object-oriented and functional styles.

When you are in a big project a multi paradigm language seems to be the only way for introducing new styles. In the stuff I am working on I can't just switch to a new language. I agree that this can create a mess though.

Re: 3.5 Years, 500k Lines of Go

#179

Post by runT1ME »

schmichael wrote: post #151

I'm 3.5 years into using Go exclusively as well, and this rings very true to me with regard to generics: > Interfaces are good enough 99% of the time. Generics would be really nice for generic data structures (heaps, trees, etc), but code generation is ok at that. Generics could allow for some nicer (and safer!) nil handling and error checking, but I think the benefits-vs-complexity are less clear than with generics…

>Generics would be really nice for generic data structures (heaps, trees, etc), but code generation is ok at that.

Either code generation is an implementation detail of generics, or this is an afterthought that adds incidental complexity and was almost assuredly better off being a core language feature.

>I think it's hard to quantify the massive benefit Go's simplicity is to onboarding developers

This is really only applicable to small applications using new languages where the main cognitive onboarding is learning a new language/paradigm. As soon as you reach a certain size of application, the frameworks, architecture and domain knowledge heavily outweigh the cost of learning even the most esoteric of language features.

>Any language features which increase cognitive overhead had better offer some extremely compelling benefits to outweigh an increased learning curve

I wonder what kind of language feature you're talking about? The whole idea of generics in a more functional oriented language is to reduce cognitive overhead. The beauty of parametricity is it takes things away from the developer to help them reason about the code!

Our (very large) team of engineers use this to great affect throughout our codebases. There is no such thing as a silver bullet, but this comes as close as I've seen in the 12 years I've been an engineer (from startups to a Fortune 10 company).

Re: 3.5 Years, 500k Lines of Go

#180

Post by dmix »

jd20 wrote: post #145
lloeki wrote: post #121

Earlier quoted context omitted.

Rails is the epitome of the magic philosophy. Stuff "happens" through inference because you touched some part of the code (check out routes, foo_{url,path} methods, url_for , and passing some models as argument to those), or the database schema (defining accessors from DB fields or adding features when magic-imbued names are used, such as type , version or foo_id / foo_type ). This makes one feel fast and powerful at…

I've been pondering this topic lately, as I come back to Rails (seems every few years I'll write a Rails app on the side, and my brain has totally forgotten everything since last time): one other way to look at this "magic", is it makes programming feel "intuitive". Not sure how to do something, I often find I can just "guess" the right and most natural way, and the code will just work. For that reason, I always feel…

I've had this same experience bouncing back to Rails for contract gigs. You always feel this temptation like you're missing out on 'real' programming, performance with low level code or super clever languages like Haskell or Clojure. But ultimately Rails is just a great programming experience for getting the job done.

Despite it's faults and the problems with using 'magic' frameworks like Rails it's a really great language/framework for what it's meant to do. And it still is in 2017 despite what some people say (although Elixir/Phoenix is getting there if it can reach the scale of adoption as Rails).

That's the end of the road lesson, that there's the right tools for different jobs. There is no 'perfect' solution. Not rabbit to keep chasing.

Either way though it's still good to get exposure to as many different languages as possible (low level ala C, easily parallel-based languages ala Erlang, some lisps, typed languages like Haskell, dynamic FP ala clojure, etc).

Post reply on HN