Hacker News Reader

Comment by ko27 | Hacker News Reader

It's interesting how C# is always far ahead of Java, they introduced it way earlier, the syntax is simpler, and you can make is safe by using FormattableString as the param type, for example in EF you can do this without worrying about SQL injection:

FromSql($"EXECUTE dbo.GetMostPopularBlogsForUser {user}")

https://learn.microsoft.com/en-us/ef/core/querying/sql-queri...

View on HN

A major shortcoming with FormattableString is that the C# compiler is hard-coded to always prefer implicitly converting an interpolated string to a string, which makes it impossible to write extension-methods for FormattsbleString objects.

…and they also always default to formatting with CurrentCulture instead of InvarintCulture. Apparently this was by-design as interpolated strings were never originally intended for generating machine-readable strings.

Finally, there’s no way to perform common “mini-templating” with a FormattableString, such as repeating regions, show/hide regions within a string, or little things like inflection (e.g. rendering “{0:N} items” or “{0:N0} item” when arg0 is 1 or not.

I’m happy to see Java (finally) gain a similar feature, but it, like C#,s, seems… limited in its abilities.

C# 10 introduced interpolated string handlers. They allow to address some of your points (you can handle format strings however you want and you could also choose invariant culture by default, without using FormattableString.InvariantCulture) and at the same time avoid allocations.

Whether or not a hoarder is "ahead" of you at having stuff is a matter of perspective. C# strives to be a very feature-rich language, while Java strives to be minimalistic. So it's pretty certain that any feature Java does end up adding will have been in C# first (although this one is not quite the same), but Java certainly doesn't want to go in the same direction.

On the other hand, Java's GCs, JIT compilers, and observability features are more sophisticated than .NET's. We like adding stuff to our runtime, while C# likes adding stuff to the language.

The point is that Java eventually adds the same stuff as well just with worse usability than the C# counterpart.

It doesn't eventually add the same stuff (even in this case, the feature is quite different from C#'s) as it will never add most of the stuff C# has because we want to keep Java as minimal as possible. But if your point is that Java usually only adds features that other languages already have, that is absolutely true and we'd like to keep it that way. We believe most programmers generally prefer languages with fewer features over languages with many features. As to it having worse usability, that's usually a matter of personal aesthetic preference, and there's no evidence to suggest that's the case by some objective metric.

I don't think that's working out so well for you, because developers disagree

https://survey.stackoverflow.co/2022/#section-most-loved-dre...

Could a diet people would say "works well" be determined by looking at the dishes people say they love most? Topping the list would be foods that are too unhealthy or too expensive, foods that most would agree wouldn’t "work well" as a sustainable diet.

When you've followed such polls for many, many years, you see that programmers report they "love" languages that they pick more than those that are picked for them, that they tend to use for hobby more than work, that they tend to use in newer/greenfield projects, that they tend to use in smaller projects, and that they tend to use alone or in a small team. But the languages that end up working out well -- for the kinds of projects where Java is used -- are those that gain wide adoption in industry, that scale to large codebases and large teams, and yield programs that are maintained for many years. The languages that have managed to achieve that best are Java and C, and, to a lesser degree, C++.

If you've lived through the BASIC and later VisualBasic craze of the eighties and nineties, the SmallTalk craze of roughly the same era, the Haskell craze in academia in the mid to late nineties, the PHP craze of the early oughts, and the Ruby craze of the mid oughts, you see that the most "loved" languages are rarely the ones that end up working well.

Aside from a short ~5 year period (its first five years), Java was never a particularly "loved" language. Hell, James Gosling designed it to be a boring, conservative, "blue collar" language for work, and this work-in-teams-on-large-import-projects has been the main focus of Java's evolution. It's hard to argue that this hasn't worked out really well for Java. Even if Java isn't your cup of tea, you should appreciate the need for a language you can safely bet on to build a very important codebase that should be maintained for twenty years or more.

Having said that, I believe we should work on making Java more suitable for smaller, more fun projects without giving up its scalability. That's a difficult challenge, and, as far as I know, no language has ever achieved it, but perhaps Python is a reasonable source of inspiration.

My 2c, I call Java a phalanx language.

Spears seems unsexy and rather limited compared to swords at an individual level, even a skilled soldier fighting with a long spear would probably lose 1v1 with a soldier who primarily fights with a sword. Put a few dozen of them in phalanx formation though, and the swordsmen don't even stand a chance.

I feel most programmers often judge tools primarily by how they function at an individual level and managers and CTOs pick based on how they perform at scale, and neither side understands the other's priorities much leading to so many debates on this aspect. So it may be unloved by individual programmers(I don't agree with most such people), but people who're responsible for delivering software absolutely love it imho.

Golang too fits in the same category, every time it comes up, half the crowd here likes shitting on it for one reason or other, but quality software is being written in golang in many places.

You-the-user can make C#'s safe, you-the-library-developer can make Java's safe. All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong. I'd usually be the first to point out how C# did it earlier and better, but in this case Java's manages to surpass even Rust's, which I didn't think was possible.

Can you not make an analyzer that raises an error if you try to pass anything but a literal-as-format string?

At that point Java is completely null-safe. But sure, static analysis and tooling is a great advantage of bigger languages.

Well, no, its not that simple for Java's nulls.

But anyway, Roslyn Analyzers are built into the language. If you throw them away then you might as well call these new template processors off limits too.

> All you need is for one silly person to assign the C# query to a `var` beforehand and then the behavior's wrong.

That would cause a compilation error. `DbSet<TEntity>.FromSql(FormattableString sql)` [0] does not have a string overload. Therefore, if a user assigned the interpolated string to a SQL query to a `var` beforehand, then there would be an implicit conversion to a `string` [1] which will be a type mismatch for the `FromSql` call. The user would have to assign the interpolated string to a `FormattableString` instead of `var` for the program to compile. There is also no implicit conversion for a `string` to a `FormattableString`.

There is a `DbSet<TEntity>.FromSqlRaw(string sql, params object[] parameters)` [2] method that explicitly documents that it is vulnerable to SQL injection.

> You-the-user can make C#'s safe, you-the-library-developer can make Java's safe.

You-the-library-developer can make C# safe.

[0] https://learn.microsoft.com/en-us/dotnet/api/microsoft.entit...

[1] https://learn.microsoft.com/en-us/dotnet/csharp/language-ref...

[2] https://learn.microsoft.com/en-us/dotnet/api/microsoft.entit...

There's a history that partially explains why this is.

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

Not always, e.g. default interface methods, just to give one example.

Reply on news.ycombinator.com