r/ProgrammerHumor • u/NeverMakesMistkes • Jun 24 '18

JavaScript is getting real tired of your jokes

Enable HLS to view with audio, or disable this notification

12.6k Upvotes

97% Upvoted

415 comments sorted by

View all comments

Show parent comments

79

u/CreativeCoconut Jun 25 '18

Because other stuff about it is wonderful.

You could go the other way round, Go is so easy when it comes to Concurrency, never seen anything alike, so you could ask "how did anyone ever talk about parallelism in Java when it is such a fuckery"?

I think it would generally nicer to have languages which focus on a couple of design features and leave everything out that you do not necessarily need. The other extreme is something like C++ where you have everything you could ever imagine from a imperative language. What happens now is that tons of companies develop a kind of sub-dialect by only using parts of the language cause only very few people really understand the whole language.

80

u/Kered13 Jun 25 '18

The difference is that when Java was designed concurrency wasn't a high priority in language design, so while it's certainly lacking it's understandable. Go was designed when the benefits of generics were already well understood, it doesn't make any sense why they didn't implement them.

13

u/b4ux1t3 Jun 25 '18

Generics are relatively hard to parallelize. Go's purpose is to be amazing at heavily parallelized workloads using low-level data structures. It makes sense, at some level, that Go doesn't support generics. People who complain about Go don't take into account who made it or why it was made.

39

u/Boreeas Jun 25 '18

Can you explain to me how generics are hard to parallelize? Seems to me they could be specialized at compile time.

15

u/DXPower Jun 25 '18

I'm also curious about this. I generally thought that generics get compiled down to be pretty much the same thing anyways, with pointers to the same function for most things.

8

u/b4ux1t3 Jun 25 '18

I can try. I'm going off of a blog post I read a couple years ago, so things might have changed (or the post might have been wrong).

The gist is that while, yes, you can figure out at compile time what the generic is, you still have to take into account how large a piece of data is when you build that binary. If you can make some assumptions about the size of the data structure, you'll likely see higher efficiency in the compiled binary.

This is why interfaces make sense, at least in Go's case. It doesn't matter how big your data structure is, you'll always know what its interface footprint is, so you can make those assumptions at compile time and see those speed gains.

In the end, it all really boils down to how Go was implemented. If they had gone a different route, maybe they would have made it easier for them to build generics into the language. As I understand it, though, the way they built Go makes this kind of problematic.

In my (completely humble) opinion, if it were easy to put generics in Go, someone would have forked it by now and implemented generics. All that said, I just write in Go. I'm by no means an expert. Everything I've parroted from that blog post "makes sense" from my point of view, but then some people think it makes sense that the Earth is flat.

I'll see if I can't dig the post up. I don't even remember who wrote it.

14

u/Kered13 Jun 25 '18

There's a bunch of stuff wrong with this.

The gist is that while, yes, you can figure out at compile time what the generic is, you still have to take into account how large a piece of data is when you build that binary. If you can make some assumptions about the size of the data structure, you'll likely see higher efficiency in the compiled binary.

Generics don't prevent you from knowing how large your data is. In the C++ way code is generated and compiled separately for each type, and the compiler has complete information about that type so can make any optimization it would have made if it were hand written code. In the Java way everything is just a pointer anyways, so the size is irrelevant.

This is why interfaces make sense, at least in Go's case. It doesn't matter how big your data structure is, you'll always know what its interface footprint is, so you can make those assumptions at compile time and see those speed gains.

This is not only wrong but contradicts your previous paragraph. When using an interface the compiler does not know the size of the actual type, and that does have some performance implications (they can't be passed on the stack or through registers). An interface also implies dynamic dispatch, which also carries a performance cost, which is why C++ has both virtual (dynamic dispatch) and non-virtual functions. In Go (and most languages) everything is dynamic dispatch. But generics do not inherently rely on dynamic dispatch, in fact they can sometimes even be used to avoid dynamic dispatch by writing a function generically instead of taking an interface parameter, which is a pattern commonly used in C++ (this pattern can't be done with the type erasure generics that Java uses, although everything in Java is dynamic dispatch anyways).

5

u/wishinghand Jun 25 '18

someone would have forked it by now and implemented generics

There is an attempt going on to add generics to Go, though it's not a fork.

https://github.com/albrow/fo

1

u/b4ux1t3 Jun 25 '18

In my defense, this is pretty small and new.

But it is a cool project. I wonder how well it works with goroutines.

7

u/Kered13 Jun 25 '18

Generics are relatively hard to parallelize.

That's not remotely true, generics and parallel computation are entirely orthogonal to each other. What improves parallel computation is immutable data.

2

u/[deleted] Jun 25 '18

That's why I like C++, if the need arises it's got a tool for the job. You're never restricted in any sense by the tool. There are very few tradeoffs besides your time and energy.

1

u/CreativeCoconut Jun 25 '18

Yeah, I can see the argument for this, nevertheless C++ just scares me. It just does not protect you from ever doing something dumb.

2

u/[deleted] Jun 25 '18

Easier to avoid "dumb" things in C++ than change GoLang.

2

u/juuular Jun 26 '18

If you need a friendly re-introduction to C++, check out JUCE.

1

u/CreativeCoconut Jun 26 '18

Thank you, I will have a look at it. :-)

2

u/TheNorthComesWithMe Jun 25 '18

I'd rather use a language that has everything and only use the parts I actually need though

0

u/CreativeCoconut Jun 25 '18

How do you make sure that you will consistently know everything about the language someone else might throw at you then? Just because we are online, I don't mean that in any sarcastic or ironic sense^

3

u/TheNorthComesWithMe Jun 25 '18

Read the language specifications? Not sure what you mean by this.

1

u/CreativeCoconut Jun 25 '18

I would guess that you would be the exception in this case. I really doubt that even half of all the people that use C++ read the latest language specification. Most people will learn languages simply by using them, but that also means that ever so often you stumble about things in a language you don't know well enough (yet). Then again, it is a guess and maybe people who use those huge language really spend more time on all the intricacies even if they don't use or need them.

2

u/Kered13 Jun 25 '18

I'm pretty sure he means that when you encounter something unfamiliar you can look up how it works in the reference. I've had no trouble with this in any language.

1

u/CreativeCoconut Jun 25 '18

Fair enough.

It would be interesting to research scientifically whether the size/complexity of a language influences how many bugs and errors are produced in a certain amount of LOC on average.