Hacker Newsnew | past | comments | ask | show | jobs | submit | more hylaride's commentslogin

> my tmobile 5g modem has ipv4 but changes ip every single page load, it's wild

They're probably using CG-NAT, though IP changes that often is a bit aggressive.


> They're probably using CG-NAT, though IP changes that often is a bit aggressive.

TMobile uses IPv4 addys in DOD's address space. They do change unexpectedly often.

And yeah. Being DOD IPs, they're cgnat'd behind tmobile's public ASN.


Separation of church and state, especially when schools don’t allow alternative books (eg in some Bible Belt areas). Also, the bible does have violence, sex (including rape and incest), etc.

I understand there are reasons it could be banned, but I'm saying that in reality it is not. It is widely available in elementary and middle school libraries.

There have been many attempts to ban it, but a backlash usually results in its reinstatement. IIRC there are often cases where questionable verses are blotted out or it's only the new testament (which is in general less "graphic"), but it really depends on the jurisdiction.

Except for one case in Texas that made a splash in the news last year, I didn't find other cases of the Bible being banned from school libraries. Did I miss something?

If not, it would make sense that Texas made the news because it's out of the ordinary.


Nominally I agree with you, but your example is classic survivorship bias.

The chances of getting kidnapped are and always were far, far, far less than automobile related injuries and deaths, yet we just see that as a normal risk of modern life.

I have been wondering if the fact that the current generation of 20-somethings isn't going out as much is because of this "over parenting" that they received. I'm sure it's also TikTok, living costs, and avoiding other vice related behaviour (drinking, sex) at such high rates, but it does make me think...


> A planned economy is certainly a lot more viable now than it was in 1950, let alone 1920. The Soviet Union was in many ways just a century too early.

If the economy were otherwise stagnant, maybe. But top-down planning just cannot take into account all the multitudes of inputs to plan anywhere near the scale that communist countries did. Bureaucrats are never going to be incentivized anywhere near the level that private decision making can be. Businesses (within a legal/regulatory framework) can "just do" things if they make economic sense via a relatively simple price signal. A top-down planner can never fully take that into account, and governments should only intervene in specific national interest situations (eg in a shortage environment legally mandating an important precursor medicine ingredient to medical companies instead of other uses).

The Soviet Union decided that defence was priority number one and shoved an enormous amount of national resources into it. In the west, the US government encouraged development that also spilled over into the civilian sector and vice-versa.

> But a major failing of the Soviet economic system was that there simply wasn't good data to make decisions, because at every layer people had the means and incentive to make their data look better than it really was.

It wasn't just data that was the problem, but also quality control, having to plan far, far ahead due to bureaucracy in the supply chain, not being able get spare parts because wear and tear wasn't properly planned, etc. There's an old saying even in private business that if you create and measure people on a metric they'll game or over concentrate on said metric. The USSR often pumped out large numbers of various widgets, but quality would often be poor (the stories of submarine and nuclear power plant manufacturers having to repeatedly deal and replace bad inputs was a massive source of waste).


Considering how much government spending goes to the elderly, either directly via programs like OAS and tax benefits or indirectly via healthcare, and it was only a matter of time before young people question their position in it all (higher schooling tuition/debt, bad job market, expensive housing, etc). OAS doesn't even start getting clawed back until personal income is over $90K and is only fully clawed back at $150K! And it's double that for a couple!

The timing of the last election was perfect for Carney when there was a window where the whole country was going WTF with Trump and PP was still railing against various "woke" grievances and mentioning Trudeau by name. The fact that he wasn't turfed after not only losing the election that was his to win, but also losing his seat, is everything wrong with the myopic federal Conservative Party (whose core members refuse to "compromise" with the rest of the country).

There is a real generational tilt happening and young Canadians no longer defaulting to left leaning ways of thinking (not that they ever were as much as people thought).


Yep agreed on all points. I like that there are a few local orgs (GenerationSqueeze, Missing Middle) bringing light to things like the portion of the federal budget allocated to OAS and how it's structured, and generally being real about present day inequities.

Carney will (hopefully) have to reckon with those in the coming year, while Pierre seriously missed a (the?) boat. It does feel like something big is shifting slowly.

> There is a real generational tilt happening and young Canadians no longer defaulting to left leaning ways of thinking (not that they ever were as much as people thought).

It's my impression that the balance between economic prosperity and social good needs to be constantly curated and revered as an inherent virtue of a democracy with strong social safety nets. It's much easier to get working age people to compensate for the ails of generations past if there's no doubt in their mind they'll have a roof over their head next year.

