TheHydroImpulse

There have been previous events in underscore's history that lead to sudden breaking changes without following semver. That's probably why.

Oops, not sure why I put that, it's indeed software transactional memory. Akka is a pretty known library that supports it.

No, it's certainly not an advantage in every case, because that's all you can use. It's not always the best tool for the job. Under the JVM, you have a massive amount of library support for multithreading and concurrency. You have things available like Futures, STM (Software transaction model), Actor Model (Akka), parallel collections, etc... Not to mention taking advantage of immutability, which can simplify concurrency a lot in some cases.

It's not a one-size-fits-all type of game here. So having one choice will essentially lock you into what you can do with it.

I also wouldn't say a Future, which is a Monad, a leaky abstraction. You don't really need to understand monads to use them, in fact, a lot of people use what are monads all the time, without knowing it.

A quite misleading title.

Couple days ago. During the summer, it's usually every weekend I stay at the dropzone without any laptops and I don't carry my phone around. I'm also outside for the whole weekend and I empty all my pockets to jump. There's planes to jump out of, people to talk, things to do, a breath of fresh air!

"poor type system" isn't too strong, it's just what it is.

There are many more areas where you simply cannot abort the process on any error that has been triggered. Erlang, being in the niche of network software, can get away with this because you can have mechanism that monitor the process and it's not the end of the world if one process goes down.

Imagine if your Browser crashed every time it hit an error, like a network connection issue, writing to a file, etc...! That just wouldn't be tolerated by consumers of the software.

> Imagine if even 5% or 10% of the 61,179 people who signed that petition instead organized rallies in their cities, or a kind of Leave The Internet Alone rally in DC.

Because the truth is that people generally don't care enough to do anything worth while ("signing" a petition is pretty minimal in terms of effort). There will always be the activists that are local to the cause who will do everything they can to fight, but everyone else, living their own lives, working, being parents, having hobbies or what have you have their own personal problems to take care of.

It's just routine. With the added regular news from the regular sources, who knows how manipulated they are, they're just so removed from what's actually going on. Not to mention, many people won't ask "What can the people do?" but "What can I do?" and their answer will be: "Nothing!"

We live in a world where people are told to live their lives, handle their business and the rest will be taken care of.

Maybe that's just common in Canada.

I don't like this situation, but this is what I'm seeing.

Type assertions happen during runtime, thus using reflections. There is no other way than to use reflections.

> It however does pass the type checking to run-time instead of compile-time

That's absolutely still loosing type safety. Reflections don't substitute type safety.

> Maybe it's because I've never felt the need to use generics and in all these articles the examples they give are functions of a few lines that would be quicker to write 2-3 times for different types than remembering generic syntax.

Uhmm, what? That seems entirely ignorant for ignoring an expressive concept and rather "do it the hard way". And, "remembering the generic syntax" is no different from remembering any other features' syntax, and I don't imagine you have issues remembering those, do you?

I'm assuming he meant why would they expose or promote the use of a construct that bypasses type safety in a statically typed language. Although `interface {}` is not some sort of special feature, it's still circumventing the type system.

Sum types are much more direct than other variants in a language that effectively implements them.

For example, in Rust, who's `enum`s are effectively sum types, we can take advantage of the type system while using channels that are well-typed.

https://github.com/servo/servo/blob/master/components/msg/co...

    pub enum Msg {
        ExitMsg,
        FailureMsg(Failure),
        InitLoadUrlMsg(Url),
        LoadCompleteMsg,
        FrameRectMsg(PipelineId, SubpageId, Rect<f32>),
        LoadUrlMsg(PipelineId, LoadData),
        ScriptLoadedURLInIFrameMsg(Url, PipelineId, SubpageId, IFrameSandboxState),
        NavigateMsg(NavigationDirection),
        PainterReadyMsg(PipelineId),
        ResizedWindowMsg(WindowSizeData),
        KeyEvent(Key, KeyState, KeyModifiers),
        /// Requests that the constellation inform the compositor of the title of the pipeline
        /// immediately.
        GetPipelineTitleMsg(PipelineId),
        /// Requests that the constellation inform the compositor of the a cursor change.
        SetCursorMsg(Cursor),
    }

Here we can define a sum type called `Msg` that has various variants. These are the only thing a channel constraint to that type can consume. Each destructing or pattern matching has to cover all possible cases, otherwise it's a compiler error.

This makes it effortless to have complex communication where the data is composed of multiple things, multiple types.

[1] Here's another example of a sum type being used as a messaging type in Servo. [2] Shows pattern matching on all variants and variants of variants, which produces well-typed code.

[1]: https://github.com/servo/servo/blob/master/components/net/re...

[2]: https://github.com/servo/servo/blob/master/components/net/re...

I probably use `enum`s pretty frequently, especially when working with channels. I don't use primitive types-based channels too often come to think of it.

