331–340 of 367 posts
Go checks a lot of boxes for my ideal language for developing web services: Static type, C derived, has garbage collection, generates a single binary, supports concurrency very well, is opinionated, is small/simple, its community prefers to just use standard lib for most work, etc. Yes, Generics is an issue and so is debugging. But, overall, I can't think of many other options that check so many boxes. EDIT: I must h…
Earlier quoted context omitted.
For my money, Java is a pretty good language; there are only a couple of things that I think were real mistakes in the core language. And the JVM certainly performs. But the ecosystem around Java is very complex and hard to manage. Dealing with JVM configuration, webserver configuration, build system configuration, IDE configuration and God knows what else takes up all kinds of brain-space. And every so often the com…
> culture really needs to learn the value of the simple and explicit. This is true for any programming community.
Earlier quoted context omitted.
Best to assume that you will need to recompile a Go program yourself. If you don't have the source and know how to build it, you're in trouble.
I am a bit worried about accepting software from vendors written in Go given those circumstances. For example, the recent OpenSSL patches would be an example. Are the Go programs fine if I update OpenSSL or did they include OpenSSL's libraries statically? If someone writes a Go replacement for OpenSSL does that change the scenario. Given a lot of software makes it to my door written by government contractors for gran…
Running unmaintainable, unfixable binaries may be standard practice in other places but for Go it's not really viable. It's a different culture with different practices.
Earlier quoted context omitted.
> Go feels similar to where Microsoft eventually wants to be with .NET Core and their native compilation. Only in that it will end in a native binary. In any other sense Go is worlds behind.
In bloat, yes ;-)
Earlier quoted context omitted.
For my money, Java is a pretty good language; there are only a couple of things that I think were real mistakes in the core language. And the JVM certainly performs. But the ecosystem around Java is very complex and hard to manage. Dealing with JVM configuration, webserver configuration, build system configuration, IDE configuration and God knows what else takes up all kinds of brain-space. And every so often the com…
Just wait when Go EE becomes a thing. Then you will get testing frameworks, libraries each with its own generics workaround and cool interface spaghetti that looks beautiful in UML diagrams at the scrum wall room. People don't really get that before Java there was C EE and C++ EE, all with similar sins. One can change the language of the enterprise, but not what those architects do with them.
Perhaps the best thing for the language would be for it not to become too popular.
Earlier quoted context omitted.
I am a bit worried about accepting software from vendors written in Go given those circumstances. For example, the recent OpenSSL patches would be an example. Are the Go programs fine if I update OpenSSL or did they include OpenSSL's libraries statically? If someone writes a Go replacement for OpenSSL does that change the scenario. Given a lot of software makes it to my door written by government contractors for gran…
Go has its own crypto library that's maintained by a real crypto expert so that might not be the best example. Still, if they do find a bug, there will be a new release of Go and you (or your supplier) should be prepared to recompile. Running unmaintainable, unfixable binaries may be standard practice in other places but for Go it's not really viable. It's a different culture with different practices.
Well, since I cannot just patch a library, I am a lot more worried about the implications of Go programs being the "unmaintainable, unfixable binaries".
Earlier quoted context omitted.
Actually JNA is actually way better than Go or JNI. And if you are looking at Kotlin / Scala you won't find yourself inside the object-oriented pain. The JVM is actually not that bad.
I agree with you. But this code, does not compile List [] j=new List [10]; and this is a a serious problem. If generics are correctly implemented, then it should compile.
val j = List(1, 2, 3)
Earlier quoted context omitted.
> Do you think this large pool of programmers are good? Yes, why not? I have yet to see evidence that Java programmers are not good. Seems like a discriminatory mindset. The large pool also makes them easy to replace. I think Facebook has had an ad for an Erlang developer for a few months now. I don't think a startup needs that kind of stress. Also, I'm sure there are Java Devi who are absolutely fantastic. That is,…
Eh, most of my post was an emotional response because of my hatred of the java language. Your reasoning I mostly agree with. I do agree, the JVM is a solid language choice. I also don't think going with too esoteric of a language is a good thing. Probably a little early to bet a company on Idris or Ceylon. Still, I apologize for my tone. Let me give you purely anecdotal information about me, so you can at least see w…
It's all good! I've had the same heat of the moment responses on here, so I get it. But thanks anyways.
> If a startup is using java, I think to myself 'why java? why not Scala, F#, or C# at the very least?'. Usually the answer is 'scala/F# programmers are too hard to find', but that's not really true, what they mean is they're not willing to pay the 20% premium for them. That's a strong indicator that a start up doesn't value talent.
Definitely. If I chose the JVM or (blanking) the Microsoft VM I would not limit myself to the object oriented languages for those platforms. I was under the impression that using multiple languages was a given, but apparently not? I wouldn't know, I'm doing iOS right now (hence the username). I graduated fairly recently, so I can only go off of what I've read.
So, I would probably do Java and Scala together if that was possible. I really haven't looked into it. My startup was completely hypothetical.
Earlier quoted context omitted.
That may be stated too strongly, but the argument is in a statically typed language you go to all the trouble to provide the compiler with sufficient amounts of information, but then don't leverage that in your editor. E.g. if you call a statically resolved function, your IDE should be able to take you to the function's definition.
Go was designed to make tooling easy, and that tooling has been written: https://github.com/nsf/gocode/blob/master/README.md And it's pretty trivial to get Vim super integrated with go: https://github.com/fatih/vim-go/blob/master/README.md
An Integrated Development Environment?
Earlier quoted context omitted.
Java doesn't require an IDE either: emacs/Ant/Maven is all I've ever used. Barring specialized platform-specific toolsets (like Android Studio) you don't NEED anything else (you might WANT something else, but that's a separate issue...)
Either you are very good, or you are working on small projects. Can't say which! Java is 100-ton dinosaur to be working with using a simple editor. Spring, it dependencies, hibernate, junit alone make you want to work with an IDE.