News for hackers. Stuff that matters.
Re:Why We switched from Python To Go by thomastjeffery on Sunday April 09, 2017 @11:52PM (#14075866)
> much better languages.

I disagree. Java has a bloated syntax, and C++ is a mess. Java also depends on a proprietary runtime, with mostly compatible free alternatives.

The biggest advantage C++ offers is speed, through memory management, which is usually a pain to deal with.

Go, on the other hand, has a well thought out syntax, good support for concurrency, garbage collection, and compiles to native executables.

Re:Why We switched from Python To Go by yummyfajitas on Monday April 10, 2017 @12:28AM (#14076020)
Could you illustrate what you mean by "bloated syntax"?

Everything else you mention (besides native executables) Java also has. From what I can see, Java provides far better concurrency support - more paradigms than simply go routines.

Re:Why We switched from Python To Go by thomastjeffery on Monday April 10, 2017 @01:32AM (#14076303)
Classes are required. Sometimes I just want a c-style program without a class. Java looks a lot like C++ (just with garbage collection, and some more consistently defined behavior). In comparison, golang (and rust) have some nice syntactical differences: inferred types, postfix type annotations, etc.

Go routines are nice when that is all the complexity you want. Having more paradigms isn't an interesting prospect until it becomes specifically useful.

Java may be more usable in many cases, but it, in my experience, just isn't easy to work with.

Re:Why We switched from Python To Go by yummyfajitas on Monday April 10, 2017 @05:26AM (#14077077)
Apart from the boilerplate enclosing class (4 lines, vs 2 in C), you can write a C-style program without classes in Java. There is literally nothing stopping you and generics are helping you significantly for this.
Re:Why We switched from Python To Go by thomastjeffery on Monday April 10, 2017 @04:19PM (#14082174)
That's completely true, but I just don't like the boiler plate. It's not hugely important to the grand scheme of things, but the more barriers I have from writing a function to running code, the less I want to deal with the toolchain/language in the first place.