Hacker News Reader

Comment by devjab | Hacker News Reader

> Because it’s a great language with amazing tooling. It’s fast, robust, easy to debug, easy to refactor, and so on.

I agree but I also think the main issue with this is that you could've said it in reference to most programming languages in 2023. I'm sure people can have a lot of debate on that, but aside from the fast bit, most programming languages are frankly in excellent places today, and fast is sort of irrelevant for us specifically as we tend to use c/c++ for that.

View on HN

I was helping some friends with F# homework, and being a Rust programmer, I had to ask: your project file is XML, and the order you list the project files matter, and it won’t tell you that you listed them wrong?

Compile errors are super long lines and don’t show an excerpt of the code with underline under what went wrong with suggestions on how to fix it?

I know I’m asking a lot here, but that level is available with Rust and Elm.

You are touching upon some of the reasons why C# is unproductive for us. Because aside from when its "included batteries" decide to in-fight, there is also the parts where the "magic" breaks. This is more anecdotal, however, since it's going to depend a lot on who you and your team are. The guy I was discussing with made a point about C# being very easy to on-board new developers in, which is probably true for them. It has been the opposite experience for us. But I say this as someone who comes from a team where we have very good results on-boarding new developers into our Typescript environment, and I doubt you'll find many people saying that this is a common feat of the JavaScript language.

I didn't particularly mind the new way project files are made up in .NET. It used to be a lot worse too. But at the same time, it can be cumbersome as you point out here and for whatever reason, it's these small annoyances that so rarely get fixed by Microsoft allowing them to pile up. I mean, I just said it used to be worse, and it really did, but then when they made it better they didn't make it great. Which is something I'll just never understand, especially because they did it recently, so it's not like they couldn't have taken inspiration from other languages and done it right.

Parent is talking about two issues in F# which are not present in C#.

But yes .. when you step out of the well-defined area in .net you have an "Apple moment" where trying to do something they didn't anticipate or actively dislike becomes wildly, unreasonably difficult and you get pushed down a hacking rabbithole. I'm quite proficient at MSBuild now but I shouldn't have to be.

> it's not like they couldn't have taken inspiration from other languages and done it right

That’s literally it: they couldn’t.

It’s hard to duplicate good effort and make it profitable. So many people make either valuable or well-made things.

> It’s hard to duplicate good effort and make it profitable. So many people make either valuable or well-made things.

Explain? This isn't an assembly line, it's not a question of scaling handmade artisanship.

You do have some tooling support for ordering files in VS and VSCode using Ionide. It is also not always the case that there is a right way to order the files and checking all permutations would get expensive fast. Basically, in F# that is part of the design process and helps you a lot later since you can just read the code in a linear way the same way the compiler does and not miss anything.

You do get the same information in the IDE from intellisense.

I’m not impressed by this design choice.

When order of declaration matters, it ceases to be declarative. “Let there be a function” is instead “make me a function”.

It’s entirely unnecessary, and even JavaScript can let you run a function that gets declared later.

The advantage when order does not matter inside the module is that you can list big things at the top of the file and the smaller things it’s made of below, rather than opposite.

The advantage when order does not matter outside the module system is that you can have mutually recursive modules.

I believe they view the file order as a feature. It forces a certain style/thought process in how you design your project.

It's also part of the ocaml legacy (I believe file order matters in ocaml as well).

> and the order you list the project files matter

What do you mean by this?

The FSharp compiler reads the source code in a sequential linear way and throws an error if you reference something defined later. This also includes separate files, which is why the order matters. If file A is read earlier you cant reference in it anything from file B which will be read later.

I see your point and I agree. At the same time, our current backend is Elixir because the BEAM is a fantastic match to our product. It’s been the right choice but I miss C# every day. Never having typos, point and click debugging, renaming stuff in a second instead of 15 minutes of careful grepping, etc. I recognize eg the JVM has all this too but plenty other popular languages do not.

Reply on news.ycombinator.com