Progressive, often barely tangible issues, necessarily become internalized as luxurious if the people who could support them can't even pay for food.


IMO, the US business industry has become over-financialised to the point of self-sabotage. R&D and capital expenditure are seen as "bad" things to have on accounting statements. Combine this with Jack Welsh type CEOs who do everything they can to cut out "costs" on financial statements and you get organizations like GE turned into (badly run) banks.

Cisco is now essentially a publicly traded PE firm that buys up other companies to milk dry. Most internal development is outsourced by suits far removed from any qualifications on quality.

We all know the foibles of Boeing, where accountants made the final calls on everything.

The only innovations the traditional American car companies seem to be able to focus on is how to make cars bigger to increase margins. It's ludicrous that it took a new company (Tesla) to make electric cars available.

I could go on. This is not to say that other countries (including China) don't have their own issues with their business climate, but the United States has an environment where some of the smartest and best paid people in the country are working their asses off to find out better ways to show ads (Google/Facebook).


Well the good news is we just destroyed our education and research sectors, too, so we'll catch up to China, uh... any day now...


I know, right? I think all we have to do is follow their lead in having near slave labor /s


That is the direction we're heading in, yes.


That's ultimately what you get when you have a system that 1) has most of its money held by the retirement/pension funds of a generation that didn't have enough children to sustain organic domestic economic growth and 2) has incentivized returns to those institutional investors at the board and c-suite levels of most companies.


I mean if we're talking about generations that didn't have enough children to sustain organic domestic economic growth, then China is actually ahead of us there. Their birth rate plummeted below replacement well before the US's did.


Everyone acts like the C8 corvette doesn’t exist when they shit on American cars. Actually GM is an innovative awesome company.

The C8 has topped many “top car” lists since it came out in 2020. The reviews on it are universally excellent and it gaps pretty much anything that the turn-signal hating BMW crowd manufactures both in literal performance and in design.


Also there's no longer really any such thing as an American car. Everything now is some globalized mess of parts from brands here and there. Made in factories wherever is most financially convenient.


The Corvette is a pretty niche vehicle though


yep bingo


Funny enough iTunes Genius was amazing at discovering new music as it created a tree of "users who bought this, also bought these songs" and I spent a fortune on the iTunes Store on single songs.

It's now all but dead, probably because with apple getting a monthly cut with Apple Music either way, there's no incentive to maintain such a system.


I know of one largish bank moving away from Oracle middleware and RDMS. It's happening in pieces starting with low hanging fruit and for awhile the two will run in parallel (with the new data stores starting off as a comparison check to reconcile any bugs that crop up). Some early wins were account transaction logs that can go into better suited DBs, etc.

My understanding is that they were relatively lucky in that most of the hard parts are in the middleware layer and rarely the DB itself - the bank has been around since the 1800s, so has a huge mishmash of technologies that go from old IBM mainframes up to more modern cloud infra. So they're already kind of used to using middleware logic to stitch together various data sources.

The funny thing is that my contact there said the primary impetus is that they see the writing on the wall for a lot of their "legacy" Sun hardware, and figure if they're going to have to redo a lot of it, they may as well re-architect the rest. There'll still be oracle DBs running in the bank for a looong time, but there'll be less and less of it.


> Is there some code of conduct for public companies but not private ones?

It's more about Private Equity firms than private companies. The oversimplified TL;DR strategy for most PE firms is acquire, strip, pump, then dump (combined with all sorts of tax strategies). Most PE firms don't own the companies themselves, but act on behalf of investors and take a cut of the ultimate profits. So it's basically tons of short term thinking.


Outside of Android work, has Kotlin really taken over? My understanding is that Java added a lot of functional programming and that took a lot of wind out of Scala's sails (though Scala's poor tooling certainly never helped anything).


> My understanding is that Java added a lot of functional programming

This is true, but needs more context. Java 8 added Stream API, which (at this time) was a fantastic breath of fresh air. However, the whole thing felt overengineered at many points, aka - it made complex things possible (collector chaining is admittedly cool, parallel streams are useful for quick-and-dirty data processing), but simple everyday things cumbersome. I cannot emphasize how tiring it was to have to write this useless bolierplate

  customers.stream().map(c -> c.getName()).collect(Collectors.joining(", "))
for 1000th time, knowing that

  customers.map(c -> c.getName()).join(", ")
is what users need 99.99999% of the time.


It's such a blessing to be able to write in Scala

  customers.map(_.name).mkString(", ")
instead of the Java bloat

  customers.stream().map(c -> c.getName()).collect(Collectors.joining(", "))


