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

D for the Win

tomerfiliba.com

Post reply on HN
Print view View original

71–80 of 105 posts

Re: D for the Win

#71

Post by klibertp »

pjmlp wrote: post #66
skizm wrote: post #38

Python a D have totally different use cases. Just because you can do something with Python doesn't mean you should.

Tell that to all those guys writing desktop utilities in Python slow as molasses. Every time I get some GNU/Linux GUI utility running very very slow and check the code, it is Python under the hood.

On the other hand, every time I start a program and have to wait tens and hundreds of seconds for it to finally fully load, it's invariable written in C, C++ or Java...

Now I could start bashing Java and the others, but I hope I don't need to and that you already realized that your comment is a bit unfair.

Re: D for the Win

#72

Post by kolev »

cnbuff410 wrote: post #65
kolev wrote: post #62

I definitely agree that D is better from many and all the hype of the day gos to Go, not D. I really have issues with the Go syntax though - it's really not intuitive, some things are just made different just for the sake of being different, syntax is all over the place. I think Rust is way more elegant, unfortunately, it doesn't get as much hype as it deserves compared to Go.

What makes Go's syntax that unintuitive to you? Go's syntax is really easy to most programmers who is willing to learn. It's probably just 1 days work to pick it up. It's very similar to Swift's syntax in many aspects, and I don't hear anyone complaining Swift's syntax is not intuitive and just for the sake of being different. Perhaps instead of just claiming you can give us some examples on "syntax is all over the p…

Please, don't compare Swift to Go! Swift is as elegant as D is, but not multi-platform yet, so, it's a "no go" for now.

Re: D for the Win

#73

Post by kolev »

klibertp wrote: post #69
cnbuff410 wrote: post #65

Earlier quoted context omitted.

What makes Go's syntax that unintuitive to you? Go's syntax is really easy to most programmers who is willing to learn. It's probably just 1 days work to pick it up. It's very similar to Swift's syntax in many aspects, and I don't hear anyone complaining Swift's syntax is not intuitive and just for the sake of being different. Perhaps instead of just claiming you can give us some examples on "syntax is all over the p…

> syntax is really easy to most programmers who is willing to learn This is exactly how this sentence should look like, no need for any language at the beginning. While syntax does matter (and I only recently arrived at this conclusion) its "intuitiveness" or "similarity" is utterly unimportant. You either are a "real programmer" and have no problem picking up different syntaxes and semantics, or you're not. That's a…

It is important - we're not just robots doing work to eat and have where to live, we need to enjoy what we do and having pleasant syntax is what made many fall in love with Ruby. Let's not pretend syntax doesn't matter - it does, indeed, otherwise there wouldn't be Scala today either!

Re: D for the Win

#74

Post by p0nce »

4ad wrote: post #68
p0nce wrote: post #53

Earlier quoted context omitted.

Can you give a code example in Go?

http://play.golang.org/p/Vl9XzK3hOS

Interesting but this is not the same feature. Go implements what seems like multiple inheritance, D simply dispatch calls to a member, which can be a pointer to T instead of T. So you can implement custom pointer types.

Re: D for the Win

#75

Post by kolev »

fleitz wrote: post #67
cnbuff410 wrote: post #65

Earlier quoted context omitted.

What makes Go's syntax that unintuitive to you? Go's syntax is really easy to most programmers who is willing to learn. It's probably just 1 days work to pick it up. It's very similar to Swift's syntax in many aspects, and I don't hear anyone complaining Swift's syntax is not intuitive and just for the sake of being different. Perhaps instead of just claiming you can give us some examples on "syntax is all over the p…

