1) You don't have to touch Content-length since it's computed. https://golang.org/pkg/net/http/#ResponseWriter
2) ETAGS, expire, ect ... are not managed by the std lib, as it should not.
Which looks like the right choice. ExpressJS has some helpers for it but it's a soup of unpredictability and shitty performance. You'd want something as simple as uwebsockets.js
Where I work we've shipped Go APIs using just the standard library running on like 1/10 of the hardware we were using in the .NET (not core) world and handling 10,000s requests per second. Perhaps that was just because we had really old shitty .NET code though.
One of our Java backends handles a few thousand requests/second with no real optimization.
The ORM story in Go is terrible compared to Java and C#. Probably due to lack of generics. I won't touch it personally till this changes
Now 4 years of golang. It beats all of them at development pace and ease of integration, especially since modules are working as they should. The killer features of golang: modules, http stuff, channels, ssh in stdlib, fantastic, easy to use crypto.
The prevalence of swagger disagrees.
A typical Golang CI/CD pipeline should - compile without CGO enabled and with go build -tags netgo -a -v so that the binary can run on in a minimal docker image like alpine or scratch - should be compiled and tested using the race detector - should be linted using golanglint-ci
All of these flags and linters considerably increase the build time for deployment to production
The rust compiler effectively gives me the same outcome using the type system and the compiler advancements when targeting release musl.
I have seen many Golang projects where the race detector was skipped because the code base was to large or it was flaky.
One the other hand I do miss the code coverage tools. Code coverage for rust seems to only work on Linux
Certainly, it's still ways better than C. But the resulting boilerplate and copy-paste programming ought to be a source of errors.
(I'm happy to see the generics proposal coming closer and closer to a future feature.)
PUSH EBP
MOV EBP, ESP
SUB ESP, 12
Which just demonstrates why slogans are not a good substitute for thought.
They're good for programming a community though.
Lastly, does anyone have any resources for actually writing concurrent Go code? I have been spoiled by so many of the underlying libraries “already” doing this for me.
What does Google do on servers that has not already been served by Java and C++? As far as I know, the vast majority of code both existing and newly written at Google is Java and C++, not golang.
Keep in mind, I use rust and c++, primarily. I just look over the fence at go and can appreciate what it does well.
They realized C++ sucks for simple services and due to the Oracle litigation they were trying to get away from Java where possible.
Having written backends in C++, Java, Python, Rust, and Golang myself, Golang is far and away the best tool for the job in my opinion.
not a lawyer here, but isn't the litigation related to Android Java-clone, not 'server-side' java-usage?
However, Koltin and Android depend heavily on the JVM eco-system, and Google is certainly not going to rewrite everything in Koltin/Native or start using ART outside Android.
Even if you castrate yourself to Java 7, whatever works depends pretty much on the Android version.
Definitely not, unless you are google.
Go is great for hardcore backend and systems programming, as a replacement for c/c++ or Java.
For most companies over there (which are not Facebook, Amazon, Google, etc) what you need is just f**ng python/django, ruby/rails, php/symfony, etc.
P.S. You probably don't need kubernetes and monorepos either.
There are a bunch of things rust has which makes it attractive over go for these types of apps, from a practical perspective it tends to be better for a team to use a minimal number of languages across their stack.
The lack of generics means that each numeric type has it's own signature, if you deal with a lot of numbers with different precisions - you'll have a bunch of identical methods lying around just to support alternate precisions.
The lack of function/closure serialization in Go means that "moving compute to data" ala Spark or Hadoop becomes exceptionally difficult.
As native code, rust interfaces cleanly with C and can run in a few more places than Go - there are some active efforts to even support GPU kernels.
Go can't really do any of the three things above today, and the community is averse to include new features into the language for both good and bad reasons. Java can do the first two, but struggles in the last category.
Rust has an interesting opportunity to be a modern C which does the things java does and the things C/C++ do. But the library support and learning curves would need to improve dramatically for it to get there.
CS papers are the worst in my experience. I know lines have to be kept short, but I think some people believe a tiny code block makes them look like a better programmer.
I like how Swift does it[0] — it reads nicer than any other language I've used.
This is news to me. I use JOE and, occasionally, vi (sic). But when I use short variable names it's often because they're idiomatic and expressive. In C for example, i, j, n, src, buf, cp, etc.
Many moons ago I used IDEs. Eventually I tired of installing, configuring, and maintaining bespoke environments.
I'm confident I'm not alone.
https://insights.stackoverflow.com/survey/2019#technology-_-...
I can't imagine working that way myself. I need syntax highlighting, code completion, and go to definition at the minimum. Another newer feature I like is spelling and grammar checking of code comments.
Edit: Have you given Sublime Text 3 a shot?
Let's just say that it's a big world. People programming Excel spreadsheets aren't using vi, either. I won't dispute that.
I think "Go uses single letter variable names" is not so true in practice. There's a balance, in every language, between when to use short and long names. Go's balance is tilted (a good bit) more towards short, but it's not a hard rule.
There's significant mental overhead in reading `numberOfSubprotosOnProto`, as well as time hearing it in my head. I'd rather see `n` declared, used a few times in the next <10 lines, and then disappear. If there's two similar concepts in the same function, use slightly longer names, sure. Certainly not m and n.
I think that's the same reason math tends to use single letter variables. "Taylor series are easy! Just memorize: 'f_series_degree(evaluation_point, expansion_point) = sum(derivative_order=0..series_degree, (evaluation_point - expansion_point)^derivative_order * f^{derivative_order}(expansion_point) / derivative_order!)'
No thanks, I'll take f_n(x, a) = sum(i=0..n, f^n(a)(x-a)^n/n!).
I'm not saying more descriptive variable names doesn't help, but saying that you are not into mathematics makes your point moot.
I think to use them when I'm trying to "show my working out" and it takes me back to algebra class days so I don't mind
For more depth, check out FreeCodeCamp's course: https://youtube.com/watch?v=YS4e4q9oBaU.
Developer productivity is unmatched with Go. Focus is almost always on the problem to solve not on language features (I'm happy for generics to come but really don't need them), memory management / borrow checker or build tools / config (gradle et all).
Rust is a formular 1 car. Use it when you need it and be aware that it has substantial costs developing and maintaining (immature ecosystem).
I wrote this back in 2014 comparing (early) Rust, Go, and Haskell, but I think it's still more or less accurate. https://yager.io/programming/go.html
Anyway, this blog-post seems to rally for a better eco-system work on Rust part. Being a new language without a rich parent (like Go's "google" or C#/Typescript's "MSFT"), the situation is somewhat understandable.
99,9% of games that you describe are built in C++, it works fine. Modern engines are doing that without much troubles.
C++ programs tend to be heavily inheritance oriented, with huge lists of includes and inheritance. Decoupling things to parallelize them is very difficult in that environment. Rust is mostly a single assignment language with move semantics, which encourages creating objects (yeah, the Rust crowd calls them structs) and passing them off to something else in a somewhat functional style. So you get programs that are less tightly coupled. That's useful if you find you want to pass an object to another thread, put it on a queue, etc. for performance reasons.
Any dangling pointers or cross-thread references will be caught at compile time. That alone makes development far easier.
So it is always a matter of equating the value of a full rewrite and how well the checkers are able to provide valuable feedback.
Which I concede Rust will be much better, however then there is the whole loss of ecosystem to also consider.
> Which I concede Rust will be much better,
Aren't these two statements contradicting each other?
Games also really don't care since they are single use applications. You are not going to run something else cpu intensive in the background while playing.
Do you agree with the article's recommendation of Rust for command-line tools, or do you think Go is the right tool for that job as well?
Or perhaps I should stick with C++? For one thing, it's nice to be able to re-use code between command-line tools and other C++ programs, which AFAICT would be a bit harder between Rust & C++ and much harder between Go & C++.
I think between http, encoding/json, and the io libraries, it’s also very simple and straightforward to do most of the things a typical command-line program does, in a cleaner way than shell or Python (both have their place) and with less fuss than Rust or C++.
The last error handling fix didn’t really go anywhere, but just being able to send Either[error, T] will help quite a bit.
Imagine if all of those years of saying that it was just laziness causing people not to like Maven, massive object hierarchies, or repeating claims about JIT performance which statistically represented no application anyone actually used had instead translated into “There are a ton of basic gaps which give every new user a bad first impression. We should do something about that!”. Repeat for “Maybe it was a really bad idea re-inventing PHP-style typing with introspection so you have all of the inconvenience of static types but still commonly find type-confusion problems which editors and the compiler won't tell you about”, “Maybe it isn't reasonable to tell people that you normally need to edit multiple XML and properties files to run anything more than hello world”, or “Maybe we should burn with fire any codebase which thinks the right way to handle an error is to permanently stop working but still keep running so anything which doesn't do an end-to-end health-check won't know all of your users see the service as down”.
It may sound a bit bitter but I'm saying that as someone who started using Java circa 1995, left to more productive shores, and recently came back to a new development team seeing that nothing seems to have changed in terms of the amount of time developers spend fighting the tools rather than doing their jobs. Yes, Java code can have competitive performance (Solr/ElasticSearch are world-class) but the code I see is more commonly slower than Python while using more memory and lines of code because it turns out that even heroic attempts at JIT optimization can be easily defeated by the average enterprise Java architecture.
It is either the “we have rewritten it in X language and due to the nature the rewrite we actually realized what is a better architecture for our software/half of the features are not even needed”, or you compare totally unrelated things.
Also, I think people commonly underestimate complexity. Just look at your typical npm package description, it is not XML, yet you would never be able to write it by hand. For sufficient complexity, XML is quite good and human parseable.
Also, it simply doesn’t matter. Noone writes 344 hello world projects. What may be missing (but is there with spring boot for example) is an auto-generator for projects.
Code which is over-architected with many levels of indirection and attempts to bolt on dynamic behaviors at various levels in the frameworks used. I’ve seen teams unable to optimize things because there were so many levels of indirection that they were unable to reason about the system.
This is not Java the language but enterprise Java the culture as the problem. I have at multiple points seen a web app replaced by Perl (in the 90s), PHP, or Python to get whole multiple performance improvements and stability increases (no more mystery OOMs where it helpfully stays running serving errors rather than exiting so the OS would restart it) when the previous team literally had no idea how to make it faster or stable within the libraries they thought Real Developers™ had to use.
That’s entirely culture, not the core language, but a very high percentage of developers I’ve interacted with had thought that good Java developers were supposed to write code with that much extra complexity. I’ve been wondering whether something like Kotlin will spur a bit of a renaissance as people realize that they don’t have to do things the old enterprise Java way.
The same people were doing that with C, SUN RPC/DCE, C++, CORBA, COM/DCOM, and will do it with Go gRPC or whatever else comes down their path.
Everything that people complain about Java culture has its roots in 90's C++ and Smalltalk enterprise development platforms.
Even J2EE initial version, hated by so many Java bashers, was originally written in Objective-C as part of the collaboration effort between NeXT and Sun, in the context of OpenSTEP support for Solaris.
Which ended up Sun coming up with J2EE after they decided Java was the way forward and not Objective-C, while Apple post NeXT acquisition when Java still had parity with Objective-C, used the same ideas to port WebObjects into Java as well.
My point to the original poster was that it was too simplistic to criticize people for not using Java or the JVM without acknowledging the many legitimate reasons which motivated people to adopt alternatives, and many of the recent features the language has acquired were added because they’d been popular elsewhere. I consider that healthy since competition benefits everyone and especially in programming languages many partisans are loathe to admit that different people have different sweet spots because not everyone does the same work.
The world is better off with fewer rather than more languages for obvious reasons. I never really considered the industry to be a fragmented mess until "Go" and "Rust" came along. That was the straw on the camels back for me where I just said: "Ok please stop, you aren't helping."
I am repeating myself, but different people might have different working style. And have different communities have different taste and ways of doing stuff.
Language is not the only barrier in communication. It is just one parameter. I honestly think, different languages allows different ways of doing things (not better), with different tradeoffs. My preference to some language is not just about language I know, but also with respect to what I want to do. And how I want to do solve the problem at hand.
Even if a language, supports all possible styles of programming, will that result in a coherent language? Then, might the language be language not get very big that different people working in different styles resulting either in monstrosity of code base or fragmentation in language community. Else, the language itself might not represent the problems succinctly as the user wants. Features are not the only issue here.
If the language is just needles and redundant, there is not going to be difference in its absence. Yet, I have seen people who have very strong opinions on how to organize code, OOP or not OOP, and of course tabs vs spaces. The fragmentation is inevitable and going to exist as long as strong opinions exist.
Imagine if everyone "doing" math did it their own way, using their own sets of symbols, and syntax. Even Einstein got his Special Theory of Relativity transform directly from Lorentz. Most innovations are built on top of other innovations, and the ability to share depends on common language.
Consider an extreme straw man example of roman numeral system winning over everything just because of the inertia. The decimal system is great innovation because, it gave us succinct way expressing idea of numbers.
Not all languages are like that, but certain languages allow and encourage certain style of programming like OOP for java, though it is a multi paradigm language. I think inertia plays a big role here too. Java is always going to be OOPy language for the most part, because it is what community is built on.
Most problems in trying to understanding and communicating is going to be about concepts not the language. The syntax is probably some work, but half a day of work. But, I often do not find it hard to read the code in some other language, I get it once I see the code. But, even after seeing some code, I find it hard to come with code in that language. Because, that is the hard part. jq is one such language. Even though it is niche. When after reading docs, I find it so hard to combine all the small parts of it to make sufficiently large program. That will take, however similar the syntax is.
That is the reason, some particular style of programming dominating a language community. We got settle on something. Language is geared towards solving problems and introducing features for certain style. And that helps. It gives a coherent outlook to language and the community.
That is what I mean when I say, fragmentation is inevitable. Not everybody wants to understand all different ways of doing things. Even if the concepts seem understandable, thinking in terms of them is much harder for people. Multiple language for different dominant style seems to be a saner alternative than single language with all the different style.
As far as performance there is no doubt that the modern JVM is quite fast. Vert.x benchmarks are consistently on par with Actix and other low level frameworks.
As a non Java developer, the reason I don't touch anything Java related is because of popular applications like:
1. Eclipse and Jdeveloper which you have time to get a coffee before any of them boot up
2. solr/elastic search: 8 core and 16GB of RAM as a minimum requirement on a DEV machine, that's insane when sqlite can do basic full text search on the cheapest raspberry pi
3. Jenkins which can't run a few jobs without using many GB of memory. Other CI/CD I've used and was made in Java were also dog slow and painful in so many way: IBM urban code and another one made by oracle which was well oracle
4. the arduino IDE which often freeze my laptop forcing me to ctrl+alt+suppr
5. oracle DB: internally refer as the beast by people who deal with it, I wasn't able to run a local copy on my machine as my work laptop don't match their 256GB of RAM server we have for the dev environment.
6. boot time which make it almost unusable for CLI type of application
7. Oracle
Maybe you can make fast and efficient Java application but the highly visible ones aren't that good if you don't need all those complicated features. On the contrary, applications made in Go/Rust tend to run fine on my machine or the cheapest server.
I just take to time to wait for one of those Rust builds to finish
> solr/elastic search: 8 core and 16GB of RAM as a minimum requirement on a DEV machine, that's insane when sqlite can do basic full text search on the cheapest raspberry pi
Definitly not the hardware requirements of a 2011 dev workstation, the first time I used Solr, and as such also not the requirements of using it in 2021.
> Jenkins which can't run a few jobs without using many GB of memory. Other CI/CD I've used and was made in Java were also dog slow and painful in so many way: IBM urban code and another one made by oracle which was well oracle
So which alternative are you using with similar capabilities and less hardware resources?
> the arduino IDE which often freeze my laptop forcing me to ctrl+alt+suppr
XCode does it all the time, and is pure native code, in a mix of C and Objective-C code.
> . boot time which make it almost unusable for CLI type of application
Learn to use AOT compilers for Java.
> Oracle
Partner in crime alongside Sun and IBM in making Java widespread, having a RDMS that allows for stored procedures in Java, responsible for sponsoring research work to prove it is possible to write high quality JIT compilers in Java, did more for Java than Google would ever done for it, if they actually bothered to buy Sun.
You would need to be using the production server settings and traffic volume for this to be true. I run both - sometimes simultaneously - on a 2012 MacBook Air with 8GB and rarely even notice them running. Unless you’re hammering the system with expensive requests these less memory than Gmail in Chrome.
Yes the younger/newer generation took a look at all the XML files in J2EE and said "Isn't there something simpler", and so now today we ended up with JavaScript running on the server side (NodeJS). TypeScript came to the rescue over the last 5 years, but now we have a world with TS and Java. The solution should have been to make Java run in the Browser, and not JavaScript, but I understand the history, and how, when, why that occurred. I've been coding 30ish years myself, like you.
I'm not sure how well you can separate that: most people are going to hit those bumps when they get started, and they're going to see an ongoing frictional cost against their productivity. Yes, there are some neat things in the language — especially newer versions — but there are a lot of people who would benefit a lot from, say, a “Java: the good parts” distribution which makes it easy to start a new project and evolve it, and then SEO it as much as possible so people get that advice rather than the 10+ year old stuff many web searches will have highly ranked.
I do think there's an interesting alternate history where WebAssembly happened many years earlier in the form of Java byte-code. That would have lost a lot of the ability to read other people's code but it would have had better performance earlier and a good story for language competition which has brought many good features to Java from other languages. Unfortunately, after around 1997 or so that really came down to Microsoft so it would have been VB or C# in any case.
XML is interestingly similar where the core language community charged ahead building ever more standards on top of it but assumed that its inevitability meant someone else would fix their … not great … tools, specs, and examples for them — and then were surprised when almost everyone abandoned them for easier tools. I always liked the idea of XPath but it's effectively never moved past 1999 unless your world exclusively avoids libxml2, which wasted most of the hard work the standards group did.
One thing I think may be common about both of those is a big shift in how easy it is to build and ship development tools and programs: a 90s programmer had to live with what they got in a distribution to a much greater extent because you couldn't count on everyone having an internet connection, a fast one, package management hadn't happened much outside of the Linux/BSD world, and new things required waiting for someone to write a book you could order, finding a local user group, asking in Usenet, etc. Warts in your language still mattered but less so since for many people it was easier to keep using something than switch. After the 2000s, though, I think a lot of people realized that the cost of switching was so low that they had to care about developer ergonomics a lot more unless they had something like the massive platform pull Apple had with Objective-C and Microsoft had with C#.
Also regarding XML, Biztalk anyone?
It was right around the time when WAR/EAR/JAR files in Java were showing the power of having everything packaged and self contained. Meanwhile MSFT was stuck in DLL Hell for decades. ha.
Regarding Java packing, isn't it funny how everyone is jumping into Docker hype just to get what Java containers have given us for the last 15 years?
https://github.com/Clay-Ferguson/quantizr
Java+SpringBoot+Docker
I think I'm "doing it right", but like religions no one's is provably correct.
The younger kids are saying: "Meh, we'll just run NodeJS on the server, so we can ignore the J2EE mess the previous generation created since they're older and therefore dumber than us."
Your XML example is spot on and I agree. However I'd never say XML itself was flawed specifically because some of the tools, APIs, and specs built on top of it were flawed.
That would be like saying electricity itself is flawed because you don't like electric tooth brushes.
Likewise, Java was not flawed just because J2EE was a mess. The fact that J2EE drove people to NodeJS, has nothing whatsoever to do with Java itself.
I’ll say XML was flawed. It was a great initiative behind the wrong data model. The idea was to take what made sense for documents (strings with markup) and use that to represent everything else. But most data structures are really awkward expressed that way, and you run into weird decisions like: Should my map be a list of items or a set of attribute pairs in a single node? Is the key a node or an attribute? When does order matter? Etc.
If the XML standards group started with JSON or YAML or .. anything else, I think they would have made something really useful. But we didn’t think of that at the time, so instead we have XML. An impressive monolith built on a dead mountain.
What I meant was "You can't say technology X is flawed because tools using X are flawed".
Even me, 20 year Java vet. Basically been doing full time TS for about 5 years now.
Q: Why was JavaScript invented? A: To run code in the Browser.
Q: Why didn't they run Java in the Browser? A: They did (applets). They tried. They failed. So they had to start over. They WANTED "Java" in the browser, but it wasn't practical for memory and CPU reasons, so they cobbled JavaScript together over a weekend.
However the world would be a better place if there was just Java, and neither of it's two offspring were ever born (JS and TS).
JavaScript is highly mutable and under the right circumstances you can trick JavaScript applications to modify themselves. i.e.: Prototype pollution.
// 100% type-safe function :-)
function f(a: Date): number {
return a.getDate();
}
// Input to 100% type-safe function
const p = new Proxy(new Date(), {
get: function(target, prop, receiver) {
if (prop !== 'getDate') {
return Reflect.get(target, prop, receiver);
}
return function() {
console.log('Not typesafe :(');
};
}
});
f(p);
What happened? all type-safety was circumvented. The f function that should return a number did not return a number. In fact, it didn't return anything.
The TypeScript compiler didn't return any errors either. This is perfectly valid TypeScript.
Why? because TypeScript is based on JavaScript. It is not 100% typesafe and it will never be.
Is TypeScript an improvement? yes. Does it help a lot of people? yes. Is it 100% typesafe? no.
Did TypeScript "fix" JavaScript? Mostly, but no. I hope the mods unflag my original comment.
You then gave an actual example of #2. lol.
The part that breaks things is that when f invokes a.getDate(), the Proxy get trap changes will return another function instead of Date#getDate at runtime, and that wasn't validated at compile time.
However this is also simultaneously true: You can code in TypeScript and achieve 100% type safety by putting types on everything. If I claim all cubes can be painted red, you can't disprove that by proving green cubes exist.
Does TypeScript forbid using JavaScript features? no.
Can TypeScript realistically verify that your program is type-safe? no.
Is TypeScript 100% type-safe? no. They wanted fast adoption, therefore they allowed JavaScript and untyped variables.
I have 100% type safety, and it's all done by TypeScript and my programming language IS TypeScript (not JS)
The the final output format generated by a compiler has absolutely nothing to do with whether the Language being compiled is typesafe or not. That would be like saying since Bytecode is not typesafe therefore Java is not a type safe language.
Google closure compiler and JetBrains IDEs can use JSdoc to validate types. I have used those to a reasonable level of accuracy to document entire JavaScript projects where I cannot migrate to TypeScript.
Now I'm not saying there's no room for Java any more, but "just Java" meeeeeeh.
That said, I shudder at the thought of Java being any larger than it is, much less ubiquitous. If I had to choose between this world and one where Java was the "one true language" (or even a more extreme version of the current situation where we have other languages all built atop the JVM) I would pick this world with fragmented languages every single time.
Remember, I'm talking about "source level" syntax of the language not any specific VM implementation. Every compiler and VM can be replaced eventually.
It's the code syntax that needs to be "universal" not anything else.
It's been DECADES. Plenty of time to fix things but nope. I don't know what Java's developers were interested in but improving things for other developers was not one of them.
C# is literally a better Java already. And Kotlin.
And by culture I mean, java attracted people who think that lines of code are cheap and see nothing wrong with a 200 line class which has no actual behaviour beyond boilerplate. People who measure their output by the number of lines of code added per day, not the number of features added to a project per year.
Any "fixed" version of java needs to either bring those people along - and in the process import a lot of java's stale thinking. (Some corners of the C# world struggle with this). Or leave those people behind and build a new community around your new thing (eg Scala, Clojure). You can see this in the java community already - there are plenty of tools in the modern JVM for doing terse functional programming. But as far as I know that stuff remains unpopular. Why? My theory is that most of the people who really care about writing terse, efficient, maintainable code jumped to better languages years ago.
A skilled Java developer might make a huge POJO have every variable private and then implement getters and setters to control or monitor access to every member.
But then some noob straight outta college will look at that code, not understand why it's being done so 'stupidly', and just delete all the accessors and make every variable public, so you don't even need any getters/setters. Said noob will consider himself a superior programmer until he looks back on it 10 years later, with enough wisdom to see clearly.
The noob’s instincts are right. Well written code in just about any other language doesn’t need all that crap. And for good reason - you can really feel the difference if you actually measure your performance programming, in the short term or the long term. And in either features/hour or features/line changed.
I worked at a place once which had this C# project which wrapped incoming http calls into calls to our internal backend (also http). Then it took the JSON from the backend and converted it to JSON for the browser. The code was 3500 lines full of that sort of POJO getter and setter crap. Every time we added a feature, this code needed to be updated. We had 2 people assigned full time to do those changes. After way too many meetings we managed to replace the whole thing with a few hundred lines of nodejs code. Those guys were moved into more useful roles - saving the company 2 full time salaries.
I will openly admit however when VSCode came along and TypeScript I totally regained a new love for Microsoft, and they have redeemed themselves, also by accepting Linux into their dying OS.
Typing is easy. It’s all that other stuff that I avoid by using better languages / better conventions.
So you never generally even open those files unless you're expending the 5 seconds it takes to add a new prop. But as I said I could make each property use one line of code if I chose too...something like "String x;" just like all other languages.
There is nothing in java that requires it per se, it’s just a design pattern/“standard” for some library to dynamically inspect objects. As for the amount of time it takes, I’m fairly sure that it takes less time to press alt+insert+select setters getters than it is to write anything, but to each there own. It’s not like people read source code from top to bottom.
Also, this decimates your velocity is just straight-up coming from an alternative world. How do you write code, are you copying something by typing?
I’m sorry to assume it, but I think you only know about java development from third-hand infos and it has nothing to do with reality. Fact is, Java is so huge that for every unreadable mess of a project, you get someone working on robot programming or something totally different with proper architectural decisions and the like. It is quite a bad take to assume it for the whole language.
I'd love to see stats on how common this stuff is amongst java programmers. I think its more popular than you think.
I agree that modern java has lots of modern tools to write reasonable code - like closures and functional primitives. But its very normal amongst java programmers to never use that stuff.
I worked as a professional interviewer for a year or so recently and interviewed 400+ programming candidates. One of the tasks was a 30 minute coding challenge - using the candidate's own computer and preferred language. A huge percentage of the java programmers, even under explicit time pressure, wasted time adding needless junk (like getters and setters or extraneous, pointless classes) to their code. Out of maybe 50 java programmers I think I only saw 1 or 2 java candidates use any of java's functional programming primitives (like map) to keep their code terse and clean. Most typed everything manually, and didn't know or didn't use their IDE's codegen features.
Is that the fault of java, the language? I don't know. As I said in another comment I think the problem is cultural. I don't really have a problem with java-the-language. But a large part of java-the-community seems blissfully content with mediocrity. I took java off my resume years ago because I don't want that kind of coworker.
> How do you write code, are you copying something by typing?
In the languages I use, copy+paste is never needed. Thats what the compiler is for, and things like rust's derive(Eq) macros.
> I’m sorry to assume it, but I think you only know about java development from third-hand infos and it has nothing to do with reality.
Nope. Eg:
https://github.com/apache/incubator-retired-wave/search?q=ge...
Nonetheless, I’m sorry for my previous overtly aggressive comments, it has no place here.
I write a lot of javascript for a living, and you're not wrong[1]. I think the struggle javascript has is that an extremely high percentage of javascript programmers are pretty new to programming in general. So there's an awful lot of javascript code written by unsteady hands.
If javascript is a magnet for novices, java feels like a magnet language for middle aged with kids "programming is just a job for me" indifference. I feel contempt for that mindset - but to respond in kind to your apology, I think the contempt I feel is probably reflected fear / disgust at the idea of settling. To me programming still feels like casting magic spells. I think I'm terrified of that spark some day being extinguished.
[1] I check in on this issue every year or so and it never fails to delight and horrify in equal measure: https://github.com/ChainSafe/web3.js/issues/1178
For example, I prefer
public class LineOptions {
public Color color = Color.BLACK;
public int thickness = 1;
...
}
void drawLine(int sx, int sy, int tx, int ty, LineOptions options) { ... }
ctx.drawLine(0,0, 100, 100, new LineOptions() {{ color=Color.RED; thickness=3; }});
public class LineOptions {
private Color color = Color.BLACK;
private int thickness = 1;
...
public LineOptions() { }
public LineOptions(Color color, int thickness, ...) {
this.color = color;
this.thickness = thickness;
...
}
public Color getColor() { return this.color; }
public LineOptions setColor(Color color) { this.color = color; return this; }
public Color getThickness() { return this.thickness; }
public LineOptions setThickness(int thickness) { this.thickness = thickness; return this; }
...
}
ctx.drawLine(0,0, 100, 100, new LineOptions().setColor(Color.RED).setThickness(3));
LineOptions opts = new LineOptions();
opts.setColor(Color.RED);
opts.setThickness(3);
ctx.drawLine(0,0, 100, 100, opts);The better parts of Scala, kotlin, and the guava library are steadily making their way into the language. But if there wasn't competition the language would absolutely stagnate again as risk aversion sets in.
I think there are some interesting points to made where you’re coming from, but this fragmented approach isn’t effectively making them. Something like a blog post might be better.
Value types, interior pointers, multiple levels of pointers, slices, and radically different indirect dispatch semantics are just a few things that Go has that Java doesn’t. These aren’t things that you can staple to Java. Java is more than syntax, it’s the semantics of the JVM and its object system, which should only be extended in a backwards-compatible way.
So I’m gonna say that the reason Go exists is exactly because the creators didn’t want to burn down Java and start over. It turns out that you can create a new language without burning anything down. There is also C# and the various nontrivial differences between C# and Java, like value types and type erasure in generics.
There are plenty of languages which exist side-by-side with Java in the JVM: Clojure, Kotlin, and Scala to name three. These all have their differences but they’re all designed specifically with the JVM in mind. Go isn’t.
While generating less garbage decreases the load on the GC so it can sometimes get away with it, complex server apps will not fall into this category. So actually, I really don’t see much value in go, other than the “you can throw as many developer at it, because they can’t really step on each other’s foot” which is actually great for what it was created for.
You're telling me that Go's garbage collector, which is optimized for low latency, has worse throughput than the JVM's default allocator, which is optimized for high throughput?
Most garbage collectors are either designed for low latency or high throughput. You cannot optimize for both. The choice for high throughput makes sense for batch programs, like compilers, command-line tools, generating analytics reports, etc. Choosing low-latency makes sense for web services and the backend services behind them.
As fanout increases, the GC latency in backend services becomes much more important.
In the end, no language is catching the whole problematic and solve it at once. So there is a programming language fatigue.
PS: when I say that things happen within a timeframe of 5 years, it includes the time to deliver the feature in the language, and people to massively adopt it, and new developped code to include it in mass.
Maybe a way to proceed would be to have a common set of code which every new language would try to rewrite, and thus see how much better it is, or is not, than the existing ones. Comparative analysis.
Companies are spending billions each year because of having to translate from one language to another.
Plus code can already be shared with various bindings. Lately there's been a big push with "microservices" or generally networked architectures so different components built in entirely different stacks can still interoperate just fine.
yeah by making it common lisp instead of java
> All those kiddies
You chose the wrong venue for this remark.
There is no monopoly on the grumpy old fart act; there is only a difference in their willingness to continue pushing back the boundaries of ignorance.
All of which is notwithstanding the necessary and essential vigour of youthful perspectives, c.f. Seymour Cray’s notable preference for working with recently graduated engineers both for their energy and their fresh ideas.
edit to respond: calling them "bells and whistles" is a deep misunderstanding of what sum types are. They profoundly change how every single piece of code in the language is written, starting from how nulls are handled, and cannot be retrofitted into an existing ecosystem. (You can add them later, but baking in sum types from the start is very different. In particular Java would not have its terrible exception system if it had sum types.)
That JEP elaborates on the same ideas (notably using `instanceof` instead), as the linked JEP explains, but the motivation for sealed classes extends to further harmony with subtyping. The major item seems, to me, to be allowing interfaces to be a supertype. A minor but distinctive item is that the sum type's variants can be defined at (some) distance from the base type, rather than all being defined in a single breath.
The problem is, even though you could always express sum types in Java, it's verbose, unpleasant, and above all "clever" in a way unnecessary in other languages. I think this JEP helps somewhat -- the private constructor trick in particular goes away -- but it doesn't really help with clients of your sum type. Pattern matching is still yet to come, and if you want a Visitor, you still need to write a Visitor.
To the grandparent's point, this JEP isn't enough to provide a coherent alternative to checked exceptions or other kinds of structured control flow.
Product types model "x and y", sum types model "x or y". One of them is universal. The other has been totally missing from mainstream languages until recently. No wonder our software sucks so much.
Go in particular is really unfortunate for a language so new. The language's weaknesses have dropped my estimation of its creators by several notches.
There, I fixed it for you.
Every language has product types. Every programmer understands how useful product types are. Why in the world would the same not apply to sum types?
Sum types can be useful. Other aspects of languages can be useful, too. Why fixate on that one? And if you're going to say that it's a minimum bar, well, some of the other features are missing in most languages that have sum types.
Pick the language that has the total set of features that makes it easiest to write whatever program you're trying to write. Don't get locked in to focusing on only one feature.
I haven't kept a tally of my frustrations with Java, but I can assure you that the most frequent is its lack of first-class sum types. Every time I need to encode (encode!) such a basic concept as "it could be this or that" using subclasses and some Design Pattern to Manage the Variants (usually Visitor, sometimes State), I metaphorically weep for my soul.
There are plenty of other minor gripes I have with the language -- there have been multiple instances where generic generics (HKTs, `class Foo<F<_>>`) would have made things much clearer -- but sum types are certainly the most prominent.
Our field has a terrible reputation for quality. In my estimation roughly 70-80% of that is directly or indirectly because of the lack of sum types.
Directly: people don't have the right tools to make invalid states in their business logic unrepresentable.
Indirectly: the lack of sum types results in broken null and error handling.
To me, sum types for error handling are isomorphic to checked exceptions. They both let you do dual-track programming - separating the normal path from the error path. Both have compiler support for enforcement. But checked exceptions are no longer considered to be the answer. What went wrong?
The problem turned out to be the programmers. They did at least two things that subverted checked exceptions.
First, they silently ate exceptions (that is, had an empty catch block just to make the exception go away. This is the equivalent of having a sum type that is either an integer or Nothing, and a function. Rather than return the sum type, the function returns an integer. In the Nothing case, the function just returns 0. That's about the same as the empty catch block to not have to declare the exception in the function's return type.
The second way checked exceptions went wrong was the opposite. When a function could throw Exception1, Exception2, Exception3, and Exception4, it was tempting to just declare it as throwing Exception (the base class). In the same way, a function that gets SumType1 back from one function, SumType2 back from another function, and SumType3 from a third function may return the sum of the sum types. It becomes an Everything type.
In both cases, the problem was that programmers were lazy. But here we are 20 years later, and programmers are still lazy. Until the programmers change, sum types won't fix things any more than checked exceptions did.
So, I think you're right about a result type being isomorphic to checked exceptions, for the reasons you laid out. If you compare it to Rust, what ends up happening is similar -- many libraries return an error type that's a union of all their dependencies' error types, and binaries end up using an "everything" anyhow::Error type in the end. However, I think where sum types in general end up working and checked exceptions don't are:
1. Sum types don't encourage a mix of checked and unchecked exceptions the way Java does. Translating from Rust, all exceptions that are meant to be handled by regular users are checked. The only exceptions that are unchecked are broken invariants (panics), which usually end up being handled either through aborting the program or through some sort of top-level restart logic. You could write Java in that style but it's not the ecosystem's convention.
2. Sum types are more general than checked exceptions: they can be used to express nulls and business logic as well. I suspect checked exceptions would have worked better if Java also had nullable and non-nullable types, because nullability is such a common source of errors.
3. You're right that you can drop an error on the floor with sum types as well, just like an empty catch block with exceptions. But that just doesn't happen nearly as often in practice, because result types form a closed set. With checked exceptions, in practice you often end up with a method throwing both checked and unchecked exceptions, and the same syntax is used to handle both. I think checked and unchecked exceptions are fundamentally very, very different and mixing the two is a mistake.
Once again, thank you for your response.
We can argue on the percentage. But the point on the direct and indirect damages makes a lot of sense.
Or, "I will not use any language which made software eat the world"
What more do you need?
Because it's designed in a way that doesn't always allow these bells and whistles.
If I were to tell you that we should have kept using horse-drawn carriages, and that any of the fancy bells and whistles that cars have could be added to horse-drawn carriages, you would probably look at me with confusion.
> Improving a dominant (but broken) language is called "innovation" and "improvement"
Sure? But modifying an existing (and for most of its history proprietary) language can be a difficult, potentially-political move. If I have an idea on how to do, I don't know, linear-types checked at compile-time, I wouldn't have any idea where to begin adding that to the javac compiler. It might be easier to build my own little language to build it, and then hope that maybe the Oracle devs decide to pick it up.
There are some improvements that can be made however (any language can be improved on), that would require minimal breaking changes (like fixing Type-Erasure), and I'd even be fine with minimal breaking changes that break backwards compatibility every 5 years or so.
The problem is when people say "Let's burn it all down and start over, so zero existing code is salvageable."
I mean, let’s go with your example with type erasure; people have been complaining about it for more than a decade, and Oracle still hasn’t fixed it. The Java language designers aren’t stupid, and I’m sure they’ve read the complaints, but it still is almost universally agreed upon to be a broken feature of the language.
It’s almost never clear if “language feature X” is a good idea until it’s been implemented and battle-tested. If I have a new idea on how to build something in a compiler and I’m not sure if it’s a good idea, are you saying that the best path forward would be for me to make a PR to javac instead of building a proof of concept language?
I actually do agree that as software engineers, we're often a bit too eager to reinvent wheels. While I am not a huge fan of Java, if I owned a company, I would probably be more likely to use a JVM language (probably Clojure) than I would to use something like Haskell or Idris, precisely for the reasons you've discussed.
My overall point, though, is that often times languages themselves lag behind the state-of-the-art; there's been a lot of progress made in language design, and Java (and a lot of other languages) can feel crufty in the process. Sometimes the wheel really does need to be reinvented...if we could somehow convince the entire industry to use Lisp, this would (arguably) be a non-issue, since they allow you to abuse macros relatively easily and add language features (see CLOS or core.async for examples), but Lisp hasn't really taken over the world like I wish it would.
When you look at the millions of man-hours that have gone into the "burn it all down and start from scratch" languages (Go, Rust, etc) and you consider what if those guys had written new compilers for JAVA syntax? How great that would be. They could still accomplish many Go and Rust objectives without having to completely invent their own non-Java-like syntax. Even something that was "Java-like" is better than burning it all down every time something new is needed.
However, in a sister thread I think you mentioned that you are basically alright with languages targeting the same VM, which I think is probably a better path forward for a majority of use-cases. Clojure and Kotlin and Scala all benefit from being more-or-less fully interoperable with each other; as a result, one can feel free to experiment with language design to their heart's content without too much fragmentation.
That said, I don't know that it's entirely fair to completely criticize Rust on this; Rust exists specifically to address issues with C and C++, languages without garbage collection, and whose design doesn't quite allow the same level of compiler safety and goodness that Rust does, though to be fair Rust does have C FFI so it's not necessarily always reinventing the wheel either. I mean, I agree with the blog post we're chatting on top of; Rust might be super awesome for systems-ey stuff, but for anything TCP-or-higher, I think a managed language is kind of better.
The same would be true if all the car companies in the world just cooperated on a single car model to rule them all, right?
Languages themselves don't need to be completely reinvented like things in the real world (cars, etc). For example C/C++ has been around for decades and no one ever said "Burn it all down and start over."
Every language is designed with a specific design decisions and tradeoffs intended for hopefully wide audience. I think C and unix culture reflects this in some way. It is home grown environment by handful engineers working initially their own sake. You cannot objectively say, "Everything as file" is good concept, but if you are just handful of people tackling myriad of problems, it should have been liberating to have a too simple of an abstraction. It might be pile of hacks on pile of hacks but, it worked for the time.
Whether it is good or bad, depends on what you want to achieve. I think more communities can benefit from more focus on what they are and how they want to do things than trying to be "be all, do all" thing. I might not want to solve problems the way somebody else would solve the problem and I would use a tool to best fits my way of thinking.
Even if there is only one language, fragmentation is inevitable. Because, all people might not have the same way of working or thinking. Even if it is written in same language, one might not understand idioms of somebody else.
It is easier to read a language with community adopted idioms, than a language that is made for all people. I have been using Java, but the erlang concurrency primitives looks great. But, it would be hell, if single code base has all possible primitives and style.
Asking people to have one language to work is not different from asking people to think in one single way.
Edit: added couple more rants.
Why not? And why things do "in the real world"?
The fact that languages should evolve (and that they do) is not in opposition to a need or desire for new languages.
Here's a newsflash for you: if the Netscape inventors of JavaScript had been capable of making Java run in the browser then all you kids would be running Java instead of JS today.
The only reason JS exists at all is because early browsers had limited memory and CPU back in 1990s, so they cobbled something together over a weekend and named it JavaScript. Now that JS is running server side, these kids claim that's the way it should've been from the beginning. No, sorry JS is a train wreck compared to Java, which is why MSFT had to come to the rescue with TypeScript.
There is such a thing as "finally getting it right". We don't need to replace English with something "new" every couple of years, and writing instructions for machines is the same. The syntax of Java was "almost perfect" and is STILL extremely similar in TS/JS so there was no need to "burn it all down" like Go and Rust did.
Why do you think JavaScript has the word "Java" right in it. lol. Must have been something in there that was good to this very day.
Eh, no. From the mouth of Brendan Eich himself [0]:
> InfoWorld: As I understand it, JavaScript started out as Mocha, then became LiveScript and then became JavaScript when Netscape and Sun got together. But it actually has nothing to do with Java or not much to do with it, correct?
> Eich: That’s right. It was all within six months from May till December (1995) that it was Mocha and then LiveScript. And then in early December, Netscape and Sun did a license agreement and it became JavaScript. And the idea was to make it a complementary scripting language to go with Java, with the compiled language.
It was completely down to marketing. I've heard it described as riding the coattails of Java, which Sun was dumping huge amounts of money into marketing to begin with. Allusions to "something in there" notwithstanding.
[0] https://www.infoworld.com/article/2653798/javascript-creator...
From day one, Eich was told to make it "Java-like". Netscape first tried to get Java itself running in the browser, even before developing JavaScript. JavaScript looks like Java not by accident but on purpose.
JavaScript is particularly hideous, and was cobbled together over a weekend, and because of that misstep the industry got stuck with it and had to invent TypeScript to "fix it" and create something tolerable in the modern world.
Neither do I. My point was that your comment didn't use any features specific to Java, so if you replaced "Java" with literally any other language you'd have the exact same argument. The details you added here like that it was "perfectly dominant and acceptable" help in that regard (not that I agree with where you're going), but your original comment would have been equally valid with literally any programming language.
No. Java never was what you're claiming.
C/C++ is the perfect example of a language lasting multiple decades without each new generation trying to throw it all out and start from scratch, but simply evolving it.
No, Java would not be the "only" language in any set of circumstances, however fictional. No language will be, ever, because no language is better than all other languages at everything.
Everyone wants to have fun.
And when things get complicated enough just switch jobs.
I think you mean to use the right medium for the project. Languages are a communications medium. Your compiler, linter, editor, debugger, those are your tools.
Also, they are tools in a much more narrow sense as well, but that is left as an exercise.
> Use the right tool for the job.
Rust will be the right tool for the job when the library ecosystem evolves beyond just Actix. Give it time.
FWIW, I've written half a dozen web services in Rust [1] and it's a breeze. The type system is incredibly expressive and lets you accomplish things with clarity. I already find it an appropriate tool for backend web and service development.
[1] eg. https://vo.codes is 100% Rust
edit to respond: as the commenter below pointed out, dynamic languages can express sum types just fine (though statically verifying e.g. null checks isn't possible without some sort of gradual typing effort). This is why they are superior to traditional statically typed languages like Java. But even better are languages which have static sum types.
What I am saying is if you have static types (good) but don't do anything else, you loose sums (bad). You then need to add (back) sums.
Firstly, dynamic languages are typed. The word "untyped" has a very specific meaning in a narrow branch of computer science, as in "untyped calculus", which refers to a situation in which the types of the syntax tree nodes of the program are not being taken into consideration. (Which doesn't mean they don't exist, by the way!)
In sofware engineering, an untyped language is something utterly unsafe, like assembly language or BCPL, where every value is just a machine word, and the meaning/type of a machine word is just that of whatever operation is being applied to it at a given spot in the program.
Dynamic languages are typed, and even to the extent that some of them do assign type to the nodes of program (type inference).
Secondly, a "tag" is an implementation concept. A tag typically does not give all of the type information about an object, or not about every object kind. There may be more than one kind of tag used. For instance, a value might have a two-bit tag indicating a crude classification of a value into four categories. For an unboxed fixnum integer, that indicates the exact type (fixnum), but most heap objects might be lumped into the same category accordint to that tag, distinguished by a more comprehensive type tag that might take on, say, one of twenty values. That tag is also not complete information for all objects. For instance for an OOP object, the tag might indicate "this is an OOP object", without regard for its class: all OOP objects might share the same tag. Yet, at the language level, their type is their class. Another example is functions. All functions might have a tag indicating "this is a function". There might be a separate tag for things like compiled function, interpreted function, foreign function or whatever. But the type of a function takes into account not just that it's a function, but other properties like number of arguments. In many dynamic languages, you cannot call a two arguments function with three arguments. That check doesn't come from the tag, which doesn't have that information.
The type of an object in a dynamic setting goes beyond the tag. For some objects, the word tag tells everything, and the heap tag does for others; but not for all object kinds.
When the dynamic language implements a type inference system, the truths which that inference system works with cannot simply be reasoning about tags. The representation of type has to include concepts like the class of an object, or the number of arguments and types of a function and its return type.
Sum types are a zillion times more important.
Right now, I'm writing a client for a virtual world in Rust. There's a big need for concurrency, but, unlike web stuff, it's all tightly interrelated. There's a GPU to keep busy. There's network traffic of several different kinds. There are compute-bound tasks which need to be kept out of the frame refresh loop.
Rust is good for this. The existing C++ client is too much of a mess to make concurrent; people looked at it and gave up. In Rust, it's coming along nicely.
Use the right tool for the job.