manjalyc

I'm curious if there's a market for an ultra-small, credit-card sized ereader that can fit in a wallet

Ironic considering the article just reeks of AI.

- AI loves to use "consumers" instead of just saying people or Americans

- "You’ve spent time and budget on it, yet your audience can’t name a single company they think is doing it well. "

- "The small moments that used to make the web worth visiting are disappearing."

- "The brand that builds that recognition first gets to define the standard."

Nearly every sentence has an AI-ism...

If you switch IPs you can usually get a message or two through during these outages. This has been a consistent issue with Gemini for the past few months, but has increased in frequency and duration of outages, especially since 3.5.

Early on this outage it was just the 3.5 pro models affected, then flash started having issues, and now flash-lite is not being responsive.

Slightly related, but has anyone else using the gemini cli noticed that over the past few months, usage of the Gemini 3 pro models frequently times out or hangs? Antigravity cli has been better about this but the quotas are just so low with the 5-hour window bs.

On the other hand, seperating concerns by process boundaries leads to more secure, composable and stable code. By not reinventing the wheel, you avoid a whole class of problems. Of course a stable API or library might be better, but convenience always wins out.

The difference is apple doesn’t let you modify your device to use other services. Their contractual obligation goes beyond the service itself. That’s why EPIC won this case.

What does the G in GaaS mean?

The reason I brought up roomba wasn't to talk about Lidar or vision necessarily. It's more a story about how the first-mover in a technological space became entrenched in what works and became resistant to investing in newer technologies. The result was rival companies taking away marketshare from a market roomba once defined. Roomba has since incorporated lidar and other innovations after being stagnant for a decade, but its too late - their competitors now dominate the market.

To complete the analogy, Tesla is invested in vision-only technologies, while its competitors are making gains with Lidar and other tech that Tesla refuses to acknowledge. It's very reminscent of Roomba in the mid 2010s.

The Matic is a cool little robot though.

A fun anecdote - a lot of people may remember Roomba from forever back with their automated little vacuums. Roomba's market share declined significantly because they failed to adopt Lidar technology as quickly as their competitors, instead they depended on the bumper for as long as possible. This put them at a disadvantage in navigation and efficiency as their competitors started using Lidar. Combined with aggressive pricing from rivals, expiry of its patented roller in 2022, a weird insistence to not combine vacuum and mopping into one device, Roomba (or iRobot now) is a just little fish in the sea it made.

Prof. Barry Marshall is an example of why Evidence-Based Medicine works against community sentiment.

Ignoring 95% of a uniform market to target the 5% of users who all have niche and conflicting preferences is a ridiculous strategy for stability, growth, and profitability.

I would rather look like a fool than be one. At least then I would have something to be accountable to

Only the first letter being case-sensitive is a major strike against readability, one of four major pillars. While I’m sure the Nim developers are probably used to it by now, it just seems like a bad design decision Nim is probably burdened with as the result of legacy/interoperabilty.

Even just reading your foobar example at a glance took a moment for me.

And case insensitivity is also generally frowned upon. To have a language with both sensitivity and insensitivity is the worst of all worlds with none of the benefits.

If you want to understand why at a deeper level I would recommend reading readability or the case insensitivity sections in any programming languages book. Personally, I enjoy Programming Languages, Principles and Practice (Louden & Lambert)

EDIT: Yes, I get it, it doesn't affect YOU. But it doesn't mean it doesn't affect other people. Non-english languages and/or speakers are an easy example. It also eliminates a whole class of human error, and maybe that only affects non-experienced juniors, but they exist too. There are other issues with symbols being case insensitive and string values being case sensitive. If you want a practical example a classic one is HttpsFtpConn vs. HttpSftpConn

I agree that sometimes linters can enforce code styles that are more of hassle to deal with than offer any real concrete gain to new developers. But I disagree that only senior developers should use linters. Especially if you are learning a new language, it can introduce you to common conventions in that language, writing cleaner and more idiomatic code, and helps form good habits off the jump instead of building bad habits you will eventually have to change in a professional setting. Sure it can be overzealous at times, but I think on the whole it is a net positive.

I agree with you, and I think you have misunderstood the nuance of the parent comment. He is not letting google "off the hook", but rather being tongue-in-cheek/slightly satirical when he says that the reality is too troubling for google. Which I believe is exactly what you mean when you call it "anti-social-history, not pro-material-reality ".

This is 4th bot I’ve seen today. Before today, I don’t think I’ve ever seen a bot on HN, or at least a bot this transparent.

The idea that “attention is all you need” here is a handwavy explanation that doesn’t hold up against basic scrutiny. Why would Google do something this embarrassing? What could they possibly stand to gain? Google has plenty of attention as it is. They have far more to lose. Not everything has to be a conspiracy.

They indeed are, just in a very polemic way. What a funny time we live in.

Code generally does not enter the YouTube code base without a lot of review namely (1) performance tests and (2) code reviews from multiple teams. Lines like this almost certainly get flagged/increased scrutiny. It would be very hard to imagine multiple people didn’t know about this and assign the blame to a single person.

Yep, and I love writing Scala as much as I hate writing Java, but I wouldn't say its maturity is in the same league as Java, C/C++, etc.

Yea, I don't imagine native stream parallelism will help when CPUs are already loaded. Presumably you're using Spring or Rx, in which case you probably can leverage reactive streams and/or Managed Blockers, but thats really just taking advantage of async patterns and not necessarily parallelism. The only case I could envision having a concrete benefit is if you used your own fork-join pool leveraging virtual threads instead of the global fork-join pool to prevent platform threads from hogging CPU, and then used reactive streams that leveraged the virtual threads. Although this would (theoretically) raise responsiveness, it would almost certainly come at the cost of throughput. All that is to say, parallelism generally only provides as much value as you have idle CPU cores.

