171–180 of 313 posts
Seems like a lot of this comes from rust defaulting to allowing several different versions of a library to be linked in ... there’s def some other pieces. But that seems like a biggie
Do you know how to not do this "default"? I would love to try it.
Earlier quoted context omitted.
> Windows 3.11 required 4MB of RAM and the whole install took Sure, and the moon landing used computers with less processing power than your kids calculator. That doesn't mean we should use those to put people on the moon over faster hardware. Does the fact that older, slower and smaller hardware and software once existed mean we should spend time, resources and potentially sacrifice features to... what? Hark back to…
But what if GUI applications that were considered lean and mean in the 90s were common on today's hardware? Wouldn't those applications be really fast and light on resources?
Earlier quoted context omitted.
I feel like a reasonable middle ground to these issues is for communities to perhaps embrace “metapackages” that serve as community maintained “standard libraries”. In the R community we have tidyverse, which is practically a full mirror of R’s standard libs at this point. These metapackage communities can then focus on interoperability of constituent packages w/o overburdening the standard libraries, and core langua…
Several attempts have been made at this in Rust in the past, but few people use them. It just adds even more dependencies that you’re not actually using.
Earlier quoted context omitted.
Python's standard library is where things go to die because of the terrible adhoc versioning system (the module name is the version number) and dynamic typing means they are afraid to change anything. But even then it's still better than having no standard library at all. The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means…
> The advantage of a standard library is that you only need to learn one API instead of a dozen different APIs for doing the same thing, which means you can develop a degree of mastery over it. The rust ecosystem has done well to converge on certain crates as sort of replacement for missing std features. In practice (at least in the rust ecosystem), I only need to learn one interface for: * regex (regex) * serializat…
Because that is the biggest asset from stuff being in the standard library.
Earlier quoted context omitted.
I think I get the tradeoffs but while my company would be a perfect fit for rust, we do all our development on an airgapped network. Custom registries are a thing now, but picking and choosing which packages our IT will consider trustworthy and then taking the subset of that with a license our legal will approve an then prunimg things with dpendencies that are now missing is a huge task that needs to happen at regula…
At least from a licensing perspective, you should be all set. Virtually everything in the Rust ecosystem is permissively licensed. Trustworthy is another thing altogether though. How do you handle this process in C and C++? Both of those languages have fairly spartan standard libraries as well.
And you usually see them cursing the platforms that don't care about POSIX support.
And ISO C++ has repented themselves from following C's footsteps and have been improving the standard library since C++11, mostly by integrating boost libraries.
Earlier quoted context omitted.
More often than not, absolutely. It requires a much higher level of competence to design a language and develop a functional compiler than it does to design libraries. There are packages in Node with millions of downloads, packages that are basically ubiquitous in certain domains that are riddled with bugs, with terrible interfaces and documentation. I can even think of libraries I've worked with in Java/C/.net/etc t…
Language design and compiler implementation are definetely high-competency skills, but they don't necessarily correlate with library design skills. For instance, http client and server libraries are often in this gray area of uncertainty about whether they should be in the stdlib or not. Is this something language designers or compiler implementors have a lot of experience in? I would say not; sending and serving htt…
Earlier quoted context omitted.
At least from a licensing perspective, you should be all set. Virtually everything in the Rust ecosystem is permissively licensed. Trustworthy is another thing altogether though. How do you handle this process in C and C++? Both of those languages have fairly spartan standard libraries as well.
The spartan C standard library was what my comment regarding 'small languages' was referencing. I don't have much experience with many of C's contemporaries, but for an opposing view take for instance the standard library of Ada ( I use the term 'standard' here to connote the library that is mandated as per the standard of these languages ). It is definitely orders of magnitude larger than that of C, and takes a fund…
Earlier quoted context omitted.
The culture of the programmers comes into it too. In the Java/.NET world devs are happier to take what the core libraries provide. A case in point is how the ORM Entity Framework that comes with .NET has made the older NHibernate (a separate package) obsolete. .NET developers love using the standard libs, but OTOH Microsoft has a lot of resources to create very complete libraries.
Even in Java, if you're looking to do anything with dates, everyone will tell you to use Joda-Time over java.util.Date.
Earlier quoted context omitted.
Apples and oranges. It is a feature that Go, Rust don't have "enterprise" standard libraries like Java and .NET.
This comment indicates the problem! Taking the scare-quotes "enterprise" as a synonym for "bloat", one person's necessary feature is another person's bloat. .NET is an interesting case, because of WinForms, which is a de facto part of the standard library. I think few C# developers think of WinForms as bloat; it's very convenient for making simple UIs. Yet putting, say, GTK+, in the Go standard library would doubtles…
It's not that convenient on Linux though...
Earlier quoted context omitted.
But two minutes is still a lot of time to wait for a build, especially if you’re doing gamedev and want to prototype something fast. It seems nalgebra is the culprit here: because Rust doesn’t yet support const generics, it has to use some hacky type-level metaprogramming to represent numbers, and that will definitely destroy build times.
2 minutes for a full build from scratch. Incremental builds afterwards take seconds, though unfortunately linking of big projects can still sometimes takes up to around a minute.
The original code, after being migrated to an up to date version of Gtkmm, takes a couple of seconds with GCC 7, not more than one minute if at all.
The big difference? I don't need to compile from scratch all the 3rd party dependencies.
With every release from Rust I do a clean build to assert how much it has improved.
It was much worse, so congrats on the work achieved thus far, but it is still a pain to set up a project from scratch.