Hacker Newsnew | past | comments | ask | show | jobs | submit | more greener_grass's commentslogin

> dotnet requiring a CLR is not particularly well-suited for containerization

Why? I routinely put compiled .NET programs into containers.

It's also easy (easier than Rust even) to build on Mac targeting a Linux image.


Create a hello world dotnet container, then do the same in a modern language. Then compare image size and resource consumption. Then imagine you're running tens of thousands of containers in a proper SaaS microservices model, and it'll make sense :)


Enterprise doesn’t spawn 10,000 containers to perform a simple “hello world” operation. That’s not how it operates. You’d be amazed at how many concurrent requests a single service can handle. This capacity must align with the actual requirements of the companies involved, not some unrealistic scenario like “we need to emulate Google.”


  > Create a hello world dotnet container
The container image is 10.9 MiB. The binary is 1.2 MiB.


While that is small for a container and modern binary, I recall C hello worlds being 17KiB -- if only AOT/Spans/interop be used more to drive down those filesizes further.


Sounds like a problem with the "proper SaaS microservices model" more than .NET


If you have that many containers, you should be having the revenue to pay for that.


Here `a` and `b` can have different types:

    let! a = fetchA() and! b = fetchB()
Whereas `Promise.all` usually requires all promises to have the same type (returning a `List<T>` or even a `List<obj>`) .

See https://learn.microsoft.com/en-us/dotnet/fsharp/whats-new/fs...


Actually, TypeScript's `Promise.all` can handle different types too.

    const [a, b] = await Promise.all([fetchA(), fetchB()]); // => a: A, b: B


I am talking about C# / F# context where the lists must have homogeneous types.

That TypeScript supports this is yet more complexity introduced to cover usages of an API not designed around types.


What are the cross-stack gains of Python?

Running TypeScript on the server is a well trodden path. It can be pretty fast too. Python on the client, not so much.


F# is a practical choice but the language features are quite far behind OCaml now.

{Ecosystem, Functors} - choose 1


From an outsider's perspective, it feels like Ocaml has more active development of features, between the new effects system they added in 5 and all the work Janestreet is doing to let Ocaml developers have more control over performance.

F# is not stagnant thankfully, it gets updates with each new version of dotnet (though I haven't checked what is coming with dotnet 10), but I don't recall anything on the level of the above Ocaml changes in years.


Applicative Computation Expressions are a big deal (added in F# 5). Recent changes have been smaller in scope.

Unfortunately lots of the more advanced stuff seems to be blocked on C# team making a decision. They want a smooth interop story.

But F# remains a solid choice for general purpose programming. It's fast, stable and .NET is mainstream.


Oh yeah I love f#, I need to find more excuses to use it. I just wish it felt like MS was willing to invest more into it. But at least they have not abandoned it and continue to put some resources into its ongoing growth.


F# also has a real slow compiler. Last time hello world took a few secs on brand new mac.


What about a strict subset of C#. The use case for F# seems to be shrinking because MS is putting all its energy in language.


This isn't true, because more is not always better.

C# has lots of anti-features that F# does not have.


For me the issue is ecosystem. The foundations are great but I need more useful and well supported packages.

For example, there is no OAuth2 client library for OCaml [1]

[1] https://ocaml.org/docs/is-ocaml-web-yet


That would be Elm :)


I've been saying for ages! Gleam, Roc, Derw, Gren, Cara, Zokka, and the error messages in Rust.

https://news.ycombinator.com/item?id=45646520#45752905


Roc says hi!


Define functional?

Even Haskell is not functional in the strictest sense. It has unsafe IO. It can throw exceptions. Functions may not halt.


Fair. Agda, gallina, f* maybe?

My point was that without any escape hatches or magic you can code a segfault starting in ocaml5. That may be true of haskell? It is true of rust too, though the only known way to do it isn't something that is likely to happen by accident and is tracked as a bug. In ocaml5 if you use domain, it is down to experience skill, and some luck to be sure you used atomic when necessary. I'm a bad programmer despite going on four decades of experience. I'm not even remotely methodical. If I adopt ocaml for a project I'm using 4 or adding something that fails the pipeline if it finds domain anywhere.


> you can code a segfault starting in ocaml5

It shouldn't, the OCaml 5 memory model bounds the reach of data races in both space and time. [1] Thread-unsafe code won't be correct when misused, but it will stay memory safe unless you reach for an additional escape hatch (or you find an implementation bug of course).

[1]: https://ocaml.org/manual/5.4/memorymodel.html

I'm much more concerned about the amount of poorly vetted escape hatches in wide use in OCaml, mainly for bindings.


You are right! As of 5.1.1 at least it catches the cross domain access I was using to smash things. From what I am reading it sounds like it didn't work in 5.1 I could go try it in godbolt to find out when it was fixed, but I kind of don't care. Very exciting, I like ocaml and was lamenting the changes.


That makes a lot more sense: The earliest 5.x releases weren't stable at all despite the non-prerelease version numbers. I waited for longer than I wanted to before upgrading from the LTS to 5, but right now it should be ok to switch as long as the few regressions, like the GC pacing issue, don't affect you workload.


Shouldn't most application programmers in OCaml be reaching for EIO or some other well-tested abstraction?


When there was no true concurrency, only preemption, eio was safe. Not now, you can still clobber things.

Edit: i was wrong! Since at least 5.1 it catches the cross domain access and errors gracefully.


Eio didn't exist before multicore OCaml actually, it was designed for it.


• Stategraph manages Terraform state, so correctness isn't optional

TypeScript has soundness issues that OCaml does not have

• Strongly-typed data structures catch field errors at compile time

TypeScript does have this, although the guarantees are in practice weaker since libraries may have incorrect type definitions

• Type-safe SQL queries prevent schema drift before deployment

There are TypeScript libraries that offer this, so fair point!

• Immutability by default eliminates race conditions

TypeScript is not immutable by default

• PPX generates correct JSON serialization automatically

TypeScript does not have an equivalent to PPX infrastructure AFAIK. If there is, it's definitely not as widely used within the ecosystem compared to PPX for OCaml.

Edit: Downvoters care to respond?


This is what F# provides.

F# has a similar whitespace syntax to Python, but is statically typed and can be compiled AoT.

Bubble sort Python:

    mylist = [64, 34, 25, 12, 22, 11, 90, 5]

    n = len(mylist)
    for i in range(n-1):
      for j in range(n-i-1):
        if mylist[j] > mylist[j+1]:
          mylist[j], mylist[j+1] = mylist[j+1], mylist[j]

    print(mylist)


Bubble sort F#:

    let mylist = ResizeArray [ 64; 34; 25; 12; 22; 11; 90; 5 ]

    let n = Seq.length mylist
    for i = 0 to n - 2 do
      for j = 0 to n - i - 2 do
        if mylist[j] > mylist[j + 1] then
          let temp = mylist[j]
          mylist[j] <- mylist[j + 1]
          mylist[j + 1] <- temp

    printfn "%A" mylist


Nim:

  var mylist = [64, 34, 25, 12, 22, 11, 90, 5]

  let n = mylist.len
  for i in 0..n-2:
    for j in 0..n-i-2:
      if mylist[j] > mylist[j + 1]:
        swap(mylist[j], mylist[j + 1])

  echo mylist


Decorators are just function application with more syntax.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: