Community
Chat Logs
Tuesday, November 3, 2026 (America/New_York)
- nevet[ByteCode.News] Where Does The Experience Come From? - https://bytecode.news/posts/2026/11/where-does-the-experience-come-from
- bluedreamreal: thoughts on `var` in java? after we moved to java 21 at work, my boss signalled being against it. I largely agree, in that. a strongly typed language that hides its types is.. weird. That being said, the verbosity of potentially declaring the same type left and right is weird. a language should provide good abstractions for it
- blue(this is slightly related to the above article)
- blue(re knuth "read like essay")
- dreamrealIt doesn't hide the types, though: var foo=new ArrayList<String>() <-- the type is right there, why would you NEED it redeclared? var isn't appropriate outside of tightly scoped functions
- bluecit approach: enforce left, be nice on right; Point point = { x: 1, y: 2 }; where Point is a struct with fields x and y, both i32
- dreamrealI'm actually kinda neutral on var
- dreamrealI use it but eh
- bluedreamreal: it doesn't in YOUR example. but it does when right is NOT a `new`
- bluethe invariant isn't universally held
- blueex: `var foo = bar.subList(0, 1);`
- * dreamreal nods. I am not a pedant when it comes to var. Use it when it helps, ignore it when it does not.
- dreamrealIt is not rocket science.
- dreamrealif that means no var ever, well, there you are: you have to be able to read your own codebase.
- bluenothing is rocket science, except rocket science. however, communicating intent, and being transparent, are invaluable, I think. it's nice to know this is a List or an ArrayList *without* hovering over it
- blue`var` feels to much javascripty to me: in a bad way, for a statically typed language
- bluetoo much*
- dreamrealIf you're using concrete types in your lvalue without that being significant, you're doing it wrong!
- dreamrealvar comes from languages like JS, scala, kotlin
- blueya hence List
- blueI'm just not very comfortable with var; or auto in c++, for that matter. I fear the gains aren't significant, and the payment is dear
- blueanyway, good article
- dreamrealThank you.
- bluedreamreal: btw, another thought: "The LLM affirms" is generally, but not *universally* true. In my example, "the clanker is servile" is the more accurate observation. It will generally pushback first, if it can; especially if the conversation has little charted ground yet (your tone is less authorative). Generally speaking, it will try to accomodate a niche between its general knowledge and your wishes. But
- blueit doesn't affirm universally, all the time, everywhen
- blueIn my experience*
- bluepush back*
- blueauthoritative*, oof, my typing is terrible
- bluedreamreal: anthropic IPO nov 20 or thereabouts
- bluehi phaleth
- phalethhi blue
- blue0.45 expected this week, god willing
- bluealso known as the Trump #1 release
- blue:P
- blueI hope 0.46 won't be slow...
- blue^ dreamreal
- phalethrepopack is already updated to 0.44
- blueyes
- phalethmobile perf of primate website is still very good https://pagespeed.web.dev/analysis/https-primate-run/wyxa3mh0bb?form_factor=mobile
- phalethis the website expected to become slower?
- jreicherblue: I use var wherever it's possible, partly because finding where it's not possible is sometimes useful information.
- jreicherDitto with <>
- jreicherI'm aware of (respectable) arguments against var though
- bluejreicher: I do use <>; also recommend by my boss. but var I do not use at all; I wouldn't use it even had he blest it
- bluerecommended*
- blueas I laid out above, there are scenarios where using var obscures the type, when you read it. this isn't a big deal statically, but it makes overviewing code harder, for no good reason other than terseness
- blueit also violates a certain principle wherein Java is different than JS; a JS var/let/const can bind to any type; this is not the case in java; but `var` seems to suggest that. And last but not least, the name is preencumbered by other programming languages
- blueI think those three arguments satisfy the threshold of "not worth to use"
- bluedreamreal: flog is edging closer to being able to format the rcompat project; after that, primate. if you wish, I can also train it on `ui-primate`
- bluenote that it formats in an opinionated way, much like prettier does; 2-spaces, double quotes, 80 columns
- bluethe main adventures is that it is very fast and that it spares you from dealing with a formatting policy in your project
- blueit will format .ts and .js files for starts, probably .tsx/.jsx later (irrelevant in your case, you use marko)
- dreamrealblue: not a matter of wishes on my part, if it's useful, USE IT
- bluedreamreal: primate 0.45 is getting transactions, and it is absolute amaze sauce!
- jreicherblue: your last two points aren't relevant to Java because, quite literally, they are not about Java. It's not really a valid argument to criticise a language for confusions suffered by people proficient in other languages.
- blueawait using tx = await db.transaction(); /* await OtherStoreINeedLocked.lock(); await Store.update(); await tx.commit();`
- bluea few notes about `await using` in JS: it's relatively; it uses known global symbols to allow you to clean up automatically upon leaving context; in this case, the transaction will automatically roll back if the route handler throws
- bluerelatively new*
- blueit also uses async context, which is another, not new, but relatively lesser known feature of JS. it basically allows you to 'serialise' (I'm oversimplifying it) callbacks
- blueI learnt about it a year or two ago from systemfault, and it's really cool. this is how we 'connect' the stores to the transaction
- blueit's a bit of magic, but I think it's good magic (tm) there
- bluehm, I botched up the example, should have not written /* there
- bluejreicher: I disagree. language designers do not live in a vacuum. they look at prior art, and it's a perfectly valid argument to criticise them for confusings they have created, by overloading known terms
- blueexample: TS people refer to arrays like this: [string, number] as tuples. the term is misleading: tuples are NOT arrays of a fixed length and fixed types. I suppose they borrowed the tuple term because in this case, the order of the types matters, but they are not tuples. it would have been better to call them bounded arrays or something that expresses better what they are, but the decision was made to call
- bluethem tuples
- bluethe java designers have choices; they could come up with a new keyword, they could choose to not introduce `var` because on how ubiquitous it is already, the fact it exists in js, is highly associated with it, and even in js itself, has very confusing semantics (hoisting). the java designers would have been better served with `auto`, which would have been just as overloaded, but at least in a very similar
- bluemanner, in another strongly typed language
- blueas it stands, they made the more confusing choice
- blueand it's 100% on them and on no one else
- bluehistorically java already shared many confusing similarities with js; js' Date was modelled after java's. this is, of course, not java's fault, but as said, the designers do not exist in a vacuum
- jreicherWhy is it not a valid complaint to say Java is right and the other languages are wrong? You seem to place a high value on tradition.
- bluebecause 'right' means nothing when the choices you made serve to confuse rather than elucidate
- jreicherWhat if the Java designers believe they are elucidating, and it's worth the cost?
- jreicherI should perhaps add this is not theoretical for me. I'm working on a language design that does exactly this.
- bluethen they are gravely mistaken, in my eyes, in that instance. I do not know who they wanted to elucidate with such a poor choice of an historically heavily burdened term
- jreicherWell I can't take myself as an example. The term they chose has worked excellently for me. That's one of the reasons i use it every chance I get.
- jreicher^can't^can
- bluein my eyes, `var` is eternally burnt by js. I might not like it, but any other language I come across, it confuses me. scala has the same situation
- jreicherAnd I don't feel the same way, because my exposure to JS is much less than my exposure to other languages.
- bluein your language, you might not have much or any history with JS, which is ok, in that case that term would work for you
- bluebut for most people it wouldn't. js is extremely ubiquitous
- blues/in your language/in your case/
- jreicherAh, now we come to the truth of it. You believe JS has special status.
- blueI don't. What special status should it have?
- dreamrealare we still yapping about var?
- jreicherYou believe it's special in its ubiquity. If a relatively "unpopular" language loaded a term I don't think you would be bothered.
- bluethis works both ways: it was a mistake by JS to replicate Java Date. They are paying for this until today. Temporal is a dumpster fire whose only existence is on account of the fact Date is so terrible
- jreicherdreamreal: kind of. Not the concept of it (LVTI) but now just the name.
- dreamrealI mean, var was requested: it's relatively safe in that it can infer its type from the use; people wanted var; they got var.
- jreicherblue: I understand your point, but I don't believe JS has the status you think it does.
- bluedreamreal, that isn't the discussion at all. the discussion is whether language designers exist in a vacuum, and shouldn't look around when introducing new constructs, and using terms that are heavily encumbered
- dreamrealscala and kotlin, other popular JVM languages, used var (and val), so there you were
- jreicherWhere "heavily encumbered" means "in use by a language of exceptional popularity according to the person making the criticism"
- blueit's not according to me, it's a quasi-universal truth
- jreicherAccording to you. :)
- blue"JavaScript is the most widely used language among professional developers, utilized by approximately 68.9% of them in 2025"
- bluethis is factual, you can look it up yourself, in countless surveys and reports
- jreicherI understand your point. I still don't think the popularity has the special status you think it does.
- jreicherIt's a bit like saying "most happy songs are written in a major key, so you can't use a major key for an unhappy song"
- jreicherStatistically true, stylistically false.
- blueyou still haven't answered the question of why java couldn't have chosen a more appropriate identifier
- blueauto and others come to mind
- jreicherI don't know the answer. There might have been something compelling the choice of "var".
- blueheck, even scala's `val` would have been better. it's *way* less encumbered
- jreicherCheck the original JEP perhaps?
- blue" - While it was not the most popular choice in the survey, it was
- blueclearly the choice that the most people were OK with. Many hated
- bluevar/val; others hated var/let. Almost no one hated var-only."
- blueso basically, it was vibe-designed. great.
- bluehttps://openjdk.org/jeps/286 and https://mail.openjdk.org/pipermail/platform-jep-discuss/2016-December/000066.html (SYNTAX)
- nevethttps://openjdk.org/jeps/286 "JEP 286: Local-Variable Type Inference" || https://mail.openjdk.org/pipermail/platform-jep-discuss/2016-December/000066.html "Update on JEP-286 (Local Variable Type Inference)"
- bluenote that javascript isn't even mentioned as prior, whilst much more obscure languages (groovy???) are mentioned as reference
- bluethis is ridiculous
- jreicherAccording to you
- blueof course it's according to me
- bluethis is my opinion
- jreicherAnd I'm OK with you having that opinion. :)
- blueI understand that clearly
- bluebut people "hating" stuff is a good way to design a language
- blueisn't*
- bluethere are other considerations
- bluethe email mentioned `var` wasn't even the most popular choice
- jreicheryes, but it also describes the designers' reasoning based on statistical fact. So in their opinion they had a compelling reason for "var", and it's not obvious your reasoning is superior.
- blueI don't care for `var` or `auto`, in this case. the way they look doesn't play a significant role for me, and honestly, nor should it for the language's designers, I would imagine
- blueprior art, and how real people might perceive the feature, is way more important than some commitee's aesthetic prefs
- bluethis isn't somewhere in the aether; my boss said he rejected `var` partially on account of how javascripty it feels. this isn't evidence for a general pattern, but I can imagine other people out there in the big wide world feel the same
- bluemaybe they're a minority. maybe java users are perfectly content with var, and there's no confusion, and wide adoption; I wouldn't know really
- bluebut one thing you cannot argue: you cannot argue a "should" from an "is" (Ist->Soll). the fact this is already decided and out there, and people, you amongst them, use it (even happily), doesn't make it good
- blueI use many features of JS that I don't like...
- blueugh, this reminds, TS using private members for type comparison is an abomination...
- blue"Apache Groovy is a Java-syntax-compatible object-oriented programming language for the Java platform."
- blueTIL...
- bluepeople *use* that?
- bluedreamreal: ^
- bluedef myGroovyBean = new AGroovyBean()
- bluedef monthMap = [ 'January' : 31, 'February' : 28, 'March' : 31 ]
- bluethis is really nice. bit weird for map syntax, but nice
- dreamrealpeople use groovy, yes
- dreamrealwhy, I could not tell you
- blueI like that def keyword
- blueI don't like the missing semicolons
- bluebut it looks kinda nice
- dreamrealgroovy is a giant chunk of crap that managed to work
- blueLOL
- dreamrealthe most common usage is in gradle, and it's going away there day after day
- bluegradle?
- dreamrealgradle
- nevetgradle is a build tool for many languages; it uses a Groovy or Kotlin DSL, and provides a configurable as well as a conventional build model. It's very terse but can be absolutely maddening if you color outside the lines at all. URL: https://gradle.org Tags: build tool, groovy, kotlin, and jvm
- dreamrealgroovy
- dreamrealpffft, need a groovy factoid
- bluethat shows you how popular it is :P
- dreamrealIt's relatively limited in scope, most people learn enough groovy to use gradle and that's it, and even there kotlin is taking over
- dreamrealkotlin, incidentally, uses val and var
- bluelike scala?
- blueMein Gott dreamreal.
- blueanything that reminds me of that dumpster fire language is terrible
- dreamrealScala is a beautiful language
- dreamrealscala
- dreamrealit needs a factoid, too
- dreamrealbut I don't have one because of javabot :D
- blueI thought you hated scala like brimstone.
- blueActually, I *know* you do.
- blueI also know why, and it's not necessarily the language, though it should be :P
- dreamrealI refuse to use it.
- dreamrealThe language is great. Everything around it is awful.
- blueCommunity makes the language, I guess?
- dreamrealCommunity makes the ecosystem.
- blueThis is kind of the reason I like Java, btw. The people are so much better than other communities I know.
- dreamrealThe language is quite capable, quite usable, quite nice, really. The community ruins it.
- blueI *really* don't like Java as a language (this is no secret).
- blueBut I love the community.
- dreamrealTake every negative trope about argumentative Jews, amplify it by 700, add in toddler-level emotional tantrums and add knives. You'll have a gentle approximation.
- blueCompared to basically any community I know... first and foremost JS, the Java community is a dream. The people feel mature and no toddlers.
- dreamrealI can point out toddlers if you like :D
- blueThe JS community is full of ego-laden toddlers.
- dreamreallombok
- bluelol
- dreamrealgrrr, no lombok factoid either
- blueWhat on god's green earth is lombok?
- dreamrealjavabot's factoid database sucks compared to nevet's features, but it's far more developed
- blueyo ucould migrate the data..
- dreamrealhttps://projectlombok.org/
- nevetProject Lombok
- dreamrealI could, yes, but I don't want to, nevet is not intended to compete with javabot and it's less "#java-owned"
- blueanyway: I truly love the Java community in terms of people.
- blueI dislike the language very much indeed, but the people/culture make it worthwhile
- dreamrealA language is what it does
- dreamrealI find java usually pretty verbose myself, I prefer writing kotlin
- bluethe JS situation is reserved: I *love* the language, the community... MUCH less
- bluereversed*
- bluethe TS community is somewhat more mature
- * dreamreal still resents hasOwnProperty()
- blueyes, you shouldn't be using that
- dreamrealI don't know if JS has made that more palatable
- dreamrealit's been a while
- * blue points to Object.hasOwn
- dreamrealSo you can't override that?
- blueoverride what?
- dreamrealThat was always the problem with hasOwnProperty
- blueyou wouldn't be using it
- dreamrealYou ended up having to use something like Object.prototype.hasOwnProperty()
- blueyes. and the short sytnax today is Object.hasOwn(obj, prop)
- dreamrealAh, right, so you're calling it directly via Object
- bluethe reason people using the prototype directly doesn't have much to do with this particular method
- blueit's just js objects can overwrite anything
- blueobj = { hasOwnProperty() { console.log("nope"); return -1; } };
- blueand Object.hasOwn doesn't really fix it, either
- bluebecause you can do Object.hasOwn = () => {}
- dreamrealI thought that's why you use the prototype
- bluealso I believe Object.hasOwn deals with null and what not better
- systemfaultPeople use objects as dictionaries. Nobody use Object as a dictionary
- bluesorry, I mean null-prototype objects
- systemfaultAhh, most people don't even know they exist.
- blueconst obj = Object.create(null);
- bluethis is the 'clean' way to create a dictionary in JS, because it doesn't carry all the Object.prototype baggage
- dreamrealaight, off