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

201–210 of 249 posts

Re: 3.5 Years, 500k Lines of Go

#201

Post by greenhouse_gas »

oxalorg wrote: post #193
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…

I completely agree, and it's one of the reasons I've liked Python. From the zen of Python: There should be one-- and preferably only one --obvious way to do it.

This is my problem with modern day Java.

Java is an OOP language.

OOP languages communicate through message passing.

So why do modern UI frameworks use callbacks?

Re: 3.5 Years, 500k Lines of Go

#202

Post by tigershark »

user5994461 wrote: post #192
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…

>>> I think it's hard to quantify the massive benefit Go's simplicity is to onboarding developers -- especially for a new language where hiring experienced devs is next to impossible. The ease of onboarding is reason enough for businesses to consider Go as over an org's life a lot of time will be spent (wasted?) onboarding. Agree. I feel it so much. I stopped counting the companies I couldn't join because they had ex…

Accordingly to your logic then we should have no language other than C because everyone had decades worth of experience in that language and was not interested in starting fresh again. From my point of view I was very relieved when imperative languages and their adept seemed finally to embrace better tools after Y2K. Apparently now there is Go that follows up with that style (that was perfectly fine for a 10 years old ages ago) and it is making again adepts. For me this new spring of imperative languages seems more like the winter of programming. The only "new" language that captured my interest is F#, but obviously all the go proponents will be horrified by the simplicity of type providers and all the nice "magic" things that are not easy unless you spend at least half an hour of your time to understand them.

Re: 3.5 Years, 500k Lines of Go

#203

Post by bogomipz »

Does anyone know where this developer is going after Canonical or why they left? It seems like they got to work on a nice project while there. Maybe that's another blog post though. It piqued my curiosity I guess.

Re: 3.5 Years, 500k Lines of Go

#204

Post by sciurus »

goatlover wrote: post #144
weberc2 wrote: post #63

Earlier quoted context omitted.

> But I wonder how it really scales on a large code base like this? Some of the best projects I've worked on leverage usability more effectively to create a sort of vocabulary. They're far more concise, there is rarely more than one source of truth, they're far easier to change and improve. Does this hold true for 540,000 lines of go code? Doesn't this article speak to this? It mentions juju has over a million lines.

Yeah, but there is no comparison to the same project done in Lisp, Haskell, Java, etc. All the author is doing is relating their success using Go, which is great, but there is no comparison to how it would have fared in another language, except his previous frustrations with C#, on other projects, I guess.

Juju was originally written in Python. They ported it to Go 4 years ago.

https://groups.google.com/forum/?fromgroups=#!topic/golang-n...

Re: 3.5 Years, 500k Lines of Go

#205

Post by pcwalton »

kornish wrote: post #187
rbehrends wrote: post #159

Earlier quoted context omitted.

> Any language features which increase cognitive overhead had better offer some extremely compelling benefits to outweigh an increased learning curve. This is a common misunderstanding that occurs (I think) because most people only know C++-, Java-, and C#-style generics, which can be conceptually complicated, because of the often tricky interactions with the type system (or, in the case of C++, the use for metaprogr…

It struck me the other day that when using Go codegen tools which generate packages based on a template, e.g. [0], the Go developer is doing manually what the OCaml compiler will do with functors at compile-time. The concepts are fundamentally the same...the effort just happens in different places. [0]: https://github.com/cheekybits/genny

They're very different. Generics in languages that have them are typed—you have to declare up front the methods that your generics support. That's the entire thing that makes ML functors functors.

By contrast, generics in languages like C++ and D, as well as the code generation tools for Go, are untyped—you can call whatever functions you want on your types, and if it doesn't work it fails at template instantiation time. This causes the confusing template errors people see in C++.

Re: 3.5 Years, 500k Lines of Go

#206

Post by pcwalton »

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…

Since you can write for loops in anything other than a pure functional language, this is equivalent to saying that, unless your language is pure functional, it shouldn't have any FP features in it. I think this is obviously false: Ruby is not any worse for having the map method.

Re: 3.5 Years, 500k Lines of Go

#207

Post by solidsnack9000 »

eloff wrote: post #103
akinalci wrote: post #92

Earlier quoted context omitted.

> rather carefully avoids coming anywhere close to addressing the legitimate criticisms of Go as a language. The "criticisms of Go are addressed every time the language is discussed: in practice, generics are rarely missed. They would be nice to have, but their absence is outweighed by other benefits of the language. Critiques of Go tend to be principal-based: "Go doesn't have features X, Y, and Z, therefore it canno…

It's clear that if a powerful language was such a competitive advantage, languages like Haskell would rule the world - instead they're hardly used for business projects. Along comes Go and in 8 years people have built more production code with it than probably all the functional programming languages of the world combined. If that's not true yet, it will be soon the way the trend is going. And those languages have be…

It does seem like Rails -- which relies heavily on Ruby features for speed of development -- has been a big part of the strategy of Silicon Valley startups for many years.

Re: 3.5 Years, 500k Lines of Go

#208

Post by solidsnack9000 »

jerf wrote: post #72
jasode wrote: post #66

Earlier quoted context omitted.

>... Go language users must be ignorant of all these other wonderful features. All of your comments are reasonable but I don't think it addresses what grabcocque was complaining about. It seems grabcocque was criticizing the writing about Go but others seem to be interpreting it as an insult to Go programmers . They are 2 different things! (My guess is that the word "blub" triggers the misinterpretation.) All of the…

"Whenever I see a writer talk about "magic", "simplicity", "spooky action at a distance", etc it usually turns out that the author picked adjectives that sounded good but not well-defined enough for readers to learn anything useful from it." A valid objection. Here's my personal definition for "magic", which is still a bit fuzzy around the edges, but much more solid than most loose definitions of it: A bit of code is…

I suspect you would have the same problem as you see in Python, in any situation where you use code generation with Go.

Re: 3.5 Years, 500k Lines of Go

#209

Post by geodel »

brightball wrote: post #166
eloff wrote: post #103

Earlier quoted context omitted.

It's clear that if a powerful language was such a competitive advantage, languages like Haskell would rule the world - instead they're hardly used for business projects. Along comes Go and in 8 years people have built more production code with it than probably all the functional programming languages of the world combined. If that's not true yet, it will be soon the way the trend is going. And those languages have be…

To be fair > Along comes Go Really means > Along comes Google It's nothing against Go, but we have to be realistic that having Google's weight behind it significantly increases its marketing while also making business owners a little more comfortable (aka - a modern nobody ever got fired for buying IBM). There are a lot of frontend frameworks out there but React and Angular dominate largely because of Facebook and Go…

> we have to be realistic that having Google's weight behind it significantly increases its marketing

It also increases no of expert engineers contributing to project full time.

Re: 3.5 Years, 500k Lines of Go

#210

Post by sheepmullet »

sagichmal wrote: post #194
pjmlp wrote: post #172

Earlier quoted context omitted.

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.

> From CS point of view + is just a function name just like any other. From a Go point of view, it isn't.

The point is in most languages operator overloading is no more complex than a method call.

It's not exactly magic.

Post reply on HN