How do you really target FPGA and GPU when these are so different?
e.g. what I find appealing about FPGA is (1) very low latency and (2) arbitrary precision data paths, like if I want 6-bit data paths I can have them. The GPU on the other hand is throughput oriented and you get the data types that were baked in.
I believe it is mostly about intrinsic libraries and developing the code to stick to the idioms of using such libraries; in the context of Clef, maybe the author of this infrastructure is aiming at close interaction between the compiler frontend, a standard GPU programming library and the Clef backend, but I can't really comment on this.
What Clef seems to be doing is:
* bringing semantics that are needed for native platform targeting, expressed with idioms familiar to F# developers (through the type system and the lowering during compilation stages, retaining target specific semantics)
* making the broad F# programming idioms applicable to such targets (when applicable obviously)
The website contains a lots of detailed articles about aspects of translating F# constructs to the type of environment this compiler targets, but AFAIR, nothing specific to GPU programming.
C# can't fix the wrong defaults, still lots more mutable by default, and statement oriented, as an example.
average C# codebase looks different depending language version idioms, not so in F# (because initial release already had >80% of things that C# today doesn't even have and won't be able to fix).
Never under-estimates wrong defaults in a language, for example:
C++, const modifier, verbose for more correct code (less mutable state, etc.)
Rust, mut modifier, verbose for less correct code
C/C++, bothersome to have tight scopped values, due to split of expression & statement
ML languages, nesting of let bound values, everything is tight scoped, even recycling local names non destructively via shadowing.
C#: mostly, all flaws of C/C++/Java
F#: mostly all right things of ML, OCaml, Rust
F#: Structural comparison of ML types from day 1
C#: just adding records recently; most of libraries, idioms, and semantics geared towards reference comparison
idioms
C#: mainly OO, noisy syntax, low expressivity (constructing immutable values out of generators or expressions), lots of navigation due to adhoc things needed to be named, poor type inference
F#: data & functions, concise end non noisy syntax, high expressivity (list expressions, computation expression values), less scrolling & navigation, object expression rather than defining type used once, great type inference (less noisy diff on refactorings)
etc.
So average F# codebase is by construct, more sound, than average C# codebase, however F# code quality may be poor, and C# great, still, more soundness in F#, IMHO.
Nonsense, .NET is one of the best ecosystems available. Your sentiment is one I tend to hear mostly from people who think it's still .NET Framework and Windows only
Indeed. I read a great write up by Sam Cox of Tracebit[0] on his selection of C# and his focus on productivity nails it on the head. One of the best ORMs, rich standard libraries and first party packages, and has been converging with TypeScript and JavaScript over the last decade[1] while having all of the advantages of runtime type safety.
Folks that last looked at C# over a decade ago don't know what they are missing.
Yes; very underrated in this regard with respect to how terse the language is now. Especially switch expressions and pattern matching. C# pattern matching is incredibly rich[0], terse, while being eminently readable.
If you feel forced to use vscode due to "lack of better alternative" but then stop at using .NET, then you're really missing out on tools that lack better alternatives.
.NET has spoiled me so badly with C#, NuGet, and the debugger that I just don't have the patience for any other languages with their half-assed build systems, janky package managers, and after-thought debuggers.
MSBuild and the dotnet CLI tool may not be fancy, but they work and I generally find "fanciness in the build system" to be a gateway drug to "broken-ass builds that invite new layers of new broken-ass build tools on top".
Every .NET project I've worked on in the last 15 years I could pull from the repo and build-and-run immediately. I can't really say that for almost any other platform.
I was onboarding some Python developers into a C# project at work. I walked them through installing the SDK, cloning the repo, and running the app. One of them piped up,
"That's it?"
"Yeah, that's it. What do you mean?"
"What about virtual environments?"
"Uhh, I'm not sure what you're getting at."
"What if I have multiple versions of the SDK for different projects, how do I keep them from clashing?"
"Oh, yeah, don't worry about that. They all can co-exist side-by-side. Which version a project uses is part of its build settings. Venv just isn't a thing in .NET."
> NET has spoiled me so badly with C#, NuGet, and the debugger that I just don't have the patience for any other languages with their half-assed build systems, janky package managers, and after-thought debuggers.
Rust and cargo are pretty good and only getting better. I don't really see a good use case for anything dotnet when JVM exists
> Every .NET project I've worked on in the last 15 years I could pull from the repo and build-and-run immediately. I can't really say that for almost any other platform.
Definitely not for any NPM project. At work when we didn't touch a project for half a year it was impossible to build due to some changes in dependencies. They require continuous maintenance.
This is a fair criticism, but I think it's more accurate to say that "Venv is built-in", more than "isn't a thing"; it sounds like something is managing it for you, if they can co-exist somehow.
Python is (slowly) getting there; `uv` gets pretty close: `uv run -m $module_name` will install required dependencies & run.
(But even then, we use it at work, and there are a few complications around macOS, native libraries, and private repositories.)
> I don't want to use Microsoft technologies unless forced to or no better alternatives
Agreed there.
> (GitHub
Github is probably in the "forced to" category, since the employer, not employee, decides, I assume.
> / vscode)
… but really? Vim. I've yet to see someone using VSCode on a VC meeting stream that isn't seemingly floundering. What does VSCode get me, aside from a proprietary editor from a company I do not trust? Telemetry and AI slop built in?
Microsoft historically abuses their market position. I think if you're wedding yourself to any MS technology, you need to be able to have a clear divorce strategy.
Maybe true for all companies but especially true for Microsoft (perhaps Google, Apple, etc. as well)
One way to look at it, but consuming OOP libraries doesn't turn code into OOP.
Also, FSharp.Core (which most F# code leans heavily on) is not OOP at all.
F# promotes object programming, doesn't proscribe mutability, encourages function and data approach.
It offers simple access to the different paradigms, with some opinionated choices (e.g. preventing leaning on OOP beyond an arbitrary stretch, like no "protected", only explicit interface implementation, etc.).
I don't see how that changes things. You'd have to async it all the way to the top but the syntax is still cleaner than F#. If you're using an Asp.Net controller you just declare the handler as async Task<IActionResult> and it's fine. Even program main methods can be async these days
It's absolutely not exactly the same; let! is only available within a computation block. If you want to return some value from the computation block and return to Functional land without having to pause the thread you need to use a continuation, which C# has built in syntactic sugar for in async/await and F# does not.
It's actually sort of the other way round. C# has hardcoded syntax for async/await. F#'s syntax for async/await is a fully-general user-accessible mechanism.
They're not so different in that regard. C# `await` can be adapted by making an awaitable and awaiter type[1], which isn't to dissimilar to how a computation expression in F# needs to implement methods `Bind`, `Return`, `Yield`, etc.
In both languages these patterns make up for the absence of typeclasses to express things like a functor, applicative, monad, comonad, etc.
* community pressure so that F# libraries could standardise on better things that Choice1Of2 = Ok and Choice2Of2 = Error, or using a bare tuple (which is very not clean for APIs)
* F# ought to remain flexible in terms of not pretending of totally abstracting away the fact that most of the dotnet base class library or the overall dotnet ecosystem, uses exceptions, it is not like Result type was created to abstract runtime exceptions away.
For all other needs, one is just one wrapper / or abstraction (for library that don't "meet our standards" in terms of exception safety) away, along with a bit of adhoc tooling around leveraging FSharp.Compiler.Service for sake of adding static analysis, for architecture astronauts, dealing with behemoth or safety critical codebases, requiring even more screws turned, but even there, F# (and so many other languages) may not meet the bar if those are the critical properties for a project involving code.
Overall, F# is just pragmatic for the 99.99%, and not trying too hard beside the steady core language idioms, and how the organic community wants it over time, to satisfy hypothetical and intellectual pursuits of the highest abstraction and safety.
The culture of F# is mostly about throwing productivity parties and being done with it (while not suffering so many of the wrong choices done by C, C++, Java and it's famed sibbling, C#), rather than the higher conceptual type theory perfection that (sometimes ?) lead to code that is not less kludgy, or easier to maintain, in the grand scheme, for the masses of developers, that are not yet expert in Haskell, Scala, etc.
It is probably not too dissimilar to OCaml culture, while embracing some aspects that are familiar to more people, due to relationship with dotnet ecosystem.
(There are languages more similar to C# than Java and vice versa, and of course the underlying type system differences between JVM and .NET also add to this rift, C# was intended as a successor to C++ just as much as it was to Java)
In context of adding burden of having someone to translate for you in Japanese, the statement he made seems good enough and to the point.
Maybe you are far too pre-assumtpive that there was any ill effect, or even ill intent, in the statement being made, especially if the same fact is accounted for in gnuplot FAQ.
