is there anything (open source) similar to microsoft database project
but that would work for postgresql
i like the following about it
1. database schema is regular code
2. make schema change declaratively
3. packaging (.daspac) and deployement script
most open source tools , seem to be after the fact tools, that do diffs
ms db project, handle the code from the start in a declarative, source code managed way
F# seem to be in abandon-ware state
the creator of F# moved to another job as his primary work
the forum and community are very dry
Nothing interesting being created in F#
As much as I had high hopes for F#
I think its safe at this point, to not pursuit it any further
.Net is C#
If you want an Ocaml like language, that is not Ocaml, your best bet is Rescript
and that being said, Rescript is probably more of a competitor to gleam, since gleam also have javascript as a target
The language is still ahead of C#, and still receiving features and keeping up by and large with the .NET ecosystem. Tbh I don't get the sheer negativity; the same thing could be said for Gleam or any other functional language these days tbh especially with AI coming along w.r.t long term support. Eventually things just work and are mostly complete; things don't have to get reinvented or get better forever.
> As much as I had high hopes for F# I think its safe at this point, to not pursuit it any further
I find this attitude interesting; you wanted it to be more than it was. I don't have high hopes for any language; other than it building my software which it and many others can do. Right tool for right job. I'm not attached to my code, other than if it can be maintained, changed, has sane defaults/guardrails to introduce less defects, etc. F# can do this, as many others. Interestingly I've seen the same attitude eventually happen to all languages of this class other than Rust; Scala, OCaml, etc are in similar positions.
Funnily enough Opus/CC has a number of times for my projects has suggested Rust, and if that doesn't work (too much for the team) went F# even over Java based langs assuming domain modelling code and the need for more perf (e.g. value types, and other stuff) without explicit prompting. Its then generated fsx scripts to run experiments, etc that seem to be more reliable than the default Python ones it runs (package errors and static typing fixes mostly). `dotnet fsi` fits well into the agentic workflow.
> Rescript and that being said, Rescript is probably more of a competitor to gleam
Depends on your target. F# at least has a backdoor into the C# ecosystem - from a risk perspective that makes it more palatable. New languages have an initial "excitement" about them; but generally they are just tools.
Pick something that fits your team and build. F# does work, and so do many other tools. In the age of AI IMO the ecosystem and guardrails for the AI matter more than the language and its syntax IMO other than readability. In this regard F# still is "less risky" with its .NET interop.
Wake up and smell the coffee: fsharp is dead. Look at the release notes of fsharp. It's laughable for a major version update. It's maintained by like 5 people working in eastern Europe and they only do maintenance updates basically. C# is getting all its features and DotNet is basically c# oriented anyway. So even in the past you had to learn C# to program in F#
I would assert that Microsoft's management always behaved as if they repented to have added F# to VS 2010, with all the maintenance guarantees it implies, throughout the years they have searched how to sell it.
Nowadays CLR has effectively changed meaning to C# Language Runtime, and ironically the JVM is more lively as the original goal of the CLR back in 2001.
I cant read the article (paywall) , but does it talk about any side effects , I am just worried we are celebrating a drug, that might have serious side effects
I am sure at some point a drug will be perfected, but the promotion of this drugs goes way beyond spreading the awareness that excess weight is a health risk, it feels political, and used as an excuse to attack leftist ideas
balance is everything, your body, your choice, move, eat healthy .. and only use proven drugs, and preferably use drugs as a last resort
So last word talk to your doctor about ozempic, if you are considering using it
As with all the ahead-of-time compiled languages that I checked, the answer is that it generates non-SIMD code for the hot loop. The assembly code I see in godbolt.org isn't bad at all; the compiler just didn't do anything super clever.
well uniformity and homoiconicity are very important
in an ideal db management system (a.k.a a true rdbms)
everything should be represent as a relation
and use the same set of operators to be manipulated
separations of types and relations should be limited to core atomic type, string, int , date etc ... (althought date is debatable as is not usually atomic in most cases, and many dbs end up with one more date relations)
Data should be data, queryable, relational. So often I have had to change enums into lookup tables - or worse, duplicate them into lookup tables - because now we need other information attached to the values. Labels, descriptions, colors, etc.
My biggest recommendation though is that if you have a lookup table like this, make the value you would have made an enum not just unique, but _the primary key_. Now all the places that you would be putting an ID have the value just like they would with an enum, and oftentimes you wont need to join. The FK makes sure its valid. The other information is a join away if you need it.
I do wish though that there were more ways to denote certain tables as configuration data vs domain data, besides naming conventions or schemas.
Edit to add: I will say there is one places where I have begrudgingly used enums and thats where we have used something like prisma to get typescript types from the schema. It is useful to have types generated for these values. Of course you can do your own generation of those values based on data, but there is a fundamental difference there between "schema" and "data".
well, if DDL (data definition language) and DML (data manipulation language), were unified and both operated on relation , manipulating meta data would have been a lot simpler, and more dynamics
you can always created data dictionary relation, where you stored the code for table creation, add meta data, and use dynamic sql to execute the DML code stored in the DB, i worked somewhere where they did this ... sort of
Everything should be represented as relations (sets of tuples) but you should always use tables (multisets of tuples) when possible? That seems a little contradictory.
If said DBMS is tablational, like SQL, then you would have to approximate them using tables and constraints.
If said DBMS is of an another paradigm, like a document database, there may be no way to represent relations within the DBMS.
An enum is a construct that numbers things. There is no way to represent a set of tuples with an integer[1]. I'm not sure where you are trying to go with that one. Inversely, you could hold an enum generated value within a relation. Is that what you mean?
[1] Yes, technically you could break up the individual bits such that they form a set of tuples, but that wouldn't be useful beyond a very narrow use-case and doesn't generalize the way relation implies.
+10 for bad windows support, i think this is a key and weirdly underestimated reason
just to give an idea how bad, until recently, you could not just go to ocaml.org and download ocaml for windows, you had to either download one for mingw or wsl
so for many it was just not installable, i.e. for many we didnt have ocaml for windows, until very very recently
The Windows support is bad because OCaml is a PL designed by people who are deep in Linux life. Windows is not something that keeps them up at night. (Which isn't to say they didn't try, just, you know, not as much as it takes)
One of the things people often neglect to mention in their love letters to the language (except for Anil Madhavapeddy) is that it actually feels UNIXy. It feels like home.
If that's what you use as your yardstick of what's Unixy, then I guess you don't consider "find" to be Unixy, in spite of being one of the early Programmer's Workbench tools.
Short options were a compromise to deal with the limits of the input hardware at the time. Double dashes were a workaround for the post-dash option car crash traditional Unix tooling allows because teletypes were so slow. There is nothing particularly Unixy about any of these options other than the leading hyphen convention.
Caml was developed in 01985, Linux was first released in 01991, and Caml was extended into OCaml in 01996. I don't think the developers were using Linux at the time; SunOS 4 would be my best guess. I didn't work on it, but I was in the sort of internetty environment that OCaml came from, and I was using Solaris at work and got my first Linux box at home. As another commenter mentioned, the command line follows Unix conventions rather than the Linux conventions from GNU.
It's just sort of anachronistic. Caml was no more designed by people deep in Linux life than James Clerk Maxwell was into aviation or Christopher Columbus liked to visit the Massachusetts Bay Colony. They probably would have been, but the timelines didn't allow it.
Sure. The larger point was about Windows. You would or would not agree that people doing PL research on SunOS workstations (or whatever UNIX) would also not give a shit about Windows?
Windows didn't exist in 01985. I mean, Microsoft did release a product by that name at the end of the year, but it wasn't an operating system.
I remember that in 01998 or 01999 I asked Andrew Tanenbaum, a different European CS professor, what he thought about Linux. His impression was still that it was some kind of hobbyist project for people who (paraphrasing here and reading between the lines) couldn't afford a real computer. So I suspect that, even when Caml became OCaml, its developers saw Linux as belonging to the same crowd as Microsoft Windows, rather than to the systems they were used to.
But even that Windows/Unix OS dichotomy didn't exist when the programming language was designed. They might have been thinking about Unix vs. VMS, or Unix vs. GCOS, or Unix vs. Oberon, or BSD vs. System V, but definitely not Linux vs. Windows.
Being a nerdy kid in the 80’s, I can’t see the acronym MCP without thinking, “You’re in trouble program. Why don’t you make it easy on yourself. Who’s your user?”
Well that one at least has appreciable parallels :)
Letting an LLM loose on a real system without containing it in a sandbox sounds about as predictably disastrous as letting a glorified chess program run all ENCOM operations…
And your mom who grew up in the 1960s might have yet another interpretation in mind ( https://www.ebay.com/itm/305272862225 ). MCP is definitely an overloaded acronym at this point.
The virtualization KVM is the new kid to the block. Back in the day the best way to get multiple machines controlled was to just have multiple machines sharing the same monitor, keyboard and mouse.
100% agree! And I'm pretty sure the Linux community had many more (hardware) KVM users than the general population. Kernel-based virtualization should've been abbreviated KbVM.
I'm mildly confused as to the value over, say RustDesk. The latter allows remote control of external machines and has ip hole punching .. no hardware involved! Any takes here?
RustDesk is an alternative to other remote desktop software, JetKVM is an alternative to a built-in IPMI. It could be used as a remote desktop in a pinch, but that's not really the main point.
E.g. you'd use JetKVM-like devices to re-install your OS via emulated drives, remotely control power (including hard reset, not just WoL and software shutdown), change BIOS settings, or troubleshoot a crashing box - all without relying on any specific software/capabilities/behavior of the given box. Meanwhile you'd use remote desktop software when you just want the desktop to present itself remotely.
Or without an OS installed at all, or with a broken OS.
I do VoIP phone systems for a living and this is why I deploy Supermicro mini-ITX servers, so even if something goes totally sideways as long as the client's IT is competent enough to get me remoted in to their voice network in some way I can troubleshoot it fully and in many cases fix it without leaving my desk possibly half way across the country. If it's an actual hardware problem and I can't fix it remotely I still then know for sure what's wrong and whoever's going on site can be properly equipped for the actual problem rather than having to bring everything.
RDP is over network, which doesn't work well if your need to access a machine that doesn't have a working network stack because you're troubleshooting a hardware failure, early boot failure, OS provisioning, etc.
KVM can also be nicer than RDP for certain multi-box workstation setups that need high bandwidth and low latency.
i like the following about it 1. database schema is regular code 2. make schema change declaratively 3. packaging (.daspac) and deployement script
most open source tools , seem to be after the fact tools, that do diffs ms db project, handle the code from the start in a declarative, source code managed way
reply