Not only do virtual threads cope very poorly with I/O other than network I/O, you still get memory barriers.

Which is why I said you probably don't want to use the paradigm I outlined for I/O, but if you did you would want to leverage Java's Managed Blockers and async Completeable Futures for those exact reasons.

Virtual threads makes the memory overhead lower since you don't need full separate stacks and reduces the cost of spawning new threads, neither of which was ever an issue with streams since they use the common thread pool. Virtual threads don't significantly increase the per-thread performance.

Of course virtual threads don't significantly increase per-thread performance? They make the overhead of spawning multiple threads minimal-to-zero compared to native OS/platform threads, minimizing the cost of jumping from sequential streams to parallel streams. Also, parallel streams don't have to use the global fork join pool, you can use your own fork-join pool? Which is possible in Java, because once again, streams are treated as a first-class citizen and can leverage nearly all other parts of the language efficiently and natively (although I will say Java's verbosity/boilerplateness can suck if you want to leverage your own fork-join pool, but that's widespread complaint of Java not specific to its streams)

Starting to program with Java streams is weird because you are utilizing functional constructs in a language that historically had little notion of them. When I first started using them it felt worthless when I could achieve the same thing in classic OOP faster (and often run it faster too). But after a while you get a feel for the fluid style programming streams enable (and imo cleaner code). These days with ChatGPT, its probably a lot easier to get started.

With that said, you should almost always write a stream thinking only sequentially first, then identify steps which can benefit from .parallel() and only parallelize those steps. Its leveraging .parallel() efficiently that provides an advantage at run-time and why I tend to use it.

OpenMP is not a language? You can take any language and add libraries to achieve a specific goal, my point is that Java streams are first-class citizens compared to other matured programming languages that also enable leveraging other aspects of the Java ecosystem without running into the rough edges you will with OpenMP.

Also, that is definitely not the rule? If your problem is parallelizable by nature, parallelism provides massive speedups. Overhead from parallelizing a stream is minimal (effectively nonexistent) now if you leverage Java virtual threads (JDK 21). Additionally, most problems are not parallelizable, yes, but most solutions consist of individual steps and there is a high likelihood that at least one of those steps will benefit from parallelism. Java streams can switch between .parallel() and .sequential() execution on the go. You almost certainly don't want to leverage stream parallelism for most I/O operations, unless you leverage Java's Completeable Futures and Managed Blocking (but any gains here are probably minimal anyways) but the point is that you can leverage them, because streams in Java are a first class citizen.

Does C# allow you to convert a sequential stream into a parallel stream, or do streams have to be parallelized when initiated? Genuinely asking, I do not know C#

My point was that it is built into Java streams and requires 0 extra configuration or work on the programmer's end. Not that you can't parallelize in other languages.

A lot of comments here focus on the readability, conciseness, and expressiveness of Java streams compared to other languages. IMO they are missing the point and are just reiterating the same complaints everyone has about the Java language in x different ways.

Java streams bring real benefits compared to other mature languages. My favorite is that sequential streams can be efficiently parallelized with a single operation, .parallel(), and sequentialized back, .sequential(), on any stream without having to configure a single knob manually (although you certainly can), an equivalent I am unaware of in any other matured language. These make operations such as .collect() and its mutable reductions leverage multiple threads for effectively 0 additional programming time.

edit: A lot of people are focusing on my favorite feature of parallelizing or serializing a stream with a single command, which apparently you can also do in C#, that was just an example guys. Other cool things you can do with Java streams natively now is leverage virtual threads (take that C#), use them asynchronously with completable futures, define how elements are accessed/gathered in streams via spliterators, etc. Streams in Java are very composable (not just as in composition, but as in utility), and enable leveraging nearly every other part of the language natively. In other mature languages, streams are very rigid and feel non-composable. I'm not saying that everything is impossible in other languages, but that in Java streams feel like a first-class citizen.

Yes, there are a lot of reasons to homeschool. And I don’t want to undermine your idea, but the vast majority (by far) of people that homeschool do so because of disagreements with secular education. Public schools are an increasingly politicized issue, likely the dominant factor in the recent uptick of homeschooling, and I think saying it is not possible to hold an opinion on the issue one way or the other is a bit too reductionist of reality.

Given the materials and methods involved it really isn’t that dangerous. With basic precautions I’d say go for it, worst case is honestly just blowing a few hundred bucks. If this pans out, there will definitely be some do it yourself tutorials on YouTube in the coming weeks.

Looking for patterns in charts is stock market astrology, but technical analysis is a broad term that goes beyond just that. An analysis of 10,000 institutional portfolios found technical analysis provided a small but statistically significant return advantage [1].

Perhaps the way most retail investors or get-rich-quick schemes use technical analysis (looking for patterns in charts) is astrology. But the big boys and institutional investors seem to profit from certain types of technical analysis. Highly reccomended watching this video by Benjamin: https://www.youtube.com/watch?v=ZN6P9ErUcOg

Essentially:

- Chart patterns are uselesss

- TA by itself is useless

- Using TA in tandem with a bigger strategy can (and is statiscally shown to) provide an edge

[1] https://scholar.google.com/scholar?hl=en&as_sdt=0%2C22&q=Hea...

Look I get it, he’s passionate and loves what he does. But there’s something about not even taking a day to step back on your 100th birthday that just doesn’t sit right with me.

Although from the sentiment in this thread I guess that makes me the minority. I’m also not a Nobel laureate, to each their own I guess.