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

41–50 of 235 posts

Re: A year with Go

#41

Post by chc »

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.

Having tools that can spot errors early, help you track them down quickly and help you comprehend, organize and refactor your code can be very useful with a large codebase, and I don't think it's fair to characterize that as "you need an IDE that speaks the language in order to write anything efficiently."

Re: A year with Go

#42

Post by nickysielicki »

meowface wrote: post #38
nickysielicki wrote: post #31

> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell." Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay. I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is st…

> You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]). You linked to someone intentionally trying to obfuscate Python as much as they can. Programmers are certainly not "almost expected to abuse the language internals". All dynamic languages provide various means for code obfuscation... it doesn't mean the language encoura…

Fair point. It does not encourage it.

But it does allow it, and I think that means it inevitably creeps into a lot of code.

Re: A year with Go

#43

Post by solarexplorer »

edgyswingset wrote: post #32
eloff wrote: post #7

Earlier quoted context omitted.

Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.

C# has had excellent concurrency support for quite some time, and is most definitely a utilitarian language. Of course, the elephant in the room is needing a windows-based infrastructure ... but if that's not a huge barrier, it's not an unreasonable choice.

I keep forgetting about C# and F#, but with Microsoft embracing open source they may become actually interesting for people outside the windows world.

Re: A year with Go

#44

Post by felixgallo »

nickysielicki wrote: post #31

> "I just don’t understand the point of Go. If I wanted a systems language, I’d use C/D/Rust, if I wanted a language built around concurrency I’d use Erlang or Haskell." Agreed. C and Rust are systems langauges, Go is not particlarly great in that category. That is okay. I will say, I hope you have fun getting an average CS graduate to properly write and maintain a Haskell or Erlang program with concurrency. Go is st…

> But the fact remains, an average programmer can sit down today with no knowledge of Go, and by the end of the day create a concurrent program using Go.

If there's any benchmark more pointless than the alioth benchmarks game, it's the 'what can a novice programmer do with the language in the course of 8 hours' benchmark.

There are zero businesses that operate by giving novice programmers 8-hour tasks in unfamiliar languages.

Re: A year with Go

#45

Post by istvan__ »

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

I am not sure your definition of upgrade, but it is definitely a downgrade in terms of features even comparing it to Java. It has lean environment that makes it more attractive to systems programming and the CSP (channels, go routines etc.) make it great for concurrency. The trouble starts when you are shifting from systems projects to business logic projects. This is where Java runs circles around Go (or for that matter several other languages/environments). I wish Go had similar type system like OCaml.

https://functionwhatwhat.com/go%E2%80%99s-type-system-is-an-...

If I would like to teach something smart to software engineers I use OCaml, if I want to teach how simple things can achieve a lot I use Go. (They gonna end up programming in Java or Python anyways :)) )

Re: A year with Go

#46

Post by sanderjd »

baudehlo wrote: post #29
dvt wrote: post #12

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…

HN was the same about Node too. In a year we will see the same articles about Rust.

See also: AngularJS, Rails, etc. A lot of this is just because things that a technology makes convenient fade into the background after awhile because you know longer feel the pain you felt before you had them, but you are actively reminded of the things that annoy you about a technology multiple times a day. For example, with Go, fast static compilation and "just works" deployment fade, while the copy-paste-tweak pattern for generic behavior continues to bite. For Angular, you start to forget how much easier it made defining modular view components and having up-to-date data everywhere, while actively finding complexity and performance frustrating.

I'm sure you're right about Rust, and that people will be down on lifetime annotation burden, painful compilation times, painful data structure nesting, the complexity of unsafe code, and other things, while forgetting all the times things are actually easier, more performant, and safer due to all that language support.

I see it as a natural damping curve: at first things seem peachier than they really are, then they seem much more frustrating than they need to be, then you come to terms with their unique trade-off of strengths and weaknesses. What I would like to know – if anyone here has discovered such a thing – is a way to skip to the last step more quickly.

Re: A year with Go

#47

Post by skybrian »

dvt wrote: post #12

Funny how HN was on the Go bandwagon just a few years ago, and now an article like this is almost unanimously upvoted (without much contrarian discussion(!)). I contributed to Go in the early phases and I really enjoyed using it and learning it, but I found myself going to either Java if I wanted to write something for production or Node if I wanted to write something as a prototype. Unfortunately, I haven't used it…

I still like Go, but the Go discussions on Hacker News aren't that interesting anymore.

Re: A year with Go

#48

Post by istvan__ »

solarexplorer wrote: post #17
eloff wrote: post #7

Earlier quoted context omitted.

Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.

Other languages like Clojure, Python and even Javascript are catching up to Go and are adding decent support for concurrency too. But I would definitely prefer a functional language for a project that involves a lot of concurrency. "not a functional language" is a weird requirement.

Are you talking about Clojure? :) I am not sure what is the fuss about functional vs. imperative, you can do both in Clojure, both ways have a place in the programming toolkit. I think about functional programming as a philosophy. Nobody is going to despite me if I use swap! in Clojure or I use a mutable variable. On the other hand even when I am in an imperative environment I tend to use functions that keep the state in the parameters so the state is explicit and visible rather than a hidden something inside a class.

Re: A year with Go

#49

Post by wyager »

eloff wrote: post #7
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?

Or just a practical concurrent language with strong libraries that lets you be productive quickly. I'm aware of many of the theoretical benefits of Erlang and Haskell over Go. But Go is still a much better choice for getting things done.

>But Go is still a much better choice for getting things done.

What makes you say this?

Re: A year with Go

#50

Post by lqdc13 »

nickysielicki wrote: post #42
meowface wrote: post #38

Earlier quoted context omitted.

> You won't see anything like in python or perl where you're almost expected to abuse the langauge internals (see this awesome example in python [0]). You linked to someone intentionally trying to obfuscate Python as much as they can. Programmers are certainly not "almost expected to abuse the language internals". All dynamic languages provide various means for code obfuscation... it doesn't mean the language encoura…

Fair point. It does not encourage it. But it does allow it, and I think that means it inevitably creeps into a lot of code.

Strongly disagree. It is actually much harder to write obfuscated code in Python than in C. It even enforces whitespace... Here is "Hello World" obfuscated in many languages: http://codegolf.stackexchange.com/questions/22533/weirdest-o...
Post reply on HN