In Log4J WTF news today…

[cvi]

@dkf Log4j just took to the next level. With it somebody else could also get lots of detail about the application (and the system it's running on) without rebuilding the whole thing. Genuinely useful to somebody out there.

[Rudolf Polzer]

It gets even better. Even after all the patches, if the log pattern contains $${ctx:something} and the something comes from user input...

then this can lead to a cl${lower:}assic. If admins ever rely on e.g. logged usernames, and usernames can contain this, then this can be used to frame another user of the website and get them banned.

Also, putting ${java:} in such a map entry causes the entire message to not get logged at all (instead, log4j will log a huge useless exception backtrace).

[Gąska]

@Rudolf-Polzer you'd think "just disable this super overcomplicated and totally useless extra feature that adds no value and just do the simple thing instead" would be easy for the developers to do. But these are Java developers.

[LaoC]

@dkf said in In Log4J WTF news today…:

@error said in In Log4J WTF news today…:

I find YAML pretty easy to use for my config files

It's not too bad for config files, but it's pretty awful for some of the other things that JSON and XML are used for.

To be fair, everything is awful for the things XML is used for, prominently including XML.

[LaoC]

@dkf said in In Log4J WTF news today…:

@hungrier said in In Log4J WTF news today…:

One of the projects I've worked on made extensive use of per component configuration, even setting up a separate TRACE level logger for one particular component

The good thing about using a logger (as opposed to just printing to stdout) is that you can get lots of detail in some parts of the application without rebuilding the whole thing or getting lots of detail from other parts. Some people never make use of that, but it is genuinely useful.

Sure, also for the visual distinction of "stuff that's supposed to be read by the user" and "stuff that's being logged for technical reasons" in the case of an application that uses the console.
So the useful part is an object that holds a file handle and a log level and that's quick to clone with an optional new log level.

[Gąska]

@LaoC said in In Log4J WTF news today…:

@dkf said in In Log4J WTF news today…:

@error said in In Log4J WTF news today…:

I find YAML pretty easy to use for my config files

It's not too bad for config files, but it's pretty awful for some of the other things that JSON and XML are used for.

To be fair, everything is awful for the things XML is used for, prominently including XML.

I initially read that as XML being awful for XML - and while probably not what you meant, I have first hand experience with writing XML schemas and I can confirm it's absolutely dreadful, largely because they're written in XML.

JSON schema, on the other hand, is pretty nice, although it'd be much better if it wasn't itself a JSON.

[LaoC]

@Gąska said in In Log4J WTF news today…:

@LaoC said in In Log4J WTF news today…:

@dkf said in In Log4J WTF news today…:

@error said in In Log4J WTF news today…:

I find YAML pretty easy to use for my config files

It's not too bad for config files, but it's pretty awful for some of the other things that JSON and XML are used for.

To be fair, everything is awful for the things XML is used for, prominently including XML.

I initially read that as XML being awful for XML - and while probably not what you meant, I have first hand experience with writing XML schemas and I can confirm it's absolutely dreadful, largely because they're written in XML.

JSON schema, on the other hand, is pretty nice, although it'd be much better if it wasn't itself a JSON.

That's pretty close to what I meant. There are a few things I'd usually choose XML over other markup for, such as corpus annotation, but that too becomes a fugly hack once you try to annotate several things at once.

[Bulb]

@LaoC said in In Log4J WTF news today…:

XML over other markup for, such as corpus annotation

Is there even any other markup? JSON and YAML are not, they are serialization formats. XML at least pretends to support the use-case where you have a stream of data and want to intersperse some metadata in it (which is the corpus annotation case).

[LaoC]

@Bulb said in In Log4J WTF news today…:

@LaoC said in In Log4J WTF news today…:

XML over other markup for, such as corpus annotation

Is there even any other markup? JSON and YAML are not, they are serialization formats. XML at least pretends to support the use-case where you have a stream of data and want to intersperse some metadata in it (which is the corpus annotation case).

I'd say you don't want to know but as we all have a bit of a WTFetish, here's an example for the kind of ad-hockery some people have been using, from the British National Corpus:

I_PPIS1 liked_VVD him_PPHO1 ,_, and_CC he_PPHS1 was_VBDZ different_JJ from_II other_JJ boys_NN2 ,_,
not_XX at_RR21 all_RR22 pushy_JJ ,_, except_CS pushy_JJ to_TO please_VVI I_PPIS1 suppose_VV0 ,_,
but_CCB even_RR that_DD1 was_VBDZ sweet_JJ in_II a_AT1 way_NN1

[Bulb]

@LaoC Well, it's ad-hoc, but also a couple of magnitudes simpler – and shorter – than XML.

[Gąska]

@Bulb said in In Log4J WTF news today…:

@LaoC said in In Log4J WTF news today…:

XML over other markup for, such as corpus annotation

Is there even any other markup?

BBCode

[topspin]

@Bulb said in In Log4J WTF news today…:

@LaoC Well, it's ad-hoc, but also a couple of magnitudes simpler – and shorter – than XML.

The simplicity probably comes with undefined edge cases, though.

[Arantor]

@Gąska if only bbcode weren’t stubbornly vendor-specific for all the non-trivial codes.

[Bulb]

@topspin said in In Log4J WTF news today…:

@Bulb said in In Log4J WTF news today…:

@LaoC Well, it's ad-hoc, but also a couple of magnitudes simpler – and shorter – than XML.

The simplicity probably comes with undefined edge cases, though.

Most of those undefined edge cases will be in the semantics and no fancy pants format will help you there. It might even add some due to impedance mismatch between the format and what you are trying to do.

[Tsaukpaetra]

@dkf said in In Log4J WTF news today…:

@hungrier said in In Log4J WTF news today…:

One of the projects I've worked on made extensive use of per component configuration, even setting up a separate TRACE level logger for one particular component

The good thing about using a logger (as opposed to just printing to stdout) is that you can get lots of detail in some parts of the application without rebuilding the whole thing or getting lots of detail from other parts. Some people never make use of that, but it is genuinely useful.

It's nice when I can set Hypatia to debug logging and get my own API token that was provided through the services.

[El_Heffe]

@Carnage said in In Log4J WTF news today…:

I'd love if Java wasn't as retarded about logging as it is.

I'd love if Java wasn't as retarded about anything as it is

[dkf]

Another day, another vuln fixed in log4j (and another point release). This one was just a way to create an infinite loop and DoS attack. Still, it's a lot less serious than a remote execution attack.

At least everyone will be used to updating log4j now, yes?

[Bulb]

@El_Heffe said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

I'd love if Java wasn't as retarded about logging as it is.

I'd love if Java wasn't as retarded about anything as it is

I'd love if the sane people still doing Java switched to Go and the rest can go die in a fire

[Zecc]

One more week until Christmas.

I can't wait to see what's next in the Log4J vulnerability advent calendar.

[Carnage]

@Bulb said in In Log4J WTF news today…:

@El_Heffe said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

I'd love if Java wasn't as retarded about logging as it is.

I'd love if Java wasn't as retarded about anything as it is

I'd love if the sane people still doing Java switched to Go and the rest can go die in a fire

Go, sane? Wth dude? It's all the dumb of Java and then some.

[Bulb]

@Carnage Well, I don't see it loading code dynamically from random places. But what would you call a sane replacement for Java then?

[Carnage]

@Bulb said in In Log4J WTF news today…:

@Carnage Well, I don't see it loading code dynamically from random places. But what would you call a sane replacement for Java then?

Did they remove the ability to add http includes? Otherwise that one is almost as bad as the dumb shit log4j did. I haven't looked at go in a long time, but when I did, it was pretty bad.

From what I've looked at, I'd probably go with rust. But any language will end up with something insane somewhere.
Java is old enough to have a lot of really dumb stuff, and I've more than once called it the next COBOL. I'm mildly surprised that there's still new stuff built in it. But I guess that the alternative to Java these days would be some npm abomination, so

[Arantor]

@Carnage as long as it can have exceptions, we’re good… something Go doesn’t have.

[Bulb]

@Carnage said in In Log4J WTF news today…:

@Bulb said in In Log4J WTF news today…:

@Carnage Well, I don't see it loading code dynamically from random places. But what would you call a sane replacement for Java then?

Did they remove the ability to add http includes? Otherwise that one is almost as bad as the dumb shit log4j did. I haven't looked at go in a long time, but when I did, it was pretty bad.

I thought it just works similar to npm, except there is no special repository format and you just link to the dependency. Is it really more dangerous than npm, nuget or maven pulling your dependencies from wherever?

From what I've looked at, I'd probably go with rust. But any language will end up with something insane somewhere.

I like Rust. But in contexts where you can afford garbage collector, it does make the development quite a bit faster. While Rust lets you be confident you didn't mess up the resource management, you still have to think about all the differences between owned and borrowed types and that takes some mental effort that will slow you down. So while it's a huge improvement over C++, it does not have the whipuptitude of a decent managed language.

And you still have automatic downloading of dependencies. It uses central repository, but when anybody and the dog can publish there, it's not much more secure than just referencing a github repo directly.

Java is old enough to have a lot of really dumb stuff, and I've more than once called it the next COBOL. I'm mildly surprised that there's still new stuff built in it. But I guess that the alternative to Java these days would be some npm abomination, so

That, and programmers who another language, is likely the reason.

[Arantor]

@Bulb there is one difference, these languages have a good standard library meaning that leftpad and friends aren’t needed as extensions. The upshot is that you don’t have quite as much garbage entering the ecosystem.

[Carnage]

@Bulb said in In Log4J WTF news today…:

I thought it just works similar to npm, except there is no special repository format and you just link to the dependency. Is it really more dangerous than npm, nuget or maven pulling your dependencies from wherever?

You can point it straight at a GitHub repo, so it's sort of like npm, only even worse.
Java, for all it's highly warts and dumb shit have at least a halfway sane dependency management flora.

@Bulb said in In Log4J WTF news today…:

I like Rust. But in contexts where you can afford garbage collector, it does make the development quite a bit faster. While Rust lets you be confident you didn't mess up the resource management, you still have to think about all the differences between owned and borrowed types and that takes some mental effort that will slow you down. So while it's a huge improvement over C++, it does not have the whipuptitude of a decent managed language.

Garbage collection doesn't relieve you from having to think about ownership, it just hides the problems of you don't. I've had to deal with memory leaks in every project I've seen professionally, no matter if the framework/platform has garbage collection or not.
I guess it makes shooting someone else in the foot easier though, because things appear to be working long enough to drink the pronghorn in someone else if you don't have a properly thought out data flow.
There is a rule of thumb that for every step removed from writing the code, the cost of fixing it increases by one magnitude, if the GC let's you ignore ownership longer, that makes it more costly than having to deal with it upfront.
As with everything programming, it's a trade-off.

[Bulb]

@Arantor Go does have a fairly good standard library and a bunch of “official” libraries (hosted on golang.org).

[Arantor]

@Bulb I know, that’s why it’s much more betterer than npm.

[Bulb]

@Carnage said in In Log4J WTF news today…:

@Bulb said in In Log4J WTF news today…:

I thought it just works similar to npm, except there is no special repository format and you just link to the dependency. Is it really more dangerous than npm, nuget or maven pulling your dependencies from wherever?

You can point it straight at a GitHub repo, so it's sort of like npm, only even worse.
Java, for all it's highly warts and dumb shit have at least a halfway sane dependency management flora.

I don't think it's any worse than npm, at least not any more. They added the dependency management functionality for specifying versions, and expected hashes and that. You can just slap in the package URL and take the defaults, but you can do that in npm, cargo or maven too except there it has to have the special package format.

@Bulb said in In Log4J WTF news today…:

I like Rust. But in contexts where you can afford garbage collector, it does make the development quite a bit faster. While Rust lets you be confident you didn't mess up the resource management, you still have to think about all the differences between owned and borrowed types and that takes some mental effort that will slow you down. So while it's a huge improvement over C++, it does not have the whipuptitude of a decent managed language.

Garbage collection doesn't relieve you from having to think about ownership, it just hides the problems of you don't. I've had to deal with memory leaks in every project I've seen professionally, no matter if the framework/platform has garbage collection or not.

I guess it makes shooting someone else in the foot easier though, because things appear to be working long enough to drink the pronghorn in someone else if you don't have a properly thought out data flow.
There is a rule of thumb that for every step removed from writing the code, the cost of fixing it increases by one magnitude, if the GC let's you ignore ownership longer, that makes it more costly than having to deal with it upfront.
As with everything programming, it's a trade-off.

Well, often “just restart it every day” is much cheaper solution that making sure you don't have leaks and it's an overall win.

Also you still should think about ownership of the big objects, but all the strings and dates and data rows you can mostly ignore them and in Rust you still have to think about the owned and borrowed variants to think about even though the ownership is fairly trivial and the garbage collector does good job for those.

[dkf]

@Bulb said in In Log4J WTF news today…:

You can just slap in the package URL and take the defaults, but you can do that in npm, cargo or maven too except there it has to have the special package format.

That's about the one thing that maven doesn't support; it really wants to talk to a proper repository (such as Artifactory). But if you stand one of those up for your organization, then that gives you a place to do centralized management of that sort of thing across all your builds. It's also where you can set up weird custom libraries that don't come with maven metadata (which is the stuff that all the later package managers in the Java ecosystem consume too; they might want more, but maven's a solid base for a sane minimum) and there are a whole bunch of settings for whether to pull from upstream services (and which of the many to pull from) though I've never really got into that side of cache repo management (it was one of my coworkers who liked to fiddle with that). But I guess you can sort of finagle it by using libraries that are located in a “well known place” on your system, putting absolute paths in your build descriptor. Because that's ever so portable. (I've only ever done that for linking to a few platform-specific libs. Ghastly, but necessary to get that particular app to do the right thing.)

The npm approach tends to fill Java programmers with horror; so much potential for uncontrolled catastrophe. The fact that it is distribution of micropackages that is done that way just makes it all more confusing as well…

[Arantor]

@dkf as an example of npm horror…

The app I am currently working on declares 12 “dependencies” and 20 “devDependencies”. I’m amazed this only imports 1650 packages.

[Carnage]

@Bulb said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

@Bulb said in In Log4J WTF news today…:

I thought it just works similar to npm, except there is no special repository format and you just link to the dependency. Is it really more dangerous than npm, nuget or maven pulling your dependencies from wherever?

You can point it straight at a GitHub repo, so it's sort of like npm, only even worse.
Java, for all it's highly warts and dumb shit have at least a halfway sane dependency management flora.

I don't think it's any worse than npm, at least not any more. They added the dependency management functionality for specifying versions, and expected hashes and that. You can just slap in the package URL and take the defaults, but you can do that in npm, cargo or maven too except there it has to have the special package format.

@Bulb said in In Log4J WTF news today…:

I like Rust. But in contexts where you can afford garbage collector, it does make the development quite a bit faster. While Rust lets you be confident you didn't mess up the resource management, you still have to think about all the differences between owned and borrowed types and that takes some mental effort that will slow you down. So while it's a huge improvement over C++, it does not have the whipuptitude of a decent managed language.

Garbage collection doesn't relieve you from having to think about ownership, it just hides the problems of you don't. I've had to deal with memory leaks in every project I've seen professionally, no matter if the framework/platform has garbage collection or not.

I guess it makes shooting someone else in the foot easier though, because things appear to be working long enough to drink the pronghorn in someone else if you don't have a properly thought out data flow.
There is a rule of thumb that for every step removed from writing the code, the cost of fixing it increases by one magnitude, if the GC let's you ignore ownership longer, that makes it more costly than having to deal with it upfront.
As with everything programming, it's a trade-off.

Well, often “just restart it every day” is much cheaper solution that making sure you don't have leaks and it's an overall win.

Yeah, unless you get high loads, when you need to cycle your servers more often. And I find it's usually cheaper to do things right from the start rather than having to do monkeypatching. Especially if you have to deal with safe shutdowns so you aren't losing state or data for requests currently being dealt with when the server is working. Though I've been dealing with stuff that works with money or base infrastructure so my values might be different from the norm of the average programmer.

Also you still should think about ownership of the big objects, but all the strings and dates and data rows you can mostly ignore them and in Rust you still have to think about the owned and borrowed variants to think about even though the ownership is fairly trivial and the garbage collector does good job for those.

I have hardly built anything but backend servers the last two decades, and there I keep everything stateless so when the root of the tree is destroyed, everything in the tree is guaranteed to not be anywhere else and is safe to destroy. The actual state for the server, such as remote services or database configuration are either constants and will not go out of scope until the server is shut down, or loaded when necessary from wherever it's kept and destroyed when used and not shared between places.

[Bulb]

@dkf said in In Log4J WTF news today…:

That's about the one thing that maven doesn't support; it really wants to talk to a proper repository (such as Artifactory).

Whoever publishes the package has to publish it in the right format for maven to understand, but presumably anybody publishing a Java package will do that. And it's still just a web server with specific layout and metadata, so it's not like it's too hard. Then you just slap in the base URL of the server and package name and maven gets it.

For go they also need to publish the package in the right format for go mod to understand it. Just that format is whatever github does, so they can just push the code to github and tag a release and call it a minute. But there is no fundamental difference.

@dkf said in In Log4J WTF news today…:

But if you stand one of those up for your organization, then that gives you a place to do centralized management of that sort of thing across all your builds.

You can do that with Go as well (Artifactory does list Go as a package type). The issue – in all the cases – is making sure your projects only reference your repository and not the wild internet directly.

@dkf said in In Log4J WTF news today…:

The npm approach tends to fill Java programmers with horror; so much potential for uncontrolled catastrophe.

Why? Technically there is almost no difference at all.

Of course there is the fact that everything has a million further dependencies, because JavaScript has almost no standard library and then you also need all the shims to cover browser incompatibilities. But that has nothing to do with how the package management works and everything with what packages there are.

And that does not apply to Go. Go has a decent standard library with a lot of high-level functionality (including an http server, because it is often used to implement network services).

[Bulb]

@Carnage said in In Log4J WTF news today…:

@Bulb said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

@Bulb said in In Log4J WTF news today…:

I thought it just works similar to npm, except there is no special repository format and you just link to the dependency. Is it really more dangerous than npm, nuget or maven pulling your dependencies from wherever?

You can point it straight at a GitHub repo, so it's sort of like npm, only even worse.
Java, for all it's highly warts and dumb shit have at least a halfway sane dependency management flora.

I don't think it's any worse than npm, at least not any more. They added the dependency management functionality for specifying versions, and expected hashes and that. You can just slap in the package URL and take the defaults, but you can do that in npm, cargo or maven too except there it has to have the special package format.

@Bulb said in In Log4J WTF news today…:

I like Rust. But in contexts where you can afford garbage collector, it does make the development quite a bit faster. While Rust lets you be confident you didn't mess up the resource management, you still have to think about all the differences between owned and borrowed types and that takes some mental effort that will slow you down. So while it's a huge improvement over C++, it does not have the whipuptitude of a decent managed language.

Garbage collection doesn't relieve you from having to think about ownership, it just hides the problems of you don't. I've had to deal with memory leaks in every project I've seen professionally, no matter if the framework/platform has garbage collection or not.

I guess it makes shooting someone else in the foot easier though, because things appear to be working long enough to drink the pronghorn in someone else if you don't have a properly thought out data flow.
There is a rule of thumb that for every step removed from writing the code, the cost of fixing it increases by one magnitude, if the GC let's you ignore ownership longer, that makes it more costly than having to deal with it upfront.
As with everything programming, it's a trade-off.

Well, often “just restart it every day” is much cheaper solution that making sure you don't have leaks and it's an overall win.

Yeah, unless you get high loads, when you need to cycle your servers more often. And I find it's usually cheaper to do things right from the start rather than having to do monkeypatching. Especially if you have to deal with safe shutdowns so you aren't losing state or data for requests currently being dealt with when the server is working. Though I've been dealing with stuff that works with money or base infrastructure so my values might be different from the norm of the average programmer.

Many of the large companies have been rewriting the performance or reliability critical stuff in Rust indeed. I just read about some components Dropbox rewrote from Go to Rust for performance reasons. And it makes sense if you are doing something that is expected to need to scale well.

But average consultation company that needs to cobble together yet another enterprise resource management software as quickly as possible, which is where Java is often used, can do just fine with Go, and the monkeys trained in Java can usually be re-trained to do Go in a couple of days, which is far from the case with Rust.

If you need manipulexity, go with Rust, but if you need whipuptitude and all you've got to work on it is a bunch of trained monkeys, Go might do you a better service.

Also you still should think about ownership of the big objects, but all the strings and dates and data rows you can mostly ignore them and in Rust you still have to think about the owned and borrowed variants to think about even though the ownership is fairly trivial and the garbage collector does good job for those.

I have hardly built anything but backend servers the last two decades, and there I keep everything stateless so when the root of the tree is destroyed, everything in the tree is guaranteed to not be anywhere else and is safe to destroy. The actual state for the server, such as remote services or database configuration are either constants and will not go out of scope until the server is shut down, or loaded when necessary from wherever it's kept and destroyed when used and not shared between places.

Keeping all state in the database is the goal for backend usually, because it keeps things simpler, and able to scale (the hard part of scaling the database delegated to someone who hopefully knows better how to do it).

But that also means that the managed runtime is good enough, and the work gets done faster, so if the memory overhead does not get too expensive, it's a good choice.

[Carnage]

@Bulb said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

@Bulb said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

@Bulb said in In Log4J WTF news today…:

I thought it just works similar to npm, except there is no special repository format and you just link to the dependency. Is it really more dangerous than npm, nuget or maven pulling your dependencies from wherever?

You can point it straight at a GitHub repo, so it's sort of like npm, only even worse.
Java, for all it's highly warts and dumb shit have at least a halfway sane dependency management flora.

I don't think it's any worse than npm, at least not any more. They added the dependency management functionality for specifying versions, and expected hashes and that. You can just slap in the package URL and take the defaults, but you can do that in npm, cargo or maven too except there it has to have the special package format.

@Bulb said in In Log4J WTF news today…:

I like Rust. But in contexts where you can afford garbage collector, it does make the development quite a bit faster. While Rust lets you be confident you didn't mess up the resource management, you still have to think about all the differences between owned and borrowed types and that takes some mental effort that will slow you down. So while it's a huge improvement over C++, it does not have the whipuptitude of a decent managed language.

Garbage collection doesn't relieve you from having to think about ownership, it just hides the problems of you don't. I've had to deal with memory leaks in every project I've seen professionally, no matter if the framework/platform has garbage collection or not.

I guess it makes shooting someone else in the foot easier though, because things appear to be working long enough to drink the pronghorn in someone else if you don't have a properly thought out data flow.
There is a rule of thumb that for every step removed from writing the code, the cost of fixing it increases by one magnitude, if the GC let's you ignore ownership longer, that makes it more costly than having to deal with it upfront.
As with everything programming, it's a trade-off.

Well, often “just restart it every day” is much cheaper solution that making sure you don't have leaks and it's an overall win.

Yeah, unless you get high loads, when you need to cycle your servers more often. And I find it's usually cheaper to do things right from the start rather than having to do monkeypatching. Especially if you have to deal with safe shutdowns so you aren't losing state or data for requests currently being dealt with when the server is working. Though I've been dealing with stuff that works with money or base infrastructure so my values might be different from the norm of the average programmer.

Many of the large companies have been rewriting the performance or reliability critical stuff in Rust indeed. I just read about some components Dropbox rewrote from Go to Rust for performance reasons. And it makes sense if you are doing something that is expected to need to scale well.

But average consultation company that needs to cobble together yet another enterprise resource management software as quickly as possible, which is where Java is often used, can do just fine with Go, and the monkeys trained in Java can usually be re-trained to do Go in a couple of days, which is far from the case with Rust.

If you need manipulexity, go with Rust, but if you need whipuptitude and all you've got to work on it is a bunch of trained monkeys, Go might do you a better service.

Also you still should think about ownership of the big objects, but all the strings and dates and data rows you can mostly ignore them and in Rust you still have to think about the owned and borrowed variants to think about even though the ownership is fairly trivial and the garbage collector does good job for those.

I have hardly built anything but backend servers the last two decades, and there I keep everything stateless so when the root of the tree is destroyed, everything in the tree is guaranteed to not be anywhere else and is safe to destroy. The actual state for the server, such as remote services or database configuration are either constants and will not go out of scope until the server is shut down, or loaded when necessary from wherever it's kept and destroyed when used and not shared between places.

Keeping all state in the database is the goal for backend usually, because it keeps things simpler, and able to scale (the hard part of scaling the database delegated to someone who hopefully knows better how to do it).

But that also means that the managed runtime is good enough, and the work gets done faster, so if the memory overhead does not get too expensive, it's a good choice.

Yeah, if it's just another cookie cutter stamp job pretty much anything that as many developers as possible have skills in is probably the best. JAva has a fuckton of libraries and frameworks to do pretty much anything fast and easy, which is why it's still around. C£ seems to be pretty much at the same level and depending on which area of business it's either java or .net that is the biggest right now around here.
Go is actually in decline around these parts. Not sure why since I haven't really bothered checking it out much.

[Bulb]

@Carnage said in In Log4J WTF news today…:

Go is actually in decline around these parts. Not sure why since I haven't really bothered checking it out much.

Surprises me a bit, as Go is still somewhat more efficient than Java as not everything is an object and therefore not everything needs an allocation with quite a bit of memory overhead. But might be the Java libraries are still more suitable to whatever they are doing – in the end good libraries make more difference to the development time than good language. Also while C# is better than Java, the .net runtime for Linux is still a bit odd and might have not earned trust yet.

[Carnage]

@Bulb said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

Go is actually in decline around these parts. Not sure why since I haven't really bothered checking it out much.

Surprises me a bit, as Go is still somewhat more efficient than Java as not everything is an object and therefore not everything needs an allocation with quite a bit of memory overhead. But might be the Java libraries are still more suitable to whatever they are doing – in the end good libraries make more difference to the development time than good language. Also while C# is better than Java, the .net runtime for Linux is still a bit odd and might have not earned trust yet.

Yeah, people seem to still be afflicted with the hardware is cheap brain worm.

[Bulb]

@Carnage Again, it depends. When you are running software for millions of users, the hardware cost becomes significant and it's worth investing development time to making it efficient. But when you are running software for thousands of users in some company, the development time dominates, so throwing some extra hardware at it is a good option.

[Carnage]

@Bulb said in In Log4J WTF news today…:

@Carnage Again, it depends. When you are running software for millions of users, the hardware cost becomes significant and it's worth investing development time to making it efficient. But when you are running software for thousands of users in some company, the development time dominates, so throwing some extra hardware at it is a good option.

Yeah, and most systems serve a few hundred or perhaps thousand concurrent users, and at that point bash has enough performance.
I've seen systems with irrigators a hundred years per week crawl on modern servers because of the completely insane design too. And the developers of course claiming that what they are doing is so shaved that it has to run on massive clouds when it's something that could probably be recreated in a month or two, and to run on a RPi if you had a decent people.

My first encounter with that grade of software was my first job, where the load testing tool was so utterly shit that you had to run several of the load testers to even make the server it was supposed to load even start to do load balancing between the two nodes.

[Bulb]

@Carnage said in In Log4J WTF news today…:

the load testing tool was so utterly …

The what? That's already pretty good. Many projects don't even have one at all.

@Carnage said in In Log4J WTF news today…:

at that point bash has enough performance

I currently need to make a utility service for an embedded linux. I thought I don't want to do it in python (which the device does have) because it would probably take too much memory, but would consider doing it in shell, because the busybox is pretty lean and might actually end up being better. Of course I'd have to try (but I'll probably just do it in C++ because of binary data formats that are hard to deal with in anything else available).

[Carnage]

@Bulb said in In Log4J WTF news today…:

The what? That's already pretty good. Many projects don't even have one at all.

Yeah, I usually have to fight to have anything more than a pitiful number of unit tests, because apparently automated testing is hard.
My last gig, i did a single load test and didn't even push it very hard and I accidentally made the backing "big data warehouse" shit itself. I think it happened somewhere around 10000 requests per second. I had even asked that team about it before I ran my test, and they said they didn't believe my system could survive a high enough load that they'd even see a blip in theirs.
But after that first load test, we didn't do any more, because that system at high loads served something like 10000 requests per day in heavy load days.
I miss working on things where performance actually matters a bit.

[HardwareGeek]

@Carnage said in In Log4J WTF news today…:

if you had a decent people

Good luck with that.

[Carnage]

@HardwareGeek said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

if you had a decent people

Good luck with that.

I've managed to build one team of good people once, and stumbled into one once, so it does happen. But not very often. A majority of the devs I've encountered are a bit shit, and some makes you amazed that they can hold down a job because they have the mierdas touch.

[DogsB]

@Bulb said in In Log4J WTF news today…:

@El_Heffe said in In Log4J WTF news today…:

@Carnage said in In Log4J WTF news today…:

I'd love if Java wasn't as retarded about logging as it is.

I'd love if Java wasn't as retarded about anything as it is

I'd love if the sane people still doing Java switched to Go and the rest can go die in a fire

I've always wanted Microsoft based languages and Java to go the way of the dodo (mostly for cobol like contractor fees in java to be a thing) and then you mentioned Go. That would keep me entertained for about a decade and a half. I love the weird shit I get out of google libraries. I can't imagine what a whole language would be like.

I've always thought we should just go back to C with Garbage Collection. It's what most developers write anyway.

[BernieTheBernie]

@Carnage said in In Log4J WTF news today…:

around 10000 requests per second. ... that system at high loads served something like 10000 requests per day in heavy load days.

That's a factor of ca. 100,000. Till the business has grown so much that your preferred number becomes an issue, lots of changes will have happened to that data warehouse anyway, and your present would-like-to-have improvements thus will be fully outdated already.

[Bulb]

@DogsB said in In Log4J WTF news today…:

I've always thought we should just go back to C with Garbage Collection. It's what most developers write anyway.

Funny, because that's basically what the designers of Go had in mind – a C with garbage collection, some minimal polymorphism and type inference to keep it concise. Also, one of the co-authors is Ken Thompson, who previously created B and co-created C.

[DogsB]

@Bulb said in In Log4J WTF news today…:

@DogsB said in In Log4J WTF news today…:

I've always thought we should just go back to C with Garbage Collection. It's what most developers write anyway.

Funny, because that's basically what the designers of Go had in mind – a C with garbage collection, some minimal polymorphism and type inference to keep it concise. Also, one of the co-authors is Ken Thompson, who previously created B and co-created C.

Colour me intrigued. Any functional stuff in it?

[Bulb]

@DogsB It has first class functions and closures, so you can do functional stuff. But I don't think the standard library does much. Usually it uses interfaces. You can define interfaces for existing types, so you can adapt things as you need. An interface-typed variable is a fat pointer, pointing separately to the data and to a virtual method table, with the virtual method tables compiled as needed.

[DogsB]

@Bulb said in In Log4J WTF news today…:

@DogsB It has first class functions and closures, so you can do functional stuff. But I don't think the standard library does much. Usually it uses interfaces. You can define interfaces for existing types, so you can adapt things as you need. An interface-typed variable is a fat pointer, pointing separately to the data and to a virtual method table, with the virtual method tables compiled as needed.

I'm not a fan of functional stuff but it does look interesting. I'll look at it next week if angular and typescript haven't turned my little brain to mush. Thanks.

[Bulb]

@DogsB It feels a bit ad-hoc to me, and it didn't fix the million dollar mistake (reference types can still be nil), but it is easy to learn with useful standard library for quickly writing smaller services where the performance does matter a bit more than you can get from python.