It bothers me that majority of languages ignores a nice python approach. `', '.join(any_str_iterable)`. Instead of supporting join for myriads of containers there is a single str method.


Python's approach is one of the most confusing ways to possibly do it. Not having proper, discoverable methods is super annoying, and I need to look it up every time anew I use Python because it's so unintuitive.

Of course you can write a generic version of `mkString` (as this method is called in Scala), so it's also just one method no matter the container count.

The Python weirdness is actually a direct result from the language lacking generics…


From typing perspective there is no sense to have Container[T].join() -> str for any T.


That's obviously the wrong signature.

The semantically correct one is "Container[T : Printable].join(): String"; T must implement the Printable concept, but Python lacks concepts (or type-classes as these are alternatively called).

But this all is irrelevant as this is anyway not the signature of `str.join()` in Python. It's `str.join(Iterable[str]) -> str` there. With sane design and syntax it would just become `Iterable[str].join(str)`.


I agree, but from convenience perspective there is a lot of sense. Java Streams is actually a good example of a "correct" design, but not very convenient.


That's my point. Python has convenient and good type design with str.join ignored by other languages.

For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.


> Python has convenient and good type design with str.join ignored by other languages.

Of course such non-discoverable and unintuitive design gets ignored everywhere!

We just established that even in Python the correct way to do it would be

  Iterable[str].join(str) -> str
but for that Python would need generic iterators on the language level…

> For example I'm lost which abstract class to inherit in Scala to obtain mkString for my custom container.

So you're saying you've been able to implement custom Scala collection types, which is regarded some of the more difficult stuff one could possibly do, but you don't know how to implement an Iterator for your custom collection—as this is all needed for mkString to work? BTW, how did you implement the collection type at all without implementing Iterator for it? Your collection is not Iterable?

TBH, this does not sound very realistic. This sounds more like typical HN Scala FUD. People throwing around some vague, most of the time outright made up issues they've heard about somewhere about 10 - 15 years ago.


Sort of true, but I often hear this take from Java programmers and it feels like "Blub" [1]/Stockholm syndrome to me.

Personally, I'm extremely glad to not have had to write .toStream().map(...).collect(Collectors.list()) or whatever in years for what could be a map. Similar with async code and exception handling.

For me one of the main advantages of Kotlin is that is decreases verbosity so much that the interesting business logic is actually much easier to follow. Even if you disregard all the things it has Java doesn't the syntax is just so much better.

[1] https://paulgraham.com/avg.html


Java 16+

    stream.map(...).toList()
https://bugs.openjdk.org/browse/JDK-8180352


So only 2 bullshit boilerplate calls instead of 3? I guess that's progress.


At least where I work, writing new Java code is discouraged and you should instead use Kotlin for backend services. Spring Boot which is the framework we use, supports Kotlin just fine, at the same level as Java. And if you use Jetbrains tools, Kotlin tooling is also pretty good (outside Jetbrains I will admit it is worse than Java). Now, even in new Java projects you can still be using Kotlin because it is the default language for Gradle (previously it was Groovy).


My org had to write a pivotal backend service on the JVM, due to JDBC having the largest number of data source adapters.

The choice was Kotlin. Scala is too "powerful" and can be written in a style that is difficult for others, and Java too verbose.

Kotlin is instantly familiar to modern TypeScript/Swift/Rust etc devs.

The only negative in my mind has been IntelliJ being the only decent IDE, but even this has changed recently with Jetbrains releasing `kotlin-lsp` for VS Code

https://github.com/Kotlin/kotlin-lsp


Java did indeed add more FP to the language, but Java's type system is still fairly primitive compared to Scala's.


Java's new features are always going to be on paper. The ecosystem, with all its legacy code, is always going to be a decade behind. And if you are starting a new project, why would you pick Java over Kotlin?


> And if you are starting a new project, why would you pick Java over Kotlin?

Because in 5-10 years you'll have a Java project that people can still maintain as if it's any other Java project. If you pick Kotlin, that might at that point no longer be a popular language in whatever niche you are in. What used to be the cool Kotlin project is now seen as a burden. See: Groovy, Clojure, Scala. Of course, I recognize that not all projects work on these kinds of timelines, but many do, including most things that I work on.


Clojure has never been a popular language, nor has it aimed to be mainstream. That is the Lisp curse. It has never positioned itself as a "better Java". It shines in applications where immutable, consistent, and queryable data is crucial, and it has found another niche in UIs through ClojureScript.


