231–240 of 254 posts
Earlier quoted context omitted.
Or they tend to just Go. Interestingly, I've read a lot of Go users come from the Ruby and Python communities.
It's the Never Java crowd who I just don't get. Java is almost always the most practical answer. And if you don't like Java, then use C#.
Earlier quoted context omitted.
If Go ever gets adopted by the enterprise for full stack applications, not only devops related stuff, expect enterprise architects to come up with GoEE .
SwiftEE looks far more probable as IBM has already jumped on Swift on server thing. The no-GUI and no-framework Go is not helping Java style solutions.
Just wait and it will come, it only needs a bit of enterprise architecture caretakers.
JEE might have its flaws, but it is way better than any C or C++ enterprise stack I have used before, definitely better than CORBA for example.
Earlier quoted context omitted.
C is just as unsafe as Assembly, as the weekly CVE entries prove. The only differences between C and a powerful macro assembler like MASM, is that C is portable across CPU architectures and exposes less internals. Rock solid? With all the UB that Assembly actually doesn't have, and the types of memory corruption issues shared with Assembly programming, not really.
My point is that safety or otherwise of the target language is just not relevant. Even C has compile errors if you use the wrong type for an operation. Assembly largely does not. Taken to the extreme, any language ultimately goes down to machine code. So if it was a relevant fact, it would be relevant for all languages.
There are strong typed assemblers, e.g. IBM i.
Also Assemblers don't remove code under your feet, like optimizing C compilers with their UB tricks happen to do, introducing security bugs.
Earlier quoted context omitted.
The most effective way to handle these kind of errors in Java unfortunately requires understanding class loading, thread contexts, wrapping connection primitives in the right kind of references, and then making sure that all resource deallocation/closing always use the same codepath. Even though you really only need to implemnt it once, it is both somewhat tricky and technically challenging. It's a pity that so few J…
Yes, I did spend large parts of my java developer looking at class loaders and class loading delegations in servlet containers etc. I think it's a bit too hard to get it right. Like, suddenly some third party library starts pulling in log4j and your whole logging setup goes wrong in subtle yet very bad ways. Or you screwed up with that one reference to a ResultSet and even though it is closed, that reference keeps an…
Earlier quoted context omitted.
Never touch a running system ;) Scala on JVM is much more tested than the new shiny thing. Also don't expect improved performance... many people think that the JVM is bloated and makes programs slower (this is mostly not true). The downsides of the JVM are more memory consumption/footprint (when you have e.g. small servers or micro instances) and the cold startup time of the JVM itself (which is not relevant on a ser…
> the cold startup time of the JVM itself (which is not relevant on a server in comparison to desktop Java apps). I disagree somewhat with this. We found that when we started writing microservices in languages that are not java, the short startup time changed how we did some error handling. For errors where we say lose connection to the database, or rabbitmq, we much rather have the nodejs-process die and restart, th…
We run our Scala apps on Aurora/Mesos behind a load balancer (hundreds of instances for just one app). If there's an issue that can't be handled within the app and error rates breach a given threshold, Aurora just kills the instance and creates a new one on another host.
Earlier quoted context omitted.
Statically compiled languages like Go do not.
Well, there are two separate questions here: 1. What should the default be? Java build systems default to building dynamically linked, though it's a few lines to change. IMO dynamic is a better default for large projects, as you usually have more library modules than executable modules. On the other hand a large project is likely to already involve a fair bit of build config, so maybe the defaults should be optimized…
As of Go 1.8 it also provide plugin support though I am not sure if they are any where near Java in term of dynamic libraries loading support.
Earlier quoted context omitted.
Well, there are two separate questions here: 1. What should the default be? Java build systems default to building dynamically linked, though it's a few lines to change. IMO dynamic is a better default for large projects, as you usually have more library modules than executable modules. On the other hand a large project is likely to already involve a fair bit of build config, so maybe the defaults should be optimized…
There are plenty of large projects like kubernetes/docker/rkt/influxdb/tidb/cockroachdb and so on. Go is providing quite large memory efficiency and sub-millisec GC as compared to Java. As of Go 1.8 it also provide plugin support though I am not sure if they are any where near Java in term of dynamic libraries loading support.
Earlier quoted context omitted.
SwiftEE looks far more probable as IBM has already jumped on Swift on server thing. The no-GUI and no-framework Go is not helping Java style solutions.
> The no-GUI and no-framework Go is not helping Java style solutions. Just wait and it will come, it only needs a bit of enterprise architecture caretakers. JEE might have its flaws, but it is way better than any C or C++ enterprise stack I have used before, definitely better than CORBA for example.
Earlier quoted context omitted.
No downvote from me. But a explanation why e.g. compiled binaries are better. I had a hard time to get a normal non fancy Scala Play project running on a 512MB DigitalOcean instance. Mostly because it needs a lot more ram for building. I solved it with using a bigger swap partition. With single binary precompiled programs this problem is more a developer machine problem than a infrastructure problem. So I think the d…
You shouldn't build it on the deployment server. You build a jar and upload/download that to/from the place you want it to run, just as you'd do with an executable. A jar is "not binary" but what practical difference does that make?
Earlier quoted context omitted.
Go uses quite a bit less memory than Java. http://benchmarksgame.alioth.debian.org/u64q/go.html
As per the Specjbb benchmark, JDK9 compact strings optimization itself provides, * 21% memory footprint reduction * 27% less GC * 5% throughput improvments https://www.infoq.com/presentations/java-se-9-cloud - check this presentation for more details.