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

Why Go Is Not Good

yager.io

Post reply on HN
Print view View original

341–350 of 367 posts

Re: Why Go Is Not Good

#341

Post by jacquesm »

ScottBurson wrote: post #324
jacquesm wrote: post #209

Earlier quoted context omitted.

In three letters: NIH. Management decision was that all IP had to be 100% owned by the company and had to be in 'C', in spite of an enormous amount of friction between C and the project as well as a bunch of work by others that could have been leveraged if we had decided to use code from other contributors. I got called in long after these decisions were made and it was very clear they weren't going to budge on those…

So you had to write your own compiler, operating system, and runtime libraries too? -- I know, you didn't think it made any sense either. I'm just pointing out that a line has to be drawn somewhere; where it gets drawn is actually arbitrary. Yeah, I've had to deal with ridiculous mandates from on high too, though none anywhere near that onerous. In my previous job, we were writing a compiler. It was mandated to be in…

> So you had to write your own compiler, operating system, and runtime libraries too?

I tried that line and it did not work.

Re: Why Go Is Not Good

#342

Post by stcredzero »

illumen wrote: post #253
axman6 wrote: post #188

Earlier quoted context omitted.

Haskell makes Go's concurrency and composition look primitive and restrictive while also giving you safer code with generics. This isn't an area that Go wins at unless you're comparing it with C, not anything modern. The lack of generics is also not a primitive issue, neither is the ease at which people can write unsafe code. You can write as unsafe code as you like in Haskell, but the pat5h of least resistance also…

Haskell uses less code to do the same thing. Haskell holds your hand and checks more things for you. Haskell code runs from two times, to five times faster for CPU based code, and lets you scale to insanely higher concurrent workload in a safer way. Why Go? Because marketing.

Smalltalkers used to complain that:

    Smalltalk uses less code to do the same thing.
    Smalltalk lets you offload bookkeeping to the runtime.
    Smalltalk code often runs faster for actual business workloads.
    Smalltalk lets you add features faster with fewer bugs.

    Why Java? Because marketing.
But doing this is was a waste of community time and energy. A better thing to do is to build cool stuff.

Re: Why Go Is Not Good

#343

Post by loup-vaillant »

nwmcsween wrote: post #333
loup-vaillant wrote: post #260

Earlier quoted context omitted.

Generics generally simplify code, you know. Plus, generic code tend to make guarantees non-generic code cannot. Picture this function: foo :: (a -> b) -> (b -> c) -> (a -> c) What does it do? As you can see this function takes 2 arguments, which appears to be functions. It also returns a function. The argument and return type of these functions are unknown, so you can't manipulate them. You can just pass them around…

Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it. A better form IMO is restricting the types allowed as it: 1. makes understanding much easier, 2. Doesn't create bloat in the form of n copies for visible symbols.

> Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it.

This is backward. A function, polymorphic or otherwise, does not influence code that does not call it. Modulo far-reaching side effects of course.

It's when you look at the call site that you have to figure out what this strange `fold` function could possibly be about.

I'll grant that polymorphic functions are often more abstract than monomorphic ones. But they are simpler. They are also better at separating concerns. Take `map` and `filter` for instance. They capture common iteration patterns, so you don't have to entangle that pattern with the actual logic of your loop. Without parametric polymorphism, you could not write them (more precisely, you would have to repeat yourself over and over).

> A better form IMO is restricting the types allowed as it: 1. makes understanding much easier

That's just false. If you restrict the types a function can operate on, you allow the function to do more things to its data. The more you know about its input, the less you know about the function. With parametric polymorphism, you are actually hiding information from the function, preventing it from making whole classes of mistake. Free tests!

Parametric polymorphism makes functions that use it simpler (as in, less moving parts). How could that possibly be harder to understand? Please give a concrete example, I don't understand where you're coming from right now.

> 2. Doesn't create bloat in the form of n copies for visible symbols.

That's an implementation detail, and mostly false anyway. Not every language is C++. Most languages that make use of parametric polymorphism don't duplicate code.

Re: Why Go Is Not Good

#344

Post by sergiosgc »

stcredzero wrote: post #339
sergiosgc wrote: post #331

Earlier quoted context omitted.

I agree. That is a correct reading. Where I do not agree is on the assumption that a basic feature set can be construed as a simpler language. While true for the language proper, it isn't true for real usage of language plus libraries. Take operator overloading. It can be used to create hellish code. It can also be used to create great libraries (numpy for instance). Because of the danger of hellish code, Go makes it…

Is it necessarily a good idea to make Go into a number crunching language?

I have no idea, but that is irrelevant. It is an example. I'm sure you can imagine others in the use case you define for the language.

Re: Why Go Is Not Good

#346

Post by nwmcsween »

loup-vaillant wrote: post #343
nwmcsween wrote: post #333

Earlier quoted context omitted.

Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it. A better form IMO is restricting the types allowed as it: 1. makes understanding much easier, 2. Doesn't create bloat in the form of n copies for visible symbols.

> Parametric polymorphism does not simplify code, it obfuscates it as now you have to see _what_ is calling it. This is backward. A function, polymorphic or otherwise, does not influence code that does not call it. Modulo far-reaching side effects of course. It's when you look at the call site that you have to figure out what this strange `fold` function could possibly be about. I'll grant that polymorphic functions…

> A function, polymorphic or otherwise, does not influence code that does not call it.

Obfuscate does not mean influence, it obfuscates it you now have to follow the rabbit hole to where the type information is (language detail but it is how almost all parametric polymorphism is) which makes reasoning about it a pain.

> That's an implementation detail, and mostly false anyway.

No it's not 'unbound' parametric polymorphism in a compiled language has to produce symbols for any visible (not internal) function as there would be no way to know what might get called.

> Most languages that make use of parametric polymorphism don't duplicate code.

Yes any compiled language does how on earth would you call a symbol that took a bool vs a size_t (I recommend you look at how ELF works). On somewhat related note a sufficiently smart compiler could 'deduplicate' common parts of the slow path within a generic function and create calls but that's about all it could do for deduplication without performance hits.

Re: Why Go Is Not Good

#347

Post by stcredzero »

coldtea wrote: post #227
stcredzero wrote: post #101

Earlier quoted context omitted.

Depends on your particular value of "better." If you're optimizing for programmer time, writing a language in Go is not a bad tactic. You get out of having to write your own GC, you can incorporate a few nice concurrency features with little effort, and you still get pretty good performance. (Admittedly, far from the best performance, though.)

> You get out of having to write your own GC No, you really don't. The built-in GC is nothing like the GC needed for lots of other languages.

The built-in GC is nothing like the GC needed for lots of other languages.

Don't write those languages in Go.

Re: Why Go Is Not Good

#348

Post by Daishiman »

personZ wrote: post #268
Daishiman wrote: post #173

Earlier quoted context omitted.

But the fact that Go proponents don't actually have solutions to those problems is an issue. How do you make a custom, generic data structure without syntax overhead? I have not seen any counter proposal to this aside from "maps should be enough for everybody". How do you avoid the noise from not having operator overloading or a similar alternative? This, again, goes unadressed. What are the succint alternatives to f…

How do you make a custom, generic data structure without syntax overhead? In real-world code, the need for generic data structures is shockingly uncommon. It really is. This requirement exaggeration comes about by people acting as language tourists, building amorphous code of uncertain purpose, where things like "I'm going to sum up a bunch of unknown objects" seems like a serious need. For most people who find Go to…

You're not answering my question. I have a bunch of numeric code where I have dense matrices, sparse matrices, diagonal matrices, etc.

I have heterogenous priority queues where I want to push in JSON data and plain strings, I have custom iterators, concurrent data structures, default dictionaries, etc.

Seriously, look up Python's itertools and data structure modules and realize that there's a wealth of things that are useful and practical and, above all, reduce code size while preserving interface contracts and semantics. Go is completely unsatisfactory in this regard.

Re: Why Go Is Not Good

#349

Post by kazuho »

Type inference and operator overloading often leads to less-readable code.

IMO when evaluating programming languages, we should not only consider writability but also its readability. This is especially true if many engineers are going to be involved in the development.

It is good to have type inference and operator overloading in terms of writability. Nobody wants to type verbose code.

OTOH some verbosity within the source code helps reading the code. And type information (which type inference and operator overloading tries to hide) is one of them.

So I can respect Go's decision not to support operator overloading / only support some part of type inference.

Re: Why Go Is Not Good

#350

Post by ScottBurson »

jacquesm wrote: post #341
ScottBurson wrote: post #324

Earlier quoted context omitted.

So you had to write your own compiler, operating system, and runtime libraries too? -- I know, you didn't think it made any sense either. I'm just pointing out that a line has to be drawn somewhere; where it gets drawn is actually arbitrary. Yeah, I've had to deal with ridiculous mandates from on high too, though none anywhere near that onerous. In my previous job, we were writing a compiler. It was mandated to be in…

> So you had to write your own compiler, operating system, and runtime libraries too? I tried that line and it did not work.

Huh. I wonder how they defined what was acceptable and what wasn't.

Oh well, I'll be fascinated to read the book if you ever write it.

Post reply on HN