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

Seven years of Go

blog.golang.org

Post reply on HN
Print view View original

131–140 of 318 posts

Re: Seven years of Go

#131

Post by randomdata »

pvsukale3 wrote: post #85

Question : Is there a possibility that when Go package management is launched there will be a good opinionated framework like rails for GO . Because for new learners ORM , authentication etc things matter a lot. I know Go promotes use of native HTTP package instead of frameworks but it is a large barrier for newcomers and have risk of writing error-prone web applications.

I'd suggest no. If Rails is the right tool for the job, there is no reason to not use Rails.

If Rails is not the right tool for the job, reimplementing Rails on top of Go isn't going to make it the right tool.

It is possible that some future "killer app" will emerge out of the Go ecosystem like Rails did with Ruby, but the effort to build something like Rails to duplicate Rails is not a particularly good use of someone's time.

Re: Seven years of Go

#133

Post by defgeneric »

aikah wrote: post #50
gtrubetskoy wrote: post #24

I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…

> Many of the "old" ways of thinking do not apply to Go Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. And it's funny when you talk about the "old" ways of thinking in language that basically promotes C styles errors and bad macros through go gen. When I say the language is broken, look at Go type system, then look at how Go reflection makes the languag…

While I'd like to have generics in go, one of the upsides of the lack of generics is that your code becomes less idiosyncratic and more idiomatic. Too often in C++ for example, I find myself frustrated reading code where templates are unintentionally over-used because the programmer needlessly introduced an abstraction where the concrete would have sufficed. There is a certain pleasure in moving from the concrete to the abstract and finding the inner connection between things, but this can also get in the way or distract from the immediate problem.

The same issue comes up in Common Lisp where you find a codebase with heavy use of macros which effectively build a DSL within the program. Working alone, this can be fun, and can produce elegant code, but it means anyone new to a project needs to first familiarize themselves with the world you've built.

When many people work on a project it helps if everyone speaks the Queen's English, as it were.

Still, generics would be nice.

Re: Seven years of Go

#134

Post by pcwalton »

weberc2 wrote: post #118
pcwalton wrote: post #79

Earlier quoted context omitted.

My experience is the exact opposite. Most of the people who I work with now using Rust did not know any Rust at the time they were hired. There haven't been any major problems at all. Do you have experience that shows otherwise?

I'm a former C++ dev. I've made repeated attempts to learn Rust over the last few years. I now feel like I'm capable of building things with much effort and frustration and constant Googling, but with a small fraction of the effort. By comparison, I got to the same point in Go in an afternoon.

I'm not interested in debating which language is easier to learn for C++ programmers. I'm pushing back against the (clearly false, IMO) idea that adopting Rust is a mistake.

Re: Seven years of Go

#135

Post by the_af »

cdelsolar wrote: post #119
keymone wrote: post #115

Earlier quoted context omitted.

a = flag ? b : c is much more readable and concise than if flag { a = b } else { a = c } battling habits by making useful code inconvenient is just sad

It's more concise, but certainly not more readable. You lose a few seconds writing it the second way. It's fine.

To me the ternary operator is more readable. It has way less extraneous symbols, it is expression-oriented and lets you focus on what's really happening: that something gets assigned to a based on some condition. It expresses intent better than the if-else.

Sure it can be abused and nested beyond human comprehension... just like if-else! So that's a non-argument.

Re: Seven years of Go

#136

Post by the_af »

mseepgood wrote: post #111
aikah wrote: post #95

Earlier quoted context omitted.

Nesting if/then/else don't make code more readable either.

Then apply the usual programming rules to un-nest the code.

The same can be applied to the ternary operator: apply the usual programming rules (and common sense).

Re: Seven years of Go

#137

Post by Skinney »

wyager wrote: post #120
weberc2 wrote: post #98

Earlier quoted context omitted.

Efficient concurrent programming. I'm not aware of any cross-platform C/C++ or Python libraries that give you async I/O + multi-threaded coroutines. Such a library exists for the Java ecosystem (quasar), but IIRC, it's enabled by clever bytecode tricks, so it's not built with vanilla Java. Further, you still have to take care not to use any libraries that are incompatible with this concurrency model (e.g., anything t…

Precisely as I said, "The only major benefits over, say, C++ or Java (which I don't think are very impressive languages) are a few convenient threading primitives" 99% of projects don't need green threads. But for those that do, I'd much rather use a language better suited to the purpose, like Haskell or Erlang. This isn't a very convincing argument for Go.

Erlang isn't necessarily better than Go in this regard. Since Erlang is interpreted and everything has to copied between processes, Go is bound to be faster than Erlang, especially when it comes to parallelism. Go is also statically typed, which in my experience makes it easier to avoid bugs in large teams.

Erlang, however, is much better at distributed concurrency. There are few who suits this use case better.

As in all cases. Use the best tool for the job.

Re: Seven years of Go

#138

Post by stcredzero »

aikah wrote: post #50
gtrubetskoy wrote: post #24

I have decided to get proficient in Go about 3 years ago and I am glad I did. One of the discoveries in the process was that Go enables you to do things that previously were extremely difficult and you'd typically not even consider as options. Many of the "old" ways of thinking do not apply to Go, and I had to get over the phase of looking for an ORM or webapp or testing frameworks - they don't exist because they are…

> Many of the "old" ways of thinking do not apply to Go Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant. And it's funny when you talk about the "old" ways of thinking in language that basically promotes C styles errors and bad macros through go gen. When I say the language is broken, look at Go type system, then look at how Go reflection makes the languag…

Whatever. Just because the language is effectively broken doesn't make practices in other languages irrelevant.

Classic. All languages stink, somewhere. The classic programmer Dunning-Kruger mistake: evaluating one language without self-awareness of all of the (probably unconscious) cost/benefit optimizations that mostly apply to the other language. This is like Smalltalkers and C++ programmers in the 90's arguing about the design decisions that went into Java.

Your definition of "effectively broken" actually means "doesn't fit my preferences." I'd expect "effectively broken" to more usefully mean "basically, very few people want to use it in production." Smalltalk now fits that. (Mostly through bad business/marketing decisions and incompatibility with mainstream programming expectations.) I bet there's many, many languages you might even call "elegant" that fit that as well.

basically promotes C styles errors and bad macros through go gen.

Funny, but my experience is that Golang basically eliminates my dealing with those. I'm writing an MMO, and my debugging time in that category amounts to literally 2 minutes. (Basically, oh duh, that member function should take a pointer reference. Otherwise, it can't mutate state!)

When I say the language is broken, look at Go type system, then look at how Go reflection makes the language look a dynamically typed one.

If you're such a poor programmer, that you can't get about the same level of type safety around array code in a Golang environment, as say, in a C++ environment, then just find a different language. On the other hand, if you can show an increase in productivity doing it your way in some kind of A/B quantitative comparison on actual production level code, then go ahead and take that show on the road. Go to conferences, write papers, and get yourself a nice consulting business preaching your gospel, getting paid, and advancing the almost-a-field of programming. Otherwise, just stop making noise and trolling.

To be fair, there are some languages with pathologies that are publicly apparent, like PHP with webapp security and C with security exploits. There are problems with programming in the large with C++ -- some involving the very features you probably think are admirable. If you have experience with Golang in production, and you've tried mitigating the type-system weaknesses to get compile-time or test-time warnings out of the tooling, and this incurred your company some cost, then talk about that. Otherwise, you are just making worthless angry programmer noise devoid of grounding in actual practice.

Re: Seven years of Go

#139

Post by chmike »

AsyncAwait wrote: post #106
be_erik wrote: post #3

Go isn't a perfect language, but it strikes the right balance for me between productivity and safety. There are few other languages right now with the same ease of deployment, good tooling, excellent standard lib, and raw performance. Here's to another seven years.

> strikes the right balance for me between productivity and safety. Would be curious to hear what "safety" you're referring to, is it just that it has a basic static type system, (which is constantly being undermined by interface{} and reflection), or is there more to it? Genuinely curious.

Compared to C it is safer. I never saw a segmentation fault, only some panic errors with bound checking.

I prefer go to python or javascipt. It's far too easy to make errors in them. Minimal static code checking.

Re: Seven years of Go

#140

Post by greendragon »

lelandbatey wrote: post #86
greendragon wrote: post #18

Earlier quoted context omitted.

Curious what they weren't so happy about with Python? Was it purely performance? If so, did they consider PyPy, or at least profile what the slowest bits are so they can evaluate whether to throw everything out or just rewrite the slow bits? Was it the language itself? Not everyone likes dynamic languages, though it's odd they started with it. Did you consider Node at all?

For me, it's the extremely straightforward conventions of Go, with it's straightforward tooling, and it's strong typing. I "grew up" on Python, wrote a lot of code in it, and love it. But it doesn't feel as cohesive as Go. As an example of cohesive tool design, let's look at Go package management. In Go, if I want to install a package, I install it with: $ go get github.com/pkg/term Having installed this package, I i…

It was pretty bad that easy_install came out with no easy_uninstall. Plus some packages are in your system's package manager (which I think is great because I'm sick of every language having its own package manager when my system's (Gentoo) is better) and some aren't, or the latest versions aren't. Plus there's the virtualenv stuff, or the general problem of your dev environment not matching the deploy environment. Needing to have both Python2 and Python3 on your system in some cases. Some packages have C/C++ code so you need a compiler, and all the dependencies that implies. On Windows I think Python development is a joke, last time I did anything extensive there I think I ended up installing Enthought's distribution and picked off from http://www.lfd.uci.edu/~gohlke/pythonlibs/ as needed. I don't see how the Go situation on Windows could be worse than that.

I'm not a huge stickler for non-local consistency -- one of the things I like about Nim is its apathy about naming conventions (foobar is the same symbol as foo_bar or fooBar, func(arg) is the same as arg.func()...) -- so that's probably why I don't find the consistency factor a huge issue. When a language and its ecosystem has it, it's nice, but when it doesn't, it's not really a thing that annoys me.

Post reply on HN