I think the reason swift gets away with it is because it borrows enough from a language you already know that the rest feels like an addition. (eg. Python + that, C# plus this, OCaml + brackets, c++ plus ARC, ObjC minus square brackets) Also, swift has an API that's familiar to ObjC devs which means it's just changing brackets. It's pretty easy to port a ObjC program to swift line by line.

Working with something familiar is always a good thing. Having something intuitive is a great pleasure for your soul - you memorize generic principles, not specific constructs. I like in rust that they really put abbreviation all across the board consistently. If they use "fn" as a keyword, also system lib is abbreviated similarly "to the max". I don't have to remember is it "string" or "str" - Rust consistency saves time and makes it obvious.

Re: D for the Win

#76

Post by tdees40 »

saosebastiao wrote: post #70

Why did Walter choose to not open source the compiler from the beginning? I would be willing to bet that it would hold the position that Ruby/Python currently hold if he had made that choice. The ability to apt-get/yum to install a language on a cheap linux server would have done wonders for its adoption, especially in the middle of the rise of linux and the web.

I feel like D's lack of adoption was mostly due to issues around the way things transpired, specifically the closed-source compiler and of course the big mess with the standard library. Otherwise it was well-placed and well-timed, just ill-executed.

Re: D for the Win

#77

Post by valarauca1 »

waps wrote: post #63
valarauca1 wrote: post #50

Earlier quoted context omitted.

Slightly unrelated, but this confused me. >1139 (each of which causes a program reschedule) I thought system calls were packaged into the binary itself and didn't necessarily cause a job to re-schedule. But just caused a context switch to take place, then execution continues. I thought re-scheduling only happened on interrupt, or a thread reaching a blocked stated. Could you clarify this for me, I'm interested.

Technically they cause a context-switch and a scheduler run upon return (I belive, not 100% sure), but you're right that does not necessarily result in getting put on the back of the work queue.

I think what might be the case is often so many system calls result in blocking events (I/O, IPC, etc.), its safe to assume a system call will block.

Re: D for the Win

#78

Post by andralex »

saosebastiao wrote: post #70

Why did Walter choose to not open source the compiler from the beginning? I would be willing to bet that it would hold the position that Ruby/Python currently hold if he had made that choice. The ability to apt-get/yum to install a language on a cheap linux server would have done wonders for its adoption, especially in the middle of the rise of linux and the web.

I think it's a good point. I can't speak for Walter, but I can say I've fostered openness ever since joining D development and we're both glad things are now in the right place.

Re: D for the Win

#79

Post by eco »

saosebastiao wrote: post #70

Why did Walter choose to not open source the compiler from the beginning? I would be willing to bet that it would hold the position that Ruby/Python currently hold if he had made that choice. The ability to apt-get/yum to install a language on a cheap linux server would have done wonders for its adoption, especially in the middle of the rise of linux and the web.

Perhaps that would have helped with adoption. I'm not all that convinced that would have really tipped the scales. It's been 5 years since it was open sourced and there have been over a hundred contributors but it's still only fairly recently gotten to the point where development is more about mundane bug fixes instead of implementing huge, unfinished parts of the language and blocker bugs that make the language hard to use. Open sourcing sooner would have given it a head start but even then, I don't think D would have been ready for heavy use in the middle of the rise of linux and the web.

Here's what Walter said at the time when asked why it took so long:

  I've been intending to for a while, it took a while for me
  to clean it up, check all the licenses, and get it into a 
  presentable form.
  
  Essentially, it's pretty obvious that the world has changed, 
  and closed source is no longer acceptable for a mainstream 
  product that people will be relying on. Open source is the 
  future, and it's past time for dmd to join the party!

Re: D for the Win

#80

Post by andralex »

rakoo wrote: post #64
tomwilde wrote: post #7

Earlier quoted context omitted.

Those properties are not mutually exclusive.

The important distinction here is that go creators never set "system programming" as a goal, contrary to what OP implied in the blog post. Now, whether go turns out to be good at that task is another story

Go has been announced as a systems programming language: https://www.youtube.com/watch?v=rKnDgT73v8s. After some backlash the slogan has been changed quietly.
Post reply on HN