HN user

ackfoobar

709 karma
Posts0
Comments372
View on HN
No posts found.

stuck to why he thought it was bad for Bun to do this

Quite the opposite. "When Jarred announced the Rust rewrite, we were ecstatic."

It’s definitionally an ad hominem against Jared.

Who Jarred is, as a CEO, definitely has an impact on how the company develops software - how Zig is used. And the argument is that Zig is used badly in Bun. Without that context, I, as a reader, would have to actually read through a lot of code to be convinced of that point.

Coming from Scala to Kotlin, this is what I thought as well. Seeing `it` felt very wrong, then I got used to it.

As noted in the article:

This feature does have some limitations, for instance when we have multiple nested function calls, but in those cases an explicit lambda expression is always still possible.

I've also complained about that a while ago https://news.ycombinator.com/item?id=35707689

---

The solution is to delimit the level of expression the underscore (or dollar sign suggested in the article) belongs to. In Kotlin they use braces and `it`.

    { add(it, 3) } // Kotiln
    add(_, 3) // Scala
Then modifying the "hole in the expression" is easy. Suppose we want to subtract the first argument by 2 before passing that to `add`:
    { add(subtract(it, 2), 3) } // Kotlin
    // add(subtract(_, 2), 3) // no, this means adding 3 to the function `add(subtract(_, 2)`
    x => { add(subtract(x, 2), 3) } // Scala

explicitly written to do this

In that case I want the signature of "this function pre-computes, then returns another function" and "this function takes two arguments" to be different, to show intent.

achieved through compiler optimisation

Haskell is different in that its evaluation ordering allows this. But in strict evaluation languages, this is much harder, or even forbidden by language semantics.

Here's what Yaron Minsky (an OCaml guy) has to say:

starting from scratch, I’d avoid partial application as the default way of building multi-argument functions.

https://discuss.ocaml.org/t/reason-general-function-syntax-d...

ditch ORMs ... make good use of SQL

I think Java (or other JVM languages) are then best positioned, because of jooq. Still the best SQL generation library I've used.

I'd gladly pay for Premium (I'm already paying for YT Music, the price difference is minimal) if they allow turning off shorts. But they won't. They see time spent in app goes up when they hypnotize the users. They're too Goodhart'ed to realize that quite a lot of users don't enjoy being hypnotized.

Your scenario is sth like: guy sees bad AI, good AI, and genuine content in his feed. Bad AI gives him confidence in his ability to detect slop, but he thinks the good AI is genuine content. Here the higher the quality of the slop, the harder it is to detect.

In this case some slop is hacked and exposed. I check them out to see if they're good yet. The quality of the slop is unrelated to whether they'd get hacked.

I checked out one of the accounts mentioned, mostly to check if I can discern fake accounts. The content is just still pictures. I'd dismiss those whether or not they're AI. Well, I'm not on TikTok anyway.

This reminds me of some youtube videos when I was researching some stuff to buy. Those videos are just still images plus text-to-speech narration, usually with an annoying background music.

[dead] 8 months ago

Just for the record, another one of his PRs was torn to shreds.

some core developers (who are compiler developers by trade) are actually experimenting with and using these same tools too, but haven't suddenly turned into 13kLoC PR-opening AI superheroes.

> Here's my question: why did the files that you submitted name Mark Shinwell as the author?

Beats me. AI decided to do so and I didn't question it.

https://github.com/ocaml/ocaml/pull/14369

