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

51–60 of 235 posts

Re: A year with Go

#51

Post by zak_mc_kracken »

vezzy-fnord wrote: post #28
zak_mc_kracken wrote: post #20

Earlier quoted context omitted.

> Erlang is probably the only true object-oriented language. And it's true because its creator says so right here, in this link!

Or because it does satisfy much of the Kay criteria for OO and encourages such programming styles.

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.

Re: A year with Go

#52

Post by istvan__ »

0xdeadbeefbabe wrote: post #19
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...

> 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 feedback from my IDE to tell me that I am doing it wrong also collapsing too verbose parts is a great thing. I don't use too much of IDE features but anything that I incorporated to my workflow over the years (very little, I keep it simple) is damn useful and I am pretty sure I would be slower without it.

Languages with small clean syntax do not require that much IDE usage, at least this is my experience. I never thought my Erlang workflow could be improved with something like IntelliJ. I guess having a REPL helps a lot.

Re: A year with Go

#53

Post by namelezz »

I always find it's difficult to navigate Go repositories on GitHub. Because there can be several source files under a package it's difficult to look for an implementation of a function or method. For Java, I can easily guess where the methods are by looking at import statements.

Re: A year with Go

#54

Post by pcwalton »

nemothekid wrote: post #27

> Adding proper mutexes to some of our code in production slowed things down so much it was actually better to just run the service under daemontools and let the service crash/restart. Can the author explain this bit some more? If adding mutexes slows down your code to the point where you would rather just deal with data corruption/races it seems to me that there are issues with your code, not the language.

Yeah, that seems weird. A properly implemented mutex is one atomic instruction in the uncontended path to lock and one more to unlock. And if you remove the mutex, you're turning "the contended path" into "the path that blows up your program". Atomic instructions can be painful on, for example, ARM (where they turn into load linked/store conditional loop + memory barrier) but they shouldn't be too bad on x86 servers.

(I have no idea how Go implements mutexes, though.)

Re: A year with Go

#55

Post by misframer »

namelezz wrote: post #53

I always find it's difficult to navigate Go repositories on GitHub. Because there can be several source files under a package it's difficult to look for an implementation of a function or method. For Java, I can easily guess where the methods are by looking at import statements.

godoc is very helpful for this. You can click on the name of a type or function and it will take you to the definition.

Re: A year with Go

#56

Post by threeseed »

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.

Compile times are largely irrelevant if you use something like JRebel, Play, Tomcat or the many other frameworks that support hot reloading. And Java is far broader and more flexible at concurrency than Go with libraries like Quasar, LMAX Disruptor and the many HFT contributed ones.

Let's also not forget that Java is significantly faster, has every library under the sun, has a dependency system that actually makes sense and you have seamless interop between multiple languages e.g. Ruby, Python, Scala, Clojure.

Anyone who thinks Go is an upgrade to Java is woefully misinformed.

Re: A year with Go

#57

Post by lobster_johnson »

meowface wrote: post #39
matthewmacleod wrote: post #34

Earlier quoted context omitted.

In some ways, this is correct. Go is much more simple and consistent than Ruby or Java, has a better deployment story, and better tooling in some ways. As a language, it's much less enjoyable to write. Yes, the concurrency primitives are much better, and that's a good programming tool. But to a developer coming from Ruby, code is often needlessly repetitive and obtuse to write. It ends up being overly verbose, full o…

I wish there was a language somewhere in between Ruby/Python, Elixir, and Go.

Have you looked at Nim?

Re: A year with Go

#59

Post by threeseed »

0xdeadbeefbabe wrote: post #19
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...

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

It takes me about 5 minutes to setup IntelliJ. And that includes the download.

And I would never want anyone in my team who was doing major refactoring work without an IDE.

Re: A year with Go

#60

Post by tomphoolery »

RyanZAG wrote: post #40
smegel wrote: post #3

> if I wanted a language built around concurrency I’d use Erlang or Haskell. And if you wanted a concurrent language that wasn't a functional language what would you use?

Probably Java (or other JVM lang) running something like Disruptor for high performance, or actor based libraries like Akka for general use case. No numbers, but considering how it's used in nearly all the bigger tech and finance companies, I'm guessing it probably has more use as a highly concurrent platform than anything else discussed here.

Another reason for their usage of the JVM could be because a lot of these languages specifically designed for concurrent programming either didn't exist or were in their infancy of real-world usage. Erlang was proprietary until 1998, and Haskell was not created by a large company. In the meantime, Sun was pushing Java everywhere they possibly could. So it makes sense that larger tech and financial firms, especially those who established themselves in the late 1990s (or descendants of such companies), would use the Java platform. There were also a lot more Java developers than Haskell developers, and there still are, and that's a big part of the decision-making process when choosing a platform.
Post reply on HN