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

A year with Go

vagabond.github.io

Post reply on HN
Print view View original

191–200 of 235 posts

Re: A year with Go

#191

Post by zak_mc_kracken »

vezzy-fnord wrote: post #66
zak_mc_kracken wrote: post #51

Earlier quoted context omitted.

Nobody follows Kay's definition of OOP. And I bet you're going to say "But he coined the term!". Yes. He's still making up his own definition twenty years after the industry gave its own, so whatever he says on the topic is moot.

Several things to note here. Firstly, I don't know at what exact point did Kay come out in demystifying OO (1998 or so?), but the design principles of Smalltalk and messaging date back to publishing in 1974, with many references to it afterwards. Secondly, the idea that there is one singular definition of OO that the industry has standardized on is absurd. Object models differ semantically from language to language,…

> But by all means, Erlang embodies many OO design principles

That's interesting because Armstrong himself thinks that OO sucks:

http://harmful.cat-v.org/software/OO_programming/why_oo_suck...

Re: A year with Go

#192

Post by tptacek »

coldtea wrote: post #149
tptacek wrote: post #113

I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous . Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undenia…

> I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Since when was compile time an interesting aspect to judge a programming language? More in the "nice to have" category, especially if your program is not 1 million lines and/or your language's compiler doesn't provide some modularity in this regard.

Have you ever worked on a large-scale C++ project?

Re: A year with Go

#193

Post by taylodl »

twic wrote: post #72
mikeokner wrote: post #11

I think the author gets closest to the mark in the Conclusion, but still falls short. Go is very attractive as an "upgrade" from Ruby/Python or Java. It's a good replacement for the interpreted languages when speed/performance matters and it makes the async paradigm feel much more accessible. And compared to Java, the fact that Go compiles to a native binary is a huge benefit. It's not a replacement for C or a good "…

> And compared to Java, the fact that Go compiles to a native binary is a huge benefit. I'm baffled by this. I've been deploying Java applications for years, and this has literally never been a problem. You build a WAR (or EAR, or uberjar, or distzip, or whatever). You install a JRE on the machine. You deploy. You're done. It's never been a problem for me, and it's not something that's talked about as a problem in th…

I'm surprised you didn't mention Java compiles to byte code which is then JITed for the processor on which you're currently executing - I don't need to recompile for every platform and I still get native performance. This has been Java's primary strength since the introduction of JIT. Even better, I don't have to use Java to create the byte code. My favorite happens to be Clojure but you have several language options to suit your needs.

Re: A year with Go

#195

Post by wglb »

coldtea wrote: post #149
tptacek wrote: post #113

I could be wrong, but I feel like when people talk about how great the Golang tooling is, what they're really saying is "the compiles are instantaneous". I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous . Write a better one! Golang is not an especially impressive programming language --- as a language. But it seems to me like it is an undenia…

> I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Since when was compile time an interesting aspect to judge a programming language? More in the "nice to have" category, especially if your program is not 1 million lines and/or your language's compiler doesn't provide some modularity in this regard.

> Since when was compile time an interesting aspect to judge a programming language?

Since compilers were dog slow.

When using irb or lisp or smalltalk, my productivity is off the charts compared with C++, in no small part to the compile time.

Re: A year with Go

#196

Post by waps »

istvan__ wrote: post #52
0xdeadbeefbabe wrote: post #19

Earlier quoted context omitted.

> IDE's Lack of an IDE is a feature not a bug. Edit: or it is a symptom of a feature. No one has written one yet because they are happy with what they have. > tooling Do you mean you need an IDE that speaks the language to write anything efficiently? Do you mean your first day on the job is spent setting up tools? Wrong philosophy in my opinion; I could imagine something better.

Depends the definition of IDE. My IDE is VIM. Why is it an IDE? Because it understand the text I am editing. An editor does not understand it. Anything, that supports programming on the top of an editor an IDE feature in my view. If you definition of IDE is IntelliJ than it is a different problem. I cannot edit Java without it anymore, Java is just too verbose and too many things can go wrong, I need immediate feedba…

I for one can't edit large programs - period - without IDEs. Refactoring is not optional once a program exceeds a certain size. A lot of problems that people try - usually unsuccessfully - to catch with tests simply don't occur with refactorings.

And I notice the same about Go programs that I used to have with python programs. They grow and grow, and beyond a certain size, the basic architecture "freezes" and no more changes are possible because nobody can fully grasp all consequences of edits.

Re: A year with Go

#197

Post by rlonstein »

nostrademons wrote: post #18
zak_mc_kracken wrote: post #15

Earlier quoted context omitted.

In my experience, Go is a lot more attractive as an upgrade from Ruby or Python. It's a very steep downgrade from Java on all points imaginable: type system, exceptions, genericity, garbage collector and runtime, tooling, IDE's, etc...

It's an upgrade in terms of compile times, deployment simplicity, conciseness, concurrency, etc. Some people care about such things.

   > It's an upgrade in terms of compile times, deployment simplicity, conciseness, 
   > concurrency, etc. Some people care about such things.
I remember the days of going for coffee while the compiler chugged away but I wonder what compiles people do on a regular basis that take such time? I just rebuilt SBCL here on a mid-2012 MBP and it took less than 6 wallclock minutes in the background including download and whatever else I was doing:

   real	 5m12.752s
   user	 4m33.393s
   sys	 0m27.579s
I personally use D when possible, but waiting on compiles is usually secondary to the amount of time I spend thinking or exploring.

Re: A year with Go

#198

Post by k_bx »

Dewie3 wrote: post #180
wz1000 wrote: post #158

Earlier quoted context omitted.

> I don't care for Haskell for anything remotely related to "work" Why not? Haskell seems perfect for this task. It has fast, robust and safe concurrency and GHC's IO manager is highly optimized and insanely fast.

As a * nix geek it's beneath his station. Welcome to the flip side of the academic ivory tower , the scoff at academic stuff because it doesn't "get shit done" .

It does "get shit done" for us perfectly, and type-system only helps here. So I still don't see why it's not suitable for *nix geeks. Give it a try!

Re: A year with Go

#199

Post by coldtea »

tptacek wrote: post #192
coldtea wrote: post #149

Earlier quoted context omitted.

> I'm sure he's right that the coverage tool isn't 100% perfect, or even 60% perfect. OK. Fine. The compiles are instantaneous. Since when was compile time an interesting aspect to judge a programming language? More in the "nice to have" category, especially if your program is not 1 million lines and/or your language's compiler doesn't provide some modularity in this regard.

Have you ever worked on a large-scale C++ project?

No, but then again, as I wrote in a comment just above that one:

"I don't think most teams outside of Google and some C++ or Scala shops have had any issue with "long compile times" for that to have been a major factor."

Re: A year with Go

#200

Post by [deleted] »

serge2k wrote: post #173
fixxer wrote: post #108

Today, I got a request for a secure message passing service from our CTO. My group, which is a small team of 2 *nix geeks in a company with ~20 mostly c# developers, has become a bit of a skunkworks operation as we have been responding to external constraints and forced to move quickly. I was able to implement the service per the provided spec in 179 lines of Go in about ~2 hours. Stress tests passed. The job is done…

you could also have written it in Java, or C#, and been done quickly with a solid result. Not sure why you didn't compare to 2 languages at about the same level, and instead went with a lower level and a higher level language.

[deleted]
Post reply on HN