I guess it's really hard to write a sequel to Tron Legacy. Quorra came to life, then what? They're supposed to change the world. How? With a Q&A site? (Sorry I can't help myself with this dumb joke.)

Most home cooks (I would bet millions) are not worrying about "the cutting experience"

Indeed, and they won't buy the knife at this price anyway. My point is that not being dishwasher-safe does not matter for ~everyone. If they care, they won't do it; if they don't, they won't buy it.

Asked for numbers, got a link. Let's see.

They can manufacture 80 GWh a year. To get through dunkelflaute with moderate renewable percentage we need tens of TWh. Not to belittle Tesla, but that's 3 orders of magnitude difference.

Are you changing your mind or can you give me numbers to change mine?

My question is a few math operations away from "how much batteries capacity can we deploy to support how much % of renewables in the short-medium term, while still having a stable grid". My "100%" phrasing was sloppy, no need to index too much on it.

Since you're in the industry, maybe you can answer this question and change my mind.

Have you done the math of how insufficient battery tech is, if we are to go 100% renewable? I'm so tired of renewable proponents just use the thought terminating cliche "BATTERIES!" when intermittency is brought up.

Junie, which also benefits greatly from integration into the IDE.

That is very plausible, I really want it to be true as a fan of IntelliJ and Kotlin. I used Cursor at work and tried out Junie on a hobby project. Maybe it's the different niche, maybe I'm more used to Cursor for chat bot workflows, but I got a personal Cursor license after trying out Junie.

I'm very embarrassed to say this. Those code examples weren't non-compiling OCaml, but valid SML. Once I remembered the existence of the language (in my defence it was never mentioned in the thread), I managed to compile the code, and confirm my suspicion:

`val point: Bound.shape = Shape.Point` type-checks, because `type shape = S.shape`. To drive the point home, so does

    val DoesNotReturnPoint : Shape.shape -> Bound.shape = fn x => x
So the module example does not show "this function won't return a point" as one would have hoped.

straight/naive rewrite was ~3 times faster

How much of that do you think comes from reduced allocations/indirections? Now I really want to try out OxCaml and see if I can approximate this speedup by picking up low hanging fruits.

PS rereading this I think "hope you're a Haskeller" might be read as an insult. That's not my intention, here's why I mention Haskell.

1. It's THE other language with a type system based on HM.

2. Variant constructors as functions. OCaml does not do that, Haskell does (slightly more elegant). This hints sunnydiskincali is more familiar with Haskell than OCaml.

3. I was confused by `type shape = S.shape`. How does `RemovePoint(Shape).shape` has the `Point` case removed then? I tried that on a REPL ^1 and it didn't even compile. Again, syntax errors hinting at Haskell experiences.

Well now I've written so much I may as well do a point-by-point refutation: ^2

you create the ability to side-step exhaustiveness

Big claim, sounds scary to someone not familiar with sum types. But Java/Kotlin both enforce exhaustiveness. You could have provided an example in your second response, instead you dump a bunch of code that does not compile.

Sure you can, that's just subtyping.

Then you followed up with an example that is not subtyping, but an unrelated type of a new set of new values.

This is doing things quick and dirty. For this trivial example it's fine

This is not fine. I undersold the verbosity of your "quick and dirty" solution saying "7 lines". To actually work with those two types, the pair of conversion functions `Shape.shape -> Bound.shape option` and `Bound.shape -> Shape.shape` is needed.

They're not similar at all.

~100 words in the paragraph, gestures to formalization, yet never explained how sum types implemented as sealed inheritance cannot be "enforcing valid program-states at a type-level". Thus my comment "a lot of words to say very little".

You're still creating a type

I see you removed "unrelated" in an edit. The statement is now accurate but pointless. Of course I need to create a type, how else can I use the type system to say "this function won't return a point"?

disingenuous to imply the quotation means that the type-system in Java ... was lifted from ML.

It would be more than disingenuous, colossally stupid even, if I did imply that. The wrongness would be on the level of claiming "English and Japanese are in the same language family".

Your cognate/false friend analogy is much smaller in scope, just like Java taking sum types (implementing them as sealed inheritance) from ML.

1: https://ocsigen.org/js_of_ocaml/toplevel/

2: https://xkcd.com/386/

I'm not sure why

Me neither.

you are entirely correct that sealed types can fully model sum types

I want to be wrong, in that case I learn something new.

Substantiate this.

You never gave an example how sum types in Java/Kotlin cannot do what "real" sum types can.

> weird name choice but whatever

snarky potshot

Sorry that you read snark. What I meant was "I find naming this 'Bound' weird. But since I am translating your example, I'll reuse it".

You're still creating an unrelated type

How can a type participating in the inheritance hierarchy be "unrelated"?

I see the same degree of contortion, actually. Far more noisy, at that.

At this point I can only hope you're a Haskeller and do not represent an average OCaml programmer.

You wrote a lot of words to say very little.

Anyway, to translate your example:

    sealed interface Shape permits Point, Bound {}
    final class Point implements Shape {}
    sealed interface Bound extends Shape permits Circle, Rectangle {}
    record Circle(double radius) implements Bound {}
    record Rectangle(double width, double height) implements Bound {}
A `Rectangle` is both a `Bound` (weird name choice but whatever), and a `Shape`. Thanks to subtyping, no contortion needed. No need to use 7 more lines to create a separate, unrelated type.

the Japanese word for "name" sounds like the English word, despite not being a loan word.

Great analogy, except for the fact that someone from the Java team explicitly said they're drawing inspirations from ML.

https://news.ycombinator.com/item?id=24203363