Java gets a bad rap in large part because it was the forefront of OOP entering the mainstream dev scene and ended up being the primary language of a lot of devs who had a better understanding of Design Patterns than good programming. Thus we get cartoonish chains of Factories in production software.
It's also a pretty slow desktop language with really bad memory management, so anyone whose suffered through a poorly-written, unoptimized Java app (that they were forced to download a Java update for) is gonna be mad at it for that as well.
Mostly, I just dislike Java because it's an extremely mediocre version of C#.
My firm used to be a Java shop, and we've moved almost entirely off of Java and into C# and Angular. Java is just too slow compared to C# or a modern web app. We're actively trying to replace any old Java code we have with newer projects, but it's slow going because large enterprise companies resist change. Heck, we still have old Lotus Notes databases we're in the process of replacing.
Java gets a bad rap in large part because it was the forefront of OOP entering the mainstream dev scene and ended up being the primary language of a lot of devs who had a better understanding of Design Patterns than good programming. Thus we get cartoonish chains of Factories in production software.
It's also a pretty slow desktop language with really bad memory management, so anyone whose suffered through a poorly-written, unoptimized Java app (that they were forced to download a Java update for) is gonna be mad at it for that as well.
Mostly, I just dislike Java because it's an extremely mediocre version of C#.
My firm used to be a Java shop, and we've moved almost entirely off of Java and into C# and Angular. Java is just too slow compared to C# or a modern web app. We're actively trying to replace any old Java code we have with newer projects, but it's slow going because large enterprise companies resist change. Heck, we still have old Lotus Notes databases we're in the process of replacing.
It's weird that Java performs so well in benchmarks compared to C# but that is the opposite experience I've had in re: actually using it.
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
Java gets a bad rap in large part because it was the forefront of OOP entering the mainstream dev scene and ended up being the primary language of a lot of devs who had a better understanding of Design Patterns than good programming. Thus we get cartoonish chains of Factories in production software.
It's also a pretty slow desktop language with really bad memory management, so anyone whose suffered through a poorly-written, unoptimized Java app (that they were forced to download a Java update for) is gonna be mad at it for that as well.
Mostly, I just dislike Java because it's an extremely mediocre version of C#.
My firm used to be a Java shop, and we've moved almost entirely off of Java and into C# and Angular. Java is just too slow compared to C# or a modern web app. We're actively trying to replace any old Java code we have with newer projects, but it's slow going because large enterprise companies resist change. Heck, we still have old Lotus Notes databases we're in the process of replacing.
It's weird that Java performs so well in benchmarks compared to C# but that is the opposite experience I've had in re: actually using it.
That's because Java the language is fine, really - but a lot of its ecosystem is horribly bloated.
Our sysops guy here made a presentation on Ansible the other day, which was interesting. The only Ansible bit I've touched myself so far has been configuration stuff that feed environment vars to our Docker containers on staging/prod.
Should also note - ansible's big drawback is that testing playbooks is tricky. My personal opinion is that a lot of software engineer types like to say "oh look it lacks a testing language" whereas I prefer to say "you can't reliably test machine config changes without actually changing machine config".
This is where Docker can be super-useful though - since a Docker container with SSH serves as a nice, very lightweight proxy for a machine's configuration.
Our sysops guy here made a presentation on Ansible the other day, which was interesting. The only Ansible bit I've touched myself so far has been configuration stuff that feed environment vars to our Docker containers on staging/prod.
Should also note - ansible's big drawback is that testing playbooks is tricky. My personal opinion is that a lot of software engineer types like to say "oh look it lacks a testing language" whereas I prefer to say "you can't reliably test machine config changes without actually changing machine config".
This is where Docker can be super-useful though - since a Docker container with SSH serves as a nice, very lightweight proxy for a machine's configuration.
Testing was possibly the biggest annoyance I ran into on my first attempt using ansible. For those less familiar the issue is that ansible has a test mode where it does not actually make the changes. The problem with that (or at least the one I ran into, maybe there are more) is that if step B relies on step A actually having happened, such as installing a package, then your test says step B failed because the package won't be there since step A did not actually run.
GnomeTankWhat the what?Portland, OregonRegistered Userregular
So I got a new job. Going from C#/SQL Server/Windows to Node/Postgres/UNIX with a smattering of Go full time. New company is already doing Docker and AWS and full in on dev ops. It's also a 10 minute walk from my house, better pay and a better cultural fit.
Monkey Ball WarriorA collection of mediocre hatsSeattle, WARegistered Userregular
edited June 2017
I miss C#. I wish it was practical to use it for actual non-microsoft-ecosystem things.
But Java is kind of a lingua franca. Everyone can read it (at least until I start going crazy with the streams and lambdas). Not everyone can read Scala or Go (It's so C but you'd be surprised how much the type-after-name, multiple returns, and omni-for-statement's throw people off). Everyone can read Python, but :rotate: GIL :rotate: . I hate Java like every other red-blooded dev, but IDE code generation and lambdas make it almost usable until such a time as a better language pushes it out of the way.
I wouldn't say Java as a language is fine... it has a lot of warts. You write C# a while and you come back and those warts seem to block out the sun.
But then again you compare it to a historical accident like Javascript and ... well, it could always be worse!
Monkey Ball Warrior on
"I resent the entire notion of a body as an ante and then raise you a generalized dissatisfaction with physicality itself" -- Tycho
Turns out I only have eight jiggabutts of RAM in my work laptop. It's not a major issue yet, but I do cap it with IntelliJ running and Chrome keeps reloading pages if a tab has been inactive for too long instead of keeping it in RAM.
I miss C#. I wish it was practical to use it for actual non-microsoft-ecosystem things.
But Java is kind of a lingua franca. Everyone can read it (at least until I start going crazy with the streams and lambdas). Not everyone can read Scala or Go (It's so C but you'd be surprised how much the type-after-name, multiple returns, and omni-for-statement's throw people off). Everyone can read Python, but :rotate: GIL :rotate: . I hate Java like every other red-blooded dev, but IDE code generation and lambdas make it almost usable until such a time as a better language pushes it out of the way.
I wouldn't say Java as a language is fine... it has a lot of warts. You write C# a while and you come back and those warts seem to block out the sun.
But then again you compare it to a historical accident like Javascript and ... well, it could always be worse!
Gawd, finally done adding a feature to this third-party integration. That took way too long because it was an unending cascade of "small thing that first requires me to fix/change another small thing".
they're only fixing it for python 3? yeah then it probably wont matter
Should've used Jython :rotate:
0
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
I'm down a rabbit hole watching video's about Python's GIL and how it came about, and how the alternative implementations avoid it. I don't even care about Python (can't stand significant white space mostly), but it's a fascinating topic.
I'm down a rabbit hole watching video's about Python's GIL and how it came about, and how the alternative implementations avoid it. I don't even care about Python (can't stand significant white space mostly), but it's a fascinating topic.
I've now spent the last hour and a half of my evening watching the same stuff. Woooooooooooooooooo, programming. :rotate:
nice. Time to watch that pycon video. I've watched a couple of them, but not enough... been too damned busy actually working. I sure hope Python can get the stuff it needs to regain its popularity. Django channels is great, python-graphene is excellent, the async/await stuff in python 3.5+ is good times (one of my toy devops projects at work uses all 3 of those, I love it). Ditching the gil would be a huge win.
Now if we could just get a python html/css to pdf tool which doesn't completely suck because an odd number of our projects seem to require generating pdfs.
"We know if can be faster because jython already does it"
I suppose piggybacking on an already pretty good garbage collector/VM is one way to do it!
The question is really just how much of the C API they are going to have to break to do it.
This is basically it. The CPython guys are plenty smart enough to implement any VM features they need to fix the issue, but in doing so will likely break C extensions. You can understand why they are a little loathe to do that after the Python 3.x situation. In reality they probably should have tackled the problem for Python 3, so as to only introduce major extension breaking once...but hindsight and all that.
By popular request, ./... no longer matches packages in vendor directories in tools accepting package names, such as go test. To match vendor directories, write ./vendor/....
Oh thank science, that was driving me nuts.
Unfortunately golint is a separate project and the greybeards there have already gone "bah, humbug" at earlier feature requests to ignore the vendor dir, but maybe this will mean some more pressure on them to actually support that natively.
We mentioned checking in vendor/ in Go a while back. Godep authors have some reasoning there.
godep's primary concern is to allow you to repeatably build your project. Your dependencies are part of that project. Without them it won't build. Not committing vendor/ adds additional external dependencies that are outside of your control. In Go, fetching packages is tied to multiple external systems (DNS, web servers, etc). Over time other developers or code hosting sites may discontinue service, delete code, force push, or take any number of other actions that may make a package unreachable. Therefore it's the opinion of the godep authors that vendor/ should always be checked in.
+1
Options
GnomeTankWhat the what?Portland, OregonRegistered Userregular
edited June 2017
I'm still not convinced. NPM doesn't advise you to check in node_modules. NuGet doesn't advise you to check in packages. The entire point of a dependency system is to allow me to keep external dependencies external. I can certainly see some recommendation for a business to keep a local proxy of the package sources (using something like ProGet as a pass-through), but bloating every source repository with all your code dependencies? I'm still not buying the rationale. It still feels very much like Google wanting people to do things the Google way.
I fully believe in making sure you have a complete consistent version of any external dependencies you've taken on, so you aren't at the whims of an external vendor to continue to keep their packages available and intact. Checking them into your own repo is probably a reasonable way to do it for small projects but I definitely agree hosting a local proxy containing your specific dependencies is a better solution as you build our more, larger projects.
My company specifically disallows using CDNs for third party libraries.
If we use JQuery, we gotta download a version of it and host it ourselves. 99.9% uptime and all that jazz, can't rely on other people for our stuff to work.
I fully believe in making sure you have a complete consistent version of any external dependencies you've taken on, so you aren't at the whims of an external vendor to continue to keep their packages available and intact. Checking them into your own repo is probably a reasonable way to do it for small projects but I definitely agree hosting a local proxy containing your specific dependencies is a better solution as you build our more, larger projects.
Do you consider the compiler /interpreter an external dependency? What about the C libraries that your external dependencies invoke / build? Soon you are using NIX / rbm for package management and have a beard that touches the floor.
Back in the days when I was managing an embedded platform, I had tarballs of everything from kernel upwards, including the compiler, libraries etc. The whole OS.
Had to, since I needed to guarantee that I could rebuild the exact same binary image for the OS when required.
But that's very different from modern web dev. I'm interested in seeing how that handles the same issue.
I fully believe in making sure you have a complete consistent version of any external dependencies you've taken on, so you aren't at the whims of an external vendor to continue to keep their packages available and intact. Checking them into your own repo is probably a reasonable way to do it for small projects but I definitely agree hosting a local proxy containing your specific dependencies is a better solution as you build our more, larger projects.
Do you consider the compiler /interpreter an external dependency? What about the C libraries that your external dependencies invoke / build? Soon you are using NIX / rbm for package management and have a beard that touches the floor.
Typically haven't gone that far. Since we work on top of .NET Framework in Windows we are generally comfortable with the idea that there's little to no chance that Microsoft disappears and if they did then we've probably got bigger problems than being able to exactly replicate our deployment environments.
Unfortunately, Microsoft's web distribution only model for VS2017 would make keeping all of those dependencies safely local much harder were we to try to do so.
i was/am really dissatisfied with dependency management in a browser based JS context
i experimented at my last company with forking our dependent git repositories onto a private git server and including them as git submodules
i was fairly happy with that but i really didn't get a chance to push the idea to its limits. it worked well with compiled langs but in JS/web where paths actually matter... wrangling directory structure gets hard with so many opinionated JS toolchains
Jasconius on
+1
Options
thatassemblyguyJanitor of Technical Debt.Registered Userregular
I'm still not convinced. NPM doesn't advise you to check in node_modules. NuGet doesn't advise you to check in packages. The entire point of a dependency system is to allow me to keep external dependencies external. I can certainly see some recommendation for a business to keep a local proxy of the package sources (using something like ProGet as a pass-through), but bloating every source repository with all your code dependencies? I'm still not buying the rationale. It still feels very much like Google wanting people to do things the Google way.
Personally, when I design something, I'm thinking about the sysadmin that will be summoned at 3:30am when shit goes down.
Like, when someone like Azer Koçulu decides to take their toys and go home.
Or, I'm thinking about the poor schlub in India that will be maintaining the product code 5 years from now. I push heavily to have as much stuff in the repository (code, documentation, third party dependencies, helper scripts, etc). Everything is there. A new hire/maintainer doesn't have to go get things from place x, y, and z, or make sure infra-server-7 is still running, just to get their development station up and running. It declutters infrastructure tremendously.
With the advent of distributed repository technology, the initial clone is a long pole, sure, but individual fetch&(merge|rebase), and checkout operations are cheap. Unlike the previous version control systems (RIP svn you were better than CVS, which was better than nothing) that require a clone for every checkout. Additonally, mass storage is super duper cheap, this means there really isn't any teeth to the "bloat" rationale anymore.
Posts
My firm used to be a Java shop, and we've moved almost entirely off of Java and into C# and Angular. Java is just too slow compared to C# or a modern web app. We're actively trying to replace any old Java code we have with newer projects, but it's slow going because large enterprise companies resist change. Heck, we still have old Lotus Notes databases we're in the process of replacing.
It's weird that Java performs so well in benchmarks compared to C# but that is the opposite experience I've had in re: actually using it.
Should also note - ansible's big drawback is that testing playbooks is tricky. My personal opinion is that a lot of software engineer types like to say "oh look it lacks a testing language" whereas I prefer to say "you can't reliably test machine config changes without actually changing machine config".
This is where Docker can be super-useful though - since a Docker container with SSH serves as a nice, very lightweight proxy for a machine's configuration.
Testing was possibly the biggest annoyance I ran into on my first attempt using ansible. For those less familiar the issue is that ansible has a test mode where it does not actually make the changes. The problem with that (or at least the one I ran into, maybe there are more) is that if step B relies on step A actually having happened, such as installing a package, then your test says step B failed because the package won't be there since step A did not actually run.
But Java is kind of a lingua franca. Everyone can read it (at least until I start going crazy with the streams and lambdas). Not everyone can read Scala or Go (It's so C but you'd be surprised how much the type-after-name, multiple returns, and omni-for-statement's throw people off). Everyone can read Python, but :rotate: GIL :rotate: . I hate Java like every other red-blooded dev, but IDE code generation and lambdas make it almost usable until such a time as a better language pushes it out of the way.
I wouldn't say Java as a language is fine... it has a lot of warts. You write C# a while and you come back and those warts seem to block out the sun.
But then again you compare it to a historical accident like Javascript and ... well, it could always be worse!
The GIL might not be an issue for much longer.
Should've used Jython :rotate:
I think Google's said they're dropping Python 2.x support in their App Engine; which seems like kind of a red flag to get a move on to 3.x...
Hahahahahaha.
I've now spent the last hour and a half of my evening watching the same stuff. Woooooooooooooooooo, programming. :rotate:
"We know if can be faster because jython already does it"
I suppose piggybacking on an already pretty good garbage collector/VM is one way to do it!
Does anybody know how to get the BBCode [ code] tag to stop replacing special characters with HTML entities?
Example:
the "no true scotch man" fallacy.
Bug report here.
the "no true scotch man" fallacy.
Now if we could just get a python html/css to pdf tool which doesn't completely suck because an odd number of our projects seem to require generating pdfs.
The question is really just how much of the C API they are going to have to break to do it.
This is basically it. The CPython guys are plenty smart enough to implement any VM features they need to fix the issue, but in doing so will likely break C extensions. You can understand why they are a little loathe to do that after the Python 3.x situation. In reality they probably should have tackled the problem for Python 3, so as to only introduce major extension breaking once...but hindsight and all that.
Oh thank science, that was driving me nuts.
Unfortunately golint is a separate project and the greybeards there have already gone "bah, humbug" at earlier feature requests to ignore the vendor dir, but maybe this will mean some more pressure on them to actually support that natively.
If we use JQuery, we gotta download a version of it and host it ourselves. 99.9% uptime and all that jazz, can't rely on other people for our stuff to work.
Do you consider the compiler /interpreter an external dependency? What about the C libraries that your external dependencies invoke / build? Soon you are using NIX / rbm for package management and have a beard that touches the floor.
Had to, since I needed to guarantee that I could rebuild the exact same binary image for the OS when required.
But that's very different from modern web dev. I'm interested in seeing how that handles the same issue.
Typically haven't gone that far. Since we work on top of .NET Framework in Windows we are generally comfortable with the idea that there's little to no chance that Microsoft disappears and if they did then we've probably got bigger problems than being able to exactly replicate our deployment environments.
Unfortunately, Microsoft's web distribution only model for VS2017 would make keeping all of those dependencies safely local much harder were we to try to do so.
i experimented at my last company with forking our dependent git repositories onto a private git server and including them as git submodules
i was fairly happy with that but i really didn't get a chance to push the idea to its limits. it worked well with compiled langs but in JS/web where paths actually matter... wrangling directory structure gets hard with so many opinionated JS toolchains
Personally, when I design something, I'm thinking about the sysadmin that will be summoned at 3:30am when shit goes down.
Like, when someone like Azer Koçulu decides to take their toys and go home.
Or, I'm thinking about the poor schlub in India that will be maintaining the product code 5 years from now. I push heavily to have as much stuff in the repository (code, documentation, third party dependencies, helper scripts, etc). Everything is there. A new hire/maintainer doesn't have to go get things from place x, y, and z, or make sure infra-server-7 is still running, just to get their development station up and running. It declutters infrastructure tremendously.
With the advent of distributed repository technology, the initial clone is a long pole, sure, but individual fetch&(merge|rebase), and checkout operations are cheap. Unlike the previous version control systems (RIP svn you were better than CVS, which was better than nothing) that require a clone for every checkout. Additonally, mass storage is super duper cheap, this means there really isn't any teeth to the "bloat" rationale anymore.