Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Rust Platform

aturon.github.io

Post reply on HN
Print view View original

141–150 of 256 posts

Re: The Rust Platform

#141

Post by hsivonen »

Having used Java and having experienced how you learn to replace the JDK URL parser with something else, the JDK HTTP client with something else, the JDK encoding libraries with something else, etc., I'm worried about entrenching first-published libraries beyond their natural first-mover advantage and making it even harder for better later-comers to be adopted.

OTOH, compared to e.g. C++, where even strings aren't standard across multiple real large code bases (e.g. Gecko and Qt) having standard types especially for foundational stuff can be very useful if the foundation is right or right enough. Java having a single (though not optimal) foundational notion for Unicode (UTF-16 even though UTF-8 would be optimal) and a common efficient and spec-wise correct (though not design-wise optimal) XML API (SAX) was a key reason to develop Validator.nu in Java as opposed to e.g. Python (whose notion of Unicode varied between UTF-16 and UTF-32 based on how the interpreter was compiled!).

Still, at this early stage, I'd point to crates.io in general as the "batteries" instead of creating a layer of official approval on top. But I'm biased, because lately, I've been writing a second-to-market crate for a topic for which a crate already exists.

Re: The Rust Platform

#142

Post by catnaroek »

sclv wrote: post #133
catnaroek wrote: post #117

Earlier quoted context omitted.

> How are type families worse than fundeps? That's a pretty ridiculous assertion; the things you can do with fundeps are strictly fewer than the things you can do with type families. It's not about how much you can do (otherwise, just use a dynamic language, you can do everything, even shoot yourself in the foot!), it's about whether the result makes sense, and how much effort it takes to make sense of it. > You're d…

> You wanna play the dependent type theory card? Type families as provided in Haskell are incompatible with univalence. Hi. As someone that knows type theory and knows homotopy type theory and also knows Haskell well I would pose the following question to you: what purpose on god's green earth would be served by introducing univalence directly to haskell? (Oh, and furthermore, you realize that fundeps have precisely…

> what purpose on god's green earth would be served by introducing univalence directly to haskell?

Generally, when I want to reason about tricky data structures, what I do is:

(0) Define a set-isomorphic auxiliary type that's easier to analyze, and whose operations are easier to implement, but have worse asymptotic performance.

(1) Prove that transporting the operations on the auxiliary type along the isomorphism yield the operations on the original tricky type.

I need univalence for this argument to hold water.

> (Oh, and furthermore, you realize that fundeps have precisely the same issues in this setting?)

Type classes are already Haskell's controlled mechanism for adding ad-hoc polymorphism “without hurting parametricity too much”. I consider it healthier to reuse and extend this mechanism (which is what functional dependencies do) rather than add a second one for exactly the same purpose (type families).

> Contrariwise, don't you find it _useful_ that we can have two monoids, say And and Or, which have different `mappend` behaviour?

Sure. In ML, I'd just make two structures having the MONOID signature. Haskellers have this wrong idea that the monoid is just the type - it's not! A monoid is a type plus two operations. Same carrier, different operations - different monoids.

> Now, can you imagine having that feature and _also_ respecting the idea that set-isomorphic things should be indistinguishable? How?

Yes. Acknowledging that an algebraic structure is more than its carrier set.

Re: The Rust Platform

#143

Post by pjmlp »

Animats wrote: post #17

I'm a bit worried when a language develops a "platform" and an "ecosystem". This usually means you need to bring in a large amount of vaguely relevant stuff to do anything. It adds another layer of cruft, and more dependencies. Write standalone tools, but don't create a "platform". Don't make the use of the language dependent on your tools. C++ does not have a "platform". Nor does it need one.

> C++ does not have a "platform". Nor does it need one.

Sure it does, it is called C++ Standard Library and ISO C++ catching up to what other languages already offer.

https://isocpp.org/std/status

Re: The Rust Platform

#144

Post by oblio »

glandium wrote: post #101
sitkack wrote: post #87

Earlier quoted context omitted.

The 'std lib is where libraries go to die' was invented by Python. The libs are shallow, don't break backwards compat and provide a substandard experience. Things that continue to improve provide an out of tree alternative package name. Python codebases that are resilient don't use much of "core", arrow for time, requests for http, simplejson, etc. Using core is an antipattern that will get you stuck on a version of…

Plus, python's std lib is a mumbo jumbo of all sorts, there is no API coherence.

That's a failure at the moment of inclusion. I'm guessing it was done for convenience and to increase adoption (getting decent libraries in the standard library faster).

Re: The Rust Platform

#145

Post by pjmlp »

wahern wrote: post #114
tdicola wrote: post #92

Earlier quoted context omitted.

Go watch recent talks by Herb Sutter and Bjarne Stroustrup--they both lament the fact that C++ never developed as strong a standard library as Python, etc. With C++14 and beyond the C++ working committee is actively trying to make the language and libraries more complete and comparable to larger libraries out there.

In a low-level language like C there's _never_ a right solution out of the box. Instead, you use the language because it permits you to tailor the solution to the problem. In a high-level language like Python there's always a right solution. It's just rarely well-tailored to the problem. I'm not at all surprised C++ is still muddling around in the middle somewhere.

In C is called UNIX and it got renamed as POSIX for other OSes.

Re: The Rust Platform

#146

Post by hubert123 »

I mean really, why is this necessary? The reasons for adding this much bloat are tiny and irrelevant. You get a big download full of packages you dont all need, you dont know if you need and all for what? We all have Google, if I want an HTTP library for Rust I'll google whatever the best one is and make a judgement call myself.

Re: The Rust Platform

#147

Post by brandonbloom »

JoshTriplett wrote: post #129
wahern wrote: post #112

Earlier quoted context omitted.

String trim is just: foo:gsub("%s*$", "") or foo:gsub("^%s*", "") The standard idiom for OOP in Lua is a one-liner: return setmetatable(self, mt) where mt.__index has all the methods. How you assign to mt.__index can vary across modules according to style, but that's a _purely_ asethetic issue. The mechanics are identical. Using a module to accomplish it creates a useless dependency. There are many criticisms one cou…

If you're reading a pile of string processing code, seeing s.rstrip() helps make code self-documenting, compared to s:gsub("%s*$", "") I don't want to argue for a massive standard library (for instance, I don't think Python should have shipped modules for dbm, bdb, sqlite, or XML-RPC), but simple string processing seems like a good thing to standardize.

String processing is never simple. Simply identifying "what is whitespace?" is a big undertaking in Unicode.

Lua's philosophy seems to be to include the absolute minimum that is unacceptably painful to omit. This is a perfectly reasonable tradeoff for Lua's primary use case: embedding.

With respect to strings in particular, most systems that Lua is embedded in has its own string type, or inherits one from a framework. This is an unfortunate reality of the C/C++ world.

Returning to my point about language standard libraries: The lack of a traditional "standard library" is a feature for Lua, but only because Lua has a strong FFI and C API that acts as a "bring your own standard library" mechanism. It's less about needing a standard library, and more about admitting a language is only one piece of the puzzle. For a language to flourish, you need to have some story for interfacing with the rest of the world in a rich way.

Re: The Rust Platform

#148

Post by sametmax »

hubert123 wrote: post #146

I mean really, why is this necessary? The reasons for adding this much bloat are tiny and irrelevant. You get a big download full of packages you dont all need, you dont know if you need and all for what? We all have Google, if I want an HTTP library for Rust I'll google whatever the best one is and make a judgement call myself.

You can still have a tiny install if you want to. But most people not knowing what to do will be able to have batteries included setup.

Basically: people knowing will still have freedom, people not knowing will have an easier life.

And in the end, in 2016, you generally don't care if you download a few extra 100Mo. If you do, you will just find spend the time to find to have a smaller setup.

Re: The Rust Platform

#150

Post by tatterdemalion »

Manishearth wrote: post #91
tatterdemalion wrote: post #56

Earlier quoted context omitted.

One possibility is for rustc to take extern crate declarations as commandline args and for cargo to invoke them based on what's in the toml.

This technically already happens

Right, I guess there's no info needed outside what the --extern flag contains.
Post reply on HN