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

Not Explicit

boats.gitlab.io

Post reply on HN
Print view View original

31–35 of 35 posts

Re: Not Explicit

#31

Post by steveklabnik »

gravypod wrote: post #29
steveklabnik wrote: post #25

Earlier quoted context omitted.

I hear you. A lot of this is based on opinion; you find the duplication good, I find it near-unbearable. :) One little objective thing though: > but writing an IDE that doesn't have immediate type information for everything in scope will be more complicated. Some may even say this might be impossible to accomplish via static analysis. Because of this the development of things like the RLS are much more difficult. The…

> I hear you. A lot of this is based on opinion; you find the duplication good, I find it near-unbearable. :) I don't really find it good. I just don't see any easier to follow alternatives. Imagine getting a contract to add a new feature to C code written for an old mainframe in the 80s. It's a pain, right? Now imagine you just deleted half of the type annotations and replacing them with let. Do you think that would…

I use VS: Code with the RLS and the plugin we provide for it, that's it. I also sometimes use vim with syntax highlighting, but no RLS or anything fancy.

> RLS locks up every time I try to load a non-trivial project.

I wonder if this is the initial build; that is, right now, RLS basically needs to build your code in order to do its thing, so the first time you open stuff, it's gonna be slow and make your fans whir. After that it shouldn't be a huge deal.

Things have been a bit wonky as of late, but the RLS is now riding the trains at least, so being available on stable will be very nice.

Re: Not Explicit

#32

Post by andrewflnr »

gravypod wrote: post #15

What bothers me about languages like Rust, which I think I'm in the minority on, is the lack of explicit type declarations. C and Java, my two first languages, strictly spell out what types they expect. Sure you can ignore those rules but as long as you don't those types convey a lot of useful information about your program. With languages like Rust I don't think I could ever start writing code in them without an IDE…

Dude, just try it. I see where you're coming from, but in practice I find that the reduction in obviousness to be small, and the benefits of reduced typing and noise in my program to be huge. I've come to see type declarations as work fit mostly for computers and I'm almost personally offended at languages that make me do it for them. So basically, if you try type inference, I don't think you'll want to go back. :)

P.S. I hear the Rust plugin for IntelliJ is pretty solid.

Re: Not Explicit

#33

Post by nitrogen »

pgwhalen wrote: post #28
jopsen wrote: post #17

Earlier quoted context omitted.

So the definition of explicit or not has to do with the computability of the question. Method resolution is not computable in a dynamic language with monkey patching. Hence, not explicit. That's a good point.

Another way to think about it is whether the IDE can do it for you. As a Java dev (who is admittedly a bit of a slave to IntelliJ) this is a huge part of my programming experience.

A heavyweight IDE is really only necessary because of the unwieldiness of Java patterns for naming and code layout. Autocompletion and navigation leads to code that is only manageable with those features in a vicious cycle.

Re: Not Explicit

#34

Post by curun1r »

kibwen wrote: post #27
gravypod wrote: post #15

What bothers me about languages like Rust, which I think I'm in the minority on, is the lack of explicit type declarations. C and Java, my two first languages, strictly spell out what types they expect. Sure you can ignore those rules but as long as you don't those types convey a lot of useful information about your program. With languages like Rust I don't think I could ever start writing code in them without an IDE…

> is the lack of explicit type declarations This is mistaken. Rust has explicit type declarations, augmented with type inference. Furthermore, unlike popular statically-typed functional languages, Rust's type inference is deliberately restricted to only operate within functions (intraprocedural) rather than between functions (interprocedural), which means that one always has explicit types available in the function s…

Perhaps not type declarations, but I think GP is onto something when it comes to Rust and how it handles types in a way that often lacks explicitness. There's a lot of Rust code where you have to have familiarity with an API to understand what's going on with the types.

As a for instance, let's say you have a function:

    fn connect(addr: std::net::IpAddr) -> ... {
        ...
    }
And it gets called:

    connect("192.168.0.1".parse());
Unless you have a pretty good level of familiarity with the APIs involved, it's pretty difficult to reason about the types when looking at just the invocation of connect. You'd have to know that str::parse() will figure out what type it's supposed to be and, if it implements FromStr, it will call the from_str() function defined for that type to handle the coercion. That's a frustrating level of indirection for a beginner. And, since all of this is defined in the std library, it's also possible for library authors to similarly declare APIs that have this kind of indirect invocation where you only really understand what's going on if you've studied/memorized that API. I've often thought that a maze of From/Into and Deref coercions would be an excellent approach to the underhanded Rust competition because it's often so difficult to realize when that code is getting executed and it would be pretty easy to hide malicious code in functions that are executed implicitly.

It also doesn't help that a sizable portion of the Rust community believes console-based editors like vi and emacs are preferred and more advanced Rust IDEs are still early days and aren't able to help out much with situations like these.

It's not that I disagree with these types of language design decisions. I just feel this kind of lack of explicitness makes the language optimized for experienced users rather than beginners and helps give Rust it's deserved reputation for having a high learning curve.

Re: Not Explicit

#35

Post by plumenator »

__s wrote: post #14
millstone wrote: post #5

I didn't agree with this article's definition of "explicit," which feels tautological: Rust is explicit because you can figure out a lot about your program from the source of it. But as long as the source code conveys the information, it is still explicit in the narrow sense I defined above. But if the thing will happen deterministically in a manner that can be derived from the source, it is still explicit in the nar…

Your example comparing to C++ is something where I think the point of this article is coming out: we can become more explicit about what we're talking about when we bring nuance into our language to describe things like 'local' vs 'statically determined' which in language design discussions are both being labelled 'explicit' despite being distinct concepts. Explicit has been overused to the point of being a bad word

As in "explicit content"?
Post reply on HN