I don't think Clojure belongs there. It was never as big as Kotlin, but it's got great community, longevity and takes backwards compatibility very seriously, and 10 year old Clojure projects seem to be aging at least as well as 10 year old Java projects.


Kotlin has already been around for ~10 years and it's in the TIOBE top 20. https://www.tiobe.com/tiobe-index/kotlin/



Because the Java Virtual Machine is designed for Java, and that is what all vendors care about.

Kotlin is Google's C#, with Android being Google's .NET, after Google being sued by coming up with Google's J++, Android Java dialect.

Since Google wasn't able to come up with a replacement themselves, Fuchsia/Dart lost the internal politics, they adopted the language of the JetBrains, thanks to internal JetBrains advocates.


| Android being Google's .NET, after Google being sued by coming up with Google's J++, Android Java dialect.

The Oracle v Google was specifically over copyright infringement concerning the Java APIs used in Android's original implementation (Dalvik/ART), not about creating a "J++" dialect.

Android never ran a JVM on mobile because it cannot be optimized for resource constrained devices a solution like DalvikVM was necessary. If you want to level critiques about creating fragmented dialects of Java I would recommend starting with J2ME. The only nice thing I can say about J2ME is at least it died.

The Android ecosystem was far too mature for Fuchsia/Dart to be successful without a very compelling interop story that was never produced.

As a technology Kotlin met Android's platform and community needs. Advocacy and politicking played a minimal, if any, role.


Lies sold by Google.

Nokia and Sony Ericsson were using J2ME perfectly fine, as did Blackberry. I should know ad ex-Nokian.

Kotlin met nothing, it was pushed by Kotlin heads working on Android Studio, telling lies comparing Kotlin to Java 7, instead of Java was already offering at the time.

To this day they never do Kotlin vs Java samples, where modern Java is used, rather the version that bests fits their purpose to sell why Kotlin.

Fragmentation, what a joke, the fragmentation got so bad in Android, that JetPack libraries, previously Android X, exist to work around the fragmentation and lack of OEM updates.

Gosling said it better, regarding Google's "good" intentions

https://www.youtube.com/watch?v=ZYw3X4RZv6Y&feature=youtu.be...


J2ME was an alphabet soup of incompatible implementations stuck somewhere between Java 1.2 and 1.3. Getting code to run across device manufacturers was a huge engineering burden. In fact doing something like JetPack for that world would be technically impossible.

If Sun was offering some technically relevant foundation for the smartphone era, it would have been able to actually have some adoption. They were starting from a leading position (obviously - see blackberry or Nokia), and in the space of 3 to 4 years they completely disappeared.


> J2ME was an alphabet soup of incompatible implementations

So Google?

(alphabet)


The ecosystem is perfectly fine. You’re more than likely using the ecosystem when you choose Kotlin, that’s the whole point. This comment doesn’t make any sense.


> And if you are starting a new project, why would you pick Java over Kotlin?

I've written multiple production services in Kotlin Spring Boot. Now, we're building a new system and using Java 21 (25 soon).

Why? Kotlin the language is great, but there are corresponding tradeoffs in interop. Meanwhile, Java the language has improved to the point that it's good enough, and Java feels like it's headed in the right direction. In my opinion, AI models are better at Java than Kotlin. If you prefer a weaker claim, the models are trained on more Java code than Kotlin code.

Finally, from an enterprise perspective, it is a safer long-term investment for a Java shop to own an application written in Java rather than in Kotlin.


That's kind of what I'm asking. I did have a former co-worker write a micro service in Kotlin around 2018. He said that as nice as the language is, the ecosystem was (at the time, not sure how it is today) so utterly dominated by Android development, that he said he wouldn't recommend using it again - half the time he was calling out Java anyways.


Kotlins "ecosystem" is all of Java, and then all of Kotlin.

Put another way: Java only has access to a subset of the ecosystem

Almost all of the backend libraries I use are Java libs. Some of them have additional Kotlin extension libs that add syntax sugar for more idiomatic code.


I use kotlin and I do not feel oppressed by Android in any way. And I'd rather call Java libraries from Kotlin than Java. Many have Kotlin wrappers.


That's a weird take. Even if true, kotlin has perfect interop with calling Java libs so there's not really a downside to keep using Java libs. There's not that much demand for kotlin-specific libs outside multiplatform which includes Android.

For what it's worth, Spring has first tier Kotlin support, I haven't noticed this bias.


It’s a lot cheaper to hire for Java than for „modern“ languages.


People on HN down-voting facts?

And yes, "you get what you pay for" is part of this.


Have you ever heard the expression "you get what you pay for?"


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: