191–200 of 220 posts
Earlier quoted context omitted.
Or a generic list, vector, map...
Go's native synonyms of lists, vectors and maps are already "generic", so I'm not sure what your point is.
Earlier quoted context omitted.
> I'm not sure what the cause is, but it definitely gnaws at me. Here's my hypothesis: programming language are made for people to use, and people spending time thinking about designing Watson, don't want to spend it thinking about expressing their program using lambda calculus. The only group for whom the stuff they develop coincides with language concepts are those writing compilers. So they get confused because th…
Or, in other words, advanced languages have some cognitive overhead that people working on extraordinarily complex applications can't spare? Maybe. Then again, I've been using C++ again recently and I feel like the cognitive overhead there is so huge that I can barely understand my simple programs. Nonetheless, Microsoft pretty much runs on C++ (and C#).
Sometimes, I get so frustrated by how weird the syntax can get (the templates always confuse me to the point I have to stop and slowly read the code before I get its meaning)!
Earlier quoted context omitted.
Yes, Go is boring, but it's interesting that the people who hate on Go for being boring are not the same people who hate on Java for being boring (though Java 8 is much improved).
People don't hate Java for being boring, per se. They hate it for being inflexible, verbose and having a bureaucratic culture.
What does it mean for language to be "fun"? I have some intuition of "fun", but it doesn't play well with what are you saying. I'd say being "fun" means ability to solve your problems easily, concentrating on problems themselves, not on language pitfalls. Isn't it? That's pretty much synonymous (maybe a little broader though) to "productive". So I can't comprehend how language can be "less fun, but more productive and maintainable".
Earlier quoted context omitted.
Go's native synonyms of lists, vectors and maps are already "generic", so I'm not sure what your point is.
Except the containers aren't typed. They are essentially containers of void*. If you believe that to be "generic", then you don't understand the topic.
Earlier quoted context omitted.
Lack of polymorphism isn't even close to the most common objection to Golang. The most common objection is the lack of generics, which make it tricky to write reusable container libraries. Golang comes pretty close to flat-out rejecting object orientation. It's only barely more object-friendly than C is. If you're the kind of programmer that wants to model a problem domain or build code with the Smalltalky feel that…
Apologies, polymorphism is a loaded term that could mean different things depending on your background. I mean parametric polymorphism , i.e. generics. What makes you unexcited about them?
> I wanted a fast, compiled replacement for stuff I write in C right now. But Go is not that language. You should look into Rust. It sounds like it might be more like what you're looking for.
On the other hand, if that's the kind of thing that excites you, Rust is a really great option right now.
Earlier quoted context omitted.
I think tptacek may have implying that, like all the REPLs for C, the REPLs for Go are more curiosities than anything anyone would want to use.
REPLs are for toying around and learning. The Go playground provides an alternative that seems to satisfy these needs for most people. If people really missed a Go REPL then the existing ones would not be "curiosities".
Really shines when the language / REPL has decent introspection, is able to break out into the REPL prompt in the middle of your code with in-scope identifier lookups, and you're dealing with lots of libraries that you don't necessarily have encyclopedic knowledge of, yet need to get the job done under time pressure.
At least that's how I use REPLs, most usually, pry in Ruby.
These sorts of posts are profoundly boring. I know people will up arrow it -- some sort of spiteful "Down with Go!" contrarian thing, when they aren't talking up rust -- but it isn't because the content is interesting or illuminating, but rather as some sort of activist thing. This particular piece (by a high school student, as an aside) starts off trying to create a surrogate for generics in Go. Don't . Here's the t…
The number of times you'll wish you had a generic red-black tree or linked list in your life: many, many times. The number of times you'll need a generic map or fold algorithm to operate on those structures: many, many times.
https://github.com/petar/gollrb
So if you need a data structure like this, you can do it without much trouble without generics. Perhaps you don't feel that solution is as clean, but it's certainly pretty easy to do.
NB that golang has not ruled out generics, it's just not something they felt compelled to put in initially, and not many people who use the language miss them.
Earlier quoted context omitted.
I honestly am not sure I follow what your concern is with that line of code. list.New() looks extremely clean to me.
You frequently have packages that are named after generic nouns, like time, host, file etc. There are many contexts where this same generic name makes for the best variable name: clear, short, and easy to type: func ReadFile(filename String) { file := file.Open(filename) } In Go you have to invent a new name, so invariably you will see a lot of: theFile := file.Open(filename) aFile := file.Open(filename) readFile :=…
a couple of times I just changed the name of the import, as you sometimes do in Python:
import (
urllib "net/url"
url := urllib.QueryEscape(...)
tada!
Earlier quoted context omitted.
People don't hate Java for being boring, per se. They hate it for being inflexible, verbose and having a bureaucratic culture.
I don't really get what all you guys mean by "boring". I'd appreciate some clarification (especially about Go). What does it mean for language to be "fun"? I have some intuition of "fun", but it doesn't play well with what are you saying. I'd say being "fun" means ability to solve your problems easily, concentrating on problems themselves, not on language pitfalls. Isn't it? That's pretty much synonymous (maybe a lit…
Go offers very little that's interesting or innovative and doesn't go out of its way to empower you in any particular way. It's fairly straightforward and tries to avoid gotchas, which is both good and bad. This means writing code is easy and you're unlikely to make a mess, but there are relatively few opportunities for making your code read better or to structure it better.
In a nutshell: Writing code is more of a drudge than an art.
For example, I was recently writing a processor for some data that came in an XML file format. I figured maybe throw it at Go since it was a lot of data and Go has pretty good XML support. In Go, this was a lot of looping and copying and basically nothing all that confusing but it just felt like busywork. For fun, I decided to write it in Clojure as well. The Clojure version was much more pleasant to read, with all the loops disappearing into simple compositions of map, reduce and filter. It felt nice to be able to easily express things in such an elegant way instead of on a more machine-like level.
(To be clear, I am not a great Go programmer and wouldn't want to speak for the Go community, though this is something the language creators seem to agree with. I'm just trying to explain what how I understand this stuff.)