I loved VB6 so i like go really much...
Everyday hassles in Go
171–180 of 297 posts
Re: Everyday hassles in Go
#172Earlier quoted context omitted.
Go 1.5 is going to have real-time guarantees on GC.
"real-time guarantees" is not a particularly useful requirement as you can just set the minimum time very high to accomplish it. Real-time and low latency on the other hand would be a game changer, and I have pretty serious doubts about their ability to accomplish this.
Here's the current doc on it: https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...
Re: Everyday hassles in Go
#173Earlier quoted context omitted.
> I am looking for a replacement programming language to solve small problems for which Python/Ruby would have traditionally been used, good file system, stream and networking APIs, but concurrency as a first class citizen, garbage collected, fast startup time. You just described Go, mostly. I can't think of a more fitting language given your stated requirements. To your first point: I don't know what Go has to do wi…
Yes, I did describe what Go is good at, that's because I am trying to find something to put it against for what I use it for currently. Let's say I prefer Haskell's syntax/approach. Coming from Go, what could I be missing in Haskell?
Fast compile times, for one.
Re: Everyday hassles in Go
#174Earlier quoted context omitted.
"real-time guarantees" is not a particularly useful requirement as you can just set the minimum time very high to accomplish it. Real-time and low latency on the other hand would be a game changer, and I have pretty serious doubts about their ability to accomplish this.
Here's the current doc on it: https://docs.google.com/document/d/16Y4IsnNRCN43Mx0NZc5YXZLo...
I consider 10ms pauses to fall into the "set the minimum time very high" branch of my statement. That is, if you can handle pauses of that magnitude there are already lots of GC options for you and golang is not adding much (that said 10 ms pause guarantees are much better than the current so more power to them).
Even 1ms pause ceilings drive people to non-GC options, so I think the "game changer" number is much lower than that.
Re: Everyday hassles in Go
#175Earlier quoted context omitted.
I think editors solve that problem pretty well. I usually only have to type something like "fo" part of my collection name and another or 2 before I get down to business, no matter what language I'm using.
You only write source code once. You read and edit it many times, and your colleagues, users of your library, etc, read it many more times. The longer the piece of code one has to read, the easier it is to read it incorrectly, miss a bug, or introduce a bug.
This is just not true. Many simple lines are easier to read than fewer more complex lines. It's hard to miss a bug in
x = x + 1
foo[x]
foo[x++]Re: Everyday hassles in Go
#176Every time I read an article criticizing Go I end up appreciating it even more. Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax. Maybe it's because they exalt one line functional functions over a nice, simple, easy to read FOR loop when…
OTOH, I think is part of the point:
> file, err = os.Open("file.txt")
> if err != nil {
> ... handle error ...
Re: Everyday hassles in Go
#177Earlier quoted context omitted.
I think Haskell is a possible alternative to Go/Python/Ruby for these kinds of tasks. But nothing's perfect. Some possible annoyances you might encounter: * Much of the functionality required to be a valid "Python alternative" is not on the base packages. You'll have to install extra packages much sooner than with Python. And you'll have to know what packages to install. * Despite having proper sum types, most I/O li…
I found ocaml to be a more flexible alternative -- I can sprinkle printf for quick debugging without having to alter types. (I think this is what you mean by "having to use the IO monad". I didn't work with haskell much, so it's possible there's an easy way around this there.) And stack traces in ocaml are reasonable, though not quite as verbose as python's. But your point about needing to install extra packages stan…
You should look into Debug.Trace for quick printf-like debugging. Usage: trace ("error occurs here") (f x)
Re: Everyday hassles in Go
#178Earlier quoted context omitted.
> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive. Or why expose this interface {} feature and allow people to use it in a statically typed language? Peo…
Are generics really that important? Java didn't have generics for 9 or 10 years, C# only got them in version 2. C still doesn't have generics and I never heard anyone complain. As a former C# developer I would agree that life got easier with the introduction of generics, but you can develop the exact same software with and without generics.
> C still doesn't have generics and I never heard anyone complain.
People who would complain already know not to bother using C.
Re: Everyday hassles in Go
#179Earlier quoted context omitted.
> That said I do worry that the Generics argument seems to be slowly approaching a religious war that will distract people from the other enjoyable aspects of Go Because generics are important.We're not talking about crazy C++ templates here but a more rigid feature that would still make Go language more expressive. Or why expose this interface {} feature and allow people to use it in a statically typed language? Peo…
> Or why expose this interface {} feature and allow people to use it in a statically typed language? `interface{}` isn't anything special, or something akin to `void*`. Interfaces are a core part of the language, and `interface{}` is just the literal form for an "interface with no methods", which happens to match anything since all types can fulfill an empty method set. It's no different than using this `Something` f…
I'm assuming he meant why would they expose or promote the use of a construct that bypasses type safety in a statically typed language. Although `interface {}` is not some sort of special feature, it's still circumventing the type system.
Re: Everyday hassles in Go
#180Earlier quoted context omitted.
You only write source code once. You read and edit it many times, and your colleagues, users of your library, etc, read it many more times. The longer the piece of code one has to read, the easier it is to read it incorrectly, miss a bug, or introduce a bug.
This is just not true. Many simple lines are easier to read than fewer more complex lines. It's hard to miss a bug in x = x + 1 foo[x] But easier to miss a bug in foo[x++]
As an industry we have no objective measures for what makes code "better", so in many ways these debates are pointless. That said, I'd add 3 points to this particular thread:
1) You cherry picked one of the most confusing uses of operators (and sources of bugs) that we have. If it weren't so ingrained in our educations/history (and so useful for old fashioned looping semantics) I think we all would have moved on from ++ syntax a long time ago.
2) As flawed as it is, it is a well studied phenomenon that LoC is nearly the only measurable statistic we have that is predictive of error rates (that is higher LoC solutions tend to have higher bug counts).
3) The bigger point about looping constructs isn't about LoC in any case. It is de-coupling 2 different areas of code responsibility. One is the mechanics of iteration and the other is what to do on each event.
At the end of the day most looping constructs end up being sugar around while loops anyway, so the reductionist argument is all of it is unnecessary complication, just do everything in a while loop.