Live data from Hacker News

D as a Better C

dlang.org

161–170 of 193 posts

Re: D as a Better C

#161
post #114

Earlier quoted context omitted.

Javascript is also high-level interpreted language, but it's much faster than Python. Python is pretty hard to optimize in a JIT (and it gets much less attention than Javascript).

True, but it's also miles behind C/C++. While Python is arguably the slowest of the mainstream interpreted language, they're all orders of magnitude slower than C.

Hmmm. I kind of expect them to be 1 or 2x slower. Maybe even a single order of magnitude... But Python seems often to be 100 or 1000x slower. For my applications this is kind of unfortunate.

Re: D as a Better C

#162
post #115
post #102

Earlier quoted context omitted.

Since it's already brought up in this thread, I recently had (another) look at nim and was a little disappointed too. It's been a while, but as I recall, on Windows - it was difficult to find a supported way to output Unicode on the console in a sane, portable way (write utf8 nim source code, get wide strings in Windows console and utf8 under eg Linux) - and I think I also had some problems getting off the ground wit…

Indeed there are some bugs with unicode output[1]. Just to be clear the standard way to output anything to the console is `echo` (similar to Python's `print`). It seems that the progress on that issue has stalled. It's unfortunate but we do have limited man-power and rely on the community to help us out, this does mean that at this stage it helps if you don't mind getting your hands dirty with potential bugs. Unless…

As I'm now on my laptop with access to the two simple programs; for text output:

  import encodings
  var hello1 = convert("Hellø, wørld!", "850", "UTF-8")

  # Doesn't work - seems to think current codepage is utf8.
  var hello2 = convert("Hellø, wørld!", getCurrentEncoding(), "UTF-8")

  # Outputs correct text:
  echo hello1
  # Outputs corrupted text:
  echo hello2
(And simply outputting an unconverted string fails, like hello2 does).

As for the linking problem I had, the main issue is that it seems to be harder than it probably should, to get started with the GUI-programming with nim on windows. The following code works, provided one manually obtains sdl2.dll (and sdl2.lib for static linking) - however, even with static linking flags (no errors), the resulting exe still depends on the presence of sdl2.dll:

  import nimx.window
  import nimx.text_field
  import nimx.system_logger

  proc startApp() =
    var window = newWindow(newRect(40, 40, 800, 600))
    let label = newLabel(newRect(20, 20, 150, 20))
    label.text = "Hellø, wørld!"
    window.addSubview(label)

  runApplication:
    startApp()
With sdl2.dll (and .lib) in the same folder both of these work:

nim --threads:on --dynlibOverride:SDL2 --passL:SDL2.lib c -r win.nim

nim --threads:on c -r win.nim

but both fail without sdl2.dll present (ie: the "statically" linked exe still depends on dynamically loading sdl2.dll).

And there's so far no easy way of getting a "supported" sdl2.dll to go with the nim compiler - as far as I can tell, neither "nimble install sdl2" or "nimble install nimx" provide a way to get the sdl2.dll and/or C source code to compile it.

But perhaps managing DLLs and such is considered to be out-of-scope for nimble/nim package manager for now.

Re: D as a Better C

#163
post #159

Earlier quoted context omitted.

It's not really Nim's fault that cmd.exe has crap Unicode support.

If you have an "echo" primitive/function, and "out of the box unicode support", then respecting the host OS codepage/output encoding by default is the sane thing to do (as indicated in the bug linked by the sibling comment ("just use the win32 api"). It's not that nim can't output wide characters from a utf8 source, it's just that it's not obvious how to do it in a standard way - one might thing that utf8 unicode "he…

Nim is not a Win32 runtime. It outputs strings to stdout. Any sane OS would do the right thing in 2017.

Re: D as a Better C

#164
post #112

Now we need another flag to enable a better Java mode. By default D is in better C++ mode.

How about betterC# instead? Given that C++/CLR is a thing, I imagine that it would be possible to get D working on it. JVM is a bit more limited in what it allows vs. CLR. For instance, C# has the unsafe keyword that allows pointer arithmetic, which would correspond to @system in D. @safe D would correspond to the normal C# behavior on that front. Probably a lot of work though and I'm not sure why anybody would bothe…

Microsoft is.

That is why .NET Native and CoreRT exist.

.NET 4.6 got a few news ways to control when the GC is allowed to run.

Also C# got its reference types improved on version 7, and the roadmap up to 8.0 includes a few more goodies, like spans.

Re: D as a Better C

#165
post #6
post #3

Earlier quoted context omitted.

The better Python market isn't an easy one to crack because its a bit crowded. Go (despite its perceived and real faults) has succeeded in this space by delivering better GC, good libraries, static typing and faster programs. Python itself is improving rapidly, for example with the addition of Type Hints. Its pretty difficult to be a better Python in 2017. The better C market, on the other hand, hasn't seen any real…

I really really don't been to pile on Python... but every time I've had to interact with it I've been shocked at how slow it is compared with C or C++. I tend to write scientific code to process datasets in the range on 10Gb, for simple operations Python code can take hours as opposed to just taking minutes or seconds in C. I'm sure it's possible to write more highly optimized code in Python, but it never seems to be…

What everyone in this subthread is looking for is LuaJIT. It's the fastest JITed language. Comparable to C for many tasks. It has a very tiny memory footprint and integrates into C and C++ well. And there's torch if you need to do fast matrix math or machine learning.

Re: D as a Better C

#166
post #31

Earlier quoted context omitted.

Idk about the editor integration problem, but usually when I run into the 'auto' problem what helps me is printing out the type as follows: typeof(var).stringof.writeln;

You can also emit the type during compilation, rather than at runtime: pragma(msg, "var has type: ", typeof(var));

You can also emit the type as a compile error by assigning it to a list or something. A trick I often used when studying C++ back when it was cool.

Re: D as a Better C

#167
post #32

Earlier quoted context omitted.

Have you looked at Rust? It uses Option types, has generics, also uses return values for error handling but has a lot more syntactic sugar to make it cleaner than in Go.

I have tried Rust in the past, though not on this particular hobby project (my Clojure interpreter). I found it hard to get into, and I've gotten into a lot of languages in my time-- some of which are considered challenging (e.g. Haskell). With Rust, I always felt I spent too much time wrestling with it, and not enough time being productive. I imagine that you hit a threshold at some point and that begins to change.…

Rust's documentation is very well written. The authors have put in great effort to make things clear.

Granted Rust has some paradigms and constructs which are not easy to learn, I found it rather exciting. I think it has future scope.

Wonder whats happening with Redox. I hope Rust adds more libraries, especially network related, since the networked world is increasingly looking like a distributed OS of sort. Browsers are looking like an OS or a shell inside the OS. Browsers are getting more complex with more functionalities added every few months. Not sure I expressed my thoughts correctly, but I guess one can understand what I mean.

Rust should move away from C standard library, if possible.

Re: D as a Better C

#168
post #126

Earlier quoted context omitted.

I am in a similar situation, as I develop a lot of scientific code. I've tested several solutions, and so far the most viable for me (though far from perfect) is Python+NumPy+Fortran, the latter exposed to Python using f2py (much easier than binding C/C++ to Python). Not sure if this might be a good solution for you, it depends whether the bottleneck in your code is in I/O or in raw calculations (in the former case y…

Julia could have had 10x the adoption if they painted themselves as more of a general purpose language, like "write the web app and your neural networks (GPU accelerable bien sur) in the same language ftw!"... if only they'd have bolted in some support for "non-weird-looking classic OOP" like in "wanna type `window.` and have even the most retarded editor autocomplete methods". Imho they got it backwards: Python got…

They're going after Matlab, Octave and R rather than Python.

Re: D as a Better C

#170
post #159

Earlier quoted context omitted.

If you have an "echo" primitive/function, and "out of the box unicode support", then respecting the host OS codepage/output encoding by default is the sane thing to do (as indicated in the bug linked by the sibling comment ("just use the win32 api"). It's not that nim can't output wide characters from a utf8 source, it's just that it's not obvious how to do it in a standard way - one might thing that utf8 unicode "he…

Nim is not a Win32 runtime. It outputs strings to stdout. Any sane OS would do the right thing in 2017.

I'm not sure how there can be "one true sane thing". There's more to strings than Unicode, and more to Unicode than utf8. In fact the os does pretty sane here - not checking for utf16 or utf32 isn't really great on Linux either (haven't checked how/if nim handles locales on Linux). Afaik, eg python3 does the right thing on Windows and Linux w/print(). It's just one of the many little things were one may whish for "one, simple, sane way" - but have to deal with the realities.

Same goes for things like handling paths, line endings for text files, resource forks (or not) for files, changing file meta-data...

Post reply on HN