Everyday hassles in Go • Hacker News Board

Re: Everyday hassles in Go

#181

Post by oahziur » Tue, Dec 30, 2014, 5:42 PM UTC

llambda wrote: post #170

tarikjn wrote: post #61

I couldn't agree more with this article. I did some Go a year ago and liked it. Then coming back to it a year later after having done some functional programming in Clojure, it's not just the lack of generics that disrupt my flow but also having to think about all sorts of imperative programming details like naming and creating variables and scope placements in cases that would otherwise be unnecessary in a functiona…

> 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 may want to have a look at ClojureScript, which has come a long way in the last few years. While the tooling is still not as nice as Clojure-on-the-JVM in…

The "REPL via NodeJS" is amazing!!! I want to try ClojureScript on NodeJS for a long time. Now I can play with the REPL.

Re: Everyday hassles in Go

#182

Post by Retra » Tue, Dec 30, 2014, 5:46 PM UTC

jbooth wrote: post #127

rjberry wrote: post #117

Earlier quoted context omitted.

Paul explains fairly well why he thinks C++ is a good example of "worse is better", including quotes from the language designer to that effect. I think when you get to more complicated (or at least alien) abstractions like the I/O Monad, it's not about whether it's practical to build software with it. It's perfectly practical - I know people working at big investment banks writing large scale software in Haskell, and…

So he invested time in building up his straw-man before tearing it down? The problem with being in such a rush to confirm your own worldview is that you don't learn anything from anyone else's. The 'worse is better' philosophy is about valuing simplicity over completeness, specifically in the context of UNIX/C vs Lisp machines back in the 80s. How do you think most of those people feel about, say, the STL?

"Worse is better" doesn't preclude good design. Something like STL is fairly straightforward to implement, so it is not too hard to get it right.

C++ has a problem with bloat and 'tacked on' features, and that is clearly 'worse is better' design. Backwards compatibility is a huge indicator of this kind of thinking. Partial backwards compatibility is an even more egregious example.

Re: Everyday hassles in Go

#183

Post by ominous_prime » Tue, Dec 30, 2014, 5:55 PM UTC

TheHydroImpulse wrote: post #179

ominous_prime wrote: post #88

Earlier quoted context omitted.

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

You don't lose "type safety", as interfaces retain all type information -- you're not casting `void*` pointers (without the unsafe package), and type conversions are limited and well defined.

It however does pass the type checking to run-time instead of compile-time, which is a trade-off that some feel is worth the language simplicity.

Re: Everyday hassles in Go

#184

Post by rjberry » Tue, Dec 30, 2014, 6:16 PM UTC

jbooth wrote: post #127

rjberry wrote: post #117

Earlier quoted context omitted.

Paul explains fairly well why he thinks C++ is a good example of "worse is better", including quotes from the language designer to that effect. I think when you get to more complicated (or at least alien) abstractions like the I/O Monad, it's not about whether it's practical to build software with it. It's perfectly practical - I know people working at big investment banks writing large scale software in Haskell, and…

So he invested time in building up his straw-man before tearing it down? The problem with being in such a rush to confirm your own worldview is that you don't learn anything from anyone else's. The 'worse is better' philosophy is about valuing simplicity over completeness, specifically in the context of UNIX/C vs Lisp machines back in the 80s. How do you think most of those people feel about, say, the STL?

