At this point if you believe they don't produce anything new is either of two things- a) having not given a fair shot to the current flagship models or b) you have a very narrow definition of new that is satisfied only by a very minuscule of human population.
If it's the latter, then agreed it doesn't produce anything new but so doesn't most of humanity and it doesn't need to, to be able to be of assistance.
I gave up on alcohol, cannabis and basically almost every stimulant with caffeine and tobacco more than a year ago with sugar and carbs remaining as the last substance I abuse.
I really thought giving up on alcohol and caffeine would have a much bigger impact on me but the only thing I notice is the minor negative effect it has on my social life from not being able to join people in for a beer or not using coffee when needing to pull all-nighters. Maybe it's just me being in late 20s and not old enough for it all to catch up to me.
Ya, it wasn't until my early 40s where a daily drink started to affect me. I never started out that way... had maybe 1-2 drinks/week in my 20s but over time the usage crept up there until 1 drink was a weekday thing (glass of wine with dinner or a cocktail later), maybe 2 drinks on a weekend night. It slowly normalized itself from something special to something routine. Once I noticed the effect it was having I started to dial it back and now I'm back down to 1-2 drinks/week... usually a glass of wine or a cocktail with my wife. I imagine it will continue to dwindle as I lose interest in it.
So given that you are only experiencing negative effects of quitting, do you think you'll start drinking alcohol/caffeine again?
I'm finishing a 3 month period of not drinking after two or so decades of moderate to heavy drinking, and I'm not really experiencing world shattering positive effects from it. I'll probably go back to drinking because in general I like it and I don't really feel the same negative effects others talk about (or at least not to the same magnitude). Curious about how you're thinking about it.
I wanted to quit smoking for good and that's one thing I am glad is not a part of my life anymore.
With alcohol and caffeine, I never thought I would stick with it for so long. But now that I have there is this inertia in me to break this period of abstinence. I am sure I would start again at some point with liquor although probably in much much lesser quantity and frequency than before.
Caffeine I probably have left for good as I have heard that the longer one goes without it the more pronounced jitteriness gets. And I am not sure I care enough to wait through the period before it normalizes again.
I'm having the same experience, trying Sober October. Hangovers suck, but I've stopped drinking to that point years ago so now I feel like not joining in socially is a net negative, limiting my ability to participate in the same experience as my friends (I'm 33).
I am curious if this is usually argued. I thought it that was generally held that agile and similar methodologies at least in the sense that sprints are defined in days/weeks and not months/years is for use cases where the product doesn't have well defined specifications.
Looks great.
I am working on side to learn product design by working on a similar system for music. The idea is to have the tactile feel of a vinyl like system but with the features of a digital library and ecosystem.
The base implementation was really straightforward and hardly a few hours but to make it bridge the gap we see with our digital tools emulating analog ones is quite fun to work on. From the latency involved between placing the card to the output from a remote service, the sound dial's latency when paired with bluetooth speakers all take one away from the experience.
It's also fun to learn little leathercrafting and concrete moulding for the prototype design.
I curated twitter in a similar style with following in my niche interest categories of academics and others with a really good signal-to-noise ratio but post musk purchase most of the accounts I followed either got off the platform, tweet much less frequent and with paid subscribers getting priority the replies feature much less relevant tweets than before. I so desire a space similar to my little corner of twitter but not able to find one anywhere after having tried with X, Mastadon(multiple servers) Bluesky, Threads. Does it still work for you?
Forgive my naiveté here but even though solutions to those finite-information abstract games are trivial but not necessarily tractable(for a loser definition of tractable here) and we still need to build heuristics for the subclass of such problems where we need solutions in a given finite time frame. Those heuristics might not be easy to deduce and hence such models help in ascertaining those.
Yes, and this is how computer "scientists" think of problems -- but this isnt science, it's mathematics.
If you have a process, eg., points = sample(circle) which fully describes its target as n->inf (ie., points = circle as n->inf) you arent engaged in statistical infernece. You might be using some of the same formula, but the whole system of science and statistics has been created for a radically different problem with radically different semantics to everything you're doing.
eg., the height of mercury in a thermometer never becomes the liquid being measured.. it might seems insane/weird/obvious to mention this... but we literally have berkelian-style neoidealists in AI research who don't realise this...
Who think that because you can find representations of abstracta in other spaces they can be projected in.. that this therefore tells you anything at all about inference problems. As if it was the neural network algorithm itself (a series of multiplications and additions) that "revealed the truth" in all data given to it. This, of course, is pseudoscience.
It only applies on mathematical problems, for obvious reasons. If you use a function approximation alg to approximate a function, do not be suprised you can succeed. The issue is that the relationship between, say, the state of a theremometer and the state of the temperature of it's target system is not an abstract function which lives in the space of temperature readings.
More precisely, in the space of temperature readings the actual causal relationship between the height of the mecurary and the temperature of the target shows up as an infinite number of temperature distributions (with any given trained NN learning only one of these). None of which are a law of nature -- laws of nature are not given by distributions in measuring devices.
I really enjoy typescript and have been yearning for a typescript runtime but I can't help but laugh that I left java all those years ago to finally seek something a lot closer to java.
I guess we all just wanted java with JIT, more feature rich type system and gradual typing. Also for all the shortcomings of npm ecosystem, it is a lot less daunting and more fun to be using libraries in this ecosystem.
And surprisingly even though rust is on a different end of the language spectrum but yet it offers a similar feel.
Edit: JIT was not the right terminology to use. I lazily wrote JIT. Apologies. What I meant to convey was the difference in startup times and run time between running something in JVM and V8. Java feels heavy but in javascript ecosystem it feels so nimble.
Java was literally the thing that made the term "JIT" popular, so I really don't know what you were going for here.
Also I just can't see how Typescript is in any way "closer" to Java - it's incredibly different IMHO. The only thing they have in common is probably the "Javascript" misnomer and the fact both support imperative programming, but that's it.
Typescript’s optional and unsound type system also does nothing for a JIT beyond what it could already do for JavaScript, you can’t do optimization if your types are unreliable. However, I really really like how Typescript’s type system super charges developer productivity (type errors via the compiler and feedback via the IDE), and don’t mind this part of the design at all.
Better for what? Quickly churning out short-lived code to get the next round of funding, definitely. Writing (and _supporting_) "serious" projects over the long term, which also require high performance and/or high scalability, and can rip through terabytes of data if needed, definitely not. (All IMHO from lots of personal experience.)
I'm actually in this exact position right now. The vast majority of the time I write in TS but I have a need to process a whole lot of data so I went for Rust instead. Java is too much of a headache for me, personally
Depends on your architecture. For scaling out rather than up, node and python are both far more performant because the footprint of minimum viable environment is much smaller. When you need to serve anywhere from 10-200,000 requests a minute on the same system quickly, and efficiently, lambda/azure functions/google app engine backed by node or python is pretty ideal.
As an example, when my org needs to contact folks about potential mass shooter events, our SLA is 90 seconds. If we did it in cloud with java or .net, it'd be too slow to spin up. If we did it on prem, we'd be charged insane amounts just for the ability to instantly respond to low frequency black swan events, or it'd be too slow. This is a real story of how a Java dev team transitioned to using node for scale in the first place.
Unlike Spring, JIT-based ASP.NET Core deployments spin up very fast (<2-5s for even large-ish applications, the main bottleneck is how fast it can open connections to dependencies, load configuration, etc.). For AOT variant, the startup time is usually below 200ms if we don't count the slowness of surrounding infra which applies to any language.
Of course CPU and RAM per request when compared to Node.js are not even close as Node is easily slower by a factor of 2-10.
Flexibility means for me more something more like, I think I know what I want to do but I also know that I'm probably wrong about that, so for now let's skip all the baroque protocol and let me make it work first. Once I'm sure I wrote what I actually wanted I'll add types if only to get rid of some bugs, consider edge cases and earn nice code completions and auto-generated docs.
I'm very glad to use typescript over java, personally - the ergonomics are so much better! Especially if you stray away from the somewhat incomplete classes thing (type support for decorator arguments isn't great, for instance) and just focus on interfaces and functions.
One thing I miss that java has is runtime reflection of types though. Typescript's ecosystem has a million different ways to get around that and they're all a bit ugly imo.
It's not really a syntax bloat, the linked docs mention how to define strict string types and elaborate on type-level programming, something that is a very rare and powerful type-level capability.
As far as I understand Virtual Threads aren't type oriented feature, which is basically the context for this thread.
I don't use them directly much, but template literal generic and contidiontal types is probably the closest a mainstream language has inched towards dependent types.
1. *Type Inference*: TypeScript can automatically infer types from context, reducing the need for explicit type declarations.
2. *Union and Intersection Types*: Allows combining multiple types, offering more flexibility in defining data structures.
3. *Literal Types*: TypeScript supports exact values as types (e.g., specific strings or numbers), which can be useful for more precise type-checking.
4. *Type Aliases*: You can create custom, reusable types, enhancing code clarity and maintainability.
5. *Interfaces and Structural Typing*: Interfaces allow for flexible contracts, and TypeScript uses structural typing, where the type compatibility is based on the shape of the data rather than explicit type declarations.
6. *Mapped and Conditional Types*: These allow for dynamic type creation and manipulation, making the type system more powerful and expressive.
7. *Optional Properties and Strict Null Checks*: These provide better handling of undefined and null values.
TL;DR: Typescript is unsound so it can add a lot more type-level features that would make a sound type system undecidable
Conceptually no, almost every useful union type can be easily converted to a sum type. In my opinion the difference is in the ergonomics and in the implicit structural subtyping.
For example a common union type is number|string, and the beatiful part is that to use a value of such a type you do not need to do any matching or mapping you can just use the value as it does not have a runtime wrapper, for example (x:string|number)=>JSON.stringify(x) works perfectly fine.
Also you can have a function that takes as input a Array<string>|number|null and returns a string|number without having to declare different contructors for the input number type and the output number type
I believe that you can essentially implement this behaviour by generating enough typeclasses in Haskell, but regardless of the feasibility it, likely, would not be a good idea.
An example of something in between union types an Hindley–Milner sum types are Ocaml's polymorphic variants types https://ocaml.org/manual/5.2/types.html#sss:typexpr-polyvar that are (I believe) more advanced than TS unions but also a lot less ergonomic to use.
And TS has much more eg intersection types you could have a function with type
(x:number)=>string & (x:string)=>number
meaning that it is both a function that maps number to strings and strings to numbers (again you can do this with typeclasses but it is a worse experience)
typescript also has very good support for value types for example there is the string type but also the "hello" type which is the type of only the string "hello"
All in all if someone told me that they implemented typescript in haskell typeclasses I would not call bullshit on them, but I would not believe that anyone would actually use it for anything
You cannot write code that will fail to compile `theEntryMethod(null)` unless you only use primitive types. (You can, of course, make that method fail at runtime, but that's not what's being talked about here).
Looking at that it's just what a default POJO (with nullable properties) already is, so I'd see no need to represent that in Java.
Looks cool though and I like Typescript; my issue with it is that it needs transpiling to run. If it was a first-class citizen in an environment I would use it for my pet projects.
Yep - all non-primitive types in Java are `TheType | null` - TypeScript actually allows you to strip out the `| null`, which then means that sometimes you want to add it back in. So Java doesn't have a need for `Partial<T>`, it has a need for `NonNull<T>` and it can't express that at the type system level very easily right now (you can do it with type tagging and runtime checks inserted explicitly, but it's not very ergonomic right now)
I'm somewhere here as well. Personally I think what I want is the stdlib (without the current legacy/ all but deprecated bits) and ecosystem of c# but with the ease and power of structural algebraic types. AoT is fine, with option for single binary. Ideally runtimeless with clever trimming. If it also ran jitted in the browser all the better.
I also want compiler/type checker niceties like exhaustive pattern matching.
Greater than 95% of the incompetence in JavaScript comes from two camps. The first of those are people who absolutely cannot program at all. The second of those are Java developers who were taught Java in school and it’s all they can do, so everything must look like Java.
The result of both tribes is pretending to do something they cannot do on their own. When you’re a pretender vanity becomes excessively important because everything is superficial, so you get layers of shit you don’t need that they cannot live without. Any attempts slice off the unnecessary bullshit always results in hyper emotional distress because people feel threatened when exposed. That right there is why I will never write JavaScript for employment ever again.
Java's type system was just very limited, gradual typing is a poor tradeoff most of the time. I used to think there were advantages to something like Python, but once I found Scala I never went back.
Yes, JIT was not the right terminology to use. I lazily wrote JIT. Apologies. What I meant to convey was the difference in startup times and run time between running something in JVM and V8. Java feels heavy but in javascript ecosystem it feels so nimble.
That's not what I am trying to convey here. JVM is amazing and it is a feat that java is as fast as it is and javascript and v8 are order of magnitude slower.
Also even though I also found java too verbose, I kept believing that we need it to be so to write good software. I still enjoy java but it doesn't compare to the ergonomics of typescript for me. And nimbleness of the experience according to me plays a decent role.
Currently for me, either I really care about performance and I default to rust for those applications or I need solutions where the product will evolve quickly over time and I need great DX over performance and I default to typescript for those.
Java definitely has a role to play but its role in my work has certainly diminished.
You're saying it like it's an absolutely good thing. Some (many?) users would rather pay the cost upfront in compilation time (doesn't really matter if it's AOT or JIT) than pay the same cost many times over through a significantly slower runtime. JVM also scales up to supercomputers (and everything in between) if you want it to, so depending on your requirements a single-threaded alternative might not even be an option.
Gradual typing is the key. The problem with Java is that types are in your face way before you actually need them.
With TS you can prototype with JS and only after you know what you are looking for you can start to add types to find bugs and edge cases and want to get nice code completions for your stuff.
Gradual typing could still keep some static guarantees if the static part were sound, e.g. you couldn't assign a dynamic-typed integer to a string-typed variable without checking the type at runtime first; which TypeScript isn't.
Elixir's new type system does much better here, as it determines whether a function actually guards for the right type at runtime ("strong arrows") and propagates the guarantees, or lack thereof, accordingly.
The fact that Java forced you to write types, and then made everything implicitly nullable so that you still get NullPointerExceptions at runtime after writing out all those types, was probably a big reason why dynamically-typed languages became popular.
The type system is a big part of what made Java cumbersome. It's loosened up a little over the years. TS itself may allow partial typing, but when team/company policies are involved, you'll often end up being forced to type everything.
How does AGPL license work for such services?
Would I have to distribute source code of my web application if I use Plausible CE?
If not, how is it different from MinIO where as far as I understand the AGPL licensed use of the product requires distribution of entire code base?
...are you sure that's right? At first blush, it feels like it break the viral nature of the GPL.
It's pretty well understood that non-GPL software cannot link to GPL-licensed libraries, which is why the LGPL exists. This is true even though most software doesn't need to vendor or otherwise modify upstream libraries.
Or does AGPL have a special carve out for this, different from the GPL?
But in the section that is the difference from GPL (section 13, "Remote Network Interaction"), it clearly states: "if you modify the Program, your modified version must ..." [emphasis added]. So the extra stuff that differentiates AGPL from GPL applies only for modified versions of the software.
For the rest, usual GPL stuff applies: if you distribute the binary, you must make the sources available, etc.
You don’t need to distribute anything if you didn’t change anything. You’re using something available somewhere else already.
Vitality comes from the way you combine this AGPL code with other code and how you can’t change the license of modified Plausible CE, or the thing you build using Plausible CE.
If you modify Plausible, you distribute the modified version. If you build something using Plausible, you distribute the thing, and with AGPL license. That’s it.
By including Plausible in a bigger website, doesn't that website become a derivative work of Plausible? If not, why is this situation different from an app that links a GPL'd library?
According to the docs [0], Plausible CE is installed as a Docker image, running in its set of containers, as an independent service from your site, which you only add the tracking snippet.
This doesn't make your site as a derivative of Plausible, but you're installing Plausible as a different tool, independent from your site.
Like installing a GPL binary doesn't make all BSD licensed binaries switch to GPL license on your system, running an AGPL licensed service on your server which communicates with your site doesn't make your site AGPL automatically, because you're not deriving Plausible, but you're installing and using it.
Now, if you want to build a service/website by directly modifying the Plausible CE source code, you have to open that derivative codebase with AGPL, only if you're redistributing the modified code (i.e. making the modified website available to other people). If you modified the code, but you're not distributing it (i.e. Only you're using it yourself), you can keep it to yourself.
> Would I have to distribute source code of my web application if I use Plausible CE
No, you don't. Folks pick AGPL because of the FUD/uncertainty around it while still appearing "FOSS". In reality these companies don't have the legal teeth to back the bark, otherwise they'd go BSL and make their intention known.
Before folks reply with whataboutism, no one has ever successfully proven the AGPL infectiousness to other web applications in court. Positing about it on hear is pointless.
The community has been trained over many years to believe that anything FOSS is immediately trustworthy, and that anything non-FOSS is immediately untrustworthy.
This gets exploited all the time when companies use FOSS licenses to get traction, then pull the rug and switch to a more restrictive license once customers are locked in.
On the flip side, if a company tries to be honest from the beginning by using BSL (or similar) they get endless grief from religious zealots.
AGPL is the magic unicorn license that is just restrictive enough to protect you from your competitors, while still passing the FOSS religious purity test.
Actually that’s not true. I’ll not trust VSCode/ium or Chrome/ium with anything.
We trust Free Software not because of the license, but because of the ecosystem and number of eyeballs. Go tried to pull something similar by forcing telemetry on everyone, and they were almost burning everything down. Almost.
People/companies get vilified when they change licenses because of the way they do it. They don’t openly say that they need the money, did some mistake and need to change things to keep company afloat, but they also change their tone after license change and vilify the past contributors and become aggressive themselves.
There are many friendly open core or closed source companies out there, and I trust them with my code, data and secrets, and pay them without any hesitation.
Software ideologies are something, so the real world. While I’d love to see everything as Free Software, we’re not there yet, we might never be, and that’s OK. I’m writing Free Software and try to use Free Software as much as I can to show my colors and do my part in the thing I believe. But I’m never a mindless zealot spewing things.
> People/companies get vilified when they change licenses because of the way they do it. They don’t openly say that they need the money, did some mistake and need to change things to keep company afloat, but they also change their tone after license change and vilify the past contributors and become aggressive themselves.
What? I can't think of any examples where they don't quote money and the lost revenue from hyperscalers just taking their software and reselling it without contributing. InfluxData's CTO and co-founder even wrote a blog post on open source monetisation and how hard it is. Elastic, Mongo even explicitly pointed the finger at Amazon. Many others smaller ones did it preventively, like Sentry and Sourcegraph.
I've also never heard any vilifying of past contributors, outside of bickering about the meaning of open source (I think it was Mongo that claimed they're still open source with the SSPL license?).
> The user interface in Tauri apps currently leverages tao as a window handling library on macOS, Windows, Linux, Android and iOS. To render your application, Tauri uses WRY, a library which provides a unified interface to the system webview, leveraging WKWebView on macOS & iOS, WebView2 on Windows, WebKitGTK on Linux and Android System WebView on Android. ... Tauri GitHub action: https://tauri.app/v1/guides/building/cross-platform/#tauri-g...
reply