While I'm not a Go programmer, the reason it should be a code smell is because you lose type safety and incur a run-time penalty cost for using reflections. Perhaps the things people build in Go will make the later point moot, but the former shouldn't.

Yes, escape analysis does tend to eliminate some unnecessary heap allocations but they're specifically isolated to a single subroutine (it's better than not having it). Whereas with Rust, you can safely pass around references to stack allocated memory to other subroutines, given proper lifetimes.

> Express is very very barebone and you wouldn't prototype with that or do anything quick with that

The point of the Node ecosystem is to be library-based. It's quite rare to have full-fledge frameworks dictate an environment like Rails does (and a method I personally hate). Go has the same principle afaik with it's web libraries.

I'd personally rather use a dynamic language rather than a statically-typed one with a weak type system. While the former can produce more errors at times, the later is often times just too inflexible and painful to use properly.

It's highly unlikely Go will be able to compete in terms of compiler optimizations because of it's goal of fast compilation speeds. The majority of the time Rust spends compiling code is within LLVM last time I checked, because LLVM does quite a bit of optimizations.

Then if you take into account the fact that Go's language features do not promote highly-performant code (GC, heap allocation, dynamic dispatching) that a few people in this thread has touched on.

While better looking code is highly subjective, Rust has indeed traded off some aesthetics for safety, performance, etc... However, that's not to say Rust code is ugly, you can certainly write very nice looking code in Rust.

> there could be bugs in unsafe code in the standard library

For any embedded work or kernels, you wouldn't be pulling in the standard library via a `#![no_std]` attribute.

But you're right that bugs in the compiler could produce safety issues.

The web ecosystem in Rust is still very early. There have been some awesome efforts recently in pushing a full-featured http library [0] (Hyper is now powering Servo [1]). The web ecosystem can't expand fully without a strong http library and previously, an unmaintained rust-http was used.

The next issue, if we're talking about high-performance http is asynchronous I/O which Rust doesn't currently bundle with (now that Rust has dismantled it's green threading runtime and is now sticking with native threading). However, mio [2], a lower-level Rust library in providing proper I/O abstractions that support async apis and the like is progressing pretty well.

The awesome part about Rust is that you have full control over the system. This allows one to build something like mio even though Rust doesn't support async I/O or a more efficient threading model, etc...

[0]: https://github.com/hyperium/hyper [1]: https://github.com/servo/servo/pull/4198 [2]: https://github.com/carllerche/mio

You could take advantage of having a single git repo for multiple cargo packages. This has worked extremely well for me. It was a lot easier having a single git repo to manage and control but still have separate packages for each of the different pieces. You could have the main package become the executable and have the core and various other packages in there, too.

After a while, the mental cost associated with Rust isn't that huge. Rust becomes a fairly productive language (even if it has some rough edges). I will say, however, that how you think of programming and structuring your application is very different from other languages. Especially when it comes to multi-threaded applications and how you deal with ownership and safety. But in the end, I think it pays off pretty well.

With proper tooling, one could automatically upgrade a 1.x Rust compatible codebase to be 2.0 compatible (if such a version ever exists in the future).

Google has had a Github account for a long time now. That doesn't mean they're moving all development over to Github for all Google projects. And the v8 project is moving to Google's Git infrastructure, not Github.

I don't know about them moving to Github, but the v8/v8 repo [0] (currently the svn mirror) has been deprecated and the git repo mirror will replace it in the near future [1]. That's the extend of them using Github as far as I know.

[0]: https://github.com/v8/v8

[1]: https://groups.google.com/forum/#!topic/v8-users/VgL3Fn4ijqE

> Macros are of course enormously useful but also very difficult to shoe horn into a c-family language properly since they need to be expanded at compile time (unless you just go ahead and embed you compiler backend into the runtime system of your language. That would be kinda of crazy/awesome but you could do it). Rust has of course proven the utility of such a choice.

Rust doesn't do that. Rust expands the macros at compile-time. Integrating the whole compiler into the runtime wouldn't make much sense considering what area Rust is targeting.

It's also recommended to not link a crate that is used during runtime with the compiler or parser because they're fairly big and would bloat your final build by a large amount.

Unlike other languages that are "done" at 1.0, Rust will still be improving and iterating. 1.0 defines a backwards-compatible release that you can depend on but the language won't be "done".

"It’s important to be clear about what we mean by stable. We don’t mean that Rust will stop evolving. We will release new versions of Rust on a regular, frequent basis, and we hope that people will upgrade just as regularly. But for that to happen, those upgrades need to be painless." [0]

[0]: http://blog.rust-lang.org/2014/10/30/Stability.html

I've had a really good experience using that library in Rust. It just works without much code or hassle.

Syntax extensions and the compiler internals are most likely not going to be stabilized for a while. Committing to a stable compiler core is a serious effort.

Algebraic effects system.

I have an RFC sitting here (and a few blog posts talking about it), but considering it'll be post 1.0 when such a thing is even entertained, I haven't submitted it. There are more pressing and more appropriate things to work on first.