Not that it particularly matters whether we're talking about C++, as it's rather tangential, the original essay by Richard P. Gabriel that coined the term "Worse is Better" talks about C++ (http://www.jwz.org/doc/worse-is-better.html):

  The good news is that in 1995 we will have a good operating system and programming language; the bad news is that they will be Unix and C++.

In his later essay on the same topic (http://dreamsongs.com/Files/IsWorseReallyBetter.pdf) he again talks about C++:

   In the computer world, the example of interest to JOOP readers is C++. Many would concede that languages like Smalltalk, Eiffel, and CLOS are vastly “better" in some sense than C++, but, because of its worse-is-better characteristics, the fortunes of object-oriented programming probably lie with C++.

Simplicity is more often simplicity of implementation than interface. Anyone who's worked with the C standard library knows that it's anything but simple. There's a lot of incidental complexity that is due to design inconsistencies. The complex parts of a language like Haskell are the bits where the ideas themselves are complicated, but the power you get for overcoming that initial learning curve is very great.

Re: Everyday hassles in Go

#185

Post by dangerlibrary » Tue, Dec 30, 2014, 6:20 PM UTC

rjberry wrote: post #129

ominous_prime wrote: post #118

Earlier quoted context omitted.

Expanding a map to a for loop is very simple. Yes it removes a shortcut available when writing code, but when reading code I can consume that simple chunk of logic in one mental bite just as easily as I can a call to map.

Sure ... but if a loop is effectively doing a map, a filter, and a bunch of other operations all at once? It's a lot quicker to figure out what's going on if it's been written with combinators (once you're familiar with them) than if it's the vanilla loop.

It can be a lot less performant to chain several combinators.

Re: Everyday hassles in Go

#186

Post by NateDad » Tue, Dec 30, 2014, 6:21 PM UTC

friendly_chap wrote: post #160

hahainternet wrote: post #82

Earlier quoted context omitted.

Your article is unbelievably arrogant. You should have been honest, not dishonest. These aren't everyday hassles, these are hassles you have selected to promote Haskell.

I write Go exclusively during my day job - these are indeed chores I encounter daily. I could and probably will blog about problems with the Haskell as well - nothing is perfect.

FWIW I thought the article was fine, when though I love go. I do think it reads like you wish you could use Rust or something. It is nice to hear about hassles from someone who has actually used the language for a change. Not every language is for everyone, that's OK. Obviously, most people who love the Haskell style of type classes and pattern matching are going to find much packing in go. That's OK.

Re: Everyday hassles in Go

#187

Post by protomyth » Tue, Dec 30, 2014, 6:25 PM UTC

TazeTSchnitzel wrote: post #38

mrweasel wrote: post #33

Earlier quoted context omitted.

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.

Java would be a lot nicer to work with had it had generics from the beginning.

That's one of the big problems with adding major features later, the standard libraries don't get rewritten to fully use the new feature.

Re: Everyday hassles in Go

#188

Post by Roboprog » Tue, Dec 30, 2014, 6:27 PM UTC

vardump wrote: post #122

zzzcpan wrote: post #76

Well, I want Go to have refcounting instead of current GC, so my programs could guaranty latency. Single-threaded runtime, without all the locks, slow channels, races and so on, because there is no point in so much overhead and complexity for the majority of programs. More consistency couldn't hurt, so I wouldn't have to assign anonymous function to a variable just to return it. Fast regular expressions compiled by t…

You don't like locks, but you want refcounting that requires a large number of atomic ops for acquire/release semantics and thus scales like crap? Ah, you really mean, single threaded as in no other threads? Well... ok. But that'd make Golang a lot less useful. For compiled regular expressions: just use PCRE library for compiled regular expressions. I bet there's already some library that does it for you. Maybe you s…

Mmmm. Threads + mutable data. What a disaster this industry has unleashed upon itself. Blech.

I think that threads are easily up there with null/nil as one of the worst CS mistakes. Communicating via shared variables at the application program level, vs an IPC function / channel, seems like a noose that should be designed away from reach.

Re: Everyday hassles in Go

#189

Post by theseoafs » Tue, Dec 30, 2014, 6:29 PM UTC

NateDad wrote: post #166

falcolas wrote: post #135

Earlier quoted context omitted.

Not every problem can be solved with the standard library. At some point you need a 3rd party library, which may require your modification to work with your data types.

The point is that everyone assumes you need generics to reuse code. And that's simply not true. For some very specific problems that can be true, but in many many cases it's not. My point is not that you never need anything outside the standard library, just that the standard library does a hell of a lot and it is by definition reusable.

Go's standard library uses generics a lot. In fact, Go's built-in datatypes are the only parts of the language that are allowed to use generics.

Re: Everyday hassles in Go

#190

Post by theseoafs » Tue, Dec 30, 2014, 6:32 PM UTC

zzzcpan wrote: post #133

vardump wrote: post #122

Earlier quoted context omitted.

You don't like locks, but you want refcounting that requires a large number of atomic ops for acquire/release semantics and thus scales like crap? Ah, you really mean, single threaded as in no other threads? Well... ok. But that'd make Golang a lot less useful. For compiled regular expressions: just use PCRE library for compiled regular expressions. I bet there's already some library that does it for you. Maybe you s…

Refcounting and a single threaded runtime, instead of GC and a multithreaded one. By compiled regexpes, I meant replacing things like bytes.Equal(foo, "qwe") with things like foo.m(`^qwe$`) or even foo.m/^qwe$/ that have the same performance. All the loops that scan through slices could benefit from it, golang has a lot of them. Plus more overall matching/scanning consistency, that should lead to fewer mistakes.

Go would need to be completely rearchitected in order to move to a single-threaded runtime.