strictfp

How can you tell if you've been hit?

When I tried to research this last time I heard that dd-wrt were more on top of CVEs than OpenWRT, so I picked them. No idea if that's correct though

Java development scales, it has pretty good performance, and great tooling.

I agree that it's underhyped. You can pick a lot of other languages, but no other language is as broad as Java.

Python reads like a dream but has useless perf and threading.

Javascript (Node et al) has the I/O concurrency but no clear solution to threading, and is bad at number crunching.

C++ has good perf but is overly complicated, compiles take forever, no good module management, etc.

Rust is great but super-hard to learn.

Golang lacks tooling and perhaps some libs, albeit being a really good contender.

Naturally there are other languages to bring up, but I personally think that Java strikes a good balance. The language itself doesn't really have any clear weak points anymore. With lambdas and streams, even FP is succinct in it.

The only thing really speaking against Java right now is the culture of overly complicated frameworks with too much meta-programming and magic. And the fact that the market of lightweight alternatives is too fragmented.

I left Java due to the culture.

I actually think the core language is great. And under Suns management Java was largely what golang is today; it was the pragmatic choice and it put the focus back onto writing code and away from complicated language features.

Then IBM stepped in with JEE, and it completely transformed Java into a language for bureaucrats and over-complicators. JEEs ethos was that the programmer is stupid and that the framework saves the programmer from their own stupidity. Not the greatest of ideas if you ask me.

Sane people jumped to newer languages. I tried to stick around and argue against bureaucracy, but in the end I realized the pointlessness of it all.

Now I'm ironically back with c++, but still the community is much purer and focusing much more on actual coding than snake oil.

Still write Java on my spare time and love it for it's relative ease of use, speed, and clarity. Not the most portable, ironically, but my language of choice for prototyping.

Java still has some true high quality libraries in it. I'm yet to find a good replacement for Doug Leas concurrency libraries in other languages. And the containers are great. And despite all the flak it gets, I actually think Swing is really good for whipping up a simple UI.

Bedrock is by far the most popular version of Minecraft.

It's the version used on all handhelds and consoles.

Been following this one. Just think it's telling of how medium prio bugs go unsolved for ages in big software projects.

I agree the it can be a problem, but it wouldn't be this bad if they didn't build on a local machine, didn't include symbols or stripped the binary. All standard practice.

Our project got bitten by this hard. I was under the impression that they did this to enable memcpy/memmove into structs, which didn't feel completely motivated if you ask me.

Interesting! Do you mind elaborating a bit? I ssh into WSL for this reason.

One possible solution to this is removing systemd from all distros. That way you won't need it for your package manager anymore.

Push-ups is taking time to understand fundamental constructs. Everytime you are surprised by the language, take the time to understand why it behaves that way. Making this into a habit will grow your knowledge and give you core strength so to speak :) You will be able to progress from trial and error into diagnosing and correcting problems.

I agree, and the bug in the report is likely not the only one caused by these changes.

No worries. The gaming industry has its own set of problems for sure, so I'm not claiming it's inherently better in any way :)

I'm glad to hear if your major challenge in the enterprise was to solve actual problems and produce real value. My journey was mostly learning one over-complicated framework after another, and finally coming to the conclusion that it was mostly for nothing. I was the local Spring expert, but at the same it's biggest critic. The "code", or more accurately the configuration, gets very consise, but you risk ending up with only a handful of people in the building who know how to debug the app properly.

I started coding Java when Sun marketed it as a very pragmatic choice, focusing on "simply writing code". The influence of IBM and the whole JEE movement (including Spring) still looks at the problem of coding from the wrong angle IMO.

Creating a good development environment is not about creating a all-in-one runtime environment or methodology, nor about simplifying the problem space for developers by letting them write plugins to large servers.

It's about establishing a fast RAD cycle and offering a buffet of good libraries, to simplify the writing of code.

Java used to be the language which allowed you to "just program", nowadays the mainstream choices are golang or node. To me it's become very clear that Java is on the wrong track here.

There are an infinite number of distractions as a coder, including Microservices, responsive design, functional purity, patterns etc.

If you managed to duck most of these and end up in a place where you were producing value effectively, you were very lucky judging by my experience :)

I'm not refuting that businesses can be complex, but I am saying that most of the complexity I've seen hasn't been inherent to the business.

That is true. I don't really refute that there are instances of complex rulesets. I've worked in some regulated markets, but not healthcare or insurance.

That said, I stand by the point that most complexity I've seen has come from infrastructure. Because although the rulesets might be complex, the way they are encoded is usually the source of the problem IMO.

For example, if the rules of the business are encoded in such a way that unit testing them is straight-forward, it puts the business at the center.

But when every rule is testable only in a complex deployment, the complexity of the app is no longer tied to the complexity of the business.

And the latter has been more the rule than the exception in my experience.

I'm sorry, having extensive experience writing enterprise apps I have to refute this. Almost all complexity I've ever seen was rooted in infrastructure, not the inherent complexities of said enterprise.

I would even go so far as to say that the enterprise logic was so straight-forward that most programmers spent their time inventing problems, which is how look at the enterprise market. They's a lot of "inner platforms", meta-problem solving and needlessly complex deployment environments.

Contrast this with my current industry, gaming. Here the problems are real, tangible and hard. Suddenly overcomplication is much less of a problem, because the extra cognitive load becomes too much when your core problem is already hard.

Enterprise apps are complex because they don't focus on solving the business problem, they focus on the tools and frameworks.

Spring is not the cure, it's the disease.

But technically it's UB, so you shouldn't use it.

Meh, it's not like there can't be a bug in whatever other parsing code a webserver uses.

Maybe using a float is overkill in this case, since you're never going to hit more than a hundred languages. But it's at least not setting any limitations.

cstheory stackexchange discussion: https://cstheory.stackexchange.com/questions/1300/integer-fa...

You can also use the original web page model; the state is on the server, every button click generates an action to change state, and the updated ui is regenerated fron scratch based on the new state.

You cannot trust established players either. For instance, cheaper Samsung phones ship with a lot of shady software, as I found out helping relatives.

And a lot of reputable software companies have sold out to peddling adware. Adobe is one, and there are a lot of others. Abandoned shareware or open source often resurface with adware installers.

The argument is made on a system level, not on a single binary level.

Given many dynamically linked binaries, it's relatively easy to patch say OpenSSL on a system.

If all binaries are statically linked, you need to relink all binaries and push new versions of each one.

Maybe they could offer you IPv6 cheaper?

That's assumed common knowledge for non-graph theory specialists.

Avoiding public transport goes a long way when avoiding colds. Could that be it?

I've used the AWS metadata trick as well. I kind of liked the solution; better use something that the machine is already relying on than adding something extra.

DNS is also usually a much better option than the framework-specific service discovery mechanism that every framework seems to be destined to reinvent. I think the problem is that most computer scientists aren't very well-versed in networking, and DNS doesn't look like the best match at first glance.

Maybe we should think about the consequences of making retention the number one KPI?

Rust is tricky. Took me about a year to grok decently.

Regarding references, the compiler does flow analysis and tries to enforce a sort of static rwlock semantic on variable level. You either have a single mutable reference xor N readable references to the same variable.

If b is a mutable reference to a, c cannot point to a until b reliquishes the "lock", which happens when b goes out of scope.

Take what he writes with a grain of salt. Highly productive people like himself likely gets free rein, and so they're looking at the process with rose-tinted glasses.

I've worked with some of these process gurus, and sadly most of them are describing the ideal situation rather than how it works in practice for the average joe. And if they're into publishing this kind of material, they might also make